kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
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())?

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).