u-boot.git/drivers, branch v2022.07-rc4

net: enetc: unregister mdiobus

2022-06-03T15:15:24Z

If the device fails to probe - for example, when there is no ethaddr set - then the private data is automatically freed but the mdiobus remains registered. Fixes: 1e354cb39314 ("drivers: net: fsl_enetc: register internal MDIO bus") Signed-off-by: Michael Walle

net: e1000: Depend on CONFIG_PCI

2022-05-26T14:32:27Z

This driver depends on PCI. Update the Kconfig accordingly. Signed-off-by: Sean Anderson Reviewed-by: Tim Harvey Reviewed-by: Stefan Roese Reviewed-by: Ramon Fried

Merge tag 'xilinx-for-v2022.07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-microblaze

2022-05-25T13:50:08Z

Xilinx changes for v2022.07-rc4 zynqmp: - Fix DP PLL configuration for zcu102/zcu106 and SOM - Fix split mode for starting R5s - DT fixes - Remove firmware node for mini configurations - Wire TEE for multi DTB fit image xilinx: - Handle board_get_usable_ram_top(0) properly phy: - Extend psgtr timeout mmc: - Fix mini configuration which misses zynqmp_pm_is_function_supported()

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi

2022-05-25T03:29:00Z

The bulk of it is (finally!) some DT sync from the kernel. We refrained from syncing one incompatible change, as this would spoil booting Linux kernels before v5.13 with U-Boot's DT (via UEFI, for instance). I test booted Linux v5.18 and v5.4 with that new DT on some boards, and the headless peripherals (MMC, USB, Ethernet) seemed to work. The rest are fixes: - silencing missing clock warnings due to the new pinctrl driver - fixing "UART0 on PortF", allowing UART access through the SD card pins - add an F1C100s clock driver, to enable MMC support (SPI comes later) - some cleanups for CONS_INDEX_n in Kconfig Tested on BananaPi-M1, Pine64-LTS, Pine-H64, X96-Mate (H616) and OrangePi-Zero.

Merge tag 'tpm-24052022' of https://source.denx.de/u-boot/custodians/u-boot-tpm

2022-05-24T13:03:34Z

Add support for i2c devices

serial: Remove obsolete CONS_INDEX_n Kconfig options

2022-05-24T00:46:06Z

These were only ever implied by sunxi platforms, and that usage has been removed. Current practice is to specify CONFIG_CONS_INDEX in each board's defconfig. Signed-off-by: Samuel Holland Reviewed-by: Tom Rini Signed-off-by: Andre Przywara

clk: sunxi: add and use dummy gate clocks

2022-05-24T00:16:15Z

Some devices enumerate various clocks in their DT, and many drivers just blanketly try to enable all of them. This creates problems since we only model a few gate clocks, and the clock driver outputs a warning when a clock is not described: ========= sunxi_set_gate: (CLK#3) unhandled ========= Some clocks don't have an enable bit, or are already enabled in a different way, so we might want to just ignore them. Add a CCU_CLK_F_DUMMY_GATE flag that indicates that case, and define a GATE_DUMMY macro that can be used in the clock description array. Define a few clocks, used by some pinctrl devices, that way to suppress the runtime warnings. Signed-off-by: Andre Przywara Reviewed-by: Samuel Holland

clk: sunxi: add PIO bus gate clocks

2022-05-24T00:15:09Z

The introduction of the DM pinctrl driver made its probe function enable all clocks enumerated in the DT. This includes the "CLK_BUS_PIO" (and variations) gate clock. Also CLK_PLL_PERIPH0 is used by the R_CCU device. So far we didn't describe those clocks in our clock driver. As we enable them already in the SPL, the devices happen to work, but the clock driver still complains about not finding those clocks: ========= sunxi_set_gate: (CLK#58) unhandled ========= Add the one-liners that are needed to announce the gate bit for those clocks, to silence that message on the console. Signed-off-by: Andre Przywara Reviewed-by: Samuel Holland

clk: sunxi: h6_r: Correct the driver name

2022-05-24T00:15:01Z

H6 is from the sun50i family, not sun6i. Signed-off-by: Samuel Holland Reviewed-by: Heinrich Schuchardt Signed-off-by: Andre Przywara

mmc: sunxi: Remove unnecessary pinmux option dependency

2022-05-24T00:14:51Z

Now that the pinmux conflict is handled in the board code (by skipping setup for the one conflicting MMC controller), the driver does not need to be entirely disabled based on the UART pinmux. Signed-off-by: Samuel Holland Reviewed-by: Peng Fan Signed-off-by: Andre Przywara