Re: [opensuse-kernel] openSUSE 13.1+ kernel config

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 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