kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: confused by char dev registration in a gpio driver
Date: Tue, 3 May 2011 15:06:00 -0700	[thread overview]
Message-ID: <20110503220600.GD14080@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1105031714430.13946@localhost6.localdomain6>

On Tue, May 03, 2011 at 05:21:11PM -0400, Robert P. J. Day wrote:
> 
>   i'm sure i'm going to embarrass myself here but i was perusing the
> char drivers for nice examples, and i ran across this excerpt in
> pc8736x_gpio.c:
> 
> ===== begin =====
> 
>         if (major) {
>                 devid = MKDEV(major, 0);
>                 rc = register_chrdev_region(devid, PC8736X_GPIO_CT, DEVNAME);
>         } else {
>                 rc = alloc_chrdev_region(&devid, 0, PC8736X_GPIO_CT, DEVNAME);
>                 major = MAJOR(devid);
>         }
> 
>         if (rc < 0) {
>                 dev_err(&pdev->dev, "register-chrdev failed: %d\n", rc);
>                 goto undo_request_region;
>         }
>         if (!major) {
>                 major = rc;
>                 dev_dbg(&pdev->dev, "got dynamic major %d\n", major);
>         }
> 
> ===== end =====
> 
>   i'm good with most of that -- if the (parameter) major is explicit,
> then a dev_t of "devid" is created and register_chrdev_region() is
> used.
> 
>   on the other hand, if major is zero, then alloc_chrdev_region() is
> used for *dynamic* allocation of the major number.  in both cases, the
> return code "rc" is saved and, if it's < 0, we have an error.  and
> that's where the confusion comes in.
> 
>   i always thought both of those routines returned a simple zero to
> indicate success.  but look at those last few lines -- that return
> code is assigned to "major", at which point it's *that* value that's
> printed.  wouldn't that just be zero all the time?
> 
>   and wouldn't it also print that this was a "dynamic" major even if
> the user specified an explicit major number at load time?  this second
> point is more nitpicky, but what about that first point?  wouldn't a
> successful registration always print an allocated major number of
> zero?

I think you are right in that this code is wrong.

The chardev stuff is a mess, I keep meaning for years to clean it up.
Any proposals on a sane interface for this stuff is greatly appreciated.

thanks,

greg k-h

  reply	other threads:[~2011-05-03 22:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-03 21:21 confused by char dev registration in a gpio driver Robert P. J. Day
2011-05-03 22:06 ` Greg KH [this message]
2011-05-10 17:26   ` Jim Cromie
2011-05-10 18:40     ` Greg KH
2011-05-13 17:05       ` Jim Cromie
2011-05-13 19:05         ` Greg KH
2011-05-09 19:54 ` Jim Cromie

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=20110503220600.GD14080@kroah.com \
    --to=greg@kroah.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).