u-boot.git/drivers/firmware, branch v2024.07-rc1

firmware: ti_sci: Bind sysreset driver when enabled

2024-04-12T02:44:36Z

The sysreset TI-SCI API is available with TI-SCI always, there is no need for a DT node to describe the availability of this. If the sysreset driver is available then bind it during ti-sci probe. Remove the unneeded device tree matching. Signed-off-by: Andrew Davis Tested-by: Jonathan Humphreys Reviewed-by: Neha Malcom Francis

firmware: psci: Fix bind_smccc_features psci check

2024-03-13T16:40:43Z

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

firmware: ti_sci_static_data: add static DMA channel data

2024-03-13T14:10:05Z

Include the static DMA channel data for ti_sci Signed-off-by: Hari Nagalla Signed-off-by: Bryan Brattlof

drivers: dma: Add support for J784S4 SoC

2024-03-04T18:41:03Z

Add support for DMA in J784S4 SoC. Signed-off-by: Jayesh Choudhary Signed-off-by: Hari Nagalla Signed-off-by: Apurva Nandan Reviewed-by: Nishanth Menon Reviewed-by: Roger Quadros Tested-by: Marcel Ziswiler # AM69-SK

firmware: ti_sci: Add comment explaining the is_secure code

2024-02-06T21:31:06Z

Add a comment to explain the code under is_secure condition of ti_sci_do_xfer. This will help avoid confusion amongst people who may in future touch upon this code. Reviewed-by: Nishanth Menon Signed-off-by: Dhruva Gole

firmware: ti_sci: fix the secure_hdr in do_xfer

2024-02-06T21:31:06Z

The ti_sci driver in U-Boot has support for secure_msg as part of it's do_xfer function. This let's U-boot send secure messages during boot up. The protocol to send such secure messages is described as part of the struct ti_sci_secure_msg_hdr. As part of this, there are 2 fields for checksum and reserved that occupy the first 4 bytes of any secure message. This is called as the secure_hdr. As of now, the secure_hdr needs to be 0 init-ed before sending secure messages. However the existing code was never putting the zero-inited vars into the secure_buf, leading to possibility of the first 4 bytes of secure_buf being possibly garbage. Fix this by initialising the secure_hdr itself to the secure_buf location, thus when we make secure_hdr members 0, it automatically ensures the first 4 bytes of secure_buf are 0. Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control Interface (TI SCI)") Reviewed-by: Nishanth Menon Signed-off-by: Dhruva Gole

mailbox: zynqmp: support mulitple mboxes via device-tree

2023-12-13T07:58:07Z

As of now only one mailbox agent is supported by mailbox driver. On zynqmp platform there are about 7 mailbox agents which can communicate over same IPI channel to U-Boot. This patch series introduces new "zynqmp_ipi_dest" driver which adds one to multi-channel mailbox support. Following format in device-tree is expected as per latest bindings: zynqmp-ipi { compatible = "xlnx,zynqmp-ipi-mailbox"; mbox_1: mailbox@1 { /* New compatible for child node */ compatible = "xlnx,zynqmp-ipi-dest-mailbox"; ... }; ... mbox_n: mailbox@n { compatible = "xlnx,zynqmp-ipi-dest-mailbox"; ... } }; Then mailbox client uses child mailbox node as following: ipi-dest-1 { ... mboxes = , ; mbox-names = "tx", "rx"; ... }; New "zynqmp_ipi_dest" driver is for devices with "xlnx,zynqmp-ipi-dest-mailbox" compatible string. This driver will take care of mailbox send recv ops and it replaces previous "zynqmp_ipi" driver. Now "zynqmp_ipi" driver simply binds each child device with "zynqmp_ipi_dest" driver. However, its important to maintain backward comaptibility with previous bindings where child node does not have compatible string. In such case, new driver isn't probed by U-Boot during boot and system fails to boot. To resolve this issue firmware-zynqmp.c driver probes all the IPI parent node driver which binds each child node device with "zynqmp_ipi_dest" driver. This makes sure corresponding child driver will be probed when requested using mbox_get_by_name or mbox_get_by_idx framework calls. This way multiple mailbox agents are supported in device-tree without breaking previous binding support. Signed-off-by: Tanmay Shah Link: https://lore.kernel.org/r/20231204215620.63334-4-tanmay.shah@amd.com Signed-off-by: Michal Simek

firmware: scmi: support protocols on sandbox only if enabled

2023-11-29T03:31:03Z

This change will be useful when we manually test SCMI on sandbox by enabling/disabling a specific SCMI protocol. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass

tree-wide: Replace http:// link with https:// link for ti.com

2023-11-10T16:01:50Z

Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon

firmware: scmi: correct a validity check against power domain id

2023-11-10T15:59:28Z

A power domain id on sandbox should be in the range from zero to ARRAY_SIZE(scmi_pwdom) - 1. Correct the validity check logic. Addresses-Coverity-ID: 467401 ("Out-of-bounds write") Addresses-Coverity-ID: 467405 ("Out-of-bounds read") Signed-off-by: AKASHI Takahiro