use of dev->dev_t

[Malte Vesper]

On 17/03/15 21:53, Greg KH wrote:
> On Tue, Mar 17, 2015 at 09:46:13PM +0000, Malte Vesper wrote:
>>
>> On 17/03/15 21:13, Greg KH wrote:
>>> On Tue, Mar 17, 2015 at 08:43:38PM +0000, Malte Vesper wrote:
>>>> Hi,
>>>> I am trying to write a driver that uses the MINOR(dev_t) to identify
>>>> cards. Since it is a PCI driver and I get pcidev->dev.dev_t anyway. I
>>>> thought about not bothering to store the minor number of the device.
>>>> However if I look at pcidev->dev.dev_t in the remove function (the
>>>> driver frameworks remove), I always get pcidev->dev.dev_t == 0.
>>> That dev_t is not for your use, sorry, it is for the driver core to use,
>>> if it needs/wants to for a class device.  A PCI driver should never need
>>> to be a char device, but if it does, you have to make your own calls to
>>> the character device core.
>>>
>>> What type of PCI device is this?  Why do you want to have a character
>>> device node for it?
>>>
>>> thanks,
>>>
>>> greg k-h
>> I want to do stream processing with a FPGA. I hoped that I could read the
>> minor from that field after calling device_create().
> Yes, you can, but that's not what your pci device uses, you have to
> create your own device to be able to use that.  And your driver should
> never need/care about what the minor number really is if you write it
> correctly :)
I only care about the minor to call device_destroy.
Also I thought it would be a nice way to ID the actual instance of the 
device (I want to support multiple FPGAs, and figured I get the minor 
from IOCTL calls for free).
If there is a driver that has a good way of doing it a pointer would 
help so I could look at the code.
>
>> As for the streaming bit the intended mode of operation is send a chunk,
>> receive a processed chunk. Since the FPGA might do filtering the result
>> might be smaller.
>> Also there is no random access, and once a bit of the returned data has been
>> read, it can not be read again. The FPGA is more or less passthrough with
>> some FIFO buffers.
> Then why not just use the firmware interface for this instead?
>
>> This use model and other examples (there are a few PCIe FPGA drivers out
>> there which do char device (i.e. Riffa)), led me to pick a char device.
>> Either way, the actual data transfer is handled solely by the device acting
>> as a bus master (DMA).
>>
>> Would you still recommend a block device driver type?
> Firmware :)
 From a quick google glance and my understanding of firmware I 
understand the firmware interface as "Load this program on the devices 
microcontroller".
The usage model I envision is more like: FPGA implements filter: Returns 
all entries from a list which have a key greater threshold. So I need to 
tell the driver 1) get list from memory here 2) put result in memory at 
location 2.
If firmware is still better and I missunderstand it I will further read 
up on it. (That would be one of the cases where one needs to know which 
parts of the fine "manual" are relevant)
>
>> Is there an elegant way to get back at the MINOR() without storing it i.e.
>> in the private data field (pci_set_drvdata).
> Why do you need to know the minor?  And again, please keep your pci
> device separate from anything that you try to create.  You don't own the
> lifecycle of the pci device, the pci core does.
I feel I fail to grasp the meaning of this with my limited insight. I 
figured that the PCI core would ensure that remove is called (after all 
I suppy it a struct pci_driver, so that I can define the add/remove work 
needed). Why is it wrong to try (well it does not work, but I can't 
quite see why it should be 0 after calling device_create succesfully):

static void remove(struct pci_dev *pcidev) {
     ...
     device_destroy(FPCI3.class, pcidev->dev.devt);
     ...
}

I understand (from your earlier mail) that the pci framework does not 
touch pcidev->dev.devt, since it uses its own identifier.
>
> Also, there's a long-standing discussion of a "real" fpga kernel
> interface on the linux-kernel mailing list.  I suggest reading the
> archives for it, and joining if you want to help create something that
> works for your card.
I will have a look. Thanks for the pointer and insights,
Malte
>
> thanks,
>
> greg k-h