[Letux-kernel] musb otg/y-cable regressions, OTG support removal

[Andreas Kemnade]

Hi Nikolaus,

On Wed, 20 Feb 2019 11:53:00 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> >> 
> >> ok, played a bit around with it. Reverting it enables me to do
> >> all the things I do with that otg usb.  
> > 
> > I have included the above patch in 5.0-rc7 and scheduled for
> > the next 4.19/4.20 (forgot to include it immediately).
> > 
> > Regarding USB/OTG I want to do some tests myself. Then we should
> > raise fingers and submit the revert...  
> 
> I have done a simple test: plug in the OTG cable and then plug a memory stick or WiFi stick:
> 
> root at letux:~# [  452.581024] musb-hdrc musb-hdrc.0.auto: configured as A device timeout
> 
> root at letux:~# [  461.739410] usb 2-1: new high-speed USB device number 2 using musb-hdrc
> [  461.920166] usb 2-1: New USB device found, idVendor=0204, idProduct=6025, bcdDevice= 1.00
> [  461.928833] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [  461.937591] usb 2-1: Product: Flash Disk
> [  461.942596] usb 2-1: Manufacturer: CBM
> [  461.946594] usb 2-1: SerialNumber: 221835001DC5F204
> [  461.960357] usb-storage 2-1:1.0: USB Mass Storage device detected
> [  461.985290] scsi host0: usb-storage 2-1:1.0
> [  463.070312] scsi 0:0:0:0: Direct-Access     CBM      Flash Disk       5.00 PQ: 0 ANSI: 2
> [  463.091278] sd 0:0:0:0: [sda] 2072064 512-byte logical blocks: (1.06 GB/1012 MiB)
> [  463.104431] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [  463.111389] sd 0:0:0:0: [sda] Write Protect is off
> [  463.116394] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
> [  463.129638] sd 0:0:0:0: [sda] No Caching mode page found
> [  463.135223] sd 0:0:0:0: [sda] Assuming drive cache: write through
> [  463.160888]  sda: sda1
> [  463.167755] sd 0:0:0:0: [sda] Attached SCSI removable disk
> [  469.191070] usb 2-1: USB disconnect, device number 2
> [  488.261047] usb 2-1: new high-speed USB device number 3 using musb-hdrc
> [  488.441894] usb 2-1: New USB device found, idVendor=0204, idProduct=6025, bcdDevice= 1.00
> [  488.450683] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [  488.458251] usb 2-1: Product: Flash Disk
> [  488.463684] usb 2-1: Manufacturer: CBM
> [  488.467681] usb 2-1: SerialNumber: 221835001DC5F204
> [  488.481872] usb-storage 2-1:1.0: USB Mass Storage device detected
> [  488.503936] scsi host0: usb-storage 2-1:1.0
> [  489.552581] scsi 0:0:0:0: Direct-Access     CBM      Flash Disk       5.00 PQ: 0 ANSI: 2
> [  489.568054] sd 0:0:0:0: [sda] 2072064 512-byte logical blocks: (1.06 GB/1012 MiB)
> [  489.582794] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [  489.593719] sd 0:0:0:0: [sda] Write Protect is off
> [  489.598754] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
> [  489.615386] sd 0:0:0:0: [sda] No Caching mode page found
> [  489.621124] sd 0:0:0:0: [sda] Assuming drive cache: write through
> [  489.633056]  sda: sda1
> [  489.643096] sd 0:0:0:0: [sda] Attached SCSI removable disk
> [  492.219909] usb 2-1: USB disconnect, device number 3
> [  501.991546] usb 2-1: new high-speed USB device number 4 using musb-hdrc
> [  502.182739] usb 2-1: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
> [  502.191528] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [  502.199096] usb 2-1: Product: 802.11n NIC
> [  502.205078] usb 2-1: Manufacturer: Realtek
> [  502.209533] usb 2-1: SerialNumber: 7CDD90A871B2
> [  502.221984] usb 2-1: rejected 1 configuration due to insufficient available bus power
> [  502.230285] usb 2-1: no configuration chosen from 1 choice
> [  509.010009] usb 2-1: USB disconnect, device number 4
> 
> Both seem to work (at least to available bus power).
> 
> This means that basic OTG (role switch by ID pin) is still working with letux-4.19.23.
> 
> So could a different solution for the Y cable be to fake an active ID pin?
> 
Well, going that road I also tried around a lot. See my slides.
The main point here is that the musb system assumes that it provides power.
That has a lot of side effects. musb then changes the DRVVBUS value via ulpi.
Well, we could clear that drvvbus flag via i2c. I have even kernel patches
for that (at least for 3.7). So the sequence would be, connect id pin to
GND (or fake it, if there is a way to), musb hwmod tells phy to
drive vbus, connect external power to vbus, disable drive vbus via i2c
(musb hwmod's internal fsm won't notice).
So, now interesting things happen when vbus drops a bit, even for a short time.
Short circuit detected (musb still thinks it drives power), that causes some bus
shutdown and restart. IMHO this is even more hacky than the b_host way of
doing things.

There is also a testmode force host bit in musb (available via debugfs)
but documentation for musb is NDAed, so there is no public
information available how to use it.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190220/7f659358/attachment.asc>