summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-03-20gpio: mcp230xx: Add support for models with SPI interface.Piotr Wojtaszczyk
Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
2024-03-19Merge tag 'u-boot-socfpga-next-20240319' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next - A new driver in the misc to register setting from device tree. This also provides user a clean interface and all register settings are centralized in one place, device tree. - Enable Agilex5 platform for Intel product. Changes, modification and new files are created for board, dts, configs and makefile to create the base for Agilex5. Build-tested on SoC64 boards, boot tested on some of them.
2024-03-18arch: arm: Agilex5 enablementJit Loon Lim
This patch is to enable Agilex5 platform for Intel product. Changes, modification and new files are created for board, dts, configs and makefile to create the base for Agilex5. Signed-off-by: Jit Loon Lim <jit.loon.lim@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
2024-03-18drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGAWan Yee Lau
Add socfpga_dtreg driver enablement for Intel SoCFPGA. Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
2024-03-17drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree nodeBenjamin Hahn
The polling rate is already specified in some devicetrees, like imx8mp.dtsi for example, but was not selected so far. For the trippoints, the cpu-thermal node is used. Also get the polling rate from this node. Use the default of 5000ms if the polling rate should not be specified in the devicetree. NOTE: The polling rate from the devicetree will be used after this patch. In imx8*.dtsi devicetrees the polling delay is set to 2000ms for example. Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
2024-03-15Merge tag 'u-boot-rockchip-20240315' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-rockchip into next Please pull the updates for rockchip platform: - Add board: rk3588 Generic, Cool Pi CM5, Theobroma-Systems RK3588 Jaguar SBC, Toybrick TB-RK3588X; rk3588s Cool Pi 4B; rk3566 Pine64 PineTab2; - Add saradc v2 support; - Add PMIC RK806 support; - rk3588 disable force_jtag by default; - Migrate to use IO-domain driver for all boards; - Use common bss and stack addresses for rk33xx and rk35xx boards; - Other updates for driver, config and dts;
2024-03-14button: add missing ADC dependency for BUTTON_ADCQuentin Schulz
The BUTTON_ADC symbol guards the compilation of button-adc driver whose name very well makes it explicit that it requires ADC support to be enabled. Fix build issue of button-adc driver when ADC support isn't enabled by making sure it cannot be built without ADC support. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14adc: add missing depends on ADC for controller driversQuentin Schulz
The ADC controller drivers are obviously all depending on ADC symbol being selected. While they don't seem to fail to build without, they won't be useful without that symbol selected, so let's make sure the options aren't shown in menuconfig when ADC isn't selected. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14power: pmic: rk8xx: fix duplicate promptQuentin Schulz
SPL_PMIC_RK8XX and PMIC_RK8XX both share the same prompt making it difficult to know at first glance in menuconfig what's for what, let's fix this by adding "in SPL" at the end of the prompt for the SPL symbol. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: adc: rockchip-saradc: add support for RK3588Quentin Schulz
This adds support for the SARADCv2 found on RK3588. There is no stop callback as it is currently configured in single conversion mode, where the ADC is powered down after a single conversion has been made. Due to what seems to be a silicon bug, a controller reset needs to be issued before starting a channel conversion otherwise Rockchip says that channel 1 will error whatever that means. This is aligned with upstream and downstream Linux kernel as well as downstream U-Boot. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: adc: rockchip-saradc: factor out stop callbackQuentin Schulz
SARADC v2 doesn't have a stop mechanism once in single mode. In series conversion, the logic is different anyway. Therefore, let's abstract this function so that it can be provided from the udevice.data pointer. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: adc: rockchip-saradc: factor out start_channel callbackQuentin Schulz
SARADC v1 and v2 have a different way of starting a channel, therefore let's abstract this function so that it can be provided from the udevice.data pointer. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: adc: rockchip-saradc: factor out channel_data callbackQuentin Schulz
SARADC v1 and v2 have a different way of reading data, therefore let's abstract this function so that it can be provided from the udevice.data pointer. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: adc: rockchip-saradc: use union for preparing for v2Quentin Schulz
The registers are entirely different between SARADC v1 and SARADC v2, so let's prepare to add another struct for accessing v2 registers by adding a union. Cc: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14power: rk8xx: add support for RK806Quentin Schulz
This adds support for RK806, only the SPI variant has been tested. The communication "protocol" over SPI is the following: - write three bytes: - 1 byte: [0:3] length of the payload, [6] Enable CRC, [7] Write - 1 byte: LSB register address - 1 byte: MSB register address - write/read length of payload The CRC is always disabled for now. The RK806 technically supports I2C as well, and this should be able to support it without any change, but it wasn't tested. The DT node name prefix for the buck converters has changed in the Device Tree and is now dcdc-reg. The logic for buck converters is however manageable within the current logic inside the rk8xx regulator driver. The same cannot be said for the NLDO and PLDO. Because pmic_bind_children() parses the DT nodes and extracts the LDO index from the DT node name, NLDO and PLDO will have overlapping indices. Therefore, we need a separate logic from the already-existing ldo callbacks. Let's reuse as much as possible though. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14regulator: rk8xx: add indirection level for some ldo callbacksQuentin Schulz
By passing a rk8xx_reg_info directly to the internal get_value, it'd be possible to call this same function with a logic for getting the rk8xx_reg_info different from the current get_ldo_reg, e.g. for NLDO and PLDO support for RK806. No logic change is expected. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14regulator: rk8xx: fix SWITCH enable on RK809William Wu
On RK809 in PMIC_POWER_ENX registers, in order to set or clear a bit N, the bit at offset N + 4 needs to be set otherwise nothing is done. This fixes the inability to modify the SWITCH state on RK809. Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: William Wu <william.wu@rock-chips.com> [reworded commit log] Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14regulator: rk8xx: remove unused functionsQuentin Schulz
Those two functions had their last user removed in commit f9c68a566c4d ("rockchip: phycore_rk3288: remove phycore_init() function") part of v2023.01 release, so let's do some cleanup here. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: spi: rk_spi: do not write bytes when in read-only modeQuentin Schulz
The read-only mode is currently supported but only for 16b-aligned buffers. For unaligned buffers, the last byte will be read in RW mode right now, which isn't what is desired. Instead, let's put the controller back into RO mode for that last byte and skip any write in the xfer loop. This is required for 3-wire SPI mode where PICO/POCI lanes are shorted on HW level. This incidentally the recommended design for RK806 PMIC for RK3588 products. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-14rockchip: io-domain: Add support for RK3399Jonas Karlman
Port the RK3399 part of the Rockchip IO-domain driver from linux. This differs from linux version in that pmu io iodomain bit is enabled in the write ops instead of in an init ops as in linux, this way we can avoid keeping a full state of all supply that have been configured. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2024-03-14rockchip: Update the default USB Product ID valueJonas Karlman
RK3036 is using the USB product id normally used by RK3066B, and RK3328 is using the product id normally used by RK3368. Fix this and update the default USB_GADGET_PRODUCT_NUM Kconfig option for remaining supported Rockchip SoCs to match the product id used in Maskrom mode. Also remove a reference to an undefined ROCKCHIP_RK3229 Kconfig symbol. Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
2024-03-14phy: rockchip-inno-usb2: Limit changes made to regsJonas Karlman
The USB2PHY regs already contain working default reset values for RK3328 and RK35xx as evidenced by the fact that this driver never has changed a single value for these SoCs. Reduce to only configure utmi_suspend_n and utmi_sel bits similar to what is currently done on RK3399. Also add missing clkout_ctl for RK3588. When enabled utmi_suspend_n is changed to normal mode and utmi_sel to use otg/host controller utmi interface to phy. When disabled utmi_suspend_n is changed to suspend mode and utmi_sel to use GRF utmi interface to phy. Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
2024-03-14phy: rockchip-inno-usb2: Write to correct GRFJonas Karlman
On RK3399 the USB2PHY regs are located in the common GRF, remaining SoCs that is supported by this driver have the USB2PHY regs in a different GRF. When support for RK356x, RK3588 and RK3328 was added this driver was never updated to use correct GRF and have instead incorrectly written to wrong GRF for these SoCs. The default reset values for the USB2PHY have made USB mostly working even when wrong GRF was used, however, following have been observed: scanning bus usb@fd840000 for devices... ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) unable to get device descriptor (error=-1) Fix this by using a regmap from rockchip,usbgrf prop and fall back to getting a regmap for parent udevice instead of always getting the common GRF. Also protect against accidental clear of bit 0 in a reg with offset 0, only bind driver to enabled otg/host-ports and remove unused headers. Fixes: 3da15f0b49a2 ("phy: rockchip-inno-usb2: Add USB2 PHY for rk3568") Fixes: cdf9010f6e17 ("phy: rockchip-inno-usb2: add initial support for rk3588 PHY") Fixes: 9aa93d84038b ("phy: rockchip-inno-usb2: Add USB2 PHY for RK3328") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2024-03-14rng: rockchip: Use same compatible as linuxJonas Karlman
Replace the rockchip,cryptov1-rng compatible with compatibles used in the linux device tree for RK3288, RK3328 and RK3399 to ease sync of SoC device tree from linux. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2024-03-14gpio: rockchip: Use gpio alias id as gpio bank idJonas Karlman
The U-Boot driver try to base the gpio bank id on the gpio-ranges prop and fall back to base the bank id on the node name. However, the linux driver try to base the bank id on the gpio alias id and fall back on node order. This can cause issues when SoC DT is synced from linux and gpioX@ nodes has been renamed to gpio@ and gpio-ranges or a SoC specific alias has not been assigned. Try to use the gpio alias id as first fallback when a gpio-ranges prop is missing to ease sync of updated SoC DT. Keep the current fallback on node name as a third fallback to not affect any existing unsynced DT. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2024-03-13driver: rng: Fix SMCCC TRNG crashWeizhao Ouyang
Fix a SMCCC TRNG null pointer crash due to a failed smccc feature binding. Fixes: 53355bb86c25 ("drivers: rng: add smccc trng driver") Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
2024-03-13firmware: psci: Fix bind_smccc_features psci checkWeizhao Ouyang
According to PSCI specification DEN0022F, PSCI_FEATURES is used to check whether the SMCCC is implemented by discovering SMCCC_VERSION. Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
2024-03-13dma: ti: k3-udma: Add DMA PSIL mappings for AM62P and J722SVignesh Raghavendra
Add PSIL data for the AM62P and the J722S SoC family. The PSIL mapping for the J722S is the same except for the extra instances of the CSI-RX. So let's reuse the same file for both the AM62P and J722S. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> [bb@ti.com: rebased to U-Boot v2024.01] Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-13firmware: ti_sci_static_data: add static DMA channel dataHari Nagalla
Include the static DMA channel data for ti_sci Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-13ram: k3-ddrss: enable the am62ax's DDR controller for am62pxBryan Brattlof
The am62px family of SoCs uses the same DDR controller as found on the am62ax family. Enable this option when building for the am62px family Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-13arm: mach-k3: am62px: introduce clock and device files for wkup splBryan Brattlof
Include the clock and lpsc tree files needed for the wkup spl to initialize the proper PLLs and power domains to boot the SoC. Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-13power: domain: ti: use IS_ENABLED macroBryan Brattlof
Cleanup this list and standardize on using the IS_ENABLED macro for the power domain data list. Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io> Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-13soc: add info to identify the am62p SoC familyBryan Brattlof
Include the part number for TI's am62px family of SoCs so we can properly identify it during boot Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-13rockchip: include asm/io.h directly in asm/arch-rockchip/hardware.hQuentin Schulz
The different macros use writel which is defined in asm/io.h, so let's include the header so users of hardware.h do not need to include asm/io.h as well. While at it, remove asm/io.h includes wherever asm/arch-rockchip/hardware.h is included already. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-13rockchip: migrate hardware.h inclusion into appropriate filesQuentin Schulz
hardware.h is only defining macros which are "wrappers" around writel(). writel() is however not available in hardware.h, <asm/io.h> needs to be included. This means in order to use the wrappers in hardware.h, one also needs to include the <asm/io.h> header. However, this cannot be done currently because hardware.h is included in include/configs files, which are implicitly included by every code file by default, which makes the compilation of arch/arm/cpu/armv8/u-boot.lds fail because ALIGN (the ARM assembly directive) got redefined by some of the include files coming from <asm.io.h>. Because nothing in the include/configs file actually use hardware.h, let's remove the inclusion of hardware.h from the include/configs files and explicitly add it wherever it is required. This prepares for the next commit where <asm/io.h> will be included in hardware.h. Cc: Quentin Schulz <foss+uboot@0leil.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
2024-03-12serial: move sbi_dbcn_available to .data sectionHeinrich Schuchardt
U-Boot SPL loads the device-tree directly behind main U-Boot overlapping the .bss section. reserve_fdt() is called in board_init_f() to relocate the device-tree to a safe location. Debug UARTs are enabled before board_init_f(). With sbi_dbcn_available in the .bss section the device-tree is corrupted when _debug_uart_init() is called in the SBI serial driver. Move the variable to the .data section. Link: https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2054091 Fixes: dfe08374943c ("risc-v: implement DBCN based debug console") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Conor Dooley <conor.dooley@microchip.com>
2024-03-11Merge tag 'v2024.04-rc4' into nextTom Rini
Prepare v2024.04-rc4
2024-03-09Merge https://source.denx.de/u-boot/custodians/u-boot-usbTom Rini
- Singular quirk DT property rename.
2024-03-09net: phy: Use PHY MDIO address from DT if availableMarek Vasut
In case the PHY is fully described in DT, use PHY MDIO address from DT directly instead of always using auto-detection. This also fixes the behavior of 'mdio list' in such DT setup, which now prints the PHY connected to the MAC correctly. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
2024-03-07serial: pl01x: set baudrate when probingYang Xiwen
It is found that when DM is enabled, only generic init function is called in .probe(). Baudrate is never honored. Add a function call to .setbrg() when probing so that we can update the baudrate of the serial device. Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
2024-03-07net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO frameworkRoger Quadros
Add a new Kconfig symbol MDIO_TI_CPSW for the CPSW MDIO driver and build it with proper DM support if enabled. If MDIO_TI_CPSW is not enabled then we continue to behave like before. Clean up MDIO custom handling in am65-cpsw and use dm_eth_phy_connect() to get the PHY. Signed-off-by: Roger Quadros <rogerq@kernel.org> Tested-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
2024-03-05virtio: fix get_config / set_config for legacy VirtIO targetsDmitry Baryshkov
The functions virtio_pci_get_config() and virtio_pci_set_config() don't take the offset into account when reading the config space. For example this manifests when U-Boot tries to read the MAC address of the VirtIO networking device. It reads 6 equa bytes instead of the proper addess. Fix those functions by taking the offset in the config space into account. Fixes: 4135e10732a0 ("virtio: Add virtio over pci transport driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-03-05Merge patch series "Fix driver for misc/atsha204a"Tom Rini
Michał Barnaś <barnas@google.com> says: Fix the driver to behave like the chip datasheet requires. Improve wake up function to send low signal on SDA line for at least 60us as chip requires to wake up. Fix sleep function to move the chip into sleep mode, not into idle mode. Remove unnecessary for loop, which would never run for more than one iteration.
2024-03-05misc: atsha204a: fix wakeup functionMichał Barnaś
The ATSHA204A chip requires SDA line to go low for at least 60us to wake up the chip. Previous implementation did not meet this requirement due to the NAK received on bus and not sending the zeroes. The function to ignore the NAK and send bytes regardless is not supported in the u-boot making it impossible to wake up the chip this way. Instead, the bus speed, if needed, is set to lowest value and the message is sent to the address 0x0. This way, the address of zero makes the SDA line go low for about 80us, meeting the required time to wake up the chip. The zero length packet is not sent by the i2c, so the one byte is sent to the transfer function, but only the address is sent anyway. After sending the zero address, the bus speed is restored to the previous value if it was slowed down to wake up the chip. Signed-off-by: Michał Barnaś <barnas@google.com>
2024-03-05misc: atsha204a: fix sleep functionMichał Barnaś
Fix the sleep function to issue the sleep command instead of idle one. Signed-off-by: Michał Barnaś <barnas@google.com>
2024-03-05misc: atsha204a: remove broken for loopMichał Barnaś
Some previous commit changed the continue statement to return, making the for loop used to retry waking up the chip to always return after one iteration. This commit removes the loop, cleaning the code a little. Signed-off-by: Michał Barnaś <barnas@google.com>
2024-03-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini
- net: mv88e6xxx: fix missing SMI address initialization (Marek) - mvebu: turris_omnia: Enable networking via ethernet switch (Marek) - mvebu: helios-4: add config fragment for spi booting et al (Josua) - rng: Add Turris Mox rTWM RNG driver (Max)
2024-03-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini
One fix makes the reboot more robust on some older board, another one stabilises the initial clock setup on the A10/A20. Two patches make sure our DRAM init does not actually change the content of the DRAM array, which allows to use DRAM for Linux' pstore functionality. We get SPI support for U-Boot proper for one more SoC, that patch was lingering around for a while, and should not affect other SoCs, so I am merging this now. As an added bonus, we get the defconfig file for a new board, the DT was already synced from the kernel tree. The CI looked happy with changes, and I tested them on five different boards with different SoCs.
2024-03-05rng: Add Turris Mox rTWM RNG driverMax Resch
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware from CZ.NIC in the secure processor. Signed-off-by: Max Resch <resch.max@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2024-03-05net: mv88e6xxx: fix missing SMI address initializationMarek Mojík
The mv88e6xxx driver does not currently initialize the smi_addr field, but instead keeps the default zero value. This leads to driver being unusable on devices where the switch is not on address zero of the mdio bus. Fix this problem by reading the SMI address from device tree. Signed-off-by: Marek Mojík <marek.mojik@nic.cz> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>