From: valentin.longchamp@epfl.ch (Valentin Longchamp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] otg Kconfig: add missing select USB_OTG_UTILS to USB_ULPI option
Date: Wed, 20 Jan 2010 19:13:41 +0100 [thread overview]
Message-ID: <4B5747D5.9080104@epfl.ch> (raw)
In-Reply-To: <20100118084622.GA15054@pengutronix.de>
Hello Uwe,
Uwe Kleine-K?nig wrote:
> Hello Valentin,
>
> On Fri, Jan 15, 2010 at 06:32:11PM +0100, Valentin Longchamp wrote:
>> Fixes a link error for mx3 platforms with ULPI host devices enabled. Should go for rc5 since it completes http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f9ffaa9ca9889f17ef30b82bc0bf954d141280f8 that was introduced in rc4.
> Actually I think this is a seperate issue. f9ffaa9ca fixed arch code to
> only use ULPI if it is configured to be available, your patch asserts
> that the code is built-in for arch code if configured.
It is separate issue, but it is a direct sequel to that patch. And with
the current usage and code, the code must be built-in for arch code.
>
> The problem is that with CONFIG_USB_ULPI=y + CONFIG_USB<=m +
> CONFIGPCI=n + CONFIG_USB_OTG_UTILS=n drivers/usb/otg/ulpi.o isn't built-in.
Yeah, but that's how it is used now with all the platforms using
USB_ULPI (meaning some mx31 platforms).
>
> So there are several ways to fix it:
>
> - let CONFIG_USB_ULPI depend on CONFIG_USB_OTG_UTILS (as done here).
> As drivers/Makefile has:
>
> obj-$(CONFIG_USB_OTG_UTILS) += usb/otg/
>
> this works fine. The downside is that CONFIG_USB_ULPI doesn't really
> depend on CONFIG_USB_OTG_UTILS.
>
> - add to drivers/Makefile
>
> obj-$(CONFIG_USB_ULPI) += usb/otg/
>
> . That's not pretty.
>
> - rework the code that arch code doesn't need functions provided by
> drivers/usb/otg/ulpi.c. That's my favorite, but probably needs some
> work.
How would you achieve this ? I see a contradiction in the current status
of the code where the otg_transceiver struct sometimes needs some
functions that are generic (ULPI) or platform specific (with isp1105
serial transceiver for instance).
One way to do it would be add (a lot !) more fields in the
mxc_usbh_platform_data struct so that the otg_transceiver can then be
intialized in the ehci_mxc_drv_probe. How does this sound ?
>
> - extend Kconfig to have something like builtin-if-configured-modular.
> Then we could have:
>
> builtin-$(CONFIG_USB_ULPI) += ulpi.o
>
> in drivers/usb/otg/Makefile resulting in ulpi.o being linked into
> drivers/builtin.o even though drivers/usb wouldn't be considered for
> building in.
>
> Would be nice, but this looks more like a long-term-project.
Yeah, too long term and far beyond my scope of competencies.
>
> That doesn't mean I'm against Valentin's patch, but IMHO the commit log
> should at least contain the breaking config (i.e. CONFIG_USB_ULPI=y +
> CONFIG_USB<=m + CONFIG_PCI=n + CONFIG_USB_OTG_UTILS=n) and the resulting
> error (message).
>
I will change the commit log so that it contains this, and this will
allow 2.6.33 to build correctly for mx3 platforms with USB host
peripherals, while maybe we implement the above discussed solution.
Val
--
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEB3494, Station 9, CH-1015 Lausanne
next prev parent reply other threads:[~2010-01-20 18:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-15 17:32 [PATCH] otg Kconfig: add missing select USB_OTG_UTILS to USB_ULPI option Valentin Longchamp
2010-01-18 8:46 ` Uwe Kleine-König
2010-01-20 18:13 ` Valentin Longchamp [this message]
2010-01-20 18:26 ` [PATCH] otg Kconfig: select USB_OTG_UTILS wtih " Valentin Longchamp
2010-01-20 18:34 ` Uwe Kleine-König
2010-01-20 18:51 ` [PATCH] otg Kconfig: let USB_OTG_UTILS select " Valentin Longchamp
2010-01-20 19:02 ` Uwe Kleine-König
2010-01-20 19:06 ` Valentin Longchamp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B5747D5.9080104@epfl.ch \
--to=valentin.longchamp@epfl.ch \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).