On Wed, Mar 28, 2012 at 09:56:48AM -0700, Randy Dunlap wrote: > On 03/26/2012 01:16 PM, Greg KH wrote: > > > On Mon, Mar 26, 2012 at 04:06:59PM -0400, Alan Stern wrote: > >> On Mon, 26 Mar 2012, Greg KH wrote: > >> > >>> On Mon, Mar 26, 2012 at 09:58:36AM -0700, Randy Dunlap wrote: > >>>> On 03/25/2012 09:28 PM, Stephen Rothwell wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> Reminder: please do not add stuff destined for v3.5 to linux-next > >>>>> included trees/branches until after v3.4-rc1 has been released. > >>>>> > >>>>> Changes since 20120323: > >>>> > >>>> > >>>> > >>>> on x86_64: > >>>> > >>>> ERROR: "utf16s_to_utf8s" [drivers/usb/core/usbcore.ko] undefined! > >>>> ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined! > >>>> > >>>> Full randconfig file is attached. > >>> > >>> Odd, nothing in the usb core has changed in a while in this area, > >>> although we might have gotten some core dependancies mixed up for random > >>> configurations like this. > >> > >> This is puzzling. > >> > >> utf16s_to_utf8s is defined in fs/nls/nls_base.c, > >> which is built according to CONFIG_NLS (in fs/nls/Makefile), > >> which is selected by CONFIG_USB (in drivers/usb/Kconfig). > >> > >> But the config that Randy attached had CONFIG_USB set to M and > >> CONFIG_NLS not set. How is that possible? > >> > >> usb_speed_string is defined in drivers/usb/usb-common.c, > >> which is built according to CONFIG_USB_COMMON (in > >> drivers/usb/Makefile), > >> which defaults to Y if CONFIG_USB_SUPPORT and either > >> CONFIG_USB or CONFIG_USB_GADGET is set (in > >> drivers/usb/Kconfig). > >> > >> The problem here was that CONFIG_USB_SUPPORT isn't set but CONFIG_USB > >> is set to M. This used not to be possible, since CONFIG_USB was > >> defined inside an "if USB_SUPPORT" section. Maybe that got changed and > >> needs to be fixed (but > >> https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git thinks > >> it's still not possible). Or maybe Randy's tree is a little out of > >> date. > > > > Yeah, that is strange, thanks for looking into it. > > > > Randy, any thoughts? > > > It's weird. The same config file builds successfully on > linux-next of Mar. 27. > > I looked more at linux-next of Mar. 26 and found one problem: > in drivers/gpu/drm/Kconfig, there is a "select USB" that should be > protected by "depends on USB_ARCH_HAS_HCD". I did that and then > kconfig complained about unmet dependencies in drivers/gpu/drm/udl/Kconfig, > so I added the same "depends on" there. That led into an awful mess: > > drivers/video/Kconfig:36:error: recursive dependency detected! > drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER > drivers/gpu/drm/Kconfig:26: symbol DRM_KMS_HELPER is selected by DRM_UDL > drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD > drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI > drivers/usb/Kconfig:24: symbol USB_ARCH_HAS_OHCI depends on I2C > drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC > drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC > drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 > drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB > > and I don't know what to do with this. > > Anyway, I do think that the problem is in drivers/gpu/drm/Kconfig > and drivers/gpu/drm/udl/Kconfig. Ok, thanks for looking. I'm worried why DRM would care about USB, but maybe I don't want to know... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
