Modify

Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#11375 closed defect (fixed)

bcm63xx: don't hardcode ohci->num_ports

Reported by: danitool <dgcbueu@…> Owned by: florian
Priority: normal Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: usb bcm63xx Cc:

Description

Is there any good reason to hardcode ohci num_ports in the kernel file drivers/usb/host/ohci-bcm63xx.c?

ohci->num_ports = 1;

This causes some routers won't detect the second usb, as a result of this it may cause one physical port won't work. Known affected routers are Hg553 and Hg556a.

So let the kernel detect them automatically.

This issue is reported at some tickets: #11200 and #9351.
Whereas this change won't solve usb speed problem reported at those tickets, at least the second port will work when plugging stuff into them. In my router (hg556a) all ports work at full speed.

Also I don't know what the comment

/* FIXME: autodetected port 2 is shared with USB slave */

means

Attachments (1)

bcm63xx_ohci-num_ports.patch (565 bytes) - added by danitool <dgcbueu@…> 4 years ago.

Download all attachments as: .zip

Change History (10)

Changed 4 years ago by danitool <dgcbueu@…>

comment:1 Changed 4 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to assigned

comment:2 Changed 3 years ago by danitool

These are the usb ports in Hg556a

usb0(SoC) ---- onboard USB2.0 HUB ---> 2 external ports
usb1(SoC) ----> 1 external port

This is current status of this issue in the Hg556a router. Tested with AA and trunk, both OHCI and EHCI modules loaded.

With AA:

  • The ports from the usb0--onboard USB2.0 HUB always work when connecting full or high speed devices, and the speed is detected correctly
  • The usb1 only works when connecting high-speed devices, full-speed devices aren't detected unless I apply the above patch. Without the patch, the usb1 becomes stunned after plugging full-speed devices. With the patch all works as expected: speed detection is correct, and all ports are able to drive any device.

With latest Trunk versions

  • The ports from the usb0--onboard USB2.0 HUB work correctly again.
  • The usb1 port works only with high-speed devices. Full speed devices aren't detected. Now if I plug a full-speed device the port doesn't become stunned. But now even when I let the kernel autodetect the two OHCI ports, full-speed devices don't work in this port. After this change when I plug a full-speed device the port becomes stunned.

I would say, things became worse with latest trunk. With previous versions the patch posted here was enough to solve the usb problems in this particular board at least.

comment:3 follow-up: Changed 3 years ago by anonymous

Here we go again. With latest patches #39274 now we are at the same point, both ports work with EHCI but only one with OHCI. And again with the new code if I change .num_ports to 2, both USB ports detect high or full speed devices, and this is the right behavior.

static struct usb_ohci_pdata bcm63xx_ohci_pdata = {
	.big_endian_desc	= 1,
	.big_endian_mmio	= 1,
	.no_big_frame_no	= 1,
	.num_ports		= 2,
	.power_on		= bcm63xx_ohci_power_on,
	.power_off		= bcm63xx_ohci_power_off,
	.power_suspend		= bcm63xx_ohci_power_off,
};

Probably deleting that line, could also work to let the kernel detect them automatically.

Now I'm testing it in a Netgear DGND3700, with the same problem. I dont have the Huawei device to test it, but now I can say this is a common problem to all boards with both the internal ports wired to external USBs.

Why the hell is this hardcoded to detect only 1 OHCI port?!

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by jogo

  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to anonymous:

Why the hell is this hardcoded to detect only 1 OHCI port?!

Because the second usb port can be used as a usb device port on some devices, and using it as a host port will break that.

Anyhow, support for dynamically setting the number of ports is now implemented in r39324.

comment:5 follow-up: Changed 3 years ago by danitool <dgcbueu@…>

Good!!!, I'm very happy to see this bug solved :). Thanks very much.

I didn't know there was planned usb device support for these boards in OpenWrt, I thought it had been dropped long time ago. Neither manufacturers nowadays don't include the usb device on any router. I think this was a feature included in the days when having an ethernet port in a computer wasn't still very common. Now we're back with this situation but with hardware like tablets.

So about usb device support, can work either with bcm6348 or 6358, or any other boards? or is still in alpha state?.

Regards.

comment:6 in reply to: ↑ 5 Changed 3 years ago by jogo

Replying to danitool <dgcbueu@…>:

Good!!!, I'm very happy to see this bug solved :). Thanks very much.

I didn't know there was planned usb device support for these boards in OpenWrt, I thought it had been dropped long time ago. Neither manufacturers nowadays don't include the usb device on any router. I think this was a feature included in the days when having an ethernet port in a computer wasn't still very common. Now we're back with this situation but with hardware like tablets.

There are still a few devices with a USB device port, and of course many reference and development boards come with it.

So about usb device support, can work either with bcm6348 or 6358, or any other boards? or is still in alpha state?.

Only the USB Device controller in BCM6368 and newer is supported. BCM6358 and older do not have a full controller and only support the CDC profile; as well as it is missing an open source driver.

Note that none of them are OTG capable, so they are fixed to either host or device.

comment:7 in reply to: ↑ 4 ; follow-up: Changed 2 years ago by qshenx@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to jogo:

Replying to anonymous:

Why the hell is this hardcoded to detect only 1 OHCI port?!

Because the second usb port can be used as a usb device port on some devices, and using it as a host port will break that.

Anyhow, support for dynamically setting the number of ports is now implemented in r39324.

with the newest trunk(svn checkout @Feb 16,2014), HG556a (Hareware rev A) still have the ploblem.
Only the internal USB port can be detected, and work in USB1.1 mode.
When plug-in an USB2.0-only device, the port will crash.
The other two ports of onboard hub don't work.

The AA 12.09 with the patch works well.

I don't know why the ticket were closed without fully test.

comment:8 in reply to: ↑ 7 Changed 2 years ago by jogo

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to qshenx@…:

Replying to jogo:

Replying to anonymous:

Why the hell is this hardcoded to detect only 1 OHCI port?!

Because the second usb port can be used as a usb device port on some devices, and using it as a host port will break that.

Anyhow, support for dynamically setting the number of ports is now implemented in r39324.

with the newest trunk(svn checkout @Feb 16,2014), HG556a (Hareware rev A) still have the ploblem.
Only the internal USB port can be detected, and work in USB1.1 mode.
When plug-in an USB2.0-only device, the port will crash.
The other two ports of onboard hub don't work.

The AA 12.09 with the patch works well.

I don't know why the ticket were closed without fully test.

Because developers don't have magically access to all supported devices?

Anyway, the issue was that ohci->num_ports is hardcoded to one, now it can be overwritten by boards, so this issue is still fixed from that standpoint.

Individual boards might need to update their number of usb ports, but that should be new tickets.

comment:9 Changed 2 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.