[PATCH] otg Kconfig: add missing select USB_OTG_UTILS to USB_ULPI option

[PATCH] otg Kconfig: add missing select USB_OTG_UTILS to USB_ULPI option

[Valentin Longchamp]

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.

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 drivers/usb/otg/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index de56b3d..3d2d3e5 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -44,6 +44,7 @@ config ISP1301_OMAP
 config USB_ULPI
 	bool "Generic ULPI Transceiver Driver"
 	depends on ARM
+	select USB_OTG_UTILS
 	help
 	  Enable this to support ULPI connected USB OTG transceivers which
 	  are likely found on embedded boards.
-- 
1.6.3.3

[PATCH] otg Kconfig: add missing select USB_OTG_UTILS to USB_ULPI option

[Uwe Kleine-König]

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.

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.

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.

 - 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.

That doesn't mean I'm against Valentin's patch, but IMHO the commit log
should@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).

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

[PATCH] otg Kconfig: add missing select USB_OTG_UTILS to USB_ULPI option

[Valentin Longchamp]

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

[PATCH] otg Kconfig: select USB_OTG_UTILS wtih USB_ULPI option

[Valentin Longchamp]

With CONFIG_USB_ULPI=y, CONFIG_USB<=m, CONFIG_PCI=n and
CONFIG_USB_OTG_UTILS=n, which is the default used for mx31moboard,
the build of all mx3 platform fails because drivers/usb/otg/ulpi.c
where otg_ulpi_create lies is not built.

Build error:
arch/arm/mach-mx3/built-in.o: In function `mxc_board_init':
kzmarm11.c:(.init.text+0x73c): undefined reference to `otg_ulpi_create'
kzmarm11.c:(.init.text+0x1020): undefined reference to `otg_ulpi_create'

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 drivers/usb/otg/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index de56b3d..3d2d3e5 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -44,6 +44,7 @@ config ISP1301_OMAP
 config USB_ULPI
 	bool "Generic ULPI Transceiver Driver"
 	depends on ARM
+	select USB_OTG_UTILS
 	help
 	  Enable this to support ULPI connected USB OTG transceivers which
 	  are likely found on embedded boards.
-- 
1.6.3.3

[PATCH] otg Kconfig: select USB_OTG_UTILS wtih USB_ULPI option

[Uwe Kleine-König]

Hi Valentin,

s/wtih/with/ in the Subject.  Or maybe still better:  

	otg Kconfig: let USB_ULPI select USB_OTG_UTILS

On Wed, Jan 20, 2010 at 07:26:11PM +0100, Valentin Longchamp wrote:
> With CONFIG_USB_ULPI=y, CONFIG_USB<=m, CONFIG_PCI=n and
> CONFIG_USB_OTG_UTILS=n, which is the default used for mx31moboard,
> the build of all mx3 platform fails because drivers/usb/otg/ulpi.c
> where otg_ulpi_create lies is not built.
s/ulpi.c/ulpi.o/ or s/built/compiled/

s/lies/is defined/

> Build error:
> arch/arm/mach-mx3/built-in.o: In function `mxc_board_init':
> kzmarm11.c:(.init.text+0x73c): undefined reference to `otg_ulpi_create'
> kzmarm11.c:(.init.text+0x1020): undefined reference to `otg_ulpi_create'
And maybe add something like:

	This isn't a strong dependency as drivers/usb/otg/ulpi.c doesn't
	use functions defined in drivers/usb/otg/otg.o and is only
	needed to get ulpi.o linked into the kernel image.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

[PATCH] otg Kconfig: let USB_OTG_UTILS select USB_ULPI option

[Valentin Longchamp]

With CONFIG_USB_ULPI=y, CONFIG_USB<=m, CONFIG_PCI=n and
CONFIG_USB_OTG_UTILS=n, which is the default used for mx31moboard,
the build of all mx3 platform fails because drivers/usb/otg/ulpi.c
where otg_ulpi_create is defined is not compiled.

Build error:
arch/arm/mach-mx3/built-in.o: In function `mxc_board_init':
kzmarm11.c:(.init.text+0x73c): undefined reference to `otg_ulpi_create'
kzmarm11.c:(.init.text+0x1020): undefined reference to `otg_ulpi_create'

This isn't a strong dependency as drivers/usb/otg/ulpi.c doesn't
use functions defined in drivers/usb/otg/otg.o and is only needed
to get ulpi.o linked into the kernel image.

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 drivers/usb/otg/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index de56b3d..3d2d3e5 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -44,6 +44,7 @@ config ISP1301_OMAP
 config USB_ULPI
 	bool "Generic ULPI Transceiver Driver"
 	depends on ARM
+	select USB_OTG_UTILS
 	help
 	  Enable this to support ULPI connected USB OTG transceivers which
 	  are likely found on embedded boards.
-- 
1.6.3.3

[PATCH] otg Kconfig: let USB_OTG_UTILS select USB_ULPI option

[Uwe Kleine-König]

On Wed, Jan 20, 2010 at 07:51:48PM +0100, Valentin Longchamp wrote:
> With CONFIG_USB_ULPI=y, CONFIG_USB<=m, CONFIG_PCI=n and
> CONFIG_USB_OTG_UTILS=n, which is the default used for mx31moboard,
> the build of all mx3 platform fails because drivers/usb/otg/ulpi.c
> where otg_ulpi_create is defined is not compiled.
> 
> Build error:
> arch/arm/mach-mx3/built-in.o: In function `mxc_board_init':
> kzmarm11.c:(.init.text+0x73c): undefined reference to `otg_ulpi_create'
> kzmarm11.c:(.init.text+0x1020): undefined reference to `otg_ulpi_create'
> 
> This isn't a strong dependency as drivers/usb/otg/ulpi.c doesn't
> use functions defined in drivers/usb/otg/otg.o and is only needed
> to get ulpi.o linked into the kernel image.
> 
> Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
provided you do s/platform/platforms/ above, you get my

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

(Is it better to say "build *for* all mx3 platforms"?)

Thanks
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

[PATCH] otg Kconfig: let USB_OTG_UTILS select USB_ULPI option

[Valentin Longchamp]

With CONFIG_USB_ULPI=y, CONFIG_USB<=m, CONFIG_PCI=n and
CONFIG_USB_OTG_UTILS=n, which is the default used for mx31moboard,
the build for all mx3 platforms fails because drivers/usb/otg/ulpi.c
where otg_ulpi_create is defined is not compiled.

Build error:
arch/arm/mach-mx3/built-in.o: In function `mxc_board_init':
kzmarm11.c:(.init.text+0x73c): undefined reference to `otg_ulpi_create'
kzmarm11.c:(.init.text+0x1020): undefined reference to `otg_ulpi_create'

This isn't a strong dependency as drivers/usb/otg/ulpi.c doesn't
use functions defined in drivers/usb/otg/otg.o and is only needed
to get ulpi.o linked into the kernel image.

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 drivers/usb/otg/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index de56b3d..3d2d3e5 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -44,6 +44,7 @@ config ISP1301_OMAP
 config USB_ULPI
 	bool "Generic ULPI Transceiver Driver"
 	depends on ARM
+	select USB_OTG_UTILS
 	help
 	  Enable this to support ULPI connected USB OTG transceivers which
 	  are likely found on embedded boards.
-- 
1.6.3.3