All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Re: [PATCH 2.6.12-rc5-mm1 3/3] i2c: modify sensors
Date: Sat, 04 Jun 2005 18:23:56 +0000	[thread overview]
Message-ID: <20050604182428.0e55eb4d.khali@linux-fr.org> (raw)
In-Reply-To: <20050602033727.GD4906@jupiter.solarsys.private>

Hi Mark, Greg,

> 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?

I totally second Greg on that. I have been working hard to get the
i2c_client.id mess out of each i2c chip driver, let's not reintroduce it
again here.

Also, this original approach was dangerous, as it relied on the
cooperation of each driver for uniqueness of the IDs. This can easily
fail. We want the uniqueness guaranted by the hwmon class itself.

I am not even sure we want to display the name of the chips here, as it
is redundant with the "name" file in the target directory. I would go
with a simple number, this is the easiest and does the job.

Last, it would be nice if the IDs were reused on driver cycling, just
like the i2c bus IDs are. You should be able to pick the code in i2c-dev
and reuse it in the hwmon class.

Thanks,
-- 
Jean Delvare

  parent reply	other threads:[~2005-06-04 18:23 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
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 [this message]
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=20050604182428.0e55eb4d.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --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.