questions about config files, I2C and hardware sensors (2.5.59)

questions about config files, I2C and hardware sensors (2.5.59)

[Robert P. J. Day]

  just to make sure i understand the kbuild language, a couple
questions about the I2C config option and its menu dependencies.

  in .../drivers/i2c/Kconfig, we have the relevant lines:

-----------------

menu "I2C support"

config I2C
	tristate "I2C support"
     ... blah blah ...

config I2C_PROC
	tristate "more blah"
 	depends on I2C && SYSCTL

source drivers/i2c/busses/Kconfig
source drivers/i2c/chips/Kconfig

endmenu

-------------------

  so far, so good.  and since the next issue deals with both of 
those sourced files similarly, i'll just pick on the first one --
busses/Kconfig, which contains:

-------------------

#  .. All depend on EXPERIMENTAL, I2C and I2CPROC.

menu "I2C HW Sensors Mainboard Support"

config I2C_AMD756
	tristate "..."
	depends on I2C && I2C_PROC

config I2C_AMD8111
	tristate "..."
	depends on I2C && I2C_PROC

...

endmenu

--------------------

  so the issues:

1) trivial: comment is wrong, there is no dependency on 
   EXPERIMENTAL

2) since, in the sourcing Kconfig file, I2C_PROC *already* depends
   on I2C, is there any practical value in having the dependency
   "I2C && I2C_PROC".  wouldn't "depends on I2C_PROC" be sufficient?
   that is, do option dependencies carry across sourced Kconfig
   files?  not a major issue, just unnecessary verbosity.

3) finally, given that the comment at the top is adamant that
   all of these options depend on I2C and I2C_PROC, wouldn't it
   be cleaner to just make the menu itself say:

   menu "I2C HW Sensors Mainboard Support"
	depends on I2C && I2C_PROC		(or just I2C_PROC)
	...

   and let the internal options inherit this dependency?  as it
   is, those two submenu names show up even though clicking on
   them shows an empty option screen.  

   by changing to the above, these become invisible submenus
   until you actually select I2C_PROC in the "Option"
   window.  is there any drawback to this?  seems cleaner.
   (this assumes, of course, that *all* options in this menu
   share exactly the same dependencies, but that's what the
   comment seems to imply.)

i can easily knock off a patch for this as long as i'm 
understanding this correctly.

rday

Re: questions about config files, I2C and hardware sensors (2.5.59)

[Roman Zippel]

Hi,

"Robert P. J. Day" wrote:

>   so the issues:
> 
> 1) trivial: comment is wrong, there is no dependency on
>    EXPERIMENTAL

This has to be answered by the I2C maintainer.

> 2) since, in the sourcing Kconfig file, I2C_PROC *already* depends
>    on I2C, is there any practical value in having the dependency
>    "I2C && I2C_PROC".  wouldn't "depends on I2C_PROC" be sufficient?

Yes.

> 3) finally, given that the comment at the top is adamant that
>    all of these options depend on I2C and I2C_PROC, wouldn't it
>    be cleaner to just make the menu itself say:
> 
>    menu "I2C HW Sensors Mainboard Support"
>         depends on I2C && I2C_PROC              (or just I2C_PROC)
>         ...
> 
>    and let the internal options inherit this dependency?

Yes, the menu entry needs the dependencies as well.

bye, Roman

Re: questions about config files, I2C and hardware sensors (2.5.59)

[Robert P. J. Day]

On Sat, 18 Jan 2003, Roman Zippel wrote:

> Hi,
> 
> "Robert P. J. Day" wrote:
> 
> >   so the issues:
> > 
> > 1) trivial: comment is wrong, there is no dependency on
> >    EXPERIMENTAL
> 
> This has to be answered by the I2C maintainer.
> 
> > 2) since, in the sourcing Kconfig file, I2C_PROC *already* depends
> >    on I2C, is there any practical value in having the dependency
> >    "I2C && I2C_PROC".  wouldn't "depends on I2C_PROC" be sufficient?
> 
> Yes.
> 
> > 3) finally, given that the comment at the top is adamant that
> >    all of these options depend on I2C and I2C_PROC, wouldn't it
> >    be cleaner to just make the menu itself say:
> > 
> >    menu "I2C HW Sensors Mainboard Support"
> >         depends on I2C && I2C_PROC              (or just I2C_PROC)
> >         ...
> > 
> >    and let the internal options inherit this dependency?
> 
> Yes, the menu entry needs the dependencies as well.
> 
> bye, Roman

-------------------------------------------------------------------------
diff -urN linux-2.5.59/drivers/i2c/busses/Kconfig linux-new/drivers/i2c/busses/Kconfig
--- linux-2.5.59/drivers/i2c/busses/Kconfig	2003-01-17 07:13:08.000000000 -0500
+++ linux-new/drivers/i2c/busses/Kconfig	2003-01-17 07:14:58.000000000 -0500
@@ -1,13 +1,13 @@
 #
 # Sensor device configuration
-# All depend on EXPERIMENTAL, I2C and I2C_PROC.
+# All depend on I2C_PROC.
 #
 
 menu "I2C Hardware Sensors Mainboard support"
+	depends on I2C_PROC
 
 config I2C_AMD756
 	tristate "  AMD 756/766"
-	depends on I2C && I2C_PROC
 	help
 	  If you say yes to this option, support will be included for the AMD
 	  756/766/768 mainboard I2C interfaces.
@@ -24,7 +24,6 @@
 
 config I2C_AMD8111
 	tristate "  AMD 8111"
-	depends on I2C && I2C_PROC
 	help
 	  If you say yes to this option, support will be included for the AMD
 	  8111 mainboard I2C interfaces.
diff -urN linux-2.5.59/drivers/i2c/chips/Kconfig linux-new/drivers/i2c/chips/Kconfig
--- linux-2.5.59/drivers/i2c/chips/Kconfig	2003-01-17 07:13:08.000000000 -0500
+++ linux-new/drivers/i2c/chips/Kconfig	2003-01-17 07:14:58.000000000 -0500
@@ -1,13 +1,13 @@
 #
 # Sensor device configuration
-# All depend on EXPERIMENTAL, I2C and I2C_PROC.
+# All depend on I2C_PROC.
 #
 
 menu "I2C Hardware Sensors Chip support"
+	depends on I2C_PROC
 
 config SENSORS_ADM1021
 	tristate "  Analog Devices ADM1021 and compatibles"
-	depends on I2C && I2C_PROC
 	help
 	  If you say yes here you get support for Analog Devices ADM1021 
 	  and ADM1023 sensor chips and clones: Maxim MAX1617 and MAX1617A,
@@ -24,7 +24,6 @@
 
 config SENSORS_LM75
 	tristate "  National Semiconductors LM75 and compatibles"
-	depends on I2C && I2C_PROC
 	help
 	  If you say yes here you get support for National Semiconductor LM75
 	  sensor chips and clones: Dallas Semi DS75 and DS1775, TelCon