aboutsummaryrefslogtreecommitdiff
path: root/include/dm/uclass-id.h
AgeCommit message (Collapse)AuthorFilesLines
2023-10-24rockchip: dm: prepare rkmtd UCLASSJohan Jonker1-0/+1
Prepare a rkmtd UCLASS in use for writing Rockchip boot blocks in combination with existing userspace tools and rockusb command. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-10-16Merge tag 'u-boot-amlogic-20231015' of ↵Tom Rini1-0/+1
https://source.denx.de/u-boot/custodians/u-boot-amlogic - add Amlogic A1 clock driver - add Amlogic A1 reset support - add USB Device support for Amlogic A1 - enable RNG on Amlogic A1 & Amlogic S4 - move Amlogic Secure Monitor to standalone driver
2023-10-15drivers: introduce Secure Monitor uclassAlexey Romanov1-0/+1
At the moment, we don't have a common API for working with SM, only the smc_call() function. This approach is not generic and difficult to configure and maintain. This patch adds UCLASS_SM with the generic API: - sm_call() - sm_call_write() - sm_call_read() These functions operate with struct pt_regs, which describes Secure Monitor arguments. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20230921081346.22157-2-avromanov@salutedevices.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-10-13firmware: scmi: implement SCMI base protocolAKASHI Takahiro1-0/+1
SCMI base protocol is mandatory according to the SCMI specification. With this patch, SCMI base protocol can be accessed via SCMI transport layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported. This is because U-Boot doesn't support interrupts and the current transport layers are not able to handle asynchronous messages properly. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
2023-08-08arm_ffa: introduce sandbox FF-A supportAbdellatif El Khlifi1-0/+1
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support Features of the sandbox FF-A support: - Introduce an FF-A emulator - Introduce an FF-A device driver for FF-A comms with emulated Secure World - Provides test methods allowing to read the status of the inspected ABIs The sandbox FF-A emulator supports only 64-bit direct messaging. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
2023-08-08arm_ffa: introduce Arm FF-A supportAbdellatif El Khlifi1-0/+6
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0 The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1] describes interfaces (ABIs) that standardize communication between the Secure World and Normal World leveraging TrustZone technology. This driver uses 64-bit registers as per SMCCCv1.2 spec and comes on top of the SMCCC layer. The driver provides the FF-A ABIs needed for querying the FF-A framework from the secure world. The driver uses SMC32 calling convention which means using the first 32-bit data of the Xn registers. All supported ABIs come with their 32-bit version except FFA_RXTX_MAP which has 64-bit version supported. Both 32-bit and 64-bit direct messaging are supported which allows both 32-bit and 64-bit clients to use the FF-A bus. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). The Secure World is considered as one entity to communicate with using the FF-A bus. FF-A communication is handled by one device and one instance (the bus). This FF-A driver takes care of all the interactions between Normal world and Secure World. The driver exports its operations to be used by upper layers. Exported operations: - ffa_partition_info_get - ffa_sync_send_receive - ffa_rxtx_unmap Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c). Arm specific methods are implemented in the Arm driver (arm-ffa.c). For more details please refer to the driver documentation [2]. [1]: https://developer.arm.com/documentation/den0077/latest/ [2]: doc/arch/arm64.ffa.rst Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
2023-07-24Revert "Merge branch '2023-07-24-introduce-FF-A-suppport'"Tom Rini1-7/+0
This reverts commit d927d1a80843e1c3e2a3f0b8f6150790bef83da1, reversing changes made to c07ad9520c6190070513016fdb495d4703a4a853. These changes do not pass CI currently. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-07-24arm_ffa: introduce sandbox FF-A supportAbdellatif El Khlifi1-0/+1
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support Features of the sandbox FF-A support: - Introduce an FF-A emulator - Introduce an FF-A device driver for FF-A comms with emulated Secure World - Provides test methods allowing to read the status of the inspected ABIs The sandbox FF-A emulator supports only 64-bit direct messaging. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
2023-07-24arm_ffa: introduce Arm FF-A supportAbdellatif El Khlifi1-0/+6
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0 The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1] describes interfaces (ABIs) that standardize communication between the Secure World and Normal World leveraging TrustZone technology. This driver uses 64-bit registers as per SMCCCv1.2 spec and comes on top of the SMCCC layer. The driver provides the FF-A ABIs needed for querying the FF-A framework from the secure world. The driver uses SMC32 calling convention which means using the first 32-bit data of the Xn registers. All supported ABIs come with their 32-bit version except FFA_RXTX_MAP which has 64-bit version supported. Both 32-bit and 64-bit direct messaging are supported which allows both 32-bit and 64-bit clients to use the FF-A bus. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). The Secure World is considered as one entity to communicate with using the FF-A bus. FF-A communication is handled by one device and one instance (the bus). This FF-A driver takes care of all the interactions between Normal world and Secure World. The driver exports its operations to be used by upper layers. Exported operations: - ffa_partition_info_get - ffa_sync_send_receive - ffa_rxtx_unmap Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c). Arm specific methods are implemented in the Arm driver (arm-ffa.c). For more details please refer to the driver documentation [2]. [1]: https://developer.arm.com/documentation/den0077/latest/ [2]: doc/arch/arm64.ffa.rst Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
2023-05-02dm: extcon: add an uclass for extconSvyatoslav Ryhel1-0/+1
Add a new simple uclass for extcon. Currently all setup is done in the probe. Uclass struct and ops are empty for now. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-27drivers/mtd/nvmxip: introduce NVM XIP block storage emulationAbdellatif El Khlifi1-0/+1
add block storage emulation for NVM XIP flash devices Some paltforms such as Corstone-1000 need to see NVM XIP raw flash as a block storage device with read only capability. Here NVM flash devices are devices with addressable memory (e.g: QSPI NOR flash). The implementation is generic and can be used by different platforms. Two drivers are provided as follows. nvmxip-blk : a generic block driver allowing to read from the XIP flash nvmxip Uclass driver : When a device is described in the DT and associated with UCLASS_NVMXIP, the Uclass creates a block device and binds it with the nvmxip-blk. Platforms can use multiple NVM XIP devices at the same time by defining a DT node for each one of them. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
2023-04-05blk: blkmap: Add basic infrastructureTobias Waldekranz1-0/+1
blkmaps are loosely modeled on Linux's device mapper subsystem. The basic idea is that you can create virtual block devices whose blocks can be backed by a plethora of sources that are user configurable. This change just adds the basic infrastructure for creating and removing blkmap devices. Subsequent changes will extend this to add support for actual mappings. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-01-23dm: core: Correct ordering of uclasses IDsSimon Glass1-2/+2
A few of these are out of order. Fix them. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-11-07dm: sandbox: Create a new HOST uclassSimon Glass1-0/+1
Sandbox supports block devices which can access files on the host machine. At present there is no uclass for this. The devices are attached to the root devic. The block-device type is therefore set to UCLASS_ROOT which is confusing. Block devices should be attached to a 'media' device instead, something which handles access to the actual media and provides the block driver for the block device. Create a new uclass to handle this. It supports two operations, to attach and detach a file on the host machine. For now this is not fully plumbed in. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-31FWU: Add FWU metadata structure and driver for accessing metadataSughosh Ganu1-0/+1
In the FWU Multi Bank Update feature, the information about the updatable images is stored as part of the metadata, which is stored on a dedicated partition. Add the metadata structure, and a driver model uclass which provides functions to access the metadata. These are generic API's, and implementations can be added based on parameters like how the metadata partition is accessed and what type of storage device houses the metadata. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2022-10-26dm: memory: Introduce new uclassRoger Quadros1-0/+1
Introduce UCLASS_MEMORY for future Memory Controller device drivers. Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-10-05dm: fpga: Introduce new uclassAlexander Dahl1-0/+1
For future DM based FPGA drivers and for now to have a meaningful logging class for old FPGA drivers. Suggested-by: Michal Simek <michal.simek@amd.com> Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Dahl <post@lespocky.de> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20220930120430.42307-2-post@lespocky.de Signed-off-by: Michal Simek <michal.simek@amd.com>
2022-06-23fuzzing_engine: Add fuzzing engine uclassAndrew Scull1-0/+1
This new class of device will provide fuzzing inputs from a fuzzing engine. Signed-off-by: Andrew Scull <ascull@google.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-04-25Merge branch '2022-04-25-initial-implementation-of-stdboot'Tom Rini1-0/+3
To quote the author: The bootflow feature provide a built-in way for U-Boot to automatically boot an Operating System without custom scripting and other customisation. This is called 'standard boot' since it provides a standard way for U-Boot to boot a distro, without scripting. It introduces the following concepts: - bootdev - a device which can hold a distro - bootmeth - a method to scan a bootdev to find bootflows (owned by U-Boot) - bootflow - a description of how to boot (owned by the distro) This series provides an implementation of these, enabled to scan for bootflows from MMC, USB and Ethernet. It supports the existing distro boot as well as the EFI loader flow (bootefi/bootmgr). It works similiarly to the existing script-based approach, but is native to U-Boot. With this we can boot on a Raspberry Pi 3 with just one command: bootflow scan -lb which means to scan, listing (-l) each bootflow and trying to boot each one (-b). The final patch shows this. With a standard way to identify boot devices, booting become easier. It also should be possible to support U-Boot scripts, for backwards compatibility only. ... The design is described in these two documents: https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing
2022-04-25bootstd: Add the bootmeth uclass and helpersSimon Glass1-0/+1
A bootmeth is a method of locating an operating system. For now, just add the uclass itself. Drivers for particular bootmeths are added later. If no bootmeths devices are included in the devicetree, create them automatically. This avoids the need for boilerplate in the devicetree files. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-25bootstd: Add the bootdev uclassSimon Glass1-0/+1
A 'bootdev' is a device which can be used to boot an operating system. It is a child of the media device (e.g. MMC) which handles reading files from that device, such as a bootflow file. Add a uclass for bootdev and the various helpers needed to make it work. Also add a binding file, empty for now. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-25bootstd: Add the bootstd uclass and core implementationSimon Glass1-0/+1
The 'bootstd' device provides the central information about U-Boot standard boot. Add a uclass for bootstd and the various helpers needed to make it work. Also add a binding file. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-23dm: disk: add UCLASS_PARTITIONAKASHI Takahiro1-0/+1
NOTE: probably we have to update config dependencies, in particular, SPL/TPL_PRINTF? With this new function, UCLASS_PARTITION devices will be created as child nodes of UCLASS_BLK device. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2021-12-09efi: Add uclass for devices provided by UEFI firmwareSimon Glass1-0/+1
UCLASS_EFI_LOADER is used for devices created by applications and drivers loaded by U-Boots UEFI implementation. This patch provides a new uclass (UCLASS_EFI_MEDIA) to be used for devices that provided by a UEFI firmware calling U-Boot as an EFI application. If the two uclasses can be unified, is left to future redesign. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-09efi: Rename UCLASS_EFI and IF_TYPE_EFISimon Glass1-1/+1
These names are better used for access to devices provided by an EFI layer. Use EFI_LOADER instead here, since these are only available in U-Boot's EFI_LOADER layer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-10-31iommu: Add IOMMU uclassMark Kettenis1-0/+1
This uclass is intended to manage IOMMUs on systems where the IOMMUs are not in bypass mode by default. In that case U-Boot cannot ignore the IOMMUs if it wants to use devices that need to do DMA and sit behind such an IOMMU. This initial IOMMU uclass implementation does not implement and device ops and is intended for IOMMUs that have a bypass mode that does not require address translation. Support for IOMMUs that do require address translation is planned and device ops will be defined when support for such IOMMUs will be added. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-09-01dm: hash: Add new UCLASS_HASH supportChia-Wei Wang1-0/+1
Add UCLASS_HASH for hash driver development. Thus the hash drivers (SW or HW-accelerated) can be developed in the DM-based fashion. Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
2021-08-16dm: crypto: Define UCLASS API for ECDSA signature verificationAlexandru Gagniuc1-0/+1
Define a UCLASS API for verifying ECDSA signatures. Unlike UCLASS_MOD_EXP, which focuses strictly on modular exponentiation, the ECDSA class focuses on verification. This is done so that it better aligns with mach-specific implementations, such as stm32mp. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-07-23reboot-mode: add support for reboot mode controlNandor Han1-0/+1
A new driver uclass is created to handle the reboot mode control. The new uclass driver is updating an environment variable with the configured reboot mode. The mode is extracted from a map provided at initialization time. The map contains a list of modes and associated ids. Signed-off-by: Nandor Han <nandor.han@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-12x86: qemu: move QFW to its own uclassAsherah Connor1-0/+1
We move qfw into its own uclass and split the PIO functions into a specific driver for that uclass. The PIO driver is selected in the qemu-x86 board config (this covers x86 and x86_64). include/qfw.h is cleaned up and documentation added. Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-16net: Introduce DSA class for Ethernet switchesClaudiu Manoil1-0/+1
DSA stands for Distributed Switch Architecture and it covers switches that are connected to the CPU through an Ethernet link and generally use frame tags to pass information about the source/destination ports to/from CPU. Front panel ports are presented as regular ethernet devices in U-Boot and they are expected to support the typical networking commands. DSA switches may be cascaded, DSA class code does not currently support this. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
2020-12-18dm: test: Add a test for DM_UC_FLAG_NO_AUTO_SEQSimon Glass1-0/+1
Check that this flag operates as expected. This patch is not earlier in this series since is uses the new behaviour of dev_seq(). Signed-off-by: Simon Glass <sjg@chromium.org>
2020-11-06board: Rename uclass to sysinfoSimon Glass1-1/+1
This uclass is intended to provide a way to obtain information about a U-Boot board. But the concept of a U-Boot 'board' is the whole system, not just one circuit board, meaning that 'board' is something of a misnomer for this uclass. In addition, the name 'board' is a bit overused in U-Boot and we want to use the same uclass to provide SMBIOS information. The obvious name is 'system' but that is so vague as to be meaningless. Use 'sysinfo' instead, since this uclass is aimed at providing information on the system. Rename everything accordingly. Note: Due to the patch delta caused by the symbol renames, this patch shows some renamed files as being deleted in one place and created in another. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-10-28drivers: Add a new framework for multiplexer devicesJean-Jacques Hiblot1-0/+1
Add a new subsystem that handles multiplexer controllers. The API is the same as in Linux. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> [trini: Update some error calls to use different functions or pass correct arguments] Signed-off-by: Tom Rini <trini@konsulko.com>
2020-09-30firmware: add SCMI agent uclassEtienne Carriere1-0/+1
This change introduces SCMI agent uclass to interact with a firmware using the SCMI protocols [1]. SCMI agent uclass currently supports a single method to request processing of the SCMI message by an identified server. A SCMI message is made of a byte payload associated to a protocol ID and a message ID, all defined by the SCMI specification [1]. On return from process_msg() method, the caller gets the service response. SCMI agent uclass defines a post bind generic sequence for all devices. The sequence binds all the SCMI protocols listed in the FDT for that SCMI agent device. Currently none, but later change will introduce protocols. This change implements a simple sandbox device for the SCMI agent uclass. The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages. To prepare for further test support, the sandbox exposes a architecture function for test application to read the sandbox emulated devices state. Currently supports 2 SCMI agents, identified by an ID in the FDT device name. The simplistic DM test does nothing yet. SCMI agent uclass is designed for platforms that embed a SCMI server in a firmware hosted somewhere, for example in a companion co-processor or in the secure world of the executing processor. SCMI protocols allow an SCMI agent to discover and access external resources as clock, reset controllers and more. SCMI agent and server communicate following the SCMI specification [1]. This SCMI agent implementation complies with the DT bindings defined in the Linux kernel source tree regarding SCMI agent description since v5.8. Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-08-14xen: pvblock: Add initial support for para-virtualized block driverAnastasiia Lukianenko1-0/+1
Add initial infrastructure for Xen para-virtualized block device. This includes compile-time configuration and the skeleton for the future driver implementation. Add new class UCLASS_PVBLOCK which is going to be a parent for virtual block devices. Add new interface type IF_TYPE_PVBLOCK. Implement basic driver setup by reading XenStore configuration. Signed-off-by: Andrii Anisov <andrii_anisov@epam.com> Signed-off-by: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
2020-07-28dm: button: add an uclass for buttonPhilippe Reynes1-0/+1
Add a new uclass for button that implements two functions: - button_get_by_label - button_get_status Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
2020-07-25dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matchingDave Gerlach1-0/+1
Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-24Revert "Merge tag 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm"Tom Rini1-1/+0
This reverts commit 5d3a21df6694ebd66d5c34c9d62a26edc7456fc7, reversing changes made to 56d37f1c564107e27d873181d838571b7d7860e7. Unfortunately this is causing CI failures: https://travis-ci.org/github/trini/u-boot/jobs/711313649 Signed-off-by: Tom Rini <trini@konsulko.com>
2020-07-20dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matchingDave Gerlach1-0/+1
Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-05-10net: Add eth phy generic driver for shared MDIOYe Li1-0/+1
For dual ethernet controllers, the HW design may connect ETH phys to one MDIO ports. So two different ethernet drivers have to share MDIO bus. Since two ethernet drivers are independent, we can't ensure their probe order. To resolve this problem, introduce an eth phy generic driver and uclass. After eth-uclass binds, we search the mdio node and binds the phy node with the eth-phy-generic driver. When one eth driver get its phy device, the parent of phy device will probe prior than phy device. So this ensure the eth driver ownes the MDIO bus will be probed before using its MDIO. Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2020-04-16acpi: Add a simple sandbox testSimon Glass1-0/+1
Add a sandbox test for the basic ACPI functionality we have so far. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2020-01-09Merge tag 'dm-pull-8jan20' of git://git.denx.de/u-boot-dmTom Rini1-0/+1
dm: Increased separation of ofdata_to_platdata() and probe methods
2020-01-07dm: test: Add a test driver for devresSimon Glass1-0/+1
Add a driver which does devres allocations so that we can write tests for devres. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-07dm: rng: Add random number generator(rng) uclassSughosh Ganu1-0/+1
Add a uclass for reading a random number seed from a random number generator device. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-12-15pci: Add support for p2sb uclassSimon Glass1-0/+1
The Primary-to-Sideband bus (P2SB) is used to access various peripherals through memory-mapped I/O in a large chunk of PCI space. The space is segmented into different channels and peripherals are accessed by device-specific means within those channels. Devices should be added in the device tree as subnodes of the p2sb. This adds a uclass and enables it for sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15x86: power: Add an ACPI PMC uclassSimon Glass1-0/+1
Intel x86 SoCs have a power manager/controller which handles several power-related aspects of the platform. Add a uclass for this, with a few useful operations. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-23ufs: Add Initial Support for UFS subsystemFaiz Abbas1-0/+1
Add Support for UFS Host Controller Interface (UFSHCI) for communicating with Universal Flash Storage (UFS) devices. The steps to initialize the host controller interface are the following: - Initiate the Host Controller Initialization process by writing to the Host controller enable register. - Configure the Host Controller base address registers by allocating a host memory space and related data structures. - Unipro link startup procedure - Check for connected device - Configure UFS host controller to process requests Also register this host controller as a SCSI host controller. Taken from Linux Kernel v5.2 (drivers/scsi/ufs/ufshcd.c) and ported to U-boot. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
2019-10-13dm: Add a dsi host uclassYannick Fertré1-0/+1
Display Serial Interface (DSI) host can usefully be modelled as their own uclass. DSI defines a serial bus and a communication protocol between the host and the device (panel, bridge). Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
2019-10-08pci: sandbox: Move the emulators into their own nodeSimon Glass1-0/+1
Sandbox pci works using emulation drivers which are currently children of the pci device: pci-controller { pci@1f,0 { compatible = "pci-generic"; reg = <0xf800 0 0 0 0>; emul@1f,0 { compatible = "sandbox,swap-case"; }; }; }; In this case the emulation device is attached to pci device on address f800 (device 1f, function 0) and provides the swap-case functionality. However this is not ideal, since every device on a PCI bus has a child device. This is only really the case for sandbox, but we want to avoid special-case code for sandbox. Worse, child devices cannot be probed before their parents. This forces us to use 'find' rather than 'get' to obtain the emulator device. In fact the emulator devices are never probed. There is code in sandbox_pci_emul_post_probe() which tries to track when emulators are active, but at present this does not work. A better approach seems to be to add a separate node elsewhere in the device tree, an 'emulation parent'. This could be given a bogus address (such as -1) to hide the emulators away from the 'pci' command, but it seems better to keep it at the root node to avoid such hacks. Then we can use a phandle to point from the device to the correct emulator, and only on sandbox. The code to find an emulator does not interfere with normal pci operation. Add a new UCLASS_PCI_EMUL_PARENT uclass which allows finding an emulator given a bus, and finding a bus given an emulator. Update the existing device trees and the code for finding an emulator. This brings PCI emulators more into line with I2C. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fix 3 typos in the commit message; encode bus number in the labels of swap_case_emul nodes; mention commit 4345998ae9df in sandbox_pci_get_emul()] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit v1.1 at 2024-08-12 17:30:00 +0000