arm64/rpi3b+: attaching mue(4)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

arm64/rpi3b+: attaching mue(4)

Artturi Alm
Hi,

rather than patching uhub(4), i figured this would be less not-ok,
if not ok as-is, given its way more limited scope.

diff below works for me, but i suppose playing w/timeouts is a must,
for root on nfs?

-Artturi


diff --git a/sys/arch/arm64/dev/bcm2835_dwctwo.c b/sys/arch/arm64/dev/bcm2835_dwctwo.c
index d6cfe61fd2a..af0fe90ad5d 100644
--- a/sys/arch/arm64/dev/bcm2835_dwctwo.c
+++ b/sys/arch/arm64/dev/bcm2835_dwctwo.c
@@ -48,6 +48,10 @@ int bcm_dwctwo_match(struct device *, void *, void *);
 void bcm_dwctwo_attach(struct device *, struct device *, void *);
 void bcm_dwctwo_deferred(void *);
 
+void rpi3bp_fix_mue_later(struct device *);
+void rpi3bp_explore_workaround(struct usbd_device *);
+static struct usbd_device *rpi3bp_mue_fix = NULL;
+
 const struct cfattach bcmdwctwo_ca = {
  sizeof(struct bcm_dwctwo_softc), bcm_dwctwo_match, bcm_dwctwo_attach,
 };
@@ -133,4 +137,41 @@ bcm_dwctwo_deferred(void *self)
 
  sc->sc_dwc2.sc_child = config_found(&sc->sc_dwc2.sc_bus.bdev,
     &sc->sc_dwc2.sc_bus, usbctlprint);
+
+ if (OF_is_compatible(OF_peer(0), "raspberrypi,3-model-b-plus")) {
+ rpi3bp_mue_fix = sc->sc_dwc2.sc_bus.root_hub;
+ config_mountroot(sc->sc_dwc2.sc_child, rpi3bp_fix_mue_later);
+ }
+}
+
+void
+rpi3bp_fix_mue_later(struct device *dv)
+{
+ rpi3bp_explore_workaround(rpi3bp_mue_fix);
+}
+
+void
+rpi3bp_explore_workaround(struct usbd_device *dev)
+{
+ static int rpi3bp_mue_fix_hubidx = 0;
+ struct usbd_port *up;
+ int port;
+
+ if (!rpi3bp_mue_fix)
+ return;
+
+ for (port = 1; port <= dev->hub->nports; port++) {
+ up = &dev->hub->ports[port-1];
+
+ /* mue0 at uhub2 port 1 ... */
+ if (rpi3bp_mue_fix_hubidx++ == 2) {
+ rpi3bp_mue_fix = NULL;
+ up->reattach = 1;
+ usb_needs_explore(dev, 0);
+ return;
+ }
+ if (up->device != NULL &&
+    up->device->hub != NULL)
+ rpi3bp_explore_workaround(up->device);
+ }
 }

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Martin Pieuchot
On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> Hi,
>
> rather than patching uhub(4), i figured this would be less not-ok,
> if not ok as-is, given its way more limited scope.

Why shouldn't we patch uhub(4)?

> diff below works for me, but i suppose playing w/timeouts is a must,
> for root on nfs?

What is the issue?  Could you explain it in words?  That would allow
us to find a solution together :o)

> diff --git a/sys/arch/arm64/dev/bcm2835_dwctwo.c b/sys/arch/arm64/dev/bcm2835_dwctwo.c
> index d6cfe61fd2a..af0fe90ad5d 100644
> --- a/sys/arch/arm64/dev/bcm2835_dwctwo.c
> +++ b/sys/arch/arm64/dev/bcm2835_dwctwo.c
> @@ -48,6 +48,10 @@ int bcm_dwctwo_match(struct device *, void *, void *);
>  void bcm_dwctwo_attach(struct device *, struct device *, void *);
>  void bcm_dwctwo_deferred(void *);
>  
> +void rpi3bp_fix_mue_later(struct device *);
> +void rpi3bp_explore_workaround(struct usbd_device *);
> +static struct usbd_device *rpi3bp_mue_fix = NULL;
> +
>  const struct cfattach bcmdwctwo_ca = {
>   sizeof(struct bcm_dwctwo_softc), bcm_dwctwo_match, bcm_dwctwo_attach,
>  };
> @@ -133,4 +137,41 @@ bcm_dwctwo_deferred(void *self)
>  
>   sc->sc_dwc2.sc_child = config_found(&sc->sc_dwc2.sc_bus.bdev,
>      &sc->sc_dwc2.sc_bus, usbctlprint);
> +
> + if (OF_is_compatible(OF_peer(0), "raspberrypi,3-model-b-plus")) {
> + rpi3bp_mue_fix = sc->sc_dwc2.sc_bus.root_hub;
> + config_mountroot(sc->sc_dwc2.sc_child, rpi3bp_fix_mue_later);
> + }
> +}
> +
> +void
> +rpi3bp_fix_mue_later(struct device *dv)
> +{
> + rpi3bp_explore_workaround(rpi3bp_mue_fix);
> +}
> +
> +void
> +rpi3bp_explore_workaround(struct usbd_device *dev)
> +{
> + static int rpi3bp_mue_fix_hubidx = 0;
> + struct usbd_port *up;
> + int port;
> +
> + if (!rpi3bp_mue_fix)
> + return;
> +
> + for (port = 1; port <= dev->hub->nports; port++) {
> + up = &dev->hub->ports[port-1];
> +
> + /* mue0 at uhub2 port 1 ... */
> + if (rpi3bp_mue_fix_hubidx++ == 2) {
> + rpi3bp_mue_fix = NULL;
> + up->reattach = 1;
> + usb_needs_explore(dev, 0);
> + return;
> + }
> + if (up->device != NULL &&
> +    up->device->hub != NULL)
> + rpi3bp_explore_workaround(up->device);
> + }
>  }
>

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Artturi Alm
On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > Hi,
> >
> > rather than patching uhub(4), i figured this would be less not-ok,
> > if not ok as-is, given its way more limited scope.
>
> Why shouldn't we patch uhub(4)?
>

There's no MD code in uhub(4), and i don't know what to fix there yet,
but the workaround i was referring to w/"patching" has MI side-effects.

> > diff below works for me, but i suppose playing w/timeouts is a must,
> > for root on nfs?
>
> What is the issue?  Could you explain it in words?  That would allow
> us to find a solution together :o)
>

I thought this was known, i'm sorry; i should have linked to the details[0].

-Artturi

[0] https://marc.info/?l=openbsd-bugs&m=154408887807578&w=2

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Martin Pieuchot
On 11/02/19(Mon) 18:58, Artturi Alm wrote:

> On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> > On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > > Hi,
> > >
> > > rather than patching uhub(4), i figured this would be less not-ok,
> > > if not ok as-is, given its way more limited scope.
> >
> > Why shouldn't we patch uhub(4)?
> >
>
> There's no MD code in uhub(4), and i don't know what to fix there yet,
> but the workaround i was referring to w/"patching" has MI side-effects.
>
> > > diff below works for me, but i suppose playing w/timeouts is a must,
> > > for root on nfs?
> >
> > What is the issue?  Could you explain it in words?  That would allow
> > us to find a solution together :o)
> >
>
> I thought this was known, i'm sorry; i should have linked to the details[0].

Sorry but that mail describes symptoms.  What is the problem?  Why your
diff work?  What did you do to write this workaround?  What could be
another alternative to the fix your proposing?

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Artturi Alm
On Wed, Feb 13, 2019 at 10:37:48AM -0200, Martin Pieuchot wrote:

> On 11/02/19(Mon) 18:58, Artturi Alm wrote:
> > On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> > > On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > > > Hi,
> > > >
> > > > rather than patching uhub(4), i figured this would be less not-ok,
> > > > if not ok as-is, given its way more limited scope.
> > >
> > > Why shouldn't we patch uhub(4)?
> > >
> >
> > There's no MD code in uhub(4), and i don't know what to fix there yet,
> > but the workaround i was referring to w/"patching" has MI side-effects.
> >
> > > > diff below works for me, but i suppose playing w/timeouts is a must,
> > > > for root on nfs?
> > >
> > > What is the issue?  Could you explain it in words?  That would allow
> > > us to find a solution together :o)
> > >
> >
> > I thought this was known, i'm sorry; i should have linked to the details[0].
>
> Sorry but that mail describes symptoms.  What is the problem?  Why your
> diff work?  What did you do to write this workaround?  What could be
> another alternative to the fix your proposing?

I haven't really diagnosed this at all, except dmesgs over irc|reading
uhub.c, when i didn't have the hw yet. And the reason to that is here[0];
somewhat ignored bug report, which made me swear i'd never look anything
at /sys/dev/usb/dwc2/ again until i see progress made by others in there.

I ran into some INVAL spam with the "port reset in uhub_explore()" hack,
so i needed something better, and aimed at minimal +++only diff,
obviously with some guesswork.

I don't honestly care about rpi3 as much as other users it has do, and i
don't want to waste your time anymore with this(nor the bug in link[0]),
so i'll let this be for now, as both of the trees i'm compiling/testing
stuff on rpi3 over nfs(w/mue(4)) have incomplete work within, and i'm
lazy even with git at times:]

Hopefully someone else will come up with something better:]

-Artturi

ps. the rthread rwlock improvement is great, thank you :)

[0] https://marc.info/?t=150188616000004&r=1&w=2

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

James Hastings
In reply to this post by Artturi Alm
On 11/02/19(Mon) 18:58, Artturi Alm wrote:

> On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> > On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > > Hi,
> > >
> > > rather than patching uhub(4), i figured this would be less not-ok,
> > > if not ok as-is, given its way more limited scope.
> >
> > Why shouldn't we patch uhub(4)?
> >
>
> There's no MD code in uhub(4), and i don't know what to fix there yet,
> but the workaround i was referring to w/"patching" has MI side-effects.

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.

Index: dev/usb/uhub.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/uhub.c,v
retrieving revision 1.92
diff -u -p -r1.92 uhub.c
--- dev/usb/uhub.c 7 Jan 2019 14:24:22 -0000 1.92
+++ dev/usb/uhub.c 15 Feb 2019 05:24:54 -0000
@@ -324,6 +324,7 @@ uhub_attach(struct device *parent, struc
  }

  /* Wait for stable power. */
+ powerdelay += 250;
         if (dev->powersrc->parent != NULL)
  usbd_delay_ms(dev, powerdelay + USB_EXTRA_POWER_UP_TIME);

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Martin Pieuchot
On 15/02/19(Fri) 01:47, James Hastings wrote:

> On 11/02/19(Mon) 18:58, Artturi Alm wrote:
> > On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> > > On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > > > Hi,
> > > >
> > > > rather than patching uhub(4), i figured this would be less not-ok,
> > > > if not ok as-is, given its way more limited scope.
> > >
> > > Why shouldn't we patch uhub(4)?
> > >
> >
> > There's no MD code in uhub(4), and i don't know what to fix there yet,
> > but the workaround i was referring to w/"patching" has MI side-effects.
>
> 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.

Why did you decide to increase the delay?   Did you find some doc or
code saying this is necessary?

> Index: dev/usb/uhub.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/usb/uhub.c,v
> retrieving revision 1.92
> diff -u -p -r1.92 uhub.c
> --- dev/usb/uhub.c 7 Jan 2019 14:24:22 -0000 1.92
> +++ dev/usb/uhub.c 15 Feb 2019 05:24:54 -0000
> @@ -324,6 +324,7 @@ uhub_attach(struct device *parent, struc
>   }
>
>   /* Wait for stable power. */
> + powerdelay += 250;
>          if (dev->powersrc->parent != NULL)
>   usbd_delay_ms(dev, powerdelay + USB_EXTRA_POWER_UP_TIME);
>

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

James Hastings
In reply to this post by James Hastings
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.


OpenBSD 6.4-current (GENERIC.MP) #0: Sun Jan 27 14:46:33 EST 2019
    [hidden email]:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 963276800 (918MB)
avail mem = 904945664 (863MB)
mainbus0 at root: Raspberry Pi 3 Model B Plus Rev 1.3
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
efi0 at mainbus0: UEFI 2.7
efi0: Das U-Boot rev 0x20180900
simplefb0 at mainbus0: 656x416, 32bpp
wsdisplay0 at simplefb0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
simplebus0 at mainbus0: "soc"
"dma" at simplebus0 not configured
bcmintc0 at simplebus0
bcmdog0 at simplebus0
"cprman" at simplebus0 not configured
bcmrng0 at simplebus0
"mailbox" at simplebus0 not configured
"gpio" at simplebus0 not configured
pluart0 at simplebus0
"mmc" at simplebus0 not configured
"dsi" at simplebus0 not configured
bcmtemp0 at simplebus0
bcmaux0 at simplebus0
com0 at simplebus0: ns16550, no working fifo
com0: console
dwctwo0 at simplebus0
"local_intc" at simplebus0 not configured
"mmc" at simplebus0 not configured
"gpiomem" at simplebus0 not configured
"firmware" at simplebus0 not configured
"power" at simplebus0 not configured
"fb" at simplebus0 not configured
"vchiq" at simplebus0 not configured
"vcsm" at simplebus0 not configured
"arm-pmu" at simplebus0 not configured
"expgpio" at simplebus0 not configured
simplebus1 at mainbus0: "clocks"
"clock" at simplebus1 not configured
"clock" at simplebus1 not configured
agtimer0 at mainbus0: tick rate 19200 KHz
cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4
cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4
cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4
cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu3: 512KB 64b/line 16-way L2 cache
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev
2.00/1.00 addr 1
uhub0: 1 port with 1 removable, self powered
uhub0: port 1 status=0x0101 change=0x0001
uhub0: intr status=0
uhub0: port 1 status=0x0503 change=0x0000
uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems
product 0x2514" rev 2.00/b.b3 addr 2
uhub1: 4 ports with 3 removable, self powered, multiple transaction
translators
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: port 1 status=0x0101 change=0x0001
uhub1: intr status=0
uhub1: port 1 status=0x0503 change=0x0000
uhub2 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems
product 0x2514" rev 2.00/b.b3 addr 3
uhub2: 3 ports with 2 removable, self powered, multiple transaction
translators
uhub2: port 1 status=0x0100 change=0x0000
uhub2: port 2 status=0x0100 change=0x0000
uhub2: port 3 status=0x0101 change=0x0001
uhub2: port 3 status=0x0503 change=0x0000
umass0 at uhub2 port 3 configuration 1 interface 0 "FUJIFILM Mass
Storage Device" rev 2.00/11.00 addr 4
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <FUJIFILM, 16GB, 1100> SCSI2 0/direct
removable serial
sd0: 15468MB, 512 bytes/sector, 31678464 sectors
uhub1: port 2 status=0x0100 change=0x0000
uhub1: port 3 status=0x0100 change=0x0000
uhub1: port 4 status=0x0100 change=0x0000
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (6d2b33ebe74c79d3.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!

OpenBSD 6.4-current (GENERIC.MP) #0: Sun Jan 27 14:05:54 EST 2019
    [hidden email]:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 963276800 (918MB)
avail mem = 904941568 (863MB)
mainbus0 at root: Raspberry Pi 3 Model B Plus Rev 1.3
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
efi0 at mainbus0: UEFI 2.7
efi0: Das U-Boot rev 0x20180900
simplefb0 at mainbus0: 656x416, 32bpp
wsdisplay0 at simplefb0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
simplebus0 at mainbus0: "soc"
"dma" at simplebus0 not configured
bcmintc0 at simplebus0
bcmdog0 at simplebus0
"cprman" at simplebus0 not configured
bcmrng0 at simplebus0
"mailbox" at simplebus0 not configured
"gpio" at simplebus0 not configured
pluart0 at simplebus0
"mmc" at simplebus0 not configured
"dsi" at simplebus0 not configured
bcmtemp0 at simplebus0
bcmaux0 at simplebus0
com0 at simplebus0: ns16550, no working fifo
com0: console
dwctwo0 at simplebus0
"local_intc" at simplebus0 not configured
"mmc" at simplebus0 not configured
"gpiomem" at simplebus0 not configured
"firmware" at simplebus0 not configured
"power" at simplebus0 not configured
"fb" at simplebus0 not configured
"vchiq" at simplebus0 not configured
"vcsm" at simplebus0 not configured
"arm-pmu" at simplebus0 not configured
"expgpio" at simplebus0 not configured
simplebus1 at mainbus0: "clocks"
"clock" at simplebus1 not configured
"clock" at simplebus1 not configured
agtimer0 at mainbus0: tick rate 19200 KHz
cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4
cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4
cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4
cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu3: 512KB 64b/line 16-way L2 cache
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev
2.00/1.00 addr 1
uhub0: 1 port with 1 removable, self powered
uhub0: port 1 status=0x0101 change=0x0001
uhub0: intr status=0
uhub0: port 1 status=0x0503 change=0x0000
uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems
product 0x2514" rev 2.00/b.b3 addr 2
uhub1: 4 ports with 3 removable, self powered, multiple transaction
translators
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: intr status=0
uhub1: port 1 status=0x0101 change=0x0001
uhub1: intr status=0
uhub1: port 1 status=0x0503 change=0x0000
uhub2 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems
product 0x2514" rev 2.00/b.b3 addr 3
uhub2: 3 ports with 2 removable, self powered, multiple transaction
translators
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
uhub2: port 2 status=0x0100 change=0x0000
uhub2: port 3 status=0x0101 change=0x0001
uhub2: port 3 status=0x0503 change=0x0000
umass0 at uhub2 port 3 configuration 1 interface 0 "FUJIFILM Mass
Storage Device" rev 2.00/11.00 addr 5
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <FUJIFILM, 16GB, 1100> SCSI2 0/direct
removable serial
sd0: 15468MB, 512 bytes/sector, 31678464 sectors
uhub1: port 2 status=0x0100 change=0x0000
uhub1: port 3 status=0x0100 change=0x0000
uhub1: port 4 status=0x0100 change=0x0000
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (6d2b33ebe74c79d3.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!



Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Artturi Alm
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 :]

this is what i currently use, while just
        s/USB_EXTRA_POWER_UP_TIME/USB_PORT_POWERUP_DELAY/
would also work, and still 'look ok' given the comment above delay, but..

-Artturi

ps. we use bPwrOn2PwrGood = 200 in ie. ehci, and = 10 in xhci, but netbsd
uses = 200 in both, fwiw.


diff --git a/sys/dev/usb/uhub.c b/sys/dev/usb/uhub.c
index 272569798c9..072bc2c5312 100644
--- a/sys/dev/usb/uhub.c
+++ b/sys/dev/usb/uhub.c
@@ -126,6 +126,7 @@ uhub_attach(struct device *parent, struct device *self, void *aux)
  usb_hub_ss_descriptor_t ss;
  } hd;
  int p, port, nports, powerdelay;
+ int minpwrdly = USB_EXTRA_POWER_UP_TIME;
  struct usbd_interface *iface = uaa->iface;
  usb_endpoint_descriptor_t *ed;
  struct usbd_tt *tts = NULL;
@@ -169,6 +170,8 @@ uhub_attach(struct device *parent, struct device *self, void *aux)
  err = usbd_get_hub_descriptor(dev, &hd.hs, 1);
  nports = hd.hs.bNbrPorts;
  powerdelay = (hd.hs.bPwrOn2PwrGood * UHD_PWRON_FACTOR);
+ if (hd.hs.bPwrOn2PwrGood <= 50) /* workaround for RPI3B+ */
+ minpwrdly += 200 * UHD_PWRON_FACTOR - powerdelay;
  ttthink = UGETW(hd.hs.wHubCharacteristics) & UHD_TT_THINK;
  if (!err && nports > 7)
  usbd_get_hub_descriptor(dev, &hd.hs, nports);
@@ -324,8 +327,8 @@ uhub_attach(struct device *parent, struct device *self, void *aux)
  }
 
  /* Wait for stable power. */
-        if (dev->powersrc->parent != NULL)
- usbd_delay_ms(dev, powerdelay + USB_EXTRA_POWER_UP_TIME);
+ if (dev->powersrc->parent != NULL)
+ usbd_delay_ms(dev, powerdelay + minpwrdly);
 
  /* The usual exploration will finish the setup. */
 

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Martin Pieuchot
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?

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Martin Pieuchot
In reply to this post by James Hastings
On 18/02/19(Mon) 03:31, 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

Did you look at the bit which is set with delay?  What does it mean?

You said that hotplugging is not working with your diff, right?  Did you
capture the output w/ UHUB_DEBUG when hot-plugging a device?  What did
you see?  Was this bit also absent?

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

Did you look at the `bPwrOn2PwrGood' value for this hub?  You can use
`lsusb -v' from the usbutils package for that.

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

James Hastings
On 02/25/2019 02:22 PM, Martin Pieuchot wrote:

> On 18/02/19(Mon) 03:31, 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
>
> Did you look at the bit which is set with delay?  What does it mean?

The status bit set with delay is UPS_CURRENT_CONNECT_STATUS. change bit
is UPS_C_CONNECT_STATUS.

> You said that hotplugging is not working with your diff, right?  Did you
> capture the output w/ UHUB_DEBUG when hot-plugging a device?  What did
> you see?  Was this bit also absent?

Yes I checked that too, hotplugging a device at uhub2 produces zero
debug output to console.

>> 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.
>
> Did you look at the `bPwrOn2PwrGood' value for this hub?  You can use
> `lsusb -v' from the usbutils package for that.

  bPwrOn2PwrGood       50 * 2 milli seconds

lsusb -v
Bus 000 Device 001: ID 0000:0000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x0000
  idProduct          0x0000
  bcdDevice            1.00
  iManufacturer           1 Broadcom
  iProduct                2 DWC2 root hub
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x40
      (Missing must-be-set bit!)
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x0008
    Ganged power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
Device Status:     0x0001
  Self Powered

Bus 000 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x2514 USB 2.0 Hub
  bcdDevice            b.b3
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x000d
    Per-port power switching
    Compound device
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      1 milli Ampere
  DeviceRemovable    0x02
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Bus 000 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x2514 USB 2.0 Hub
  bcdDevice            b.b3
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             3
  wHubCharacteristic 0x000d
    Per-port power switching
    Compound device
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      1 milli Ampere
  DeviceRemovable    0x02
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0503 highspeed power enable connect
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Bus 000 Device 004: ID 0424:7800 Standard Microsystems Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol       255
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x7800
  bcdDevice            3.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               4
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000006
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        1500 micro seconds
Device Status:     0x0001
  Self Powered

Bus 000 Device 005: ID 8564:1000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x8564
  idProduct          0x1000
  bcdDevice           11.00
  iManufacturer           1 FUJIFILM
  iProduct                2 Mass Storage Device
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)



Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

Martin Pieuchot
On 26/02/19(Tue) 00:49, James Hastings wrote:

> On 02/25/2019 02:22 PM, Martin Pieuchot wrote:
> > On 18/02/19(Mon) 03:31, 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
> >
> > Did you look at the bit which is set with delay?  What does it mean?
>
> The status bit set with delay is UPS_CURRENT_CONNECT_STATUS. change bit
> is UPS_C_CONNECT_STATUS.
>
> > You said that hotplugging is not working with your diff, right?  Did you
> > capture the output w/ UHUB_DEBUG when hot-plugging a device?  What did
> > you see?  Was this bit also absent?
>
> Yes I checked that too, hotplugging a device at uhub2 produces zero
> debug output to console.

But do you see different port status when using lsusb(1)?

You could also enable DWC_DEBUG and see if adding/removing a device
generates interrupts?

Reply | Threaded
Open this post in threaded view
|

Re: arm64/rpi3b+: attaching mue(4)

James Hastings
On 02/27/2019 12:13 PM, Martin Pieuchot wrote:

> On 26/02/19(Tue) 00:49, James Hastings wrote:
>> On 02/25/2019 02:22 PM, Martin Pieuchot wrote:
>>> On 18/02/19(Mon) 03:31, 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
>>>
>>> Did you look at the bit which is set with delay?  What does it mean?
>>
>> The status bit set with delay is UPS_CURRENT_CONNECT_STATUS. change bit
>> is UPS_C_CONNECT_STATUS.
>>
>>> You said that hotplugging is not working with your diff, right?  Did you
>>> capture the output w/ UHUB_DEBUG when hot-plugging a device?  What did
>>> you see?  Was this bit also absent?
>>
>> Yes I checked that too, hotplugging a device at uhub2 produces zero
>> debug output to console.
>
> But do you see different port status when using lsusb(1)?
>
lsusb(1) port status bits from uhub2:
before:
   Port 2: 0000.0100 power

inserted:
   Port 2: 0001.0101 C_CONNECT power connect

removed:
   Port 2: 0001.0100 C_CONNECT power

> You could also enable DWC_DEBUG and see if adding/removing a device
> generates interrupts?
>
I attempted this with a GENERIC kernel and debug output would
run for days without stopping because the root disk is on usb.

I am starting a make build and make release to get a ramdisk kernel
with DWC_DEBUG enabled.