From: Jean Delvare <jdelvare@suse.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "Pali Rohár" <pali.rohar@gmail.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Steven Honeyman" <stevenhoneyman@gmail.com>,
Valdis.Kletnieks@vt.edu,
"Jochen Eisinger" <jochen@penguin-breeder.org>,
"Gabriele Mazzotta" <gabriele.mzt@gmail.com>,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: i8k: move driver from char to hwmon
Date: Wed, 22 Apr 2015 10:23:04 +0200 [thread overview]
Message-ID: <20150422102304.35d9e2d1@endymion.delvare> (raw)
In-Reply-To: <54EA1BC4.9080606@roeck-us.net>
On Sun, 22 Feb 2015 10:11:16 -0800, Guenter Roeck wrote:
> On 02/22/2015 09:44 AM, Pali Rohár wrote:
> > What about CONFIG_DELLDIAG (or DELLSMM or CONFIG_SENSORS_*) for
> > mandatory core & hwmon code and (keep existing) CONFIG_I8K for
> > /proc/i8k?
>
> One option might be to leave CONFIG_I8K more or less alone
> (it is in arch/x86/Kconfig anyway, which is odd by itself),
> but add something like
> select SENSORS_DELL
> select I8K_PROC
> to it. Then add new config options SENSORS_DELL and
> I8K_PROC to drivers/hwmon/Kconfig.
On a related note...
Changing Kconfig symbol names is allowed, it has happened a lot in the
past, although we should make it the least painful possible for the
users.
I thought about it earlier as I considered several times the
possibility to rename all CONFIG_SENSORS_* symbols to CONFIG_HWMON_*
for consistency. I never actually took the time to do it, but here's
how I would do it, taking the lm75 driver as an example.
As a first step, I would introduce a hidden symbol that would be
selected automatically by the existing symbol:
drivers/hwmon/Kconfig | 4 ++++
drivers/hwmon/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
--- linux-4.1-rc0.orig/drivers/hwmon/Kconfig 2015-04-22 09:54:21.965974944 +0200
+++ linux-4.1-rc0/drivers/hwmon/Kconfig 2015-04-22 10:10:16.974551936 +0200
@@ -909,10 +909,14 @@ config SENSORS_LM73
This driver can also be built as a module. If so, the module
will be called lm73.
+config HWMON_LM75
+ tristate
+
config SENSORS_LM75
tristate "National Semiconductor LM75 and compatibles"
depends on I2C
depends on THERMAL || !THERMAL_OF
+ select HWMON_LM75
help
If you say yes here you get support for one common type of
temperature sensor chip, with models including:
--- linux-4.1-rc0.orig/drivers/hwmon/Makefile 2015-04-22 09:54:21.965974944 +0200
+++ linux-4.1-rc0/drivers/hwmon/Makefile 2015-04-22 10:09:03.712048849 +0200
@@ -85,7 +85,7 @@ obj-$(CONFIG_SENSORS_LINEAGE) += lineage
obj-$(CONFIG_SENSORS_LM63) += lm63.o
obj-$(CONFIG_SENSORS_LM70) += lm70.o
obj-$(CONFIG_SENSORS_LM73) += lm73.o
-obj-$(CONFIG_SENSORS_LM75) += lm75.o
+obj-$(CONFIG_HWMON_LM75) += lm75.o
obj-$(CONFIG_SENSORS_LM77) += lm77.o
obj-$(CONFIG_SENSORS_LM78) += lm78.o
obj-$(CONFIG_SENSORS_LM80) += lm80.o
Running "make oldconfig" after that silently selects the new symbol as
needed:
--- .config.old 2015-04-20 10:16:42.645359313 +0200
+++ .config 2015-04-22 10:09:09.358164599 +0200
@@ -2805,6 +2805,7 @@
CONFIG_SENSORS_LM63=m
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
+CONFIG_HWMON_LM75=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
Then I would let several kernel versions pass. After a year maybe, or 5
kernel versions, we could get rid of the original symbol:
drivers/hwmon/Kconfig | 4 ----
1 file changed, 4 deletions(-)
--- linux-4.1-rc0.orig/drivers/hwmon/Kconfig 2015-04-22 10:08:39.017542771 +0200
+++ linux-4.1-rc0/drivers/hwmon/Kconfig 2015-04-22 10:09:57.376149603 +0200
@@ -910,13 +910,9 @@ config SENSORS_LM73
will be called lm73.
config HWMON_LM75
- tristate
-
-config SENSORS_LM75
tristate "National Semiconductor LM75 and compatibles"
depends on I2C
depends on THERMAL || !THERMAL_OF
- select HWMON_LM75
help
If you say yes here you get support for one common type of
temperature sensor chip, with models including:
Again running "make oldconfig" will do the right thing silently:
--- .config.old 2015-04-22 10:09:09.358164599 +0200
+++ .config 2015-04-22 10:10:02.942263851 +0200
@@ -2806,7 +2806,6 @@
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
CONFIG_HWMON_LM75=m
-CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
This allows for a transparent migration to the new names from a user's
perspective, as long as they do not jump directly from the original
state to the final state. Maybe something like that can be done for
CONFIG_I8K if you want to rename it.
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2015-04-22 8:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 11:50 i8k: move driver from char to hwmon Pali Rohár
2015-02-22 17:33 ` Guenter Roeck
2015-02-22 17:44 ` Pali Rohár
2015-02-22 17:55 ` Guenter Roeck
2015-02-22 18:11 ` Guenter Roeck
2015-02-22 22:07 ` Jean Delvare
2015-02-22 23:31 ` Guenter Roeck
2015-04-22 8:23 ` Jean Delvare [this message]
2015-04-22 8:42 ` Pali Rohár
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=20150422102304.35d9e2d1@endymion.delvare \
--to=jdelvare@suse.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=arnd@arndb.de \
--cc=gabriele.mzt@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jochen@penguin-breeder.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=pali.rohar@gmail.com \
--cc=stevenhoneyman@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox