From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: use of dev->dev_t
Date: Tue, 17 Mar 2015 22:53:26 +0100 [thread overview]
Message-ID: <20150317215326.GA22301@kroah.com> (raw)
In-Reply-To: <5508A0A5.2060806@postgrad.manchester.ac.uk>
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
next prev parent reply other threads:[~2015-03-17 21:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 20:43 use of dev->dev_t Malte Vesper
2015-03-17 21:13 ` Greg KH
2015-03-17 21:46 ` Malte Vesper
2015-03-17 21:53 ` Greg KH [this message]
2015-03-17 22:25 ` Malte Vesper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150317215326.GA22301@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).