From: danielhilst@gmail.com (Daniel Hilst Selli)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Strategies for accessing driver data from file operations!?
Date: Wed, 13 Aug 2014 09:46:51 -0300 [thread overview]
Message-ID: <53EB5E3B.20508@gmail.com> (raw)
In-Reply-To: <20140812195328.GA20273@kroah.com>
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())?
next prev parent reply other threads:[~2014-08-13 12:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 13:47 Strategies for accessing driver data from file operations!? Daniel Hilst Selli
2014-08-12 19:53 ` Greg KH
2014-08-13 12:46 ` Daniel Hilst Selli [this message]
2014-08-13 21:40 ` Greg KH
2014-08-25 18:34 ` Daniel Hilst Selli
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=53EB5E3B.20508@gmail.com \
--to=danielhilst@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.