summaryrefslogtreecommitdiff
path: root/drivers/misc
AgeCommit message (Collapse)Author
2024-11-25wdt: imx8qxp: add option to control external PMIC wdt via IMX8 SCUHeiko Schocher
Driver for a PMIC watchdog timer controlled via Siemens SCU firmware extensions. Only useful on some Siemens i.MX8-based platforms as special SCFW is needed which provides the needed SCU API. Signed-off-by: Andrej Valek <[email protected]> Signed-off-by: Heiko Schocher <[email protected]> Reviewed-by: Alexander Sverdlin <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-10-27Merge patch series "Implement ACPI on aarch64"Tom Rini
Patrick Rudolph <[email protected]> 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/[email protected]
2024-10-27drivers: misc: irq-uclass: Update irq_get_by_indexPatrick Rudolph
Support reading the "interrupts" property from the devicetree in case the "interrupts-extended" property isn't found. As the "interrupts" property is commonly used, this allows to parse all existing FDT and makes irq_get_by_index() more useful. The "interrupts" property doesn't contain a phandle as "interrupts-extended" does, so implement a new method to locate the interrupt-parent called irq_get_interrupt_parent(). TEST: Read the interrupts from the GIC node for ACPI MADT generation. Signed-off-by: Patrick Rudolph <[email protected]> Reviewed-by: Moritz Fischer <[email protected]>
2024-10-21Merge patch series "Add AVS support for J721S2"Tom Rini
Manorit Chawdhry <[email protected]> says: This series adds support for Adaptive voltage scaling on J721S2 device [0]. [0]: https://www.ti.com/lit/pdf/spruj28 (Section 5.2.4.1 AVS Support) AVS Test for J721S2: https://gist.github.com/manorit2001/b2fd9f6764a863294d4aa0755c83c84f Boot Test results: https://gist.github.com/manorit2001/d44e035552cb19aadeb0d928d5cb5f26 Link: https://lore.kernel.org/r/[email protected]
2024-10-21drivers: misc: k3_avs: Extract MPU clk and dev ID from DTManorit Chawdhry
Different devices have different MPU clk and dev ID. Currently it had been hardcoded. Move it to DT based extraction. Signed-off-by: Manorit Chawdhry <[email protected]> Reviewed-by: Aniket Limaye <[email protected]>
2024-10-21drivers: misc: k3_avs: Check return code while programming AVSManorit Chawdhry
Check if AVS could not be programmed and print a warning. Fixes: 9d233b4e3ed6 ("misc: k3_avs: add driver for K3 Adaptive Voltage Scaling Class 0") Reviewed-by: Udit Kumar <[email protected]> Signed-off-by: Manorit Chawdhry <[email protected]> Reviewed-by: Aniket Limaye <[email protected]>
2024-10-13misc: fuse: Update fuse driverYe Li
When OSCCA is enabled, FSB fuse shadow (offset 0x8000) access is disabled for SOC. So update the driver to read fuse from ELE API. The ELE has supported to read all shadow fuses like FSB, reuse the table of FSB for the word index used by ELE API. Add ELE shadow fuse read and write to current ELE fuse driver. But when LC is OEM closed, the ELE read/write shadow fuse APIs are forbidden. Reading from any fuse will return error. This causes problem to u-boot which must read out some fuse no matter whatever LC. So we have to change back to read from FSB and ELE common fuse read API. For using ELE shadow read API for development purpose like checking the ELE shadow fuse write result, user can set env variable "enable_ele_shd" to y to switch it. Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2024-10-13misc: fuse: Fix FSB redundancy fuse word check and clear resYe Li
There is a bug when checking fuse word with redundancy fuse in FSB table. The redundancy fuses are combined into 4 words, so we can't directly use word index to do the check, otherwise the high 4 words will fail to match. And When calling ELE API, res parameter will pass to ELE API to get ELE response value for failure. So most of usage does not initialize this variable and print it after calling ELE API. However, when ELE API returns failure, we can't ensure this res is always set because there may be other failure like MU failure. Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2024-10-13misc: ele_api: Add read/write shadow fuse APIsYe Li
Add ELE APIs to support read and write shadow fuses Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2024-10-13misc: ele_api: Update ELE read common fuse APIPeng Fan
On iMX8ULP, the word index 1 is used to read OTP_UNIQ_ID with 4 words data responsed. However this special index does not apply others. So restrict the check to i.MX8ULP to avoid problem when reading from fuse word 1 for others, such as i.MX93. Also update header order Signed-off-by: Peng Fan <[email protected]>
2024-10-13misc: ele_mu: Clear RR when initialize MUPeng Fan
When OS is doing ELE API call, before OS get the response, OS is force reseted, then it is possible that MU RR has data during initialization in SPL stage. So clear the RR registers, otherwise SPL ELE API call will work abnormal. Cc: Alice Guo <[email protected]> Cc: Marek Vasut <[email protected]> Signed-off-by: Peng Fan <[email protected]>
2024-10-13misc: ele_mu: Update ELE MU to get TR/RR number from HWYe Li
The MU parameter register can provide the TR and RR number. For i.MX95 which has 8 RR is different with i.MX93 and i.MX8ULP, so update the driver to read the PAR for exact TR and RR number. Also update compatible string for i.MX95 ELE MU. Cc: Alice Guo <[email protected]> Cc: Marek Vasut <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Ye Li <[email protected]>
2024-10-11Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"Tom Rini
Simon Glass <[email protected]> says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.
2024-10-11global: Rename SPL_TPL_ to PHASE_Simon Glass
Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass <[email protected]>
2024-10-11global: Rename SPL_ to XPL_Simon Glass
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass <[email protected]>
2024-10-11drivers: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILDSimon Glass
Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <[email protected]>
2024-10-11xpl: Rename spl_phase() to xpl_phase()Simon Glass
Rename this function to indicate that it refers to any xPL phase. Signed-off-by: Simon Glass <[email protected]>
2024-10-04rockchip: Provid SPL control over otp presenceJonas Karlman
The series "rockchip: Add efuse and otp support to more SoCs" [1], merged in v2023.04, refactored and extended the Rockchip efuse and otp driver to support reading eFUSE/OTP for all supported Rockchip SoCs. Due to use of different licenses the drivers were never combined into a single driver, however anything non SoC specific should be applied to both drivers. The commit fe38b88453d2 ("rockchip: Provided SPL control over efuse presence") changed Makefile options for only one of the two drivers, apply same change to keep these two drivers in sync. [1] https://lore.kernel.org/r/[email protected]/ Fixes: fe38b88453d2 ("rockchip: Provided SPL control over efuse presence") Signed-off-by: Jonas Karlman <[email protected]>
2024-10-03rockchip: Provided SPL control over efuse presenceSimon Glass
This driver should not generally be present in SPL, even if misc devices are enabled. Update the Makefile rule accordingly. Signed-off-by: Simon Glass <[email protected]>
2024-08-30imx: ele_ahab: Add HUK derivation supportMathieu Othacehe
Add a new ahab_derive command that derives the hardware unique key (HUK) into a 16 or 32 bytes key and stores it at the given address. Signed-off-by: Mathieu Othacehe <[email protected]> Reviewed-by: Ye Li <[email protected]>
2024-08-09rockchip: io-domain: Add support for RK3308Jonas Karlman
Port the RK3308 part of the Rockchip IO Domain driver from linux. This differs from linux version in that vccio3 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 <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2024-07-22drivers: misc: Remove duplicate newlinesMarek Vasut
Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <[email protected]>
2024-07-17rockchip: io-domain: add support for PX30Quentin Schulz
Port the PX30 part of the Rockchip IO Domain driver from Linux. This differs from linux version in that the 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 supplies that have been configured. Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Kever Yang <[email protected]>
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 <[email protected]> Signed-off-by: Tom Rini <[email protected]>
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 <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2024-05-07misc: Remove <common.h> and add needed includesTom Rini
Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <[email protected]>
2024-05-06global: Audit usage of <eeprom.h>Tom Rini
The file include/eeprom.h is used only in some legacy non-DM I2C EEPROM access cases. Remove most inclusions of this file as they are not needed. Signed-off-by: Tom Rini <[email protected]>
2024-04-26rockchip: io-domain: Add support for RK3328Jonas Karlman
Port the RK3328 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. Enable by default on all RK3328 boards, skip rk3328-evb because this target is typically also used on miscellaneous boards and boxes not fully supported by U-Boot. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2024-04-15drivers: misc: Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to ↵Wan Yee Lau
CONFIG_SPL_SOCFPGA_DT_REG Commit 3f190c55a4211215914126b74357344342329943 ("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA") This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG in Makefile. Signed-off-by: Wan Yee Lau <[email protected]>
2024-04-04misc: turris_omnia_mcu: Add support for rng provided by MCUMarek Behún
Add support for true random number generator provided by the MCU on Turris Omnia. The MCU firmware supports TRNG if the FEAT_TRNG bit is set in features. In that case we bind the rng driver. Signed-off-by: Marek Behún <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-04-04gpio: turris_omnia_mcu: Add support for system power off via sysresetMarek Behún
Add support for system power off via UCLASS_SYSRESET. Newer versions of Turris Omnia MCU firmware can power off the board (MCU will disable almost all voltage regulators and go into low power mode). Move the MCU driver into drivers/misc and register it under UCLASS_MISC. The sysreset and gpio device are bound as child devices of the MCU device. Signed-off-by: Marek Behún <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-03-24imx: ele_ahab: Add ahab_commit command supportMathieu Othacehe
This message is used to commit into the fuses any new SRK revocation and FW version information that have been found into the NXP (ELE FW) and OEM containers. Signed-off-by: Mathieu Othacehe <[email protected]>
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-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 <[email protected]> Reviewed-by: Tien Fong Chee <[email protected]>
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 <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Reviewed-by: Kever Yang <[email protected]>
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ś <[email protected]>
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ś <[email protected]>
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ś <[email protected]>
2024-02-08imx: scu_api: add implementation of sc_pm_reset_reasonIgor Opaniuk
Add implementation of sc_pm_reset_reason() call for obtaining reset reason. Signed-off-by: Igor Opaniuk <[email protected]>
2024-02-02smbios: correctly name Structure Table Maximum Size fieldHeinrich Schuchardt
In the SMBIOS 3 entry point the Structure Table Maximum Size field was incorrectly named max_struct_size. A Maximum Structure Size field only exists in the SMBIOS 2.1 entry point and has a different meaning. Call the Structure Table Length field table_maximum_size. Signed-off-by: Heinrich Schuchardt <[email protected]>
2024-01-29treewide: Remove clk_freeSean Anderson
This function is a no-op. Remove it. Signed-off-by: Sean Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-01-26smbios: use struct_table_length to get SMBIOS 2.1 total table lengthMasahisa Kojima
The current code convert the SMBIOS 2.1 entry point structure to SMBIOS 3.0 entry point structure. The max_struct_size member in SMBIOS 2.1 entry point structure indicates "Size of the largest SMBIOS structure, in bytes". We need to use struct_table_length instead. Fixes: 1c5aab803c0b ("smbios: copy QEMU tables") Signed-off-by: Masahisa Kojima <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
2024-01-16smbios: copy QEMU tablesHeinrich Schuchardt
QEMU provides SMBIOS tables with detailed information. We should not try to replicate them in U-Boot. If we want to inform about U-Boot, we can add a Firmware Inventory Information (type 45) table in future. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2024-01-16serial: msm-geni: don't rely on parent misc deviceCaleb Connolly
commit 1b15483deb3f ("misc: add Qualcomm GENI SE QUP device driver") introduced support for platform-specific oversampling values, necessary to configure the UART clocks on all platforms at runtime. However it relies in probing a parent device. Despite the DM_FLAG_PRE_RELOC flag, this is not done consistently during boot. Instead, take another approach by relying on ofnode_ helpers to read the serial engine base address and do the read directly. This fixes early UART on boards with a non-default oversampling rate. Signed-off-by: Caleb Connolly <[email protected]>
2024-01-07acpi: enable writing ACPI tables on QEMUHeinrich Schuchardt
Invoke write_acpi_tables() via EVT_LAST_STAGE_INIT on QEMU except on X86. X86 calls write_acpi_tables() in write_tables(). Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2024-01-07acpi: carve out qfw_acpi.cHeinrich Schuchardt
Move the code related to copying tables from QEMU to a separate code module. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Tom Rini <[email protected]> Reviewed-by: Simon Glass <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-01-07acpi: Kconfig symbol CONFIG_QFW_ACPIHeinrich Schuchardt
We have two implementations of write_acpi_tables(). One for writing ACPI tables based on ACPI_WRITER() entries another based on copying tables from QEMU. Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from QEMU and use it consistently. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2023-12-18Merge tag 'v2024.01-rc5' into nextTom Rini
Prepare v2024.01-rc5
2023-12-13acpi: move acpi_get_rsdp_addr() to acpi/acpi_table.hHeinrich Schuchardt
Function acpi_get_rsdp_addr() is needed on all architectures which write ACPI tables. Move the definition from the x86 include to an architecture independent one. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Tom Rini <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2023-12-13Merge patch series "bootm: Refactoring to reduce reliance on CMDLINE (part A)"Tom Rini
To quote the author: It would be useful to be able to boot an OS when CONFIG_CMDLINE is disabled. This could allow reduced code size. Standard boot provides a way to handle programmatic boot, without scripts, so such a feature is possible. The main impediment is the inability to use the booting features of U-Boot without a command line. So the solution is to avoid passing command arguments and the like to code in boot/ A similar process has taken place with filesystems, for example, where we have (somewhat) separate Kconfig options for the filesystem commands and the filesystems themselves. This series starts the process of refactoring the bootm logic so that it can be called from standard boot without using the command line. Mostly it removes the use of argc, argv and cmdtbl from the internal logic. Some limited tidy-up is included, but this is kept to smaller patches, rather than trying to remove all #ifdefs etc. Some function comments are added, however. A simple programmatic boot is provided as a starting point. This work will likely take many series, so this is just the start. Size growth with this series for firefly-rk3288 (Thumb2) is: arm: (for 1/1 boards) all +23.0 rodata -49.0 text +72.0 This should be removed by: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/11 but it is not included in this series as it is already large enough. No functional change is intended in this series. Changes in v3: - Add a panic if programmatic boot fails - Drop RFC tag Changes in v2: - Add new patch to adjust position of unmap_sysmem() in boot_get_kernel() - Add new patch to obtain command arguments - Fix 'boot_find_os' typo - Pass in the command name - Use the command table to provide the command name, instead of "bootm"