Skip to contentSkip to conversation

usb_nop_xceiv_register() missing when OTG built as modules

DISCUSSION NAK Kevin Hilman 5 participants 14 messages Mar 4, 2010 – May 26, 2010

Subsystems (6)
Arm (32-bit) USB Arm sub-architectures OMAP2+ support +2 more subsystems
lore
Share & tools
lore

Kevin Hilman

author
#0 lore raw

This just started happening with v2.6.33.

On OMAP3EVM, usb_nop_xceiv_register() is called in the board file, but if USB gadget support is built as a module, this causes a link error (below)

This is obviously broken, and this hook needs to be fixed to work when called as a module.

To reproduce, start with omap3_defconfig and change both USB host and gadget to be built as modules.

Kevin

[...]
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board-omap3evm.c:686: undefined reference to usb_nop_xceiv_register' arch/arm/mach-omap2/built-in.o: In function omap_4430sdp_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board-4430sdp.c:143: undefined reference to `usb_nop_xceiv_register' make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2

#1 lore raw
Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Kevin Hilman
Sent: Thursday, March 04, 2010 5:39 AM
To: [email protected]
Subject: usb_nop_xceiv_register() missing when OTG built as modules

Quoted 5 lines

This just started happening with v2.6.33.

On OMAP3EVM, usb_nop_xceiv_register() is called in the board file, but if USB gadget support is built as a module, this causes a link error (below)

Kevin,

usb_nop_xceiv_register() is defined at drivers/usb/otg/nop-usb-xceiv.c file which gets compiled if CONFIG_NOP_USB_XCEIV=y.

I think you have enabled CONFIG_NOP_USB_XCEIV as module?

Regards,
Ajay

Quoted 24 lines

This is obviously broken, and this hook needs to be fixed to work when called as a module.

To reproduce, start with omap3_defconfig and change both USB host and gadget to be built as modules.

Kevin

[...]
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- omap3evm.c:686: undefined reference to usb_nop_xceiv_register' arch/arm/mach-omap2/built-in.o: In function omap_4430sdp_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- 4430sdp.c:143: undefined reference to `usb_nop_xceiv_register' make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#2 lore raw
Quoted 13 lines · Ajay Kumar
Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Kevin Hilman
Sent: Thursday, March 04, 2010 5:39 AM
To: [email protected]
Subject: usb_nop_xceiv_register() missing when OTG built as modules

Quoted 5 lines

This just started happening with v2.6.33.

On OMAP3EVM, usb_nop_xceiv_register() is called in the board file, but if USB gadget support is built as a module, this causes a link error (below)

Quoted 6 lines

Kevin,

usb_nop_xceiv_register() is defined at drivers/usb/otg/nop-usb-xceiv.c file which gets compiled if CONFIG_NOP_USB_XCEIV=y.

I think you have enabled CONFIG_NOP_USB_XCEIV as module?

Yes, I did that intentionally. I *want* USB compiled as a module. If I do that, the build fails, and that's a bug that needs to be fixed.

Kevin

Quoted 25 lines
Quoted 25 lines

This is obviously broken, and this hook needs to be fixed to work when called as a module.

To reproduce, start with omap3_defconfig and change both USB host and gadget to be built as modules.

Kevin

[...]
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- omap3evm.c:686: undefined reference to usb_nop_xceiv_register' arch/arm/mach-omap2/built-in.o: In function omap_4430sdp_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- 4430sdp.c:143: undefined reference to `usb_nop_xceiv_register' make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 24 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, March 04, 2010 11:03 PM
To: Gupta, Ajay Kumar
Cc: [email protected]
Subject: Re: usb_nop_xceiv_register() missing when OTG built as modules

Quoted 15 lines · Ajay Kumar
Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Kevin Hilman
Sent: Thursday, March 04, 2010 5:39 AM
To: [email protected]
Subject: usb_nop_xceiv_register() missing when OTG built as modules

Quoted 5 lines

This just started happening with v2.6.33.

On OMAP3EVM, usb_nop_xceiv_register() is called in the board file, but if USB gadget support is built as a module, this causes a link error (below)

Kevin,

Quoted 8 lines
Quoted 1 line

usb_nop_xceiv_register() is defined at drivers/usb/otg/nop-usb-xceiv.c

file

Quoted 3 lines

which gets compiled if CONFIG_NOP_USB_XCEIV=y.

I think you have enabled CONFIG_NOP_USB_XCEIV as module?

Yes, I did that intentionally. I *want* USB compiled as a module. If I do that, the build fails, and that's a bug that needs to be fixed.

USB can still be compiled as module without any error if we choose CONFIG_NOP_USB_XCEIV=y. Any reason why you want NOP transceiver also as module ?

-Ajay

Quoted 30 lines

Kevin

Quoted 11 lines
Quoted 11 lines

This is obviously broken, and this hook needs to be fixed to work when called as a module.

To reproduce, start with omap3_defconfig and change both USB host and gadget to be built as modules.

Kevin

Quoted 12 lines
Quoted 4 lines

[...]
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board-

Quoted 8 lines

omap3evm.c:686: undefined reference to usb_nop_xceiv_register' arch/arm/mach-omap2/built-in.o: In function omap_4430sdp_init':
/opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- 4430sdp.c:143: undefined reference to `usb_nop_xceiv_register' make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"

in

Quoted 2 lines
Quoted 2 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
In reply to Kevin Hilman
Quoted 2 lines · ext Kevin Hilman

Yes, I did that intentionally. I *want* USB compiled as a module. If I do that, the build fails, and that's a bug that needs to be fixed.

it depends on where you're calling usb_nop_xceiv_register(), if you're calling from a file that's built-into the kernel, then it's your fault.

I suggest you keep usb as a module, but keep nop xceiv built-in.

Signature · 1 line
balbi
author
#5 lore raw
Quoted 5 lines · Felipe Balbi
Quoted 2 lines · ext Kevin Hilman

Yes, I did that intentionally. I *want* USB compiled as a module. If I do that, the build fails, and that's a bug that needs to be fixed.

it depends on where you're calling usb_nop_xceiv_register(),

It's called from various board files (board-omap3evm.c, board-4430sdp.c.)

Quoted 2 lines

if you're calling from a file that's built-into the kernel, then it's your fault.

It would be my fault if I wrote those board files. ;)

Quoted 1 line

I suggest you keep usb as a module, but keep nop xceiv built-in.

Yes, that's the workaround I'm already using, but it is not a fix.

This dependency breaks the ability to build a minimal kernel with everything as modules (allmodconfig)

The nop xceiv needs a way for built-in code to register itself for the cases when no xceiv is built as a module.

Kevin

#6 lore raw

On Fri, 05 Mar 2010 09:59:52 -0800, Kevin Hilman

Quoted 1 line

It would be my fault if I wrote those board files. ;)

sure, sorry. Maybe I didn't express myself really well.

Quoted 6 lines
Quoted 1 line

I suggest you keep usb as a module, but keep nop xceiv built-in.

Yes, that's the workaround I'm already using, but it is not a fix.

This dependency breaks the ability to build a minimal kernel with everything as modules (allmodconfig)

now this is a really good point. Haven't thought that way...

Quoted 2 lines

The nop xceiv needs a way for built-in code to register itself for the cases when no xceiv is built as a module.

when way to do that is not to use usb_nop_xceiv_register() and add the platform_device to the board-files. I never really liked the whole usb_nop_xceiv_register() hackery. Almost all board-files have a list of platform_devices which get added by platform_add_devices() anyways, so why not using that ??

to me the usb_nop_xceiv_register() thing is just a lazy way of defining platform_devices. Specially one that takes some 3 lines of code only.

Signature · 1 line
balbi
author
#7 lore raw
Quoted 23 lines · <[email protected]> writes:

On Fri, 05 Mar 2010 09:59:52 -0800, Kevin Hilman

Quoted 1 line

It would be my fault if I wrote those board files. ;)

sure, sorry. Maybe I didn't express myself really well.

Quoted 6 lines
Quoted 1 line

I suggest you keep usb as a module, but keep nop xceiv built-in.

Yes, that's the workaround I'm already using, but it is not a fix.

This dependency breaks the ability to build a minimal kernel with everything as modules (allmodconfig)

now this is a really good point. Haven't thought that way...

Quoted 2 lines

The nop xceiv needs a way for built-in code to register itself for the cases when no xceiv is built as a module.

when way to do that is not to use usb_nop_xceiv_register() and add the platform_device to the board-files. I never really liked the whole usb_nop_xceiv_register() hackery. Almost all board-files have a list of platform_devices which get added by platform_add_devices() anyways, so why not using that ??

Quoted 3 lines

to me the usb_nop_xceiv_register() thing is just a lazy way of defining platform_devices. Specially one that takes some 3 lines of code only.

Completely agree. I didn't take the time to look into the USB code to see if a simple plaform device creation would fix this.

If so, any chance of a patch for OMAP3EVM and 4430SDP?

I'll be happy to test on OMAP3EVM, but don't have a 4430.

Kevin

#8 lore raw
Quoted 29 lines · Kevin Hilman
Quoted 23 lines · <[email protected]> writes:

On Fri, 05 Mar 2010 09:59:52 -0800, Kevin Hilman

Quoted 1 line

It would be my fault if I wrote those board files. ;)

sure, sorry. Maybe I didn't express myself really well.

Quoted 6 lines
Quoted 1 line

I suggest you keep usb as a module, but keep nop xceiv built-in.

Yes, that's the workaround I'm already using, but it is not a fix.

This dependency breaks the ability to build a minimal kernel with everything as modules (allmodconfig)

now this is a really good point. Haven't thought that way...

Quoted 2 lines

The nop xceiv needs a way for built-in code to register itself for the cases when no xceiv is built as a module.

when way to do that is not to use usb_nop_xceiv_register() and add the platform_device to the board-files. I never really liked the whole usb_nop_xceiv_register() hackery. Almost all board-files have a list of platform_devices which get added by platform_add_devices() anyways, so why not using that ??

Quoted 3 lines

to me the usb_nop_xceiv_register() thing is just a lazy way of defining platform_devices. Specially one that takes some 3 lines of code only.

Quoted 8 lines

Completely agree. I didn't take the time to look into the USB code to see if a simple plaform device creation would fix this.

If so, any chance of a patch for OMAP3EVM and 4430SDP?

I'll be happy to test on OMAP3EVM, but don't have a 4430.

Kevin

Here is a compile-tested patch since I haven't seen this fixed in mainline yet. It applies to the tip of Linus' tree.

Attempting to remove usb_nop_xceiv_register() completely will require someone with more knowledge of davinci and blackfin archs to comment on what boards need the platform_device defined.

Cheers,
Amit

Quoted 1 line

From 3df714f995b0895e905090760482194233f66a1d Mon Sep 17 00:00:00 2001

Message-Id: <3df714f995b0895e905090760482194233f66a1d.1274570700.git.amit.kucheria@canonical.com>
From: Amit Kucheria <[email protected]>
Date: Sun, 23 May 2010 01:35:00 +0300
Subject: [PATCH] omap: remove calls to usb_nop_xceiv_register from board files

This will allow the OMAP USB drivers to be compiled in as modules. At the moment, CONFIG_NOP_USB_XCEIV cannot be a module.

Signed-off-by Amit Kucheria <[email protected]>
---
 arch/arm/mach-omap2/board-4430sdp.c  |   10 ++++++++--
 arch/arm/mach-omap2/board-omap3evm.c |   11 ++++++++---
 2 files changed, 16 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/board-4430sdp.c +8 -2
index e4a5d66..131f0fd 100644
@@ -110,8 +110,16 @@ static struct platform_device sdp4430_lcd_device = {
 	.id		= -1,
 };
 
+static struct platform_device sdp4430_nop_usb_device = {
+	.name		= "nop_usb_xceiv",
+	.id		= -1,
+	.resource	= NULL,
+	.num_resources	= 0,
+};
+
 static struct platform_device *sdp4430_devices[] __initdata = {
 	&sdp4430_lcd_device,
+	&sdp4430_nop_usb_device,
 };
 
 static struct omap_lcd_config sdp4430_lcd_config __initdata = {

@@ -374,8 +382,6 @@ static void __init omap_4430sdp_init(void)
 	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
 	omap_serial_init();
 	omap4_twl6030_hsmmc_init(mmc);
-	/* OMAP4 SDP uses internal transceiver so register nop transceiver */
-	usb_nop_xceiv_register();
 	/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
 	if (!cpu_is_omap44xx())
 		usb_musb_init(&musb_board_data);
arch/arm/mach-omap2/board-omap3evm.c +8 -3
index 81bba19..456e218 100644
@@ -620,6 +620,13 @@ struct spi_board_info omap3evm_spi_board_info[] = {
 	},
 };
 
+static struct platform_device omap3_evm_nop_usb_device = {
+	.name		= "nop_usb_xceiv",
+	.id		= -1,
+	.resource	= NULL,
+	.num_resources	= 0,
+};
+
 static struct omap_board_config_kernel omap3_evm_config[] __initdata = {
 };
 

@@ -634,6 +641,7 @@ static void __init omap3_evm_init_irq(void)
 
 static struct platform_device *omap3_evm_devices[] __initdata = {
 	&omap3_evm_dss_device,
+	&omap3_evm_nop_usb_device,
 };
 
 static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {

@@ -682,9 +690,6 @@ static void __init omap3_evm_init(void)
 
 	omap_serial_init();
 
-	/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
-	usb_nop_xceiv_register();
-
 	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
 		/* enable EHCI VBUS using GPIO22 */
 		omap_mux_init_gpio(22, OMAP_PIN_INPUT_PULLUP);
Signature · 1 line
1.7.0.4
NAK
#9 lore raw

Hi,

Quoted 8 lines

Here is a compile-tested patch since I haven't seen this fixed in mainline yet. It applies to the tip of Linus' tree.

Attempting to remove usb_nop_xceiv_register() completely will require someone
with more knowledge of davinci and blackfin archs to comment on what boards
need the platform_device defined.

NAK..
This is an incorrect fix as it duplicates the code snippet which is already present in nop file.

Here is a better fix for this (patch attached below). The approach in this patch has already been discussed and was not agreed and I was asked to move nop registration to board files.

------------ cut here ------------------
NOP transceiver is getting registered in board files of OAMP3EVM and OMAP4430 SDP as they use ISP150x and internal transceivers.

This registration in board file forces NOP transceiver to be built into the kernel.

Fixing this by removing NOP tranceiver from board files to omap platform file within musb driver.

Signed-off-by Ajay Kumar Gupta <[email protected]>
---
 arch/arm/mach-omap2/board-4430sdp.c  |    3 ---
 arch/arm/mach-omap2/board-omap3evm.c |    4 ----
 drivers/usb/musb/omap2430.c          |   11 ++++++++++-
 3 files changed, 10 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/board-4430sdp.c +0 -3
index e4a5d66..77af4c9 100644
@@ -17,7 +17,6 @@
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/gpio.h>
-#include <linux/usb/otg.h>
 #include <linux/spi/spi.h>
 #include <linux/i2c/twl.h>
 #include <linux/regulator/machine.h>

@@ -374,8 +373,6 @@ static void __init omap_4430sdp_init(void)
 	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
 	omap_serial_init();
 	omap4_twl6030_hsmmc_init(mmc);
-	/* OMAP4 SDP uses internal transceiver so register nop transceiver */
-	usb_nop_xceiv_register();
 	/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
 	if (!cpu_is_omap44xx())
 		usb_musb_init(&musb_board_data);
arch/arm/mach-omap2/board-omap3evm.c +0 -4
index 81bba19..83d3aa5 100644
@@ -27,7 +27,6 @@
 #include <linux/spi/spi.h>
 #include <linux/spi/ads7846.h>
 #include <linux/i2c/twl.h>
-#include <linux/usb/otg.h>
 #include <linux/smsc911x.h>
 
 #include <linux/regulator/machine.h>

@@ -682,9 +681,6 @@ static void __init omap3_evm_init(void)
 
 	omap_serial_init();
 
-	/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
-	usb_nop_xceiv_register();
-
 	if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
 		/* enable EHCI VBUS using GPIO22 */
 		omap_mux_init_gpio(22, OMAP_PIN_INPUT_PULLUP);
drivers/usb/musb/omap2430.c +10 -1
index e06d65e..58acd0c 100644
@@ -198,6 +198,13 @@ int __init musb_platform_init(struct musb *musb, void *board_data)
 	omap_cfg_reg(AE5_2430_USB0HS_STP);
 #endif
 
+#if defined(CONFIG_MACH_OMAP3EVM) || defined(CONFIG_MACH_OMAP_4430SDP)
+	/* OMAP3EVM used ISP150x and OMAP4 SDP uses internal transceiver
+	 * so register nop transceiver
+	 */
+	usb_nop_xceiv_register();
+#endif
+
 	/* We require some kind of external transceiver, hooked
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.

@@ -325,6 +332,8 @@ int musb_platform_exit(struct musb *musb)
 {
 
 	musb_platform_suspend(musb);
-
+#if defined(CONFIG_MACH_OMAP3EVM) || defined(CONFIG_MACH_OMAP_4430SDP)
+	usb_nop_xceiv_unregister();
+#endif
 	return 0;
 }
Signature · 5 lines
1.6.2.4
----------------------------------------

Regards,
Ajay
Quoted 3 lines

Cheers,
Amit

#13 lore raw
In reply to Amit Kucheria

Hi,

Quoted 20 lines · ext Amit Kucheria

From 3df714f995b0895e905090760482194233f66a1d Mon Sep 17 00:00:00 2001
Message-Id: <3df714f995b0895e905090760482194233f66a1d.1274570700.git.amit.kucheria@canonical.com>
From: Amit Kucheria <[email protected]>
Date: Sun, 23 May 2010 01:35:00 +0300
Subject: [PATCH] omap: remove calls to usb_nop_xceiv_register from board files

This will allow the OMAP USB drivers to be compiled in as modules. At the moment, CONFIG_NOP_USB_XCEIV cannot be a module.

Signed-off-by Amit Kucheria <[email protected]>

---

arch/arm/mach-omap2/board-4430sdp.c  |   10 ++++++++--
arch/arm/mach-omap2/board-omap3evm.c |   11 ++++++++---
2 files changed, 16 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/board-4430sdp.c +0 -0
index e4a5d66..131f0fd 100644

arch/arm/mach-omap2/board-4430sdp.c static struct platform_device sdp4430_lcd_device = { · line 117

Quoted 8 lines
arch/arm/mach-omap2/board-4430sdp.c +5 -0
@@ -110,8 +110,16 @@ static struct platform_device sdp4430_lcd_device = {
 	.id		= -1,
 };
 
+static struct platform_device sdp4430_nop_usb_device = {
+	.name		= "nop_usb_xceiv",
+	.id		= -1,
+	.resource	= NULL,
+	.num_resources	= 0,

you don't need to zero-initialize a static variable. So you can just drop .resource and .num_resources altogether.

Signature · 3 lines
balbi

DefectiveByDesign.org
#10 lore raw
In reply to Gupta, Ajay Kumar
Quoted 10 lines · Ajay Kumar

Hi,

Quoted 8 lines

Here is a compile-tested patch since I haven't seen this fixed in mainline yet. It applies to the tip of Linus' tree.

Attempting to remove usb_nop_xceiv_register() completely will require someone
with more knowledge of davinci and blackfin archs to comment on what boards
need the platform_device defined.

Quoted 3 lines

NAK..
This is an incorrect fix as it duplicates the code snippet which is already present in nop file.

I don't believe you understood the purpose of the original patch:

The idea is that currently, it's impossible to build a board which uses nop transceiver and have that be a module because when you'll have an undefined function being used on a board file.

Removing the call to nop_xceiv_register() and using a platform_device_register() is the way to go, since it's only 4 ~ 5 lines of code anyway.

ps: you really think that adding more and more ifdefs is better than Amit's patch ??

Signature · 3 lines
balbi

DefectiveByDesign.org
#11 lore raw

Hi,

Quoted 7 lines · Ajay Kumar
Quoted 6 lines
Quoted 5 lines

Attempting to remove usb_nop_xceiv_register() completely will require someone
with more knowledge of davinci and blackfin archs to comment on what boards
need the platform_device defined.

Quoted 5 lines
Quoted 3 lines

NAK..
This is an incorrect fix as it duplicates the code snippet which is already present in nop file.

I don't believe you understood the purpose of the original patch:

I did and that's why an alternative patch.

Quoted 3 lines

The idea is that currently, it's impossible to build a board which uses nop transceiver and have that be a module because when you'll have an undefined function being used on a board file.

I know.

Quoted 4 lines

Removing the call to nop_xceiv_register() and using a platform_device_register() is the way to go, since it's only 4 ~ 5 lines of code anyway.

4 ~5 lines would keep on repeating for all current and future boards requiring to use NOP.

Quoted 3 lines

ps: you really think that adding more and more ifdefs is better than Amit's patch ??

Yes, when compared to the approach of repeating those 4 ~5 line in all the board files requiring NOP.

-Ajay

Quoted 3 lines

--
balbi

#12 lore raw
In reply to Felipe Balbi
Quoted 2 lines

ps: you really think that adding more and more ifdefs is better than Amit's patch ??

We can avoid using #ifdefs by introducing '.neednop' flag to board_data. Here is the patch for this which can be used on top of my earlier patch.

------------------- cut here ---------------

arch/arm/mach-omap2/board-4430sdp.c +1 -0
index 77af4c9..fb29837 100644
@@ -137,6 +137,7 @@ static struct omap_musb_board_data musb_board_data = {
 	.interface_type		= MUSB_INTERFACE_UTMI,
 	.mode			= MUSB_PERIPHERAL,
 	.power			= 100,
+	.neednop		= 1,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
arch/arm/mach-omap2/board-omap3evm.c +1 -0
index 83d3aa5..609f021 100644
@@ -665,6 +665,7 @@ static struct omap_musb_board_data musb_board_data = {
 	.interface_type		= MUSB_INTERFACE_ULPI,
 	.mode			= MUSB_OTG,
 	.power			= 100,
+	.neednop		= 1,
 };
 
 static void __init omap3_evm_init(void)
arch/arm/plat-omap/include/plat/usb.h +1 -0
index a32d3af..b53489a 100644
@@ -69,6 +69,7 @@ struct omap_musb_board_data {
 	u8	mode;
 	u16	power;
 	unsigned extvbus:1;
+	unsigned neednop:1;	/* NOP transceiver */
 };
 
 enum musb_interface    {MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
drivers/usb/musb/musb_core.c +1 -0
index e71049c..b774312 100644
@@ -1964,6 +1964,7 @@ bad_config:
 	musb->board_set_power = plat->set_power;
 	musb->set_clock = plat->set_clock;
 	musb->min_power = plat->min_power;
+	musb->board_data = plat->board_data;
 
 	/* Clock usage is chip-specific ... functional clock (DaVinci,
 	 * OMAP2430), or PHY ref (some TUSB6010 boards).  All this core
drivers/usb/musb/musb_core.h +1 -0
index eaabf98..b72e2e5 100644
@@ -392,6 +392,7 @@ struct musb {
 	int			(*board_set_power)(int state);
 
 	int			(*set_clock)(struct clk *clk, int is_active);
+	void			*board_data;
 
 	u8			min_power;	/* vbus for periph, in mA/2 */
drivers/usb/musb/omap2430.c +5 -6
index 58acd0c..8488a23 100644
@@ -198,12 +198,11 @@ int __init musb_platform_init(struct musb *musb, void *board_data)
 	omap_cfg_reg(AE5_2430_USB0HS_STP);
 #endif
 
-#if defined(CONFIG_MACH_OMAP3EVM) || defined(CONFIG_MACH_OMAP_4430SDP)
 	/* OMAP3EVM used ISP150x and OMAP4 SDP uses internal transceiver
 	 * so register nop transceiver
 	 */
-	usb_nop_xceiv_register();
-#endif
+	if (data->neednop)
+		usb_nop_xceiv_register();
 
 	/* We require some kind of external transceiver, hooked
 	 * up through ULPI.  TWL4030-family PMICs include one,

@@ -330,10 +329,10 @@ static int musb_platform_resume(struct musb *musb)
 
 int musb_platform_exit(struct musb *musb)
 {
+	struct omap_musb_board_data *data = musb->board_data;
 
 	musb_platform_suspend(musb);
-#if defined(CONFIG_MACH_OMAP3EVM) || defined(CONFIG_MACH_OMAP_4430SDP)
-	usb_nop_xceiv_unregister();
-#endif
+	if (data->neednop)
+		usb_nop_xceiv_unregister();
 	return 0;
 }

--------------------------------------------
-Ajay

Quoted 5 lines

--
balbi

DefectiveByDesign.org