u-boot.git/drivers/usb, branch v2025.01

usb: renesas: Fix R-Car spelling

2024-12-11T07:36:24+00:00

The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.

Signed-off-by: Marek Vasut

Merge tag 'u-boot-dfu-20241126' of https://source.denx.de/u-boot/custodians/u-boot-dfu

2024-11-26T14:05:11+00:00

CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/23572

- Fastboot:
  - handle unknown partition type as "raw"
- USB gadget:
  - Fix ci_udc gadget driver for Tegra 2 devices by not using USBADRA

usb: ci_udc: don't use "advance" feature when setting address

2024-11-26T08:56:03+00:00

In the older USB controllers like for example in ChipIdea controller
used by the Tegra 2 the "USBADRA: Device Address Advance" bitflag
does not exist, so the new device address set during SET_ADDRESS
can't be deferred by hardware, which causes the host to not recognize
the device and give an error.

Instead store it until ep completes to apply the change into the hw
register as Linux kernel does. This should fix regression on old and
and be compatible with newer controllers.

Inspired by: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef15e5490edc7edf808d3477ab32e0e320792f65

Signed-off-by: Ion Agorria 
Signed-off-by: Svyatoslav Ryhel 
Reviewed-by: Mattijs Korpershoek 
Link: https://lore.kernel.org/r/20241126072956.64778-2-clamor95@gmail.com
Signed-off-by: Mattijs Korpershoek

eth: asix88179: packet drop when receiving large fragmented packets

2024-11-25T18:11:19+00:00

The ASIX 88179A drops packets when receiving fragmented packets larger
than the MTU size due to an insufficient URB buffer size. This change
synchronizes the URB buffer size with the configuration used in the
Linux kernel, resolving the packet drop issue.

To reproduce the issue, set the following configuration:
    CONFIG_IP_DEFRAG=y
    CONFIG_TFTP_BLOCKSIZE=16352

Then, run the `tftp` command. It will fail with a timeout error:

    U-Boot> tftp zero.bin
    Using ax88179_eth device
    TFTP from server 10.0.0.196; our IP address is 10.0.0.18
    Filename 'zero.bin'
    Load address: 0x10000000
    Loading: T T T T T T T T T T T
    Retry count exceeded; starting again

Signed-off-by: Khoa Hoang 
Reviewed-by: Marek Vasut

eth: asix88179: Fix ASIX AX88179A PHY hang

2024-11-25T18:11:19+00:00

The ASIX AX88179A locks up when the ADVERTISE_NPAGE bit is set in the
MII_ADVERTISE register, suggesting that this feature may be broken or
unsupported on this chip. In the Linux kernel, this bit is not set,
and enabling it also causes the PHY to lock up and stay in a
link-down state.

Additionally, the AX88179 and AX88179A variants do not appear to
support the ADVERTISE_LPACK bit, as setting it consistently reads
back as 0.

This patch removes the ADVERTISE_NPAGE and ADVERTISE_LPACK bits from
the MII_ADVERTISE register configuration. It also resets the PHY
before modifying the MII_ADVERTISE register, then restarts
auto-negotiation, following the same flow used in the U-Boot asix.c
driver.

Signed-off-by: Khoa Hoang 
Reviewed-by: Marek Vasut

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13+00:00

Patrick Rudolph  says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com

drivers: usb: Add generic XHCI

2024-10-27T23:24:13+00:00

Add support for the generic XHCI driver that contains no SoC
specific code. It can be used on platforms that simply work out
of the box, like on emulated platforms.

TEST: Booted on QEMU sbsa machine using the generic xhci driver.

Signed-off-by: Patrick Rudolph 
Reviewed-by: Marek Vasut 
Cc: Tom Rini 
Cc: Marek Vasut

Merge tag 'u-boot-dfu-20241017' of https://source.denx.de/u-boot/custodians/u-boot-dfu

2024-10-17T14:34:01+00:00

u-boot-dfu-20241017

CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22742

Usb Gadget:
- Fix cdns3 endpoint configuration by setting maxpacket
- Fix dwc3 cache handling when using DMA

Fastboot:
- Make AVB_VERIFY depends on FASTBOOT

usb: tcpm: fusb302: add driver

2024-10-17T01:12:47+00:00

Now that the TCPM framework exists we can introduce fusb302
driver using it. This chip is a very common USB-C controller
chip with PD support, which can be found in the Radxa Rock 5B
among many other boards. Apart from Power Delivery, it also
handles detection of the cable orientation. That can be used
to control a mux for connecting the right USB3 lane pair to
the USB3 controller.

The driver is originally from the Linux kernel, but has been
adapted to the requirements of U-Boot and its TCPM framework.

Co-developed-by: Wang Jie 
Signed-off-by: Wang Jie 
Tested-by: Soeren Moch 
Tested-by: Anand Moon 
Reviewed-by: Jonas Karlman 
Signed-off-by: Sebastian Reichel

usb: tcpm: add core framework

2024-10-17T01:12:47+00:00

This adds TCPM framework in preparation for fusb302 support, which can
handle USB power delivery messages. This is needed to solve issues with
devices, that are running from a USB-C port supporting USB-PD, but not
having a battery.

Such a device currently boots to the kernel without interacting with
the power-supply at all. If there are no USB-PD message replies within
5 seconds, the power-supply assumes the peripheral is not capable of
USB-PD. It usually takes more than 5 seconds for the system to reach
the kernel and probe the I2C based fusb302 chip driver. Thus the
system always runs into this state. The power-supply's solution to
fix this error state is a hard reset, which involves removing the
power from VBUS. Boards without a battery (or huge capacitors) will
reset at this point resulting in a boot loop.

This imports the TCPM framework from the kernel. The porting has
originally been done by Rockchip using hardware timers and the Linux
kernel's TCPM code from some years ago.

I had a look at upgrading to the latest TCPM kernel code, but that
beast became a lot more complex due to adding more USB-C features.
I believe these features are not needed in U-Boot and with multiple
kthreads and hrtimers being involved it is non-trivial to port them.
Instead I worked on stripping down features from the Rockchip port
to an even more basic level. Also the TCPM code has been reworked
to avoid complete use of any timers (Rockchip used SoC specific
hardware timers + IRQ to implement delayed work mechanism). Instead
the delayed state changes are handled directly from the poll loop.

Note, that (in contrast to the original Rockchip port) the state
machine has the same hard reset quirk, that the kernel has - i.e.
it avoids disabling the CC pin resistors for devices that are not
self-powered. Without that quirk, the Radxa Rock 5B will not just
end up doing a machine reset when a hard reset is triggered, but will
not even recover, because the CPU will loose power and the FUSB302
will keep this state because of leak voltage arriving through the RX
serial pin (assuming a serial adapter is connected).

This also includes a 'tcpm' command, which can be used to get
information about the current state and the negotiated voltage
and current.

Co-developed-by: Wang Jie 
Signed-off-by: Wang Jie 
Tested-by: Soeren Moch 
Tested-by: Anand Moon 
Reviewed-by: Jonas Karlman 
Signed-off-by: Sebastian Reichel