Skip to contentSkip to conversation

musb as module broken in 2.6.38

DISCUSSION Alexander Holler 2 participants 12 messages Mar 16, 2011

lore
Share & tools
lore

Alexander Holler

author
#0 lore raw

Hello,

in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the platform-driver was splitted and musb-omap2430 is used for several boards (arch/arm/mach-omap2/usb-musb.c).

But musb_hdrc still uses musb-hdrc as name when platform_driver_probe() is called. The result is that loading the driver (when build as a module) doesn't work anymore (it doesn't find the platform-device).

Do I miss something or was something forgotten when the glue-layers for musb got introduced?

(The driver still works when linked into the kernel, but is disfunctional when build as a module.)

Regards,

Alexander Holler

#1 lore raw

Hi,

Quoted 9 lines · Alexander Holler

in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the platform-driver was splitted and musb-omap2430 is used for several boards (arch/arm/mach-omap2/usb-musb.c).

But musb_hdrc still uses musb-hdrc as name when platform_driver_probe() is called. The result is that loading the driver (when build as a module) doesn't work anymore (it doesn't find the platform-device).

Quoted 5 lines

Do I miss something or was something forgotten when the glue-layers for musb got introduced?

(The driver still works when linked into the kernel, but is disfunctional when build as a module.)

Send me the output you get on console and a snippet of the .config with the MUSB section.

Signature · 1 line
balbi
author
#2 lore raw

Am 16.03.2011 10:03, schrieb Felipe Balbi:

Quoted 12 lines

Hi,

Quoted 9 lines · Alexander Holler

in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the platform-driver was splitted and musb-omap2430 is used for several boards (arch/arm/mach-omap2/usb-musb.c).

But musb_hdrc still uses musb-hdrc as name when platform_driver_probe() is called. The result is that loading the driver (when build as a module) doesn't work anymore (it doesn't find the platform-device).

Quoted 8 lines
Quoted 5 lines

Do I miss something or was something forgotten when the glue-layers for musb got introduced?

(The driver still works when linked into the kernel, but is disfunctional when build as a module.)

Send me the output you get on console and a snippet of the .config with the MUSB section.

I don't see the need for it, but here it is:

------------
beagle linux # grep -i MUSB .config
CONFIG_USB_MUSB_HDRC=m
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_PERIPHERAL is not set
CONFIG_USB_MUSB_OTG=y
CONFIG_USB_GADGET_MUSB_HDRC=y
CONFIG_USB_MUSB_HDRC_HCD=y
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_MUSB_DEBUG=y
beagle linux # modprobe musb_hdrc
FATAL: Error inserting musb_hdrc (/lib/modules/2.6.38-beagleboard-00002-g0017ea0-dirty/kernel/drivers/usb/musb/musb_hdrc.ko): No such device beagle linux # tail -n 1 /var/log/messages

Mar 16 10:37:51 beagle kernel: [  177.302825] musb-hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=5

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430
------------

The problem in detail:

Through modprobe musb_core.c:musb_init() is called, and this calls platform_driver_probe() with a pointer to a struct of platform_device where the name is musb-hdrc. drivers/base/platform.c:platform_driver_probe() fails with -ENODEV because it doesn't find a platform device with the name musb-hdrc (list_empty()) which is understandable because the platform-device has the name musb-omap2430.

Regards,

Alexander Holler

#3 lore raw
Quoted 49 lines · Alexander Holler

Am 16.03.2011 10:03, schrieb Felipe Balbi:

Quoted 12 lines

Hi,

Quoted 9 lines · Alexander Holler

in commit dc09886bfa781e2b442301116c18199519e36f0f the name of the platform-driver was splitted and musb-omap2430 is used for several boards (arch/arm/mach-omap2/usb-musb.c).

But musb_hdrc still uses musb-hdrc as name when platform_driver_probe() is called. The result is that loading the driver (when build as a module) doesn't work anymore (it doesn't find the platform-device).

Quoted 8 lines
Quoted 5 lines

Do I miss something or was something forgotten when the glue-layers for musb got introduced?

(The driver still works when linked into the kernel, but is disfunctional when build as a module.)

Send me the output you get on console and a snippet of the .config with the MUSB section.

I don't see the need for it, but here it is:

------------
beagle linux # grep -i MUSB .config
CONFIG_USB_MUSB_HDRC=m
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_PERIPHERAL is not set
CONFIG_USB_MUSB_OTG=y
CONFIG_USB_GADGET_MUSB_HDRC=y
CONFIG_USB_MUSB_HDRC_HCD=y
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_MUSB_DEBUG=y
beagle linux # modprobe musb_hdrc
FATAL: Error inserting musb_hdrc (/lib/modules/2.6.38-beagleboard-00002-g0017ea0-dirty/kernel/drivers/usb/musb/musb_hdrc.ko):
No such device
beagle linux # tail -n 1 /var/log/messages

Mar 16 10:37:51 beagle kernel: [  177.302825] musb-hdrc: version 6.0,

musb-dma, otg (peripheral+host), debug=5 beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430
------------

The problem in detail:

Quoted 7 lines

Through modprobe musb_core.c:musb_init() is called, and this calls platform_driver_probe() with a pointer to a struct of platform_device where the name is musb-hdrc. drivers/base/platform.c:platform_driver_probe() fails with -ENODEV because it doesn't find a platform device with the name musb-hdrc (list_empty()) which is understandable because the platform-device has the name musb-omap2430.

look further, omap2430.c allocates musb-hdrc platform_device. The problem is a different one.

static int __init omap2430_probe(struct platform_device *pdev)

{
	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
	struct platform_device		*musb;
	struct omap2430_glue		*glue;
	struct clk			*clk;

	int				ret = -ENOMEM;

	glue = kzalloc(sizeof(*glue), GFP_KERNEL);
	if (!glue) {
		dev_err(&pdev->dev, "failed to allocate glue context\n");
		goto err0;
	}

	musb = platform_device_alloc("musb-hdrc", -1);
	if (!musb) {
		dev_err(&pdev->dev, "failed to allocate musb device\n");
		goto err1;
	}
Signature · 1 line
balbi
author
#4 lore raw

Am 16.03.2011 10:55, schrieb Felipe Balbi:

Quoted 34 lines · Alexander Holler
Quoted 25 lines

------------
beagle linux # grep -i MUSB .config
CONFIG_USB_MUSB_HDRC=m
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_PERIPHERAL is not set
CONFIG_USB_MUSB_OTG=y
CONFIG_USB_GADGET_MUSB_HDRC=y
CONFIG_USB_MUSB_HDRC_HCD=y
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_MUSB_DEBUG=y
beagle linux # modprobe musb_hdrc
FATAL: Error inserting musb_hdrc (/lib/modules/2.6.38-beagleboard-00002-g0017ea0-dirty/kernel/drivers/usb/musb/musb_hdrc.ko):
No such device
beagle linux # tail -n 1 /var/log/messages

Mar 16 10:37:51 beagle kernel: [  177.302825] musb-hdrc: version 6.0,

musb-dma, otg (peripheral+host), debug=5 beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430
------------

The problem in detail:

Quoted 7 lines

Through modprobe musb_core.c:musb_init() is called, and this calls platform_driver_probe() with a pointer to a struct of platform_device where the name is musb-hdrc. drivers/base/platform.c:platform_driver_probe() fails with -ENODEV because it doesn't find a platform device with the name musb-hdrc (list_empty()) which is understandable because the platform-device has the name musb-omap2430.

Quoted 4 lines

look further, omap2430.c allocates musb-hdrc platform_device. The problem is a different one.

static int __init omap2430_probe(struct platform_device *pdev)

Neither omap2430_init() nor omap2430_probe() will be called here.

Regards,

Alexander Holler

#5 lore raw

Hi,

Quoted 3 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

(ps: sorry if it's mis-formatted, I'm on the go, not using my laptop)

Signature · 1 line
balbi
author
#6 lore raw

Am 16.03.2011 11:24, schrieb Felipe Balbi:

Quoted 11 lines

Hi,

Quoted 3 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

Don't know, I haven't written or changed the driver. ;)

But I will look (later) if I will find the reason.

Regards,

Alexander Holler

#7 lore raw

hi,

Quoted 6 lines · Alexander Holler

Am 16.03.2011 11:24, schrieb Felipe Balbi:

Quoted 5 lines

Hi,

Quoted 2 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

Don't know, I haven't written or changed the driver. ;)

hehe, Just thought that you had something in mind already.

probe() functions are called when, in case of platform_devices, the name matches with driver name. musb-omap2430 platform_device is allocated in arch/arm/mach-omap2/usb-musb.c, then musb-2430 driver lives in drivers/usb/musb/omap2430.c. musb-2430 allocates a platform_device for musb-hdrc core driver.

We did that because the same core is used in many different platforms (OMAP, discrete chips, ST-Ericsson, DaVinci, PCI cards, etc) so we needed to "abstract" platform-specific details such as clock handling and power management.

There's still work to be done, for sure, e.g. the DMA part is still quite screwed up, but the drivers are correctly named which means they should be matching and probing. Now, musb-hdrc isn't probing, as you say, and I'd like to know why. I'll try to spend some time in it when I get back to the office.

Signature · 1 line
balbi
author
#8 lore raw

Am 16.03.2011 11:38, schrieb Felipe Balbi:

Quoted 31 lines

hi,

Quoted 6 lines · Alexander Holler

Am 16.03.2011 11:24, schrieb Felipe Balbi:

Quoted 5 lines

Hi,

Quoted 2 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

Don't know, I haven't written or changed the driver. ;)

hehe, Just thought that you had something in mind already.

probe() functions are called when, in case of platform_devices, the name matches with driver name. musb-omap2430 platform_device is allocated in arch/arm/mach-omap2/usb-musb.c, then musb-2430 driver lives in drivers/usb/musb/omap2430.c. musb-2430 allocates a platform_device for musb-hdrc core driver.

We did that because the same core is used in many different platforms (OMAP, discrete chips, ST-Ericsson, DaVinci, PCI cards, etc) so we needed to "abstract" platform-specific details such as clock handling and power management.

Quoted 5 lines

There's still work to be done, for sure, e.g. the DMA part is still quite screwed up, but the drivers are correctly named which means they should be matching and probing. Now, musb-hdrc isn't probing, as you say, and I'd like to know why. I'll try to spend some time in it when I get back to the office.

I currently assume it's something with

subsys_initcall(omap2430_init);

Have to read about subsys_initcall() and why omap2430_init isn't called here.

Regards,

Alexander Holler

#9 lore raw

Hi,

Quoted 38 lines · Alexander Holler

Am 16.03.2011 11:38, schrieb Felipe Balbi:

Quoted 31 lines

hi,

Quoted 6 lines · Alexander Holler

Am 16.03.2011 11:24, schrieb Felipe Balbi:

Quoted 5 lines

Hi,

Quoted 2 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

Don't know, I haven't written or changed the driver. ;)

hehe, Just thought that you had something in mind already.

probe() functions are called when, in case of platform_devices, the name matches with driver name. musb-omap2430 platform_device is allocated in arch/arm/mach-omap2/usb-musb.c, then musb-2430 driver lives in drivers/usb/musb/omap2430.c. musb-2430 allocates a platform_device for musb-hdrc core driver.

We did that because the same core is used in many different platforms (OMAP, discrete chips, ST-Ericsson, DaVinci, PCI cards, etc) so we needed to "abstract" platform-specific details such as clock handling and power management.

Quoted 5 lines

There's still work to be done, for sure, e.g. the DMA part is still quite screwed up, but the drivers are correctly named which means they should be matching and probing. Now, musb-hdrc isn't probing, as you say, and I'd like to know why. I'll try to spend some time in it when I get back to the office.

Quoted 5 lines

I currently assume it's something with

subsys_initcall(omap2430_init);

Have to read about subsys_initcall() and why omap2430_init isn't called here.

I guess I know what the problem is. If you search for omap2430_init in vmlinux it won't be there. I guess when a directory is marked as obj-m, Kbuild won't search for symbols to be statically linked to vmlinux on that directory. Since we use the same Kconfig entry to select musb as module and include drivers/usb/musb directory into build system, we are falling into that case.

Try changing drivers/usb/musb to obj-y in drivers/Makefile and see if things start working.

Signature · 1 line
balbi
author
#10 lore raw

Am 16.03.2011 11:48, schrieb Felipe Balbi:

Quoted 55 lines

Hi,

Quoted 38 lines · Alexander Holler

Am 16.03.2011 11:38, schrieb Felipe Balbi:

Quoted 31 lines

hi,

Quoted 6 lines · Alexander Holler

Am 16.03.2011 11:24, schrieb Felipe Balbi:

Quoted 5 lines

Hi,

Quoted 2 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

Don't know, I haven't written or changed the driver. ;)

hehe, Just thought that you had something in mind already.

probe() functions are called when, in case of platform_devices, the name matches with driver name. musb-omap2430 platform_device is allocated in arch/arm/mach-omap2/usb-musb.c, then musb-2430 driver lives in drivers/usb/musb/omap2430.c. musb-2430 allocates a platform_device for musb-hdrc core driver.

We did that because the same core is used in many different platforms (OMAP, discrete chips, ST-Ericsson, DaVinci, PCI cards, etc) so we needed to "abstract" platform-specific details such as clock handling and power management.

Quoted 5 lines

There's still work to be done, for sure, e.g. the DMA part is still quite screwed up, but the drivers are correctly named which means they should be matching and probing. Now, musb-hdrc isn't probing, as you say, and I'd like to know why. I'll try to spend some time in it when I get back to the office.

Quoted 5 lines

I currently assume it's something with

subsys_initcall(omap2430_init);

Have to read about subsys_initcall() and why omap2430_init isn't called here.

I guess I know what the problem is. If you search for omap2430_init in vmlinux it won't be there. I guess when a directory is marked as obj-m, Kbuild won't search for symbols to be statically linked to vmlinux on that directory. Since we use the same Kconfig entry to select musb as module and include drivers/usb/musb directory into build system, we are falling into that case.

Quoted 2 lines

Try changing drivers/usb/musb to obj-y in drivers/Makefile and see if things start working.

Thanks, seems to be the right way, but doesn't work without more changes. I get some undefined references e.g. to stuff in musb_core.c and musb_debug (otg_state_string and musb_debug). I assume it's because musb_core and musb_debug are part of the module musb_hdrc.

Regards,

Alexander Holler

#11 lore raw
Quoted 56 lines · Alexander Holler

Am 16.03.2011 11:48, schrieb Felipe Balbi:

Quoted 55 lines

Hi,

Quoted 38 lines · Alexander Holler

Am 16.03.2011 11:38, schrieb Felipe Balbi:

Quoted 31 lines

hi,

Quoted 6 lines · Alexander Holler

Am 16.03.2011 11:24, schrieb Felipe Balbi:

Quoted 5 lines

Hi,

Quoted 2 lines · Alexander Holler
Quoted 1 line

static int __init omap2430_probe(struct platform_device *pdev)

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Neither omap2430_init() nor omap2430_probe() will be called here.

and why is that ? It's even in sysfs already:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

beagle linux # ls /sys/devices/platform/ | grep musb musb-omap2430

Don't know, I haven't written or changed the driver. ;)

hehe, Just thought that you had something in mind already.

probe() functions are called when, in case of platform_devices, the name matches with driver name. musb-omap2430 platform_device is allocated in arch/arm/mach-omap2/usb-musb.c, then musb-2430 driver lives in drivers/usb/musb/omap2430.c. musb-2430 allocates a platform_device for musb-hdrc core driver.

We did that because the same core is used in many different platforms (OMAP, discrete chips, ST-Ericsson, DaVinci, PCI cards, etc) so we needed to "abstract" platform-specific details such as clock handling and power management.

Quoted 5 lines

There's still work to be done, for sure, e.g. the DMA part is still quite screwed up, but the drivers are correctly named which means they should be matching and probing. Now, musb-hdrc isn't probing, as you say, and I'd like to know why. I'll try to spend some time in it when I get back to the office.

Quoted 5 lines

I currently assume it's something with

subsys_initcall(omap2430_init);

Have to read about subsys_initcall() and why omap2430_init isn't called here.

I guess I know what the problem is. If you search for omap2430_init in vmlinux it won't be there. I guess when a directory is marked as obj-m, Kbuild won't search for symbols to be statically linked to vmlinux on that directory. Since we use the same Kconfig entry to select musb as module and include drivers/usb/musb directory into build system, we are falling into that case.

Quoted 7 lines
Quoted 2 lines

Try changing drivers/usb/musb to obj-y in drivers/Makefile and see if things start working.

Thanks, seems to be the right way, but doesn't work without more changes. I get some undefined references e.g. to stuff in musb_core.c and musb_debug (otg_state_string and musb_debug). I assume it's because musb_core and musb_debug are part of the module musb_hdrc.

yeah, just saw it. I need to fix up the musb_debug part... I guess there was a patch making otg_state_string generic (as it should be) will get that. I guess a fix for this can't come to -rc though, it would depend on new features, unfortunately :-(

Signature · 1 line
balbi