All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Linuxppc-dev@ozlabs.org, Alan Clucas <alanc@pipstechnology.co.uk>,
	Detlev Zundel <dzu@denx.de>,
	lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [PATCH] Support for DS75 thermal sensor
Date: Wed, 16 Jul 2008 10:10:59 +0000	[thread overview]
Message-ID: <20080716121059.2dbbfebe@hyperion.delvare> (raw)
In-Reply-To: <487DC457.6000103@grandegger.com>

On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > The problem is that at this point in time, only a couple hwmon drivers
> > have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> > would break most systems.
> > 
> > I have a set of patches converting most hwmon drivers to new-style i2c.
> > I plan to send it to Linus later today. Once all drivers are converted,
> > everyone can start adding device definitions to platform code. And only
> > once this is done for all platforms, you may remove I2C_CLASS_HWMON
> > from the i2c-mpc driver.
> 
> Of course.
> 
> > But even then, you can't exclude the possibility that some people want
> > to keep relying on the auto-detection mode. In that case, the setting
> 
> I understood that this is only true for the HWMON devices. Why the 
> special treatment?

Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.

What makes hwmon a bit different is the historical context. Originally,
the hwmon drivers were written for PCs, which have no per-system
platform code, so declaring the devices was simply not an option.
Additionally, i2c was maintained as part of the lm-sensors project
itself. This determined the probe-everything approach that has ruled
the i2c subsystem until recently. I've spent (with a few other
developers) the past few years drawing a clear separation between i2c
and hwmon, and now making it possible to declare i2c devices where
possible. This is a lot of work if you want to do this without breaking
any system out there (which is my case.)

> > of the I2C_CLASS_HWMON flag should become an attribute of each i2c-mpc
> > device.
> 
> Yep, as probing might not be acceptable in some cases, I makes sense to 
> add a property to suppress probing:

It'd rather make no-probing the default if possible. My understanding
is that all systems using i2c-mpc should have proper platform data.

But then again, that's not really my business. The decision is left to
the actual users of this i2c bus driver.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Linuxppc-dev@ozlabs.org, Alan Clucas <alanc@pipstechnology.co.uk>,
	Detlev Zundel <dzu@denx.de>,
	lm-sensors@lm-sensors.org
Subject: Re: [PATCH] Support for DS75 thermal sensor
Date: Wed, 16 Jul 2008 12:10:59 +0200	[thread overview]
Message-ID: <20080716121059.2dbbfebe@hyperion.delvare> (raw)
In-Reply-To: <487DC457.6000103@grandegger.com>

On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > The problem is that at this point in time, only a couple hwmon drivers
> > have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> > would break most systems.
> > 
> > I have a set of patches converting most hwmon drivers to new-style i2c.
> > I plan to send it to Linus later today. Once all drivers are converted,
> > everyone can start adding device definitions to platform code. And only
> > once this is done for all platforms, you may remove I2C_CLASS_HWMON
> > from the i2c-mpc driver.
> 
> Of course.
> 
> > But even then, you can't exclude the possibility that some people want
> > to keep relying on the auto-detection mode. In that case, the setting
> 
> I understood that this is only true for the HWMON devices. Why the 
> special treatment?

Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.

What makes hwmon a bit different is the historical context. Originally,
the hwmon drivers were written for PCs, which have no per-system
platform code, so declaring the devices was simply not an option.
Additionally, i2c was maintained as part of the lm-sensors project
itself. This determined the probe-everything approach that has ruled
the i2c subsystem until recently. I've spent (with a few other
developers) the past few years drawing a clear separation between i2c
and hwmon, and now making it possible to declare i2c devices where
possible. This is a lot of work if you want to do this without breaking
any system out there (which is my case.)

> > of the I2C_CLASS_HWMON flag should become an attribute of each i2c-mpc
> > device.
> 
> Yep, as probing might not be acceptable in some cases, I makes sense to 
> add a property to suppress probing:

It'd rather make no-probing the default if possible. My understanding
is that all systems using i2c-mpc should have proper platform data.

But then again, that's not really my business. The decision is left to
the actual users of this i2c bus driver.

-- 
Jean Delvare

  reply	other threads:[~2008-07-16 10:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-08  9:22 [lm-sensors] [PATCH] Support for DS75 thermal sensor Wolfgang Grandegger
2008-07-08  9:53 ` Jean Delvare
2008-07-08 13:09 ` Wolfgang Grandegger
2008-07-08 13:29 ` Jean Delvare
2008-07-08 13:38 ` Wolfgang Grandegger
2008-07-11 12:40 ` Wolfgang Grandegger
2008-07-11 12:56 ` Jean Delvare
2008-07-16  9:12   ` Wolfgang Grandegger
2008-07-16  9:12     ` Wolfgang Grandegger
2008-07-16  9:33     ` Jean Delvare
2008-07-16  9:33       ` Jean Delvare
2008-07-16  9:50       ` [lm-sensors] " Wolfgang Grandegger
2008-07-16  9:50         ` Wolfgang Grandegger
2008-07-16 10:10         ` Jean Delvare [this message]
2008-07-16 10:10           ` Jean Delvare
2008-07-16 10:23           ` [lm-sensors] " Wolfgang Grandegger
2008-07-16 10:23             ` Wolfgang Grandegger
2008-07-16 14:08           ` [lm-sensors] " Grant Likely
2008-07-16 14:08             ` Grant Likely
2008-07-16 14:18             ` [lm-sensors] " Jon Smirl
2008-07-16 14:18               ` Jon Smirl
2008-07-16 14:29               ` [lm-sensors] " Jean Delvare
2008-07-16 14:29                 ` Jean Delvare
2008-07-17  7:31                 ` [lm-sensors] " Wolfgang Grandegger
2008-07-17  7:31                   ` Wolfgang Grandegger
2008-07-17  7:33                   ` [lm-sensors] " Grant Likely
2008-07-17  7:33                     ` Grant Likely
2008-07-17 10:39                     ` [lm-sensors] " Wolfgang Grandegger
2008-07-17 10:39                       ` Wolfgang Grandegger

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=20080716121059.2dbbfebe@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=alanc@pipstechnology.co.uk \
    --cc=dzu@denx.de \
    --cc=lm-sensors@lm-sensors.org \
    --cc=wg@grandegger.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.