From: khali@linux-fr.org (Jean Delvare)
To: Michael Hunold <hunold@convergence.de>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, akpm@osdl.org,
greg@kroah.com, sensors@stimpy.netroedge.com
Subject: [PATCH][2.6]
Date: Thu, 19 May 2005 06:24:56 +0000 [thread overview]
Message-ID: <20040506213455.29154c51.khali@linux-fr.org> (raw)
In-Reply-To: <409923F7.7050101@convergence.de>
> With the new I2C_CLASS_ALL flag it will be possible that an adapter
> can request that really all drivers are probed on the adapter. On the
> other hand, drivers can make sure that they get the chance to probe on
> every i2c adapter out there (this is not encouraged, though)
Depends. For example the eeprom driver will do that, and this is
correct. That said, I agree that this is a collaborative approach and
everybody will have to play the game.
> - rename I2C_ADAP_CLASS_xxx to I2C_CLASS_xxx (to be used both for
> drivers and adapters)
> - add new I2C_CLASS_ALL and I2C_CLASS_SOUND classes
Mmm, I once proposed that I2C_ADAP_CLASS_SMBUS would be better renamed
I2C_ADAP_CLASS_SENSORS (so I2C_CLASS_SENSORS now). What about that? I
think it would be great to embed that change into your patch, so that
the name changes only once.
Now that we come to speak about that, I wonder if we would _also_ need a
SMBUS class. SMBus is mostly a subset of I2C, essentially (but not
completely) compatible. It may be useful at some point to know if a chip
is compliant with SMBus or not. I don't think that i2c-core can make use
of this at the moment, nor can I think of concrete examples where this
would be needed. It's just a thought at the moment and I mention it here
in case anyone has comments ;)
For now we can stick to the classes we have (with the SMBUS->SENSORS
change and the new SOUND class). The true SMBUS class can always be
added later if needed, I guess.
BTW, if HWMON is prefered to SENSORS, this is fine with me too, I have
no strong preference.
Thanks.
--
Jean Delvare
http://khali.linux-fr.org/
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Michael Hunold <hunold@convergence.de>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, akpm@osdl.org,
greg@kroah.com, sensors@stimpy.netroedge.com
Subject: Re: [PATCH][2.6]
Date: Thu, 6 May 2004 21:34:55 +0200 [thread overview]
Message-ID: <20040506213455.29154c51.khali@linux-fr.org> (raw)
In-Reply-To: <409923F7.7050101@convergence.de>
> With the new I2C_CLASS_ALL flag it will be possible that an adapter
> can request that really all drivers are probed on the adapter. On the
> other hand, drivers can make sure that they get the chance to probe on
> every i2c adapter out there (this is not encouraged, though)
Depends. For example the eeprom driver will do that, and this is
correct. That said, I agree that this is a collaborative approach and
everybody will have to play the game.
> - rename I2C_ADAP_CLASS_xxx to I2C_CLASS_xxx (to be used both for
> drivers and adapters)
> - add new I2C_CLASS_ALL and I2C_CLASS_SOUND classes
Mmm, I once proposed that I2C_ADAP_CLASS_SMBUS would be better renamed
I2C_ADAP_CLASS_SENSORS (so I2C_CLASS_SENSORS now). What about that? I
think it would be great to embed that change into your patch, so that
the name changes only once.
Now that we come to speak about that, I wonder if we would _also_ need a
SMBUS class. SMBus is mostly a subset of I2C, essentially (but not
completely) compatible. It may be useful at some point to know if a chip
is compliant with SMBus or not. I don't think that i2c-core can make use
of this at the moment, nor can I think of concrete examples where this
would be needed. It's just a thought at the moment and I mention it here
in case anyone has comments ;)
For now we can stick to the classes we have (with the SMBUS->SENSORS
change and the new SOUND class). The true SMBUS class can always be
added later if needed, I guess.
BTW, if HWMON is prefered to SENSORS, this is fine with me too, I have
no strong preference.
Thanks.
--
Jean Delvare
http://khali.linux-fr.org/
next prev parent reply other threads:[~2005-05-19 6:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-05 17:27 [PATCH][2.6] Michael Hunold
2005-05-19 6:24 ` [PATCH][2.6] Michael Hunold
2004-05-05 17:53 ` [PATCH][2.6] Greg KH
2005-05-19 6:24 ` [PATCH][2.6] Greg KH
2004-05-06 8:17 ` [PATCH][2.6] Michael Hunold
2004-05-05 23:13 ` [PATCH][2.6] Greg KH
2005-05-19 6:24 ` [PATCH][2.6] Greg KH
2004-05-06 19:34 ` Jean Delvare [this message]
2005-05-19 6:24 ` [PATCH][2.6] Jean Delvare
2004-05-09 15:48 ` [PATCH 2.6] Rename hardware monitoring I2C class Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2004-05-11 20:44 ` Greg KH
2005-05-19 6:24 ` 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=20040506213455.29154c51.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=hunold@convergence.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@stimpy.netroedge.com \
--cc=torvalds@osdl.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.