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?

Quoted 23 lines · Daniel Hilst Selli

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,

Quoted 8 lines

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

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

Quoted 2 lines · Daniel Hilst Selli

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