Strategies for accessing driver data from file operations!?

Daniel Hilst Selli danielhilst at gmail.com
Wed Aug 13 08:46:51 EDT 2014


On 08/12/2014 04:53 PM, Greg KH wrote:
> 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
>
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())?




More information about the Kernelnewbies mailing list