10 Apr, 2020

1 commit

  • Rather than keeping the asynchronous schedule running always, keep it
    running only across USB mass storage transfers for now, as it seems
    that keeping it running all the time interferes with certain control
    transfers during device enumeration.

    Note that running the async schedule all the time should not be an
    issue, especially on EHCI HCD, as that one implements most of the
    transfers using async schedule.

    Note that we have usb_disable_asynch(), which however is utterly broken.
    The usb_disable_asynch() blocks the USB core from doing async transfers
    by setting a global flag. The async schedule should however be disabled
    per USB controller. Moreover, setting a global flag does not prevent the
    controller from using the async schedule, which e.g. the EHCI HCD does.

    This patch implements additional callback to the controller, which
    permits it to lock the async schedule and keep it running across
    multiple transfers. Once the schedule is unlocked, it must also be
    disabled. This thus prevents the async schedule from running outside
    of the USB mass storage transfers.

    Signed-off-by: Marek Vasut
    Cc: Lukasz Majewski
    Cc: Tom Rini
    Tested-by: Tom Rini [omap3_beagle, previously failing]

    Marek Vasut
     

31 Oct, 2019

2 commits

  • Clear the USB_READY flag in the storage driver only in case there
    is an error, otherwise usb_stor_BBB_transport() waits 5 mS before
    doing anything every single time.

    This is because the USB_READY flag is only ever set in
    usb_test_unit_ready(), which is called only upon storage device
    probe, not between each and every request. However, the device
    cannot move out of USB_READY state once it was initialized.

    Signed-off-by: Marek Vasut
    Cc: Bin Meng
    Cc: Simon Glass

    Marek Vasut
     
  • Due to constant influx of more and more weird and broken USB sticks,
    do as Linux does in commit 779b457f66e10de3471479373463b27fd308dc85

    usb: storage: scsiglue: further describe our 240 sector limit

    Just so we have some sort of documentation as to why
    we limit our Mass Storage transfers to 240 sectors,
    let's update the comment to make clearer that
    devices were found that would choke with larger
    transfers.

    While at that, also make sure to clarify that other
    operating systems have similar, albeit different,
    limits on mass storage transfers.

    And reduce the maximum transfer length of USB storage to 120 kiB.

    Signed-off-by: Marek Vasut
    Reviewed-by: Bin Meng
    Cc: Bin Meng
    Cc: Simon Glass

    Marek Vasut
     

11 Sep, 2019

2 commits


27 Nov, 2018

2 commits


15 Nov, 2018

1 commit

  • part_init() is currently called in every DM BLK driver, either
    in its bind() or probe() method. However we can use the BLK
    uclass driver's post_probe() method to do it automatically.

    Update all DM BLK drivers to adopt this change.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     

11 Sep, 2018

1 commit

  • In int-ll64.h, we always use the following typedefs:

    typedef unsigned int u32;
    typedef unsigned long uintptr_t;
    typedef unsigned long long u64;

    This does not need to match to the compiler's .
    Do not include it.

    The use of PRI* makes the code super-ugly. You can simply use
    "l" for printing uintptr_t, "ll" for u64, and no modifier for u32.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

01 Oct, 2017

1 commit

  • The stored 'blk' value is overwritten to 'size / 512' before it can
    be used in usb_stor_set_max_xfer_blk(). This is not what we want.
    In fact, when 'size' exceeds the upper limit (USHRT_MAX * 512), we
    should simply assign 'size' to the upper limit.

    Reported-by: Coverity (CID: 167250)
    Signed-off-by: Bin Meng

    Bin Meng
     

27 Sep, 2017

2 commits

  • When EHCD and xHCD are enabled at the same time, USB storage device
    driver will fail to read/write from/to the storage device attached
    to the xHCI interface, due to its transfer blocks exceeds the xHCD
    driver limitation.

    With driver model, we have an API to get the controller's maximum
    transfer size and we can use that to determine the storage driver's
    capability of read/write.

    Note: the non-DM version driver is still broken with xHCD and the
    intent here is not to fix the non-DM one, since the xHCD itself is
    already broken in places like 3.0 hub support, etc.

    Signed-off-by: Bin Meng

    Bin Meng
     
  • This adds a new memeber max_xfer_blk in struct us_data to record
    the maximum number of transfer blocks for the storage device.

    It is set per HCD setting, and so far is to 65535 for EHCD and 20
    for everything else.

    Signed-off-by: Bin Meng

    Bin Meng
     

12 Jul, 2017

1 commit

  • We should not be using typedefs in U-Boot and 'ccb' is a pretty short
    name. It is also used with variables. Drop the typedef and use 'struct'
    instead.

    Signed-off-by: Simon Glass
    Reviewed-by: Bin Meng

    Simon Glass
     

15 May, 2017

1 commit


14 Apr, 2017

1 commit

  • This fixes a regression caused by

    commit 07b2b78ce4bc8ae25e066c65245eaf58c0d9a67c
    dm: usb: Convert USB storage to use driver-model for block devs

    which caused part_init to be called when it was not previously.
    Without this patch, the following happens when a USB sd card reader is used.

    => usb start
    starting USB...
    USB0: Port not available.
    USB1: USB EHCI 1.00
    scanning bus 1 for devices... 3 USB Device(s) found
    scanning usb for storage devices... Device NOT ready
    Request Sense returned 02 3A 00
    ### ERROR ### Please RESET the board ###

    This happens because dev_desc->blksz is 0.

    Signed-off-by: Troy Kisky

    Troy Kisky
     

17 Jan, 2017

1 commit

  • By enabling DM_USB information about number of storage devices
    was lost.
    Get this information back simply by printing number of devices detected
    via BLK uclass.

    For example:
    scanning bus 0 for devices... 7 USB Device(s) found
    scanning usb for storage devices... 3 Storage Device(s) found
    scanning usb for ethernet devices... 0 Ethernet Device(s) found

    Signed-off-by: Michal Simek

    Michal Simek
     

24 Sep, 2016

1 commit


17 May, 2016

3 commits


23 Mar, 2016

2 commits


15 Mar, 2016

6 commits


21 Jan, 2016

1 commit


14 Jan, 2016

1 commit

  • This will allow the implementation to make use of data in the block_dev
    structure beyond the base device number. This will be useful so that eMMC
    block devices can encompass the HW partition ID rather than treating this
    out-of-band. Equally, the existence of the priv field is crying out for
    this patch to exist.

    Signed-off-by: Stephen Warren
    Reviewed-by: Tom Rini

    Stephen Warren
     

08 Jan, 2016

1 commit

  • The current limit of 5 is not enough for the driver model USB tests. Really
    we should not have a limit but the driver model code still uses the
    usb_dev_desc[] array, which has a limit.

    Increasing the limit by 2 should not bother anyone. Adjust it.

    Signed-off-by: Simon Glass
    Reviewed-by: Marek Vasut

    Simon Glass
     

04 Nov, 2015

1 commit


23 Oct, 2015

1 commit


12 Sep, 2015

1 commit


22 Jul, 2015

1 commit

  • In Linux USB_DEVICE() is used to declare a USB device by vendor/device ID.
    We should follow the same convention in U-Boot. Rename the existing
    USB_DEVICE() macro to U_BOOT_USB_DEVICE() and bring in the USB_DEVICE()
    macro from Linux for use in U-Boot.

    Signed-off-by: Simon Glass

    Simon Glass
     

19 Apr, 2015

4 commits