Skip to content
Snippets Groups Projects
  1. Jun 26, 2023
  2. Jun 25, 2023
  3. Jun 24, 2023
  4. Jun 23, 2023
  5. Jun 21, 2023
    • Tom Rini's avatar
    • Teik Heng Chong's avatar
      usb: dwc2: Fix the write to W1C fields in HPRT register · 9c9454ac
      Teik Heng Chong authored and Marek Vasut's avatar Marek Vasut committed
      
      Fix the write to the HPRT register which treat W1C fields
      as if they were mere RW. This leads to unintended clearing of such fields
      
      This bug was found during the testing on Simics model. Referring to
      specification DesignWare Cores USB 2.0 Hi-Speed On-The-Go (OTG)
      Databook (3.30a)"5.3.4.8 Host Port Control and Status Register (HPRT)", the
      HPRT.PrtPwr is cleared by this mistake. In the Linux driver (contrary to
      U-Boot), HPRT is always read using dwc2_read_hprt0 helper function which
      clears W1C bits. So after write back those bits are zeroes.
      
      Signed-off-by: default avatarTeik Heng Chong <teik.heng.chong@intel.com>
      9c9454ac
    • Xavier Drudis Ferran's avatar
      cmd: usb: Prevent reset in usb tree/info command · 7a875a8e
      Xavier Drudis Ferran authored and Marek Vasut's avatar Marek Vasut committed
      
         Commands causing reset in some configs:
      
      When bootflow scan is run, this will cause a UCLASS_BOOTDEV device to
      be added as sibling of those UCLASS_BLK devices found in the search
      chain defined in environment variable "boot_targets", until boot
      succeeds from some device. This can happen automatically as part of
      the default boot process on some boards (example: Rock Pi 4) depending
      on the board configuration (DISTRO_DEFAULTS, BOOTSTD, BOOTCOMMAND,
      etc.) because they have bootcmd=bootflow scan.
      
      If boot doesn't succeed from any device, and usb is in boot_targets,
      and an usb storage device is plugged to some usb port at boot time,
      its UCLASS_MASS_STORAGE device will have a UCLASS_BOOTDEV device as
      child, besides a UCLASS_BLK child.
      
      If once the boot fails the user enters at the U-Boot shell prompt:
      
      usb info
      
      or
      
      usb tree
      
      The code in cmd/usb.c will eventually recurse into the UCLASS_BOOTDEV
      device and pass a null usb_device pointer to usb_show_tree_graph() or
      usb_show_info() (because it has no parent_priv_).
      
      This causes a reset. The expected behaviour would be to ignore the
      UCLASS_BOOTDEV device, continue listing the usb information and return
      to the prompt.
      
         Minimal test:
      
      Another way to trigger this reset as a minimal test or on boards with
      a different bootcmd would be:
      
      - make sure "usb" is in environment variable boot_targets (might need
        setenv boot_targets usb; and/or saveenv and reset), then, with a usb
        storage device plugged to a usb port, run:
      
      => usb reset ; bootflow scan ; usb info
      
         Solution:
      
      Fix it (twice) by checking for null parent_priv_ and adding
      UCLASS_BOOTDEV to the list of ignored class ids before the recursive
      call.
      
      This prevents the current particular problem with UCLASS_BOOTDEV, even
      in case it ever gets some parent_priv_ struct which is not an
      usb_device, despite being the child of a usb_device->dev. And it also
      prevents possible future problems if other children are added to usb
      devices that don't have parent_priv_ because they are not part of the
      usb tree, just abstractions of functionality (like UCLASS_BLK and
      UCLASS_BOOTDEV are now).
      
      Signed-off-by: default avatarXavier Drudis Ferran <xdrudis@tinet.cat>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
      Tested-by: default avatarMarek Vasut <marex@denx.de>
      7a875a8e
  6. Jun 19, 2023
  7. Jun 16, 2023
Loading