Strategies for accessing driver data from file operations!?

I was writing an spi driver, and taking a look into spidev.c, I see the the author
allocates a linked list to hold driver data instances. From open it iterates over
the list comparing two dev_t fields, one from current element on list other from
struct inode * parameter, here is the lines:

static int spidev_open(struct inode *inode, struct file *filp)
{
         struct spidev_data      *spidev;
         int                     status = -ENXIO;

         mutex_lock(&device_list_lock);

         list_for_each_entry(spidev, &device_list, device_entry) {
                 if (spidev->devt == inode->i_rdev) {
                         status = 0;
                         break;
                 }
         }
...

Now it set the filp->private data to its driver data, and on read and write file
operations he knows how to access is driver data,

I was looking for a simpler strategy, on my module I would have same devices on
distinct spi busses and chipselects, but it wouldn't go greater than 9 devices.

I need to access spi_device struct pointer for the right device from read and
write file operations.

Isn't there any path from struct file *filp to struct device *devp created
with device_create? I can't see it, but if is possible I can set device private
data from my probe function.

Cheers,

On Tue, Aug 12, 2014 at 10:47:20AM -0300, Daniel Hilst Selli wrote:

I was writing an spi driver, and taking a look into spidev.c, I see the the author
allocates a linked list to hold driver data instances. From open it iterates over
the list comparing two dev_t fields, one from current element on list other from
struct inode * parameter, here is the lines:

static int spidev_open(struct inode *inode, struct file *filp)
{
         struct spidev_data      *spidev;
         int                     status = -ENXIO;

         mutex_lock(&device_list_lock);

         list_for_each_entry(spidev, &device_list, device_entry) {
                 if (spidev->devt == inode->i_rdev) {
                         status = 0;
                         break;
                 }
         }
...

Now it set the filp->private data to its driver data, and on read and write file
operations he knows how to access is driver data,

I was looking for a simpler strategy, on my module I would have same devices on
distinct spi busses and chipselects, but it wouldn't go greater than 9 devices.

I need to access spi_device struct pointer for the right device from read and
write file operations.

Isn't there any path from struct file *filp to struct device *devp created
with device_create?

No, a struct device does not have a set of file operations to tie it
together, so there isn't a way to do this, sorry.  If you pass a dev_t to
device_create() you are telling userspace the dev_t that you want
associated with this struct device, but you had better have already set
up that dev_t with a call to the proper block or char creation call
first.

It's a bit ackward, but as very few people should be creating their own
special character devices these days, it shouldn't be that big of an
issue.

And yes, the character device creation interface is crazy, and rough,
and it's been on my list of things to fix up "properly" for a decade or
so, sorry, never had the chance to actually get to it...

Hope this helps,

greg k-h

On 08/12/2014 04:53 PM, Greg KH wrote:

On Tue, Aug 12, 2014 at 10:47:20AM -0300, Daniel Hilst Selli wrote:

quoted

I was writing an spi driver, and taking a look into spidev.c, I see the the author
allocates a linked list to hold driver data instances. From open it iterates over
the list comparing two dev_t fields, one from current element on list other from
struct inode * parameter, here is the lines:

static int spidev_open(struct inode *inode, struct file *filp)
{
          struct spidev_data      *spidev;
          int                     status = -ENXIO;

          mutex_lock(&device_list_lock);

          list_for_each_entry(spidev, &device_list, device_entry) {
                  if (spidev->devt == inode->i_rdev) {
                          status = 0;
                          break;
                  }
          }
...

Now it set the filp->private data to its driver data, and on read and write file
operations he knows how to access is driver data,

I was looking for a simpler strategy, on my module I would have same devices on
distinct spi busses and chipselects, but it wouldn't go greater than 9 devices.

I need to access spi_device struct pointer for the right device from read and
write file operations.

Isn't there any path from struct file *filp to struct device *devp created
with device_create?

No, a struct device does not have a set of file operations to tie it
together, so there isn't a way to do this, sorry.  If you pass a dev_t to
device_create() you are telling userspace the dev_t that you want
associated with this struct device, but you had better have already set
up that dev_t with a call to the proper block or char creation call
first.

It's a bit ackward, but as very few people should be creating their own
special character devices these days, it shouldn't be that big of an
issue.

And yes, the character device creation interface is crazy, and rough,
and it's been on my list of things to fix up "properly" for a decade or
so, sorry, never had the chance to actually get to it...

Hope this helps,

greg k-h

Thank you very much Greg,

One last question, supposing I need to create multiple /dev nodes, do I need to
allocate one struct cdev for each major:minor pair (cdev_alloc(), cdev_init(), cdev_add())?

On Wed, Aug 13, 2014 at 09:46:51AM -0300, Daniel Hilst Selli wrote:

One last question, supposing I need to create multiple /dev nodes, do I need to
allocate one struct cdev for each major:minor pair (cdev_alloc(), cdev_init(), cdev_add())?

No, you can allocate multiple minor numbers with a single set of cdev
calls.  But watch out, you also need to create a 'struct device' for
_each_ minor number you are actually using if you want the device nodes
to show up in /dev automatically.

Yeah, it's a pain, sorry, but this way you can allocate a whole range of
major:minor pairs but don't actually expose them to userspace until you
really need them (i.e. the hardware is present in the system.)  This
keeps /dev looking like only the devices that are present in the system,
not the "old" way of "every possible device that could ever be possibly
present".

Hope this helps,

greg k-h

On 08/13/2014 06:40 PM, Greg KH wrote:

On Wed, Aug 13, 2014 at 09:46:51AM -0300, Daniel Hilst Selli wrote:

quoted

One last question, supposing I need to create multiple /dev nodes, do I need to
allocate one struct cdev for each major:minor pair (cdev_alloc(), cdev_init(), cdev_add())?

No, you can allocate multiple minor numbers with a single set of cdev
calls.  But watch out, you also need to create a 'struct device' for
_each_ minor number you are actually using if you want the device nodes
to show up in /dev automatically.

Yeah, it's a pain, sorry, but this way you can allocate a whole range of
major:minor pairs but don't actually expose them to userspace until you
really need them (i.e. the hardware is present in the system.)  This
keeps /dev looking like only the devices that are present in the system,
not the "old" way of "every possible device that could ever be possibly
present".

Hope this helps,

greg k-h

It help-me alot Greg, thanks.. At last I know I'm doing in the right way :)

Cheers,