Why is drivers/usb/Makefile even read when CONFIG_USB is not set? Won't it make more sense to throw the line obj-$(CONFIG_PCI) += usb/ from drivers/Makfile? On Wed, Apr 22, 2015 at 7:11 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > The USB PCI quirks code gets built into the kernel whenever CONFIG_PCI > is enabled, even if CONFIG_USB is not set. This can cause unnecessary > messages to show up in the kernel log, such as "CONFIG_USB_XHCI_HCD is > turned off, defaulting to EHCI" (which makes no sense when the kernel > has been configured without host-side USB support). > > This patch addresses the problem by building pci-quirks.o only when > CONFIG_PCI and CONFIG_USB are both enabled. > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Reported-by: Toralf Förster <toralf.foerster@xxxxxx> > > --- > > Ver. 2: My earlier approach, removing the dependency from CONFIG_PCI > to drivers/usb/host/, doesn't work when CONFIG_PCI=y and CONFIG_USB=m. > This is because pci-quirks.o will not be available to be linked into > the kernel image, since nothing will cause "make" to descend into the > host/ directory when building the main kernel. > > > [as1778b] > > > drivers/usb/host/Makefile | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > Index: usb-4.0/drivers/usb/host/Makefile > =================================================================== > --- usb-4.0.orig/drivers/usb/host/Makefile > +++ usb-4.0/drivers/usb/host/Makefile > @@ -24,7 +24,9 @@ endif > > obj-$(CONFIG_USB_WHCI_HCD) += whci/ > > -obj-$(CONFIG_PCI) += pci-quirks.o > +ifneq ($(CONFIG_USB), ) > + obj-$(CONFIG_PCI) += pci-quirks.o > +endif > > obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o > obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
