All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Re: [PATCH 2.6.12-rc5-mm1 3/3] i2c: modify sensors
Date: Fri, 03 Jun 2005 06:47:57 +0000	[thread overview]
Message-ID: <20050603045739.GB28055@kroah.com> (raw)
In-Reply-To: <20050602033727.GD4906@jupiter.solarsys.private>

On Fri, Jun 03, 2005 at 12:00:07AM -0400, Mark M. Hoffman wrote:
> Hi Greg:
> 
> * Greg KH <greg@kroah.com> [2005-06-01 23:13:06 -0700]:
> > On Wed, Jun 01, 2005 at 11:37:27PM -0400, Mark M. Hoffman wrote:
> > > @@ -37,6 +39,8 @@ static unsigned int normal_isa[] = { I2C
> > >  /* Insmod parameters */
> > >  SENSORS_INSMOD_8(adm1021, adm1023, max1617, max1617a, thmc10, lm84, gl523sm, mc1066);
> > >  
> > > +static int id;	/* increment once for every chip found */
> > > +
> > 
> > You duplicate this logic in every driver.  Is it really needed?  How
> > about having the "bus id" be unique for all hwmon devices?  That way, no
> > id varible is needed, and just the name of the device.  Then, in the
> > hwmon core, you add the unique number to the front of the name.
> > Something like:
> > 	01-adm1021
> > 	02-adm1025
> > and so on.
> > 
> > Any thoughts?
> 
> Yeah, that looks reasonable [1].  Ultimately, libsensors isn't going to care
> about that name; it will grab all the info it needs through the device link.
> It also renders the first patch in the set unnecessary - you can apply that
> seperately if you want it at all.

Well, things are in a quilt tree, so it's quite easy to drop any one
patch if needed.  I'll keep it around for a while, it's a nice function
to have :)

> Again, hold up on sending through to -mm and I'll fix this up.

Heh, the fun thing about -mm release is, we never know when they will
happen...  My stuff is public and Andrew pulls it in when he wants to
update.  As he just released one last night, we might have a day or so
before the next one, so it should be fine.

> [1] I personally prefer more leading zeros, or better yet none at all.

Sure, just an example, use what you want.  More is always nice to keep
things sorted sanely.

thanks,

greg k-h

  parent reply	other threads:[~2005-06-03  6:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-02  5:38 [lm-sensors] Re: [PATCH 2.6.12-rc5-mm1 3/3] i2c: modify sensors Mark M. Hoffman
2005-06-02  8:03 ` Greg KH
2005-06-03  6:00 ` Mark M. Hoffman
2005-06-03  6:47 ` Greg KH [this message]
2005-06-03  8:26 ` Yani Ioannou
2005-06-03  8:53 ` Greg KH
2005-06-03 21:00 ` Yani Ioannou
2005-06-04 18:13 ` Jean Delvare
2005-06-04 18:23 ` Jean Delvare
2005-06-04 22:32 ` Yani Ioannou
2005-06-04 23:21 ` Jean Delvare
2005-06-05  1:35 ` Yani Ioannou
2005-06-05  5:42 ` Mark M. Hoffman
2005-06-05  8:06 ` Jean Delvare
2005-06-09  9:28 ` Greg KH
2005-06-09  9:58 ` Yani Ioannou
2005-06-09 10:23 ` Jean Delvare
2005-06-10  6:26 ` Mark M. Hoffman
2005-06-10  6:40 ` Greg KH
2005-06-10 18:45 ` Jean Delvare

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=20050603045739.GB28055@kroah.com \
    --to=greg@kroah.com \
    --cc=lm-sensors@vger.kernel.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.