Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH] gpio: tegra: don't auto-enable for COMPILE_TEST | Date | Wed, 20 Jul 2016 13:07:17 +0200 |
| |
On Wednesday, July 20, 2016 12:41:48 PM CEST Ingo Molnar wrote: > * Linus Walleij <linus.walleij@linaro.org> wrote: > > > On Wed, Jul 6, 2016 at 2:54 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > > > > I stumbled over a build error with COMPILE_TEST and CONFIG_OF > > > disabled: > > > > > > drivers/gpio/gpio-tegra.c: In function 'tegra_gpio_probe': > > > drivers/gpio/gpio-tegra.c:603:9: error: 'struct gpio_chip' has no member named 'of_node' > > > > > > The problem is that the newly added GPIO_TEGRA Kconfig symbol > > > does not have a dependency on CONFIG_OF. However, there is another > > > problem here as the driver gets enabled unconditionally whenever > > > COMPILE_TEST is set. > > > > > > This fixes both problems, by making the symbol user-visible > > > when COMPILE_TEST is set and default-enabled for ARCH_TEGRA=y. > > > > > > As a side-effect, it is now possible to compile-test a Tegra > > > kernel with GPIO support disabled, which is harmless. > > > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > > Fixes: 4dd4dd1d2120 ("gpio: tegra: Allow compile test") > > > > Patch applied. > > This is still not upstream and this build failure is very prominent in the > upstream kernel right now.
Note that Linus Walleij is currently on vacation. I don't know if Alexandre could forward this patch in the meantime.
I also have another patch for a similar regression in linux-next that prevents an x86 allmodconfig kernel with CONFIG_OF=n from building (see "pinctrl: bcm: add OF dependencies") and that one hasn't made it into -next yet (unlike this one that is fixed in -next but broken in v4.7).
> > I'm starting to get a bit tired about anything related to compile testing. > > They are very useful in finding real problems as well, and some people > (like me! rely on being able to generate random kernel images and > boot them.
Agreed, I send many patches for build-time regressions every week. Most of them are for harmless problems, but the other ones that find actual bugs make it absolutely worthwhile.
I don't mind doing this, and most folks are happy to get an early feedback about when things break. What's annoying is when I send a patch within hours after a linux-next release that breaks something and then the bug makes it into mainline anyway, weeks later.
Arnd
| |