[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F7342D0.1010706@xenotime.net>
Date: Wed, 28 Mar 2012 09:56:48 -0700
From: Randy Dunlap <rdunlap@...otime.net>
To: Greg KH <gregkh@...uxfoundation.org>
CC: Alan Stern <stern@...land.harvard.edu>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linux-usb@...r.kernel.org
Subject: Re: linux-next: Tree for Mar 26 (usbcore)
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.
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists