Strategies for accessing driver data from file operations!?

[Greg KH]

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