On 24/02/19(Sun) 10:55, Artturi Alm wrote: > On Mon, Feb 18, 2019 at 03:31:45AM -0500, James Hastings wrote: > > On 17/02/19(Sun) 15:07, Martin Pieuchot wrote: > > > On 15/02/19(Fri) 01:47, James Hastings wrote: > > > > I settled on a patch providing an additional 250ms powerdelay in > > uhub(4). > > > > mue(4) reliably attaches now, but hotplugging devices in the left two > > > > ports is still an issue. > > > > > > Interesting. Could you build a kernel with UHUB_DEBUG enable and > > > compare the status of the ports? I'm wondering if your increased delay > > > will change the value returned by usbd_get_port_status() line 376. > > > > Before: > > uhub2: port 1 status=0x0100 change=0x0000 > > > > With delay: > > uhub2: port 1 status=0x0101 change=0x0001 > > uhub2: port 1 status=0x0503 change=0x0000 > > mue0 at uhub2 port 1 configuration 1 interface 0 "Standard Microsystems > > LAN7800" rev 2.10/3.00 addr 4 > > mue0: LAN7800, address > > ukphy0 at mue0 phy 1: Generic IEEE 802.3u media interface, rev. 2: OUI > > 0x0001f0, model 0x0013 > > > > > Why did you decide to increase the delay? Did you find some doc or > > > code saying this is necessary? > > > > No code or docs, just thought the device might be slow to wake up > > and need extra delay to be attached on initial bus exploration. > > so it seems, and i came up with a diff to limit the workaround a bit :]
Guys why don't you spend your time trying to understand the issue? We can continue bikescheding workarounds but how is that making our software better? If there's an actual bug in our code? Does fixing it would help everyone? Why don't you investigate why it is not working? If we're using an incorrect value, why not look for the specification? What is it saying?
