Hi Simon, Hi Bin,
On 20.11.2017 16:38, Simon Glass wrote:
On 20 November 2017 at 00:07, Bin Meng bmeng.cn@gmail.com wrote:
Hi Stefan,
On Wed, Sep 27, 2017 at 1:03 AM, Stefan Roese sr@denx.de wrote:
Hi,
I'm currently testing USB on my x86 platform. And noticed, that the "usb storage" command does not work as expected:
=> usb reset resetting USB... USB0: Register 7000820 NbrPorts 7 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 5 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Mass Storage (480 Mb/s, 224mA) | SanDisk Ultra 4C530001010620110505 | +-3 Hub (480 Mb/s, 0mA) | +-4 Hub (480 Mb/s, 100mA) | +-5 Hub (12 Mb/s, 100mA)
=> usb storage Card did not respond to voltage select! mmc_init: -95, time 28 No storage devices, perhaps not 'usb start'ed..?
While debugging I found, that usb_stor_info() calls blk_first_device(IF_TYPE_USB, &dev) which calls uclass_first_device(UCLASS_BLK, devp). With my current DM tree:
=> dm tree Class Probed Name
root [ + ] root_driver ... mmc [ + ] | |-- pci_mmc blk [ ] | | `-- pci_mmc.blk mmc [ + ] | |-- pci_mmc blk [ ] | | `-- pci_mmc.blk
the first BLK device is a MMC device. With uclass_first_device() its probe function is called here, which fails in this case. Resulting in an abort for the loop over all BLK devices.
How should this be handled for the "usb storage" command. Probing all BLK devices while running this command seems a bit too much.
Any suggestions on how to fix this?
Sorry I missed this before. Is it still broken in current mainline?
Me too.
Probing the block device should call mmc_blk_probe() which should call mmc_init(), etc. I'm not sure what is going wrong there?
I'm currently traveling and frankly I don't recall everything on this issue. I need to dig into this, once I'm back in the office end of this week. But many thanks for checking on this.
Thanks, Stefan