From: Andrew F. Davis <hidden> Date: 2016-06-13 20:01:59
Hello all,
I was building a kernel for x86 and noticed Make still descended into
directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
nothing will be built here. It looks to be due to some directories being
included in obj-y unconditionally instead of only when the relevant
CONFIG_ is set.
These patches are split by subsystem in-case, for some reason, a file in
a directory does need to be built, I believe I have checked for all
instances of this, but a quick review from some maintainers would be nice.
Thanks,
Andrew
Andrew F. Davis (12):
gpio: Only descend into gpio directory when CONFIG_GPIOLIB is set
pwm: Only descend into pwm directory when CONFIG_PWM is set
amba: Only descend into amba directory when CONFIG_ARM_AMBA is set
NFC: Only descend into nfc directory when CONFIG_NFC is set
macintosh: Only descend into directory when CONFIG_MACINTOSH_DRIVERS
is set
hsi: Only descend into hsi directory when CONFIG_HSI is set
auxdisplay: Only descend into directory when CONFIG_AUXDISPLAY is set
i2c: Only descend into i2c directory when CONFIG_I2C is set
[media] Only descend into directory when CONFIG_MEDIA_SUPPORT is set
lguest: Only descend into lguest directory when CONFIG_LGUEST is set
mmc: Only descend into mmc directory when CONFIG_MMC is set
leds: Only descend into leds directory when CONFIG_NEW_LEDS is set
drivers/Makefile | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
--
2.8.3
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:00
When CONFIG_GPIOLIB is not set make will still descend into the gpio
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -12,7 +12,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy/# GPIO must come after pinctrl as gpios may need to mux pins etcobj-$(CONFIG_PINCTRL)+=pinctrl/-obj-y+=gpio/+obj-$(CONFIG_GPIOLIB)+=gpio/obj-y+=pwm/obj-$(CONFIG_PCI)+=pci/obj-$(CONFIG_PARISC)+=parisc/
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:01
When CONFIG_PWM is not set make will still descend into the pwm
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -13,7 +13,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy/# GPIO must come after pinctrl as gpios may need to mux pins etcobj-$(CONFIG_PINCTRL)+=pinctrl/obj-$(CONFIG_GPIOLIB)+=gpio/-obj-y+=pwm/+obj-$(CONFIG_PWM)+=pwm/obj-$(CONFIG_PCI)+=pci/obj-$(CONFIG_PARISC)+=parisc/obj-$(CONFIG_RAPIDIO)+=rapidio/
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:02
When CONFIG_ARM_AMBA is not set make will still descend into the amba
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -28,7 +28,7 @@ obj-$(CONFIG_SFI) += sfi/# PnP must come after ACPI since it will eventually need to check if acpi# was used and do nothing if soobj-$(CONFIG_PNP)+=pnp/-obj-y+=amba/+obj-$(CONFIG_ARM_AMBA)+=amba/# Many drivers will want to use DMA so this has to be made available# really early.obj-$(CONFIG_DMADEVICES)+=dma/
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:03
When CONFIG_NFC is not set make will still descend into the nfc
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:04
When CONFIG_MACINTOSH_DRIVERS is not set make will still descend into the
macintosh directory but nothing will be built. This produces unneeded
build artifacts and messages in addition to slowing the build.
Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:05
When CONFIG_HSI is not set make will still descend into the hsi
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:06
When CONFIG_AUXDISPLAY is not set make will still descend into the
auxdisplay directory but nothing will be built. This produces unneeded
build artifacts and messages in addition to slowing the build.
Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:07
When CONFIG_I2C is not set make will still descend into the i2c
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:08
When CONFIG_MEDIA_SUPPORT is not set make will still descend into the
media directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:09
When CONFIG_LGUEST is not set make will still descend into the lguest
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:10
When CONFIG_MMC is not set make will still descend into the mmc
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-13 20:02:11
When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-s3c64xx/mach-crag6410.c:854: undefined reference to `gpio_led_register_device'
vim +854 arch/arm/mach-s3c64xx/mach-crag6410.c
e1a3c74f Mark Brown 2011-05-06 838 s3c_sdhci2_set_platdata(&crag6410_hsmmc2_pdata);
e1a3c74f Mark Brown 2011-05-06 839
e1a3c74f Mark Brown 2011-05-06 840 s3c_i2c0_set_platdata(&i2c0_pdata);
8351c7aa Mark Brown 2011-12-02 841 s3c_i2c1_set_platdata(&i2c1_pdata);
e1a3c74f Mark Brown 2011-05-06 842 s3c_fb_set_platdata(&crag6410_lcd_pdata);
1f91b4cc Felipe Balbi 2015-08-06 843 dwc2_hsotg_set_platdata(&crag6410_hsotg_pdata);
e1a3c74f Mark Brown 2011-05-06 844
e1a3c74f Mark Brown 2011-05-06 845 i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
e1a3c74f Mark Brown 2011-05-06 846 i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
e1a3c74f Mark Brown 2011-05-06 847
e1a3c74f Mark Brown 2011-05-06 848 samsung_keypad_set_platdata(&crag6410_keypad_data);
479535ed Mark Brown 2012-10-17 849 s3c64xx_spi0_set_platdata(NULL, 0, 2);
e1a3c74f Mark Brown 2011-05-06 850
799fbf8c Thierry Reding 2015-10-13 851 pwm_add_table(crag6410_pwm_lookup, ARRAY_SIZE(crag6410_pwm_lookup));
e1a3c74f Mark Brown 2011-05-06 852 platform_add_devices(crag6410_devices, ARRAY_SIZE(crag6410_devices));
e1a3c74f Mark Brown 2011-05-06 853
66211f98 Mark Brown 2011-12-29 @854 gpio_led_register_device(-1, &gpio_leds_pdata);
66211f98 Mark Brown 2011-12-29 855
ae24c263 Mark Brown 2011-06-22 856 regulator_has_full_constraints();
ae24c263 Mark Brown 2011-06-22 857
c656c306 Mark Brown 2011-12-08 858 s3c64xx_pm_init();
e1a3c74f Mark Brown 2011-05-06 859 }
e1a3c74f Mark Brown 2011-05-06 860
e1a3c74f Mark Brown 2011-05-06 861 MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
e1a3c74f Mark Brown 2011-05-06 862 /* Maintainer: Mark Brown [off-list ref] */
:::::: The code at line 854 was first introduced by commit
:::::: 66211f98d611056bf5fe918bbda37c636688574e ARM: S3C64XX: Support GPIO LEDs on Cragganmore
:::::: TO: Mark Brown [off-list ref]
:::::: CC: Kukjin Kim [off-list ref]
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Mon, Jun 13, 2016 at 10:02 PM, Andrew F. Davis [off-list ref] wrote:
When CONFIG_GPIOLIB is not set make will still descend into the gpio
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
Patch applied. Strange that this went unnoticed for years.
Yours,
Linus Walleij
From: Andrew F. Davis <hidden> Date: 2016-06-14 16:13:56
If the HSI core is built as a module hsi_boardinfo may still
be built-in as its Kconfig type is bool, which can cause build
issues. Fix this by building this code into the HSI core when
enabled.
Reported-by: kbuild test robot <redacted>
Signed-off-by: Andrew F. Davis <redacted>
---
This build error seems to be due to Kconfig symbol CONFIG_HSI_BOARDINFO
being a bool but depending on a tristate (CONFIG_HSI). This is normally
okay when it is just a flag to enable a feature in source, but the
helper code file hsi_boardinfo.c is built as a separate entity when
enabled. This patch is probably how it was intended, and is more like
how others do this kind of thing.
This patch should be applied before the parent patch:
drivers/hsi/Makefile | 3 ++-
drivers/hsi/{hsi.c => hsi_core.c} | 0
2 files changed, 2 insertions(+), 1 deletion(-)
rename drivers/hsi/{hsi.c => hsi_core.c} (100%)
From: Jacek Anaszewski <hidden> Date: 2016-06-15 06:49:00
Hi Andrew,
Thanks for the patch.
Please address the issue [1] raised by test bot and resubmit.
Thanks,
Jacek Anaszewski
[1] https://lkml.org/lkml/2016/6/13/1091
On 06/13/2016 10:02 PM, Andrew F. Davis wrote:
quoted hunk
When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Sebastian Reichel <sre@kernel.org> Date: 2016-06-15 12:48:51
Hi Andrew,
On Tue, Jun 14, 2016 at 11:13:04AM -0500, Andrew F. Davis wrote:
If the HSI core is built as a module hsi_boardinfo may still
be built-in as its Kconfig type is bool, which can cause build
issues. Fix this by building this code into the HSI core when
enabled.
Reported-by: kbuild test robot <redacted>
Signed-off-by: Andrew F. Davis <redacted>
---
This build error seems to be due to Kconfig symbol CONFIG_HSI_BOARDINFO
being a bool but depending on a tristate (CONFIG_HSI). This is normally
okay when it is just a flag to enable a feature in source, but the
helper code file hsi_boardinfo.c is built as a separate entity when
enabled. This patch is probably how it was intended, and is more like
how others do this kind of thing.
This patch should be applied before the parent patch:
From: Andrew F. Davis <hidden> Date: 2016-06-17 22:47:06
On 06/15/2016 01:48 AM, Jacek Anaszewski wrote:
Hi Andrew,
Thanks for the patch.
Please address the issue [1] raised by test bot and resubmit.
Thanks,
Jacek Anaszewski
[1] https://lkml.org/lkml/2016/6/13/1091
It looks like some systems use 'gpio_led_register_device' to make an
in-memory copy of their LED device table so the original can be removed
as .init.rodata. This doesn't necessarily depend on the LED subsystem
but it kind of seems useless when the rest of the subsystem is disabled.
One solution could be to use a dummy 'gpio_led_register_device' when the
subsystem is not enabled. Another is just to remove the five or so uses
of 'gpio_led_register_device' and have those systems register LED device
tables like other systems do.
If nether of these are acceptable then this patch can be dropped from
this series for now.
Thanks,
Andrew
On 06/13/2016 10:02 PM, Andrew F. Davis wrote:
quoted
When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jacek Anaszewski <hidden> Date: 2016-06-20 07:55:30
On 06/18/2016 12:46 AM, Andrew F. Davis wrote:
On 06/15/2016 01:48 AM, Jacek Anaszewski wrote:
quoted
Hi Andrew,
Thanks for the patch.
Please address the issue [1] raised by test bot and resubmit.
Thanks,
Jacek Anaszewski
[1] https://lkml.org/lkml/2016/6/13/1091
It looks like some systems use 'gpio_led_register_device' to make an
in-memory copy of their LED device table so the original can be removed
as .init.rodata. This doesn't necessarily depend on the LED subsystem
but it kind of seems useless when the rest of the subsystem is disabled.
One solution could be to use a dummy 'gpio_led_register_device' when the
subsystem is not enabled.
It sounds good. Please add a no-op version of gpio_led_register_device()
to include/leds.h, in a separate patch.
Thanks,
Jacek Anaszewski
Another is just to remove the five or so uses
of 'gpio_led_register_device' and have those systems register LED device
tables like other systems do.
If nether of these are acceptable then this patch can be dropped from
this series for now.
Thanks,
Andrew
quoted
On 06/13/2016 10:02 PM, Andrew F. Davis wrote:
quoted
When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andrew F. Davis <hidden> Date: 2016-06-20 22:22:11
Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
include/linux/leds.h | 8 ++++++++
1 file changed, 8 insertions(+)
From: Rusty Russell <hidden> Date: 2016-06-21 03:19:42
"Andrew F. Davis" [off-list ref] writes:
When CONFIG_LGUEST is not set make will still descend into the lguest
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jacek Anaszewski <hidden> Date: 2016-06-21 07:12:08
Hi Andrew,
This patch doesn't apply, please rebase onto recent LED tree.
On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
quoted hunk
Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
include/linux/leds.h | 8 ++++++++
1 file changed, 8 insertions(+)
Currently there is some stuff here, and in fact it has been for
a long time.
Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?
From: Andrew F. Davis <hidden> Date: 2016-06-21 12:01:35
On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
Hi Andrew,
This patch doesn't apply, please rebase onto recent LED tree.
On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
quoted
Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
include/linux/leds.h | 8 ++++++++
1 file changed, 8 insertions(+)
Currently there is some stuff here, and in fact it has been for
a long time.
Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?
v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.
A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.
From: Jacek Anaszewski <hidden> Date: 2016-06-21 13:11:11
On 06/21/2016 01:48 PM, Andrew F. Davis wrote:
On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
quoted
Hi Andrew,
This patch doesn't apply, please rebase onto recent LED tree.
On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
quoted
Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.
Signed-off-by: Andrew F. Davis <redacted>
---
include/linux/leds.h | 8 ++++++++
1 file changed, 8 insertions(+)
Currently there is some stuff here, and in fact it has been for
a long time.
Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?
v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.
A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.