The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Himanshu Chauhan <hschauhan@nulltrace.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [PATCH] hwmon class driver registration with a device number
Date: Thu, 6 Oct 2011 08:15:26 -0700	[thread overview]
Message-ID: <1317914126.3983.55.camel@groeck-laptop> (raw)
In-Reply-To: <20111006094302.71ea4dfd@endymion.delvare>

On Thu, 2011-10-06 at 03:43 -0400, Jean Delvare wrote:
> I am purposely removing kernelnewbies from the CC list, as it seems
> quite irrelevant for this discussion.
> 
> On Wed, 5 Oct 2011 22:19:55 -0700, Guenter Roeck wrote:
> > On Thu, Oct 06, 2011 at 12:06:59AM -0400, Himanshu Chauhan wrote:
> > > Hi,
> > > 
> > > > I can not comment on the merits of your patch. Unless I am missing
> > > > something, which may well be since I only spent a couple of minutes on
> > > > it, other device classes don't seem to provide a similar API, so I don't
> > > > know if or why it would make sense for hwmon. Maybe a driver which wants
> > > > to register a character device interface should do so independently of
> > > > hwmon.
> > > > 
> > > 
> > > The idea here is to sit in the same class directory as of hwmon. Devices
> > > registered with this interface will have "dev" under, for example,
> > > /sys/class/hwmon/hwmon0/dev. To do the same inside the driver will be
> > > a bit more involved than a call.
> > > 
> > > In my opinion other classes should also have similar interfaces.
> > > 
> > I think you'll have to spend some more time and effort explaining the "what for".
> > 
> > Apparently no other device class needs this functionality so far, yet you
> > suggest that such an interface should exist for all device classes.
> 
> Actually a lot of class devices do have a device node:
> $ ls -1 /sys/class/*/*/dev | wc -l
> 252
> This includes block, drm, dvb, input, msr, sound and tty class devices,
> to name just a few. But this isn't the problem. All these are

I meant instances where the major/minor device number is passed to the
class registration function.

Having said that, I realize there are instances where the _minor_ device
number is passed to the class registration function (eg for misc
devices). In that case, though, misc_register() checks if the asked for
minor device already exists, and retains the option to generate a
dynamic minor device. This is different here, where the proposal is to
pass both major and minor device number to the registration function.

Maybe there are instances where both major and minor device number are
passed; as I mentioned before, I did not spend that much time on it. But
you are right - that isn't the point anyway.

Guenter



  parent reply	other threads:[~2011-10-06 15:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05 17:13 [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-05 18:30 ` Guenter Roeck
2011-10-06  4:06   ` Himanshu Chauhan
2011-10-06  5:19     ` Guenter Roeck
2011-10-06  7:43       ` [lm-sensors] " Jean Delvare
2011-10-06 15:12         ` Himanshu Chauhan
2011-10-06 15:46           ` Alan Cox
2011-10-06 16:25             ` Himanshu Chauhan
2011-10-06 15:15         ` Guenter Roeck [this message]
2011-10-06 16:43           ` Himanshu Chauhan
2011-10-05 19:33 ` Greg KH
2011-10-06  4:10   ` Himanshu Chauhan
2011-10-06 18:25     ` Greg KH
2011-10-06 19:07       ` [lm-sensors] " Guenter Roeck
2011-10-07  6:42         ` Himanshu Chauhan
2011-10-07  6:52           ` Greg KH
2011-10-07  9:56             ` Himanshu Chauhan
2011-10-07 11:11               ` Jonathan Cameron
2011-10-07 15:46               ` Greg KH

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=1317914126.3983.55.camel@groeck-laptop \
    --to=guenter.roeck@ericsson.com \
    --cc=hschauhan@nulltrace.org \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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