On 10/19/13, 4:10 PM, Jean Delvare wrote:
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(a)suse.com>
Date: Sun May 13 22:31:50 2012 -0400
Disabled more Intel embedded drivers.
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
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
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
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.