Re: [BUG] SD card reader disappears after suspend

Re: [BUG] SD card reader disappears after suspend

[Samuel Sadok]

Hello,

It's been a while that there was any discussion on this bug so here's
a brief context: There's a bug on some MacBook Pro's where the
built-in SD card reader would be missing after a suspend/resume cycle.

After looking at the schematics for my laptop I noticed that
`OC6*/GPIO10` of the Intel PCH is connected to a net called
`SD_PWR_EN`. So I tried to set this pin to 0 and then to 1 again in
order to completely power cycle the card reader. Turns out this
finally makes the card reader appear after a suspend/resume cycle.

For the record, here's the user space workaround:
https://gist.github.com/samuelsadok/6d7b3e3015d3370a92ed4702e4d3c4b5#gistcomment-3134437

Are there other buggy devices for which the kernel already implements
such a power cycle? Otherwise, where would be the right place to add
this?

Additional observations:
 - by default (after boot), GPIO10 is configured as input and shows
the state "high". In the schematics there's a pull-up resistor. and I
assume it goes to a mosfet (off-sheet). So the problem is not that the
card reader has no power after suspend. It just needs a power cycle.
 - the card reader is connected to the PCH via the four USB3 data
lines, but the two USB2 data lines are not connected. Is this a legal
configuration? Might this prevent the card reader from receiving power
state commands?

Best,
Samuel



Am Do., 15. Feb. 2018 um 16:36 Uhr schrieb Mathias Nyman
<mathias.nyman@linux.intel.com>:
>
> On 14.02.2018 15:06, Samuel Sadok wrote:
> > Thanks for the patches.
> >
> > However no luck yet, the usb device still doesn't reinitialize.
> >
> > Logs:
> > https://gist.github.com/90ccb390c5777b9e2d5dc595f44d50da
> >
> > Can I somehow check if it is at all possible to bring back this
> > particular device after hub power loss?
> > For instance would you expect reloading all USB modules to bring back
> > the device? I tried that and it didn't help:
>
> I'm starting to run out if ideas, maybe powering port off and on again
> in the logical disconnect could be worth a shot, or maybe trying
> to disable->re-enable port a bit earlier, before the disconnect
>
> -Mathias
>
> >
> > #!/bin/bash
> > echo "Unload modules..."
> > echo 1 > /sys/bus/pci/devices/0000\:00\:14.0/remove
> > rmmod xhci_pci
> > rmmod xhci_hcd
> > rmmod usbhid
> > rmmod bcm5974
> > rmmod btusb
> > rmmod uas
> > rmmod usb_storage
> > rmmod usbcore
> > rmmod usb_common
> > echo "wait"
> > sleep 2
> > echo "Reload modules..."
> > modprobe usb_common
> > modprobe usbcore
> > modprobe usb_storage
> > modprobe uas
> > modprobe btusb
> > modprobe bcm5974
> > modprobe usbhid
> > modprobe xhci_hcd
> > modprobe xhci_pci
> > echo 1 > /sys/bus/pci/rescan
> >
> >
> >
> > 2018-02-13 17:07 GMT+01:00 Mathias Nyman <mathias.nyman@linux.intel.com>:
> >> On 12.02.2018 16:03, Mathias Nyman wrote:
> >>>
> >>> On 10.02.2018 02:01, Samuel Sadok wrote:
> >>>>
> >>>> Thanks Mathias for looking into this.
> >>>>
> >>>> 2018-02-06 18:32 GMT+01:00 Mathias Nyman <mathias.nyman@linux.intel.com>:
> >>>>>
> >>>>>
> >>>>> Does reverting
> >>>>> 37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3
> >>>>> devices
> >>>>> help?
> >>>>
> >>>>
> >>>> Unfortunately not, the card reader is still missing after resume.
> >>>>
> >>>> Here's the dmesg and usbmon (as previously, doing one suspend-resume
> >>>> cycle):
> >>>> https://gist.github.com/anonymous/5aea8eddf97e1b964bffd75ed88793fd
> >>>>
> >>>> For this log I also increased the usbmon buffer size as suggested by
> >>>> Alan (to about 2MB). This (seemingly) resolved the issue with the log
> >>>> gaps.
> >>>>
> >>> Ok, one reason reverting didn't help is that it we still don't really
> >>> disable and re-enable:
> >>>
> >>> [  100.771564] usb usb2-port4: logical disconnect
> >>> ...
> >>> [ 100.771586] usb usb2-port4: Not disabling port; link state is RxDetect
> >>>
> >>>> The reset resume of device "usb 2-4" (the device in question) happens
> >>>> around [100.77].
> >>>> In the usbmon log there is no activity at that exact time, only ~50ms
> >>>> before and after. Can we infer from this that the issue is independent
> >>>> from the actual device and must stem from some faulty state in the
> >>>> kernel or USB controller?
> >>>>
> >>>> Btw I also added/modified some debug lines for my own understanding,
> >>>> those are tagged with "[CUSTOM LOG]".
> >>>>
> >>>>> * check that root cause for failing USB3 device reset after resume is
> >>>>> not
> >>>>> that several
> >>>>>     xhci slots are in Default state at the same time. xHC can't handle
> >>>>> this.
> >>>>>     In normal device enumeration usb core has a mutex protecting it, not
> >>>>> sure
> >>>>> it works here,
> >>>>>     maybe usb core and xhci are out of sync after xHC reset?
> >>>>
> >>>>
> >>>> I find this line in particular interesting:
> >>>> [ 100.771536] xhci_hcd 0000:00:14.0: [CUSTOM LOG] xHCI
> >>>> xhci_urb_enqueue called with unaddressed device, slot_id = 1
> >>>> This comes from xhci_check_args(). Since udev->slot_id == 1 is
> >>>> non-zero this implies that xhci->devs[udev->slot_id] must be NULL for
> >>>> this particular device (usb 2-4), which I guess is not good. So to me
> >>>> this does indeed look like the usb core and xhci are out of sync.
> >>>>
> >>>> However I'm not familiar with the code (for instance what is slot_id
> >>>> is for, who uses it, should it always be 0 on resume?) but based on
> >>>> the log and what you wrote I guess this sounds like a good point:
> >>>
> >>>
> >>> xhci uses slot_id to identify different usb devices connected to it.
> >>> xHC hw gives each enabled attached usb device a slot_id.
> >>> When usb core asks xhci host to do something to a device xhci driver knows
> >>> which device based on udev->slot_id
> >>>
> >>> when xhci controller is reset, all xhci slots are disabled and freed, but
> >>> usb core still has udev->slot_id pointers set.
> >>>
> >>> In normal resume case the xHC controller is not reset, but if something
> >>> goes wrong,
> >>> or power is cut from xHC during suspend then we recover by resetting xHC
> >>> at resume.
> >>>
> >>> I'll try to write some quick testpatches that:
> >>> - removes LPM and LTM disabling from usb_reset_and_verify_device
> >>> - zeroes udev->slot_id when slot is disabled and freed in xhci
> >>> - forces a disable/enable port after port reset failed a few times.
> >>>
> >>
> >> A series for testing can be found at:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git
> >> port-disable-test
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=port-disable-test
> >>
> >> Based on 4.15
> >> Can you try it out?
> >>
> >>
> >> -Mathias
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>

Re: [BUG] SD card reader disappears after suspend

[Alan Stern]

On Mon, 13 Jan 2020, Samuel Sadok wrote:

> Hello,
> 
> It's been a while that there was any discussion on this bug so here's
> a brief context: There's a bug on some MacBook Pro's where the
> built-in SD card reader would be missing after a suspend/resume cycle.
> 
> After looking at the schematics for my laptop I noticed that
> `OC6*/GPIO10` of the Intel PCH is connected to a net called
> `SD_PWR_EN`. So I tried to set this pin to 0 and then to 1 again in
> order to completely power cycle the card reader. Turns out this
> finally makes the card reader appear after a suspend/resume cycle.
> 
> For the record, here's the user space workaround:
> https://gist.github.com/samuelsadok/6d7b3e3015d3370a92ed4702e4d3c4b5#gistcomment-3134437
> 
> Are there other buggy devices for which the kernel already implements
> such a power cycle? Otherwise, where would be the right place to add
> this?

This is a platform-specific solution, so it belongs in a
platform-specific region of the kernel.  Any necessary changes would
mostly have to go outside the USB stack -- after all, GPIO lines aren't
USB devices.

If the kernel already contains some system-setup code specific to the 
MacBook Pro, that's where such a fix belongs.

> Additional observations:
>  - by default (after boot), GPIO10 is configured as input and shows
> the state "high". In the schematics there's a pull-up resistor. and I
> assume it goes to a mosfet (off-sheet). So the problem is not that the
> card reader has no power after suspend. It just needs a power cycle.
>  - the card reader is connected to the PCH via the four USB3 data
> lines, but the two USB2 data lines are not connected. Is this a legal
> configuration? Might this prevent the card reader from receiving power
> state commands?

It is not allowed for a generic connection (i.e., to an external
device) but I think it's okay for something that's built into the
platform.  It could prevent the card reader from working correctly if
for some reason the USB-3 signalling failed and the device tried to
switch over to USB-2 signalling.

On the other hand, there's no real reason I can think of for the card 
reader to need a power cycle following resume.  Fixing that problem, 
whatever it is, would be a better solution.

Alan Stern