[opensuse-kernel] openSUSE 13.1+ kernel config
Hi all, I was looking at the openSUSE 13.1 kernel config and noticed the following settings which I'd like to discuss. # CONFIG_BATMAN_ADV_NC is not set Given that all other CONFIG_BATMAN_ADV_* options are enabled, what is the rationale for not enabling CONFIG_BATMAN_ADV_NC too? I'm not using Batman so I don't care personally, but for consistency it seems this option should be enabled. # CONFIG_GPIO_SCH is not set # CONFIG_GPIO_PCH is not set These were disabled on purpose by commit f554d8b2: Author: Jeff Mahoney <jeffm@suse.com> Date: Sun May 13 22:31:50 2012 -0400 Disabled more Intel embedded drivers. Disabled: - CONFIG_GPIO_LANGWELL - CONFIG_GPIO_PCH - CONFIG_GPIO_SCH But meanwhile (kernel v3.5) the gpio-sch driver was added support for the Intel Centerton microprocessor family, which I'm fairly sure we want to fully support. I am also wondering about gpio-pch because it supports a chipset for Tunnel Creek (Intel Atom E6xx) processors since kernel v3.3, and I don't quite understand why we wouldn't want to support these. I seem to recall it was already discussed but I can no longer find the discussion so I can't verify. But I see we have CONFIG_PCH_PHUB=m, CONFIG_PCH_GBE=m and CONFIG_PCH_DMA=m, so CONFIG_GPIO_PCH=m would seem consistent. # CONFIG_INTEL_POWERCLAMP While I don't expect this driver to get widely used, it could be useful in specific cases, like machines working in extreme conditions, temporary workaround to fan or air conditioning system failure, or debugging. The driver is small and unintrusive, so I see no downside to including it. -- Jean Delvare Suse L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Jeff (and others), No comment on this? Should I just change the config files as I see fit? Jean Le Saturday 19 October 2013 à 22:10 +0200, Jean Delvare a écrit :
Hi all,
I was looking at the openSUSE 13.1 kernel config and noticed the following settings which I'd like to discuss.
# CONFIG_BATMAN_ADV_NC is not set
Given that all other CONFIG_BATMAN_ADV_* options are enabled, what is the rationale for not enabling CONFIG_BATMAN_ADV_NC too? I'm not using Batman so I don't care personally, but for consistency it seems this option should be enabled.
# CONFIG_GPIO_SCH is not set # CONFIG_GPIO_PCH is not set
These were disabled on purpose by commit f554d8b2:
Author: Jeff Mahoney <jeffm@suse.com> Date: Sun May 13 22:31:50 2012 -0400
Disabled more Intel embedded drivers.
Disabled: - CONFIG_GPIO_LANGWELL - CONFIG_GPIO_PCH - CONFIG_GPIO_SCH
But meanwhile (kernel v3.5) the gpio-sch driver was added support for the Intel Centerton microprocessor family, which I'm fairly sure we want to fully support.
I am also wondering about gpio-pch because it supports a chipset for Tunnel Creek (Intel Atom E6xx) processors since kernel v3.3, and I don't quite understand why we wouldn't want to support these. I seem to recall it was already discussed but I can no longer find the discussion so I can't verify. But I see we have CONFIG_PCH_PHUB=m, CONFIG_PCH_GBE=m and CONFIG_PCH_DMA=m, so CONFIG_GPIO_PCH=m would seem consistent.
# CONFIG_INTEL_POWERCLAMP
While I don't expect this driver to get widely used, it could be useful in specific cases, like machines working in extreme conditions, temporary workaround to fan or air conditioning system failure, or debugging. The driver is small and unintrusive, so I see no downside to including it.
-- Jean Delvare Suse L3 Support
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 10/19/13, 4:10 PM, Jean Delvare wrote:
Hi all,
I was looking at the openSUSE 13.1 kernel config and noticed the following settings which I'd like to discuss.
# CONFIG_BATMAN_ADV_NC is not set
This was probably marked experimental at some point and wasn't updated.
Given that all other CONFIG_BATMAN_ADV_* options are enabled, what is the rationale for not enabling CONFIG_BATMAN_ADV_NC too? I'm not using Batman so I don't care personally, but for consistency it seems this option should be enabled.
# CONFIG_GPIO_SCH is not set # CONFIG_GPIO_PCH is not set
These were disabled on purpose by commit f554d8b2:
Author: Jeff Mahoney <jeffm@suse.com> Date: Sun May 13 22:31:50 2012 -0400
Disabled more Intel embedded drivers.
Disabled: - CONFIG_GPIO_LANGWELL - CONFIG_GPIO_PCH - CONFIG_GPIO_SCH
But meanwhile (kernel v3.5) the gpio-sch driver was added support for the Intel Centerton microprocessor family, which I'm fairly sure we want to fully support.
Ok, that's fine. I researched a bit before disabling them and it seemed like there wasn't anything beyond embedded hardware using them. I suppose as Atom blurs that line further that will become more difficult to distinguish.
I am also wondering about gpio-pch because it supports a chipset for Tunnel Creek (Intel Atom E6xx) processors since kernel v3.3, and I don't quite understand why we wouldn't want to support these. I seem to recall it was already discussed but I can no longer find the discussion so I can't verify. But I see we have CONFIG_PCH_PHUB=m, CONFIG_PCH_GBE=m and CONFIG_PCH_DMA=m, so CONFIG_GPIO_PCH=m would seem consistent.
I'm curious, though -- what is actually using the GPIO functionality? I'm not questioning its usefulness -- but how often is it likely to be used on systems where the owner wouldn't be building their own kernel anyway?
# CONFIG_INTEL_POWERCLAMP
While I don't expect this driver to get widely used, it could be useful in specific cases, like machines working in extreme conditions, temporary workaround to fan or air conditioning system failure, or debugging. The driver is small and unintrusive, so I see no downside to including it.
Ok, that's fine. My goal is to save build resources and disk space on the user side. If there's a reason for having it, great, but I don't think "it's small" is a really good argument by itself. -Jeff -- Jeff Mahoney SUSE Labs
Hi Jeff, Le Thursday 07 November 2013 à 13:03 -0500, Jeff Mahoney a écrit :
On 10/19/13, 4:10 PM, Jean Delvare wrote:
Hi all,
I was looking at the openSUSE 13.1 kernel config and noticed the following settings which I'd like to discuss.
# CONFIG_BATMAN_ADV_NC is not set
This was probably marked experimental at some point and wasn't updated.
Doesn't look like it, it was added with d353d8d4d9f0184ac43a90c6e04b593c33bd28ea and wasn't experimental then. It default to n though, but so does BATMAN_ADV_DAT and we include it still.
Given that all other CONFIG_BATMAN_ADV_* options are enabled, what is the rationale for not enabling CONFIG_BATMAN_ADV_NC too? I'm not using Batman so I don't care personally, but for consistency it seems this option should be enabled.
# CONFIG_GPIO_SCH is not set # CONFIG_GPIO_PCH is not set
These were disabled on purpose by commit f554d8b2:
Author: Jeff Mahoney <jeffm@suse.com> Date: Sun May 13 22:31:50 2012 -0400
Disabled more Intel embedded drivers.
Disabled: - CONFIG_GPIO_LANGWELL - CONFIG_GPIO_PCH - CONFIG_GPIO_SCH
But meanwhile (kernel v3.5) the gpio-sch driver was added support for the Intel Centerton microprocessor family, which I'm fairly sure we want to fully support.
Ok, that's fine. I researched a bit before disabling them and it seemed like there wasn't anything beyond embedded hardware using them. I suppose as Atom blurs that line further that will become more difficult to distinguish.
I am also wondering about gpio-pch because it supports a chipset for Tunnel Creek (Intel Atom E6xx) processors since kernel v3.3, and I don't quite understand why we wouldn't want to support these. I seem to recall it was already discussed but I can no longer find the discussion so I can't verify. But I see we have CONFIG_PCH_PHUB=m, CONFIG_PCH_GBE=m and CONFIG_PCH_DMA=m, so CONFIG_GPIO_PCH=m would seem consistent.
I'm curious, though -- what is actually using the GPIO functionality? I'm not questioning its usefulness -- but how often is it likely to be used on systems where the owner wouldn't be building their own kernel anyway?
One example I know of is SMBus multiplexing. There's an I2C multiplexer or switch on the SMBus, and which branches are reachable at any given time is decided by GPIO values. We also have generic drivers to do 1-Wire, SPI or I2C over GPIO pins. These are mostly used on embedded platforms, but as you noted, the line gets blurred these days so I wouldn't exclude the possibility that we start seeing use cases on desktop or server hardware.
# CONFIG_INTEL_POWERCLAMP
While I don't expect this driver to get widely used, it could be useful in specific cases, like machines working in extreme conditions, temporary workaround to fan or air conditioning system failure, or debugging. The driver is small and unintrusive, so I see no downside to including it.
Ok, that's fine. My goal is to save build resources and disk space on the user side. If there's a reason for having it, great, but I don't think "it's small" is a really good argument by itself.
I agree it's not a good argument for inclusion - my point was that "it's huge and bloated" would have been a good argument against inclusion. Which is not the case here. I've committed all the proposed changes to the master branch now, and I'll commit to the openSUSE-13.1 branch as well unless someone objects. -- Jean Delvare Suse L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (2)
-
Jean Delvare -
Jeff Mahoney