From: khali@linux-fr.org (Jean Delvare)
To: Philip Pokorny <ppokorny@penguincomputing.com>
Cc: LM Sensors <sensors@stimpy.netroedge.com>,
LKML <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: [RFC] I2C: Remove the i2c_client id field
Date: Thu, 19 May 2005 06:25:27 +0000 [thread overview]
Message-ID: <20041228114258.35e9b5b7.khali@linux-fr.org> (raw)
In-Reply-To: <41D0942B.8020109@penguincomputing.com>
Hi Philip,
> So only the drives I wrote use the ID in a meaningful way?
True, providing we limit our consideration to the hardware monitoring
drivers. Even in your drivers, the meaningfulness is discussable.
The lm85 driver simply displays the assigned id once (at the time it
assigns it). Since the id is then never used, I would consider the lm85
driver similar to the other hardware monitoring drivers.
The adm1026 driver, OTOH, does use the id value in all debug messages,
and it also only reconfigures the GPIO pins for the first client only
(id = 0). Although this is a real use of the id, it only matters if you
use the module parameters for GPIO pins reconfiguration and actually
have more than one ADM1026 chip (a quite rare chip if you remember). You
don't necessarily know which ADM1026 will get id 0 anyway (if the chips
are on different busses it depends on the order the bus drivers were
loaded in), and I am not sure why one would want to reprogram only the
first chip. Unless someone comes with such a specific hardware setup so
that we can examine what is really needed, I think we can get rid of the
"id = 0" test and reconfigure "all" ADM1026 chips (which really is only
one for the two known boards using an ADM1026).
BTW, does anyone really use the GPIO pins reconfiguration parameters?
> What do you propose to replace the ID value in the debug messages
> with?
> Ideally it would be the things you mention that uniquely identify
> the chip in question (bus number and address)
> How hard are those values to get at? Do we have to chase possibly
> NULL pointers?
Everything is already done. The adm1026 driver (like all other drivers
of the directory) uses dev_dbg to print its debug messages, and dev_dbg
prepends the bus number and chip address to any line it prints. This
means that the "client id" is redundant and can be removed losslessly.
Thanks,
--
Jean Delvare
http://khali.linux-fr.org/
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Philip Pokorny <ppokorny@penguincomputing.com>
Cc: LM Sensors <sensors@stimpy.netroedge.com>,
LKML <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: Re: [RFC] I2C: Remove the i2c_client id field
Date: Tue, 28 Dec 2004 11:42:58 +0100 [thread overview]
Message-ID: <20041228114258.35e9b5b7.khali@linux-fr.org> (raw)
In-Reply-To: <41D0942B.8020109@penguincomputing.com>
Hi Philip,
> So only the drives I wrote use the ID in a meaningful way?
True, providing we limit our consideration to the hardware monitoring
drivers. Even in your drivers, the meaningfulness is discussable.
The lm85 driver simply displays the assigned id once (at the time it
assigns it). Since the id is then never used, I would consider the lm85
driver similar to the other hardware monitoring drivers.
The adm1026 driver, OTOH, does use the id value in all debug messages,
and it also only reconfigures the GPIO pins for the first client only
(id == 0). Although this is a real use of the id, it only matters if you
use the module parameters for GPIO pins reconfiguration and actually
have more than one ADM1026 chip (a quite rare chip if you remember). You
don't necessarily know which ADM1026 will get id 0 anyway (if the chips
are on different busses it depends on the order the bus drivers were
loaded in), and I am not sure why one would want to reprogram only the
first chip. Unless someone comes with such a specific hardware setup so
that we can examine what is really needed, I think we can get rid of the
"id == 0" test and reconfigure "all" ADM1026 chips (which really is only
one for the two known boards using an ADM1026).
BTW, does anyone really use the GPIO pins reconfiguration parameters?
> What do you propose to replace the ID value in the debug messages
> with?
> Ideally it would be the things you mention that uniquely identify
> the chip in question (bus number and address)
> How hard are those values to get at? Do we have to chase possibly
> NULL pointers?
Everything is already done. The adm1026 driver (like all other drivers
of the directory) uses dev_dbg to print its debug messages, and dev_dbg
prepends the bus number and chip address to any line it prints. This
means that the "client id" is redundant and can be removed losslessly.
Thanks,
--
Jean Delvare
http://khali.linux-fr.org/
next prev parent reply other threads:[~2005-05-19 6:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-27 22:04 [RFC] I2C: Remove the i2c_client id field Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2004-12-27 23:00 ` Philip Pokorny
2005-05-19 6:25 ` Philip Pokorny
2004-12-28 10:42 ` Jean Delvare [this message]
2005-05-19 6:25 ` Jean Delvare
2004-12-28 16:36 ` Philip Pokorny
2005-05-19 6:25 ` Philip Pokorny
2004-12-28 17:22 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-01-06 23:12 ` Greg KH
2005-05-19 6:25 ` 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=20041228114258.35e9b5b7.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ppokorny@penguincomputing.com \
--cc=sensors@stimpy.netroedge.com \
/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.