use of dev->dev_t

use of dev->dev_t

[Malte Vesper]

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.

Is this the intended behaviour and if so why? (This means I have to 
store the minor separatly to call device_destroy())

Thanks
Malte

FYI: I am running a 3.19.0 Kernel

use of dev->dev_t

[Greg KH]

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

use of dev->dev_t

[Malte Vesper]

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().

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.

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?
Is there an elegant way to get back at the MINOR() without storing it 
i.e. in the private data field (pci_set_drvdata).

Thanks,
Malte

use of dev->dev_t

[Greg KH]

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 :)

> 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 :)

> 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.

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.

thanks,

greg k-h

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