summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-06-18net: dwc_eth_qos: add support for phy-reset-gpios propertyHeesub Shin
This commit adds support for a property 'phy-reset-gpios' to reset PHY chipset. Signed-off-by: Heesub Shin <heesub@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-06-17Merge tag 'xilinx-for-v2024.10-rc1' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-microblaze into next AMD/Xilinx changes for v2024.10-rc1 common: - spl: Introduce SoC specific init function xilinx: - Enable FF-A and NVMEM - Rename spl_board_init() to spl_soc_init() zynqmp: - DT alignments - Enable reset from SPL - Enable USB3 for KD240 - Align multiboot register on Kria for proper reboot - Allow multiboot environment write even in saved environment - Move zynqmp commands from board/ to arch/ - Clean up xilinx_zynqmp.h versal: - Do not prioritize boot device if driver is not enabled versal-net: - Setup location for redundant variables in SPI versal2: - Add support for new SOC mmc: - Fix tap delay for SD on Versal NET spi: - Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part gpio: - Cover MODEPIN firmware dependency
2024-06-17gpio: Add proper dependency on ZYNQMP_FIRMWAREMichal Simek
ZYNQMP_FIRMWARE can be disabled and driver depends on it that's why record this dependency via Kconfig. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/c3ca38fbb2f4e6948a5ef95b369015de96259709.1717685091.git.michal.simek@amd.com
2024-06-17spi: versal2: Enable spi drivers for Versal Gen 2Michal Simek
Enable and update OSPI/QSPI/GQSPI drivers to support Versal Gen 2 SoCs. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/691782470f56f7d49a3204f6757296f2752d4156.1716994063.git.michal.simek@amd.com
2024-06-17mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2Michal Simek
Enable tap delay programming for new SoC and also enable it via defconfig. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/f07daded9704cbc393657b65a28933c34a8cec25.1716994063.git.michal.simek@amd.com
2024-06-17soc: versal2: Add SoC driver for AMD Versal Gen 2Michal Simek
Communication is happening via firmware interface (SMC) or via direct register reading if firmware driver is not available. Also enable it via defconfig. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/22cf9c765e47ab03dbf2b8363e6626e809113432.1716994063.git.michal.simek@amd.com
2024-06-17arm64: versal2: Add support for AMD Versal Gen 2Michal Simek
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2 cpu core each. A lot of IPs are shared with previous families. There are couple of new IP blocks where the most interesting from user point of view is UFS. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com
2024-06-17mtd: spi-nor: Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash partPrasad Kummari
Added SPI_NOR_OCTAL_READ flag for Macronix mx66uw2g345gx0 2Gb(256MB) NOR Flash memory. Initial testing was conducted on the Versal NET board using SDR mode, which included basic erase, write, and read-back operations. Signed-off-by: Prasad Kummari <prasad.kummari@amd.com> Link: https://lore.kernel.org/r/20240508052749.214286-1-prasad.kummari@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-06-17sdhci: zynq: Fix tap delay for SD on Versal NETSimek, Michal
I can't see any way how tap delays are setup on Versal NET platform because xlnx,versal-8.9a compatible string is also used there but driver is not letting to setup tap delays. Not sure if versal_iclk_phases[] is also valid for Versal NET but the patch is made to investigate it. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/e535cfc1a59b5146a5c9a3ab389dc770de80440c.1713427490.git.michal.simek@amd.com
2024-06-16Merge branch 'next' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-watchdog into next - misc cyclic infrastructure improvements (Rasmus) - watchdog_reset cleanup (Rasmus) CI: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=369&view=results
2024-06-16Merge tag 'u-boot-rockchip-next-20240615' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-rockchip into next CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/21113 - New board: Theobroma Systems SOM-RK3588-Q7 Tiger, ArmSoM Sige7 Rk3588; - PX30 dts migrate to OF_UPSTREAM; - Some other update on board or config;
2024-06-16serial: ns16550: fix comment to mention schedule instead of watchdog_resetRasmus Villemoes
watchdog_reset() is no more. Make the comments match the code and today's reality. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de>
2024-06-16wdt-uclass: watchdog_reset cleanupRasmus Villemoes
watchdog_reset() is no longer called from anywhere, so we do not need to define a dummy no-op function. Remove that definition, and update references to say schedule() instead. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de>
2024-06-16cyclic: make clients embed a struct cyclic_info in their own data structureRasmus Villemoes
There are of course not a whole lot of examples in-tree yet, but before they appear, let's make this API change: Instead of separately allocating a 'struct cyclic_info', make the users embed such an instance in their own structure, and make the convention that the callback simply receives the 'struct cyclic_info *', from which the clients can get their own data using the container_of() macro. This has a number of advantages. First, it means cyclic_register() simply cannot fail, simplifying the code. The necessary storage will simply be allocated automatically when the client's own structure is allocated (often via uclass_priv_auto or similar). Second, code for which CONFIG_CYCLIC is just an option can more easily be written without #ifdefs, if we just provide an empty struct cyclic_info {}. For example, the nested CONFIG_IS_ENABLED()s in https://lore.kernel.org/u-boot/20240316201416.211480-1-marek.vasut+renesas@mailbox.org/ are mostly due to the existence of the 'struct cyclic_info *' member being guarded by #ifdef CONFIG_CYCLIC. And we do probably want to avoid the extra memory overhead of that member when !CONFIG_CYCLIC. But that is automatic if, instead of a 'struct cyclic_info *', one simply embeds a 'struct cyclic_info', which will have size 0 when !CONFIG_CYCLIC. Also, the no-op cyclic_register() function can just unconditionally be called, and the compiler will see that (1) the callback is referenced, so not emit a warning for a maybe-unused function and (2) see that it can actually never be reached, so not emit any code for it. Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2024-06-16wdt-uclass: prevent multiple cyclic_register callsRasmus Villemoes
Currently, the cyclic_register() done in wdt_start() is not undone in wdt_stop(). Moreover, calling wdt_start multiple times (which is perfectly allowed on an already started device, e.g. to change the timeout value) will result in another struct cyclic_info being registered, referring to the same watchdog device. This can easily be seen on e.g. a wandboard: => cyclic list function: watchdog@20bc000, cpu-time: 22 us, frequency: 1.01 times/s => wdt list watchdog@20bc000 (imx_wdt) => wdt dev watchdog@20bc000 => wdt start 50000 WDT: Started watchdog@20bc000 with servicing every 1000ms (50s timeout) => cyclic list function: watchdog@20bc000, cpu-time: 37 us, frequency: 1.03 times/s function: watchdog@20bc000, cpu-time: 241 us, frequency: 1.01 times/s => wdt start 12345 WDT: Started watchdog@20bc000 with servicing every 1000ms (12s timeout) => cyclic list function: watchdog@20bc000, cpu-time: 36 us, frequency: 1.03 times/s function: watchdog@20bc000, cpu-time: 100 us, frequency: 1.04 times/s function: watchdog@20bc000, cpu-time: 299 us, frequency: 1.00 times/s So properly unregister the watchdog device from the cyclic framework in wdt_stop(). In wdt_start(), we cannot just skip the registration, as the (new) timeout value may mean that we have to ask the cyclic framework to call us more often. So if we're already running, first unregister the old cyclic instance. Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2024-06-14Merge patch series "efi_loader: select BLK not depends on BLK"Tom Rini
Tom Rini <trini@konsulko.com> says: Rework how the BLK symbol is used now that so much DM migration has been completed.
2024-06-14block: Update BLK to be def_boolTom Rini
At this point in the DM migration, all platforms enable DM. BLK requires DM. Make BLK "def_bool y" in the cases it had been "default y" to make this clearer. Now remove the symbol requirement from other places as it is redundant here. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-14power: rk8xx: properly print all supported PMICs nameQuentin Schulz
The ID of the PMIC is stored in the 2 16b registers but the only part that matters right now is the 3 MSB, which make the 3 digits (in hex) of the part number. Right now, only RK808 was properly displayed, with this all currently supported PMICs should display the proper part number. Additionally, when the PMIC variant is not found, print that value instead of the masked unshifted value as all PMICs we support for now have their LSB ignored to represent the actual part number. Tested on RK806 (RK3588 Jaguar), RK808 (RK3399 Puma) and RK809 (PX30 Ringneck). Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
2024-06-13bcmgenet: fix Rx buffer corruption caused by lack of cache flushYasuharu Shibata
When bcmgenet complete to write Rx buffer with the DMA, some U-Boot commands write data to the buffer directly. Those write data will become dirty in CPU cache. After this driver calls free_pkt to the buffer, the buffer is assigned as the future Rx buffer. At some point, if bcmgenet writes to a buffer with DMA and CPU cache flushes dirty data to the buffer, the buffer is corrupted. This patch calls flush_dcache_range in free_pkt to immediately flush the data written by U-Boot command and prevent data corruption. This issue can be reproduced using wget on Raspberry Pi4. If wget receives data larger than RX_BUF_LENGTH * RX_DESCS = 2048 * 256 bytes, it will timeout due to data corruption. In addition, if LOG_DEBUG is enabled in net/tcp.c, the following error log is output. TCP RX TCP xSum Error Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com>
2024-06-13net: phy: Replace PHY_ANEG_TIMEOUT with Kconfig symbolMarek Vasut
Switch PHY_ANEG_TIMEOUT to CONFIG_PHY_ANEG_TIMEOUT Kconfig symbol. This removes one more configuration headers option finalizes its Kconfig symbol conversion. No functional change expected. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-06-13net: phy: Turn default auto-negotiation timeout into Kconfig symbolMarek Vasut
Let users configure default auto-negotiation timeout via Kconfig instead of specifying it in board configuration headers. This is the first step toward converting this to Kconfig fully, so far the legacy PHY_ANEG_TIMEOUT in configuration headers takes precedence. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-06-13Merge patch series "Enable OSPI boot for j721s2"Tom Rini
Manorit Chawdhry <m-chawdhry@ti.com> says: The series enables ospi boot for j721s2. Test logs: https://gist.github.com/manorit2001/6bb91885c608e3a8cb0267ab2c614781
2024-06-12mtd: spi-nor-core: Do not start or end writes at odd address in DTR modePratyush Yadav
On DTR capable flashes like Micron Xcella the writes cannot start or end at an odd address in DTR mode. Extra 0xff bytes need to be prepended or appended respectively to make sure both the start and end addresses are even. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Apurva Nandan <a-nandan@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com> Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
2024-06-07memory: ti-gpmc: use printf to dump settings/timingsRoger Quadros
pr_info() depends on CONFIG_LOGLEVEL > 6. If user has enabled CONFIG_TI_GPMC_DEBUG then we should print the GPMC settings/timings regardless of CONFIG_LOGLEVEL. So use printf() instead of pr_info(). Signed-off-by: Roger Quadros <rogerq@kernel.org>
2024-06-07Merge patch series "Adding support to load secure firmware for HS devices"Tom Rini
Udit Kumar <u-kumar1@ti.com> says: Some use case needs rproc firmware to be loaded at u-boot stage, using following commands at u-boot shell, firmware could be loaded => setenv dorprocboot 1 => run boot_rprocs For Secure devices, secure version of rproc firmware should be loaded, which is appended by sec keyword[0]. but currently non-secure firmware is loaded even for secure devices. So adding support for loading secure firmware on Secured devices. [0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7 Bootlogs: GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-gp_device line 65 onwards HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-hs-device line 60 onwards
2024-06-07drivers: remoteproc: ti_k3 : enable secure booting with firmware imagesManorit Chawdhry
Remoteproc firmware images aren't authenticated in the current boot flow. Authenticates remoteproc firmware images to complete the root of trust in secure booting. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2024-06-04Merge tag 'v2024.07-rc4' into nextTom Rini
Prepare v2024.070-rc4
2024-05-30andes: l2 cache driver: fixes typos and cctl statusLeo Yu-Chi Liang
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2024-05-27Merge tag 'tpm-master-27052024' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-tpm TPM fixes
2024-05-27tpm: display warning if using gpio reset with TPMTim Harvey
Instead of displaying what looks like an error message if a gpio-reset dt prop is missing for a TPM display a warning that having a gpio reset on a TPM should not be used for a secure production device. TCG TIS spec [1] says: "The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the platform CPU Reset signal such that it complies with the requirements specified in section 1.2.7 HOST Platform Reset in the PC Client Implementation Specification for Conventional BIOS." The reasoning is that you should not be able to toggle a GPIO and reset the TPM without resetting the CPU as well because if an attacker can break into your OS via an OS level security flaw they can then reset the TPM via GPIO and replay the measurements required to unseal keys that you have otherwise protected. Additionally restructure the code for improved readability allowing for removal of the init label. Before: - board with no reset gpio u-boot=> tpm init && tpm info tpm_tis_spi_probe: missing reset GPIO tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open] - board with a reset gpio u-boot=> tpm init && tpm info tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open] After: - board with no reset gpio u-boot=> tpm init && tpm info tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open] - board with a reset gpio u-boot=> tpm init && tpm info tpm@1: TPM gpio reset should not be used on secure production devices tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open] [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-05-24Merge patch series "FWU: Add support for FWU metadata version 2"Tom Rini
Sughosh Ganu <sughosh.ganu@linaro.org> says: The following patch series adds support for version 2 of the FWU metadata. The version 2 metadata structure is defined in the latest revision of the FWU specification [1]. The earlier versions of these patches were migrating to a version 2 only support in U-Boot, similar to TF-A. However, based on feedback from ST [2], this series has been updated to support both versions. A platform would still be needed to enable one of the two versions of metadata through a config symbol. TF-A has code which reads the FWU metadata and boots the platform from the active partition. TF-A has decided to migrate the FWU code to a version 2 only support. These changes have been merged in upstream TF-A. These changes have been tested on the ST DK2 board, which uses the GPT based partitioning scheme. Both V1 and V2 metadata versions have been tested on the DK2 board. These changes need to be tested on platforms with MTD partitioned storage devices.
2024-05-24drivers: fwu: mtd: allocate buffer for image info dynamicallySughosh Ganu
The FWU metadata access driver for MTD partitioned devices currently uses a statically allocated array for storing the updatable image information. This array depends on the number of banks and images per bank. With migration of the FWU metadata to version 2, these parameters are now obtained at runtime from the metadata. Make changes to the FWU metadata access driver for MTD devices to allocate memory for the image information dynamically in the driver's probe function, after having obtained the number of banks and images per bank by reading the metadata. Move the image information as part of the driver's private structure, instead of using a global variable. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
2024-05-24drivers: fwu: add the size parameter to the metadata access API'sSughosh Ganu
In version 2 of the metadata structure, the size of the structure cannot be determined statically at build time. The structure is now broken into the top level structure which contains a field indicating the total size of the structure. Add a size parameter to the metadata access API functions to indicate the number of bytes to be accessed. This is then used to either read the entire structure, or only the top level structure. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
2024-05-24clk: rockchip: rk3588: Set SPLL frequency during SPL stageHeiko Stuebner
All parts expect the SPLL to run at 702MHz. In U-Boot it's the SPLL_HZ declaring this rate and in the kernel it's a fixed clock definition. While everything is expecting 702MHz, the SPLL is not running that frequency when coming from the bootrom though, instead it's running at 351MHz and the vendor-u-boot just sets it to the expected frequency. The SPLL itself is located inside the secure-BUSCRU and in theory accessible as an SCMI clock, though this requires an unknown amount of cooperation from trusted-firmware to set at a later stage, though during the SPL stage we can still access the relevant CRU directly. The SPLL is for example necessary for the DSI controllers to produce output. As the SPLL is "just" another rk3588 pll, just set the desired rate directly during the SPL stage. Tested on rk3588-rock5b and rk3588-tiger by reading back the PLL rate and also observing working DSI output with this change. Fixes: 6737771600d4 ("rockchip: rk3588: Add support for sdmmc clocks in SPL") Suggested-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2024-05-22Merge patch series "Clean-up patch set for MbedTLS integration"Tom Rini
Raymond Mao <raymond.mao@linaro.org> says: This patch set is picked from the previously posted serie: "[RFC] Integrate MbedTLS v3.6 LTS with U-Boot" They are not directly related to MbedTLS integration, but the prerequisite for a few clean-up, refactoring and minor fixes. For V2, the linker script patch is dropped and added one patch to move the snprintf to stdio.h
2024-05-22include: Move snprintf to stdio.hRaymond Mao
Move snprintf to stdio.h since it is needed by exteranl libraries. Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-05-22md5: Use typedef for MD5 contextRaymond Mao
Use of typedef is beneficial for porting with other crypto libs without changing the API callers. Secondly, it is for the code consistency with other digest libs. SHA1, SHA256 and SHA512 are all using typedef for their context. Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-20Merge tag 'v2024.07-rc3' into nextTom Rini
Prepare v2024.07-rc3
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-17phy: Use dt-bindig definations for npcm usb phyJim Liu
Use dt-binding definations for the phy switch connection. It declares the target usb controller it is connected to. Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
2024-05-17pinctrl: Fix pinctrl_gpio_get_pinctrl_and_offset()Jonas Karlman
Linux kernel Documentation/devicetree/bindings/gpio/gpio.txt define the format of the gpio-ranges prop as: The format is: <[pin controller phandle], [GPIO controller offset], [pin controller offset], [number of pins]>; Example: gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>; This means: - pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and - pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29 For this example, a call to pinctrl_gpio_get_pinctrl_and_offset() using offset 10 incorrectly return pin controller "foo" instead of "bar". Fix this by using an exclusive range check. Fixes: d0bb00adccb8 ("pinctrl: fix pinctrl_gpio_get_pinctrl_and_offset for gpio-ranges array") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quanyang Wang <quanyang.wang@windriver.com>
2024-05-16Merge tag 'u-boot-dfu-20240516' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-dfu u-boot-dfu-20240516 - Fix cdns3 low power hang via fast access bit - Multiple dwc3 gadget fixes, mainly for USB support on TI AM6232 - Consistent USB_GADGET_MANUFACTURER for PHYTEC boards - MAINTAINERS file update for u-boot-dfu
2024-05-16usb: dwc3: gadget: Disable GUSB2PHYCFG.SUSPHY for End TransferThinh Nguyen
Upstream Linux commit 3aa07f72894d. If there's a disconnection while operating in eSS, there may be a delay in VBUS drop response from the connector. In that case, the internal link state may drop to operate in usb2 speed while the controller thinks the VBUS is still high. The driver must make sure to disable GUSB2PHYCFG.SUSPHY when sending endpoint command while in usb2 speed. The End Transfer command may be called, and only that command needs to go through at this point. Let's keep it simple and unconditionally disable GUSB2PHYCFG.SUSPHY whenever we issue the command. This scenario is not seen in real hardware. In a rare case, our prototype type-c controller/interface may have a slow response triggerring this issue. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/5651117207803c26e2f22ddf4e5ce9e865dcf7c7.1668045468.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240412202611.3565052-7-alexander.sverdlin@siemens.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-16usb: dwc3: gadget: properly check ep cmdFelipe Balbi
Upstream Linux commit 5999914f227b. The cmd argument we pass to dwc3_send_gadget_ep_cmd() could contain extra arguments embedded. When checking for StartTransfer command, we need to make sure to match only lower 4 bits which contain the actual command and ignore the rest. Reported-by: Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> [A. Sverdlin: cherry-picked only DWC3_DEPCMD_CMD() define] Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240412202611.3565052-6-alexander.sverdlin@siemens.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-16usb: dwc3: gadget: Check ENBLSLPM before sending ep commandThinh Nguyen
Upstream Linux commit 87dd96111b0b. When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint command. Current implementation only save and restore GUSB2PHYCFG.SUSPHY configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY settings. Restore them after the command is completed. DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2 Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240412202611.3565052-5-alexander.sverdlin@siemens.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-16usb: dwc3: gadget: only resume USB2 PHY in <=HIGHSPEEDFelipe Balbi
Upstream Linux commit ab2a92e7a608. As a micro-power optimization, let's only resume the USB2 PHY if we're working on <=HIGHSPEED. If we're gonna work on SUPERSPEED or SUPERSPEED+, there's no point in resuming the USB2 PHY. Fixes: 2b0f11df84bb ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds") Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240412202611.3565052-4-alexander.sverdlin@siemens.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-16usb: dwc3: gadget: clear SUSPHY bit before ep cmdsFelipe Balbi
Upstream Linux commit 2b0f11df84bb. Synopsys Databook 2.60a has a note that if we're sending an endpoint command we _must_ make sure that DWC3_GUSB2PHY(n).SUSPHY bit is cleared. This patch implements that particular detail. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240412202611.3565052-3-alexander.sverdlin@siemens.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-16usb: dwc3: gadget: combine return points into a single oneFelipe Balbi
Upstream Linux commit c0ca324d09a0. dwc3_send_gadget_ep_cmd() had three return points. That becomes a pain to track when we need to debug something or if we need to add more code before returning. Let's combine all three return points into a single one just by introducing a local 'ret' variable. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20240412202611.3565052-2-alexander.sverdlin@siemens.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-15dma: ti: k3-udma: invalidate prepared buffers before pushing to recv ringMatthias Schiffer
Buffers must not have an unclean cache before being used for DMA - a pending write-back may corrupt the next dev-to-mem transfer otherwise. This was consistently noticeable during long TFTP transfers, when an ARP request is answered by U-Boot in the middle of the transfer: As U-Boot's arp_receive() reuses the receive buffer to prepare its reply packet, the beginning of one of the next incoming TFTP packets is overwritten by the ARP reply. The corrupted packet is ignored, but the TFTP transfer stalls for a few seconds until a timeout is detected and a retransmit is triggered. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
generated by cgit v1.2.3 (git 2.0.4) at 2025-08-03 12:56:31 +0000