summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31i3c: master: Add support for devices using SETAASAAkhil R3-3/+127
Add support for devices using SETAASA, such as SPD5118 and SPD5108 attached to DDR5 memory modules that do not support ENTDAA. Follow the guidelines proposed by the MIPI Discovery and Configuration Specification [1] for discovering such devices. SETAASA (Set All Addresses to Static Address) differs from standard I3C address assignment that uses ENTDAA or SETDASA to assign dynamic addresses. Devices using SETAASA assign their pre-defined static addresses as their dynamic addresses during DAA, and it is not mandatory for these devices to implement standard CCC commands like GETPID, GETDCR, or GETBCR. For such devices, it is generally recommended to issue SETHID (specified by JEDEC JESD300) as a prerequisite for SETAASA to stop HID bit flipping. [1] https://www.mipi.org/mipi-disco-for-i3c-download Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://www.mipi.org/mipi-disco-for-i3c-download Link: https://patch.msgid.link/20260728065955.809445-5-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Support ACPI enumeration of child devicesAkhil R1-8/+143
Although the existing subsystem allows host controllers to register through the ACPI table, it was not possible to describe I3C or I2C devices when using ACPI. This is because the driver relied on the reg property to retrieve the PID, static address, etc., whereas ACPI uses _ADR or serial resources to describe such devices. Read _ADR and LVR from ACPI resources and extract the data as per the ACPI specification for an I3C bus. Also read mipi-i3c-static-address as per the MIPI DISCO specifications [1] to get the static address to be used. Enable describing I3C or I2C devices in the ACPI table. This is required if the device uses a static address or if it needs device-specific properties. [1] https://www.mipi.org/mipi-disco-for-i3c-download Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-4-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Use unified device property interfaceAkhil R2-36/+46
Replace all OF-specific functions with unified device property functions as a prerequisite to support both ACPI and device tree. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-3-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASAAkhil R2-5/+35
Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C Discovery and Configuration Specification [1] to specify which discovery method an I3C device supports during bus initialization. The property is a bitmap, where a bit value of 1 indicates support for that method, and 0 indicates lack of support. Bit 0: SETDASA CCC (Direct) Bit 1: SETAASA CCC (Broadcast) Bit 2: Other CCC (vendor / standards extension) All other bits are reserved. It is specifically needed when an I3C device requires SETAASA for the address assignment. SETDASA will be supported by default if this property is absent, which means for now the property just serves as a flag to enable SETAASA, but keep the property as a bitmap to align with the specifications. [1] https://www.mipi.org/mipi-disco-for-i3c-download Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://patch.msgid.link/20260728065955.809445-2-akhilrajeev@nvidia.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: require dests for read CCC commandsAdrian Ng Ho Yin1-1/+2
Read CCC commands (rnw set) always need a destination array to store payload data. Extend the existing direct-CCC validation so cmd->dests is guaranteed non-NULL when cmd->rnw is set. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202607222347.TXH6r6ie-lkp@intel.com/ Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Link: https://patch.msgid.link/153608c2ff6504fe29f5f727a23c53c41768a44a.1784796086.git.adrian.ho.yin.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Fix info leak and UAF in device unregister pathAdrian Hunter1-4/+5
i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/ Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260723075747.34049-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: dw: Drop redundant core reset nameShubham Patil1-1/+1
The DesignWare I3C master has a single reset line, so a dedicated reset name is redundant. Look up the reset by index by passing NULL instead of the "core_rst" name. Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260720073510.1869623-3-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31dt-bindings: i3c: dw: Document missing optional core resetShubham Patil1-0/+3
The DesignWare I3C master IP supports a core reset input, but the binding is missing the corresponding reset description. Document the optional reset property. Keep it optional because the reset line is integration-specific. Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260720073510.1869623-2-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: adi: add OF module alias for autoloadingCan Peng1-0/+1
The Analog Devices I3C master driver can be built as a module and uses adi_i3c_master_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Signed-off-by: Can Peng <pengcan@kylinos.cn> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260715012949.180245-1-pengcan@kylinos.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31dt-bindings: i3c: cdns: add Axiado AX3005 I3C variantSwark Yang1-0/+1
Add binding for Axiado AX3005 I3C master. So far, no changes are known, so it can fall back to the cdns,i3c-master compatible. Signed-off-by: Swark Yang <syang@axiado.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-upstream-axiado-ax3005-upstream-v3-4-c429095143ec@axiado.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Add runtime PM supportClaudiu Beznea1-28/+112
On the SoCs where the Renesas I3C driver is enabled (RZ/G3S and RZ/G3E), the clocks of the IP are managed through a clock PM domain. To keep the I3C code simpler, the explicit clock handling was dropped along with the addition of runtime PM support, in favor of the runtime PM APIs. Only the code for getting tclk was preserved, as it is necessary to compute the I3C clock rate. All the APIs provided to the I3C subsystem through struct i3c_master_controller_ops are guarded with runtime PM APIs to enable/disable the controller at runtime. As the Renesas I3C driver implements an asynchronous transmit model by preparing a transfer and waiting for its completion through the ISR, renesas_i3c_abort_xfer() was added to disable interrupts and clear any pending IRQ status bits when there is no completion in the defined timeout. Along with this, renesas_i3c_wait_xfer() return type was changed to unsigned long. Add runtime PM support for the Renesas I3C driver. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-18-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Drop unnecessary tabClaudiu Beznea1-1/+1
Remove an unnecessary tab to make the code cleaner. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-17-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Use the "dev_name:irq_name" format for the interrupt nameClaudiu Beznea1-1/+8
Use the "dev_name:irq_name" format for the interrupt names. This makes it easier to identify interrupts in systems where multiple devices may request interrupts with the same name. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-16-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Organize structures to avoid unnecessary paddingClaudiu Beznea1-15/+16
Reorder structure members to reduce padding and improve memory layout. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-15-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Update HW registers after SW computations are doneClaudiu Beznea1-14/+14
renesas_i3c_bus_init() performs a number of computations and software cache updates, interleaving them with hardware register writes. While this works today, it makes it harder to minimize the time the controller must remain powered when runtime PM is introduced. Perform all software computations and cache updates first, then update the hardware registers. This prepares for future runtime PM support. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-14-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Drop the explicit memset() callClaudiu Beznea1-1/+0
Drop the explicit memset() call on struct i3c_device_info object, as it is already initialized at declaration through compiler initialization. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-13-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Follow a unified pattern for transfer and command initializationClaudiu Beznea1-11/+11
Follow a unified pattern for transfer and command initialization across the driver. This keeps the code cleaner and easier to follow. Also, in some cases the I3C device was enabled before the transfer data structure was even allocated. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-12-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Return immediately if there is no transferClaudiu Beznea1-3/+3
There is no need to allocate a transfer structure when i2c_nxfers is zero. Return immediately instead of unnecessarily allocating memory. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-11-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Use reset_control_bulk_{assert, deassert}()Claudiu Beznea1-17/+13
Use reset_control_bulk_assert() and reset_control_bulk_deassert() in the suspend and resume paths to simplify the code. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-10-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Fix out-of-bounds access for newdevs maskClaudiu Beznea1-1/+5
When software initiates DAA (Dynamic Address Assignment), the controller reports the result via the NRSPQP (Normal Response Queue Port Register). The data length field of the response descriptor, which is accessible through the NRSPQP register, indicates the number of devices remaining after DAA. Consequently, when the bus is empty, this field contains the maximum number of devices supported by the controller (8 for the Renesas I3C controller). Adjust the condition that computes the newly discovered devices bitmask to prevent an out-of-bounds when the I3C bus is empty. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-9-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Clean DATBAS register on detachClaudiu Beznea1-0/+2
The controller uses DATBAS registers on TX/RX logic. Clean the DATBAS register for the detached I3C device to avoid issues. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-8-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Perform Dynamic Address Assignment on resumeClaudiu Beznea1-23/+15
The Renesas RZ/G3S SoC supports a power saving mode where power to most SoC components, including I3C, is turned off. On systems where the I3C devices also loses power during suspend (e.g. NXP P3T1085UK-ARD connected to the PMOD1_6A connector of the RZ SMARC Carrier 2 + Renesas RZ/G3S SMARC SOM), the devices becomes unreachable after resume. Running DAA in the controller resume path restores communication. However, DAA relies on interrupts for TX/RX, which are not available in the noirq suspend/resume phase (unless they are wakeup interrupts). For this, the suspend/resume callbacks were moved out of the noirq phase. Currently, there is no identified use case on either the Renesas RZ/G3S or Renesas RZ/G3E SoCs that requires the controller suspend/resume hooks to be part of the noirq suspend/resume phase. Since renesas_i3c_reset() is not called anymore in atomic context update it to use read_poll_timeout(). Along with this, struct renesas_i3c::DATBASn and its usage were removed, as they are no longer needed. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-7-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Reset the controller on resumeClaudiu Beznea1-2/+8
Reset the controller on resume after enabling the clocks to follow the same sequence as in probe and avoid potential ordering related failures. With it, renesas_i3c_reset() was updated to use read_poll_timeout_atomic(), as the driver's resume callback is executed during the noirq phase of resume, where interrupts are disabled. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-6-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Reconfigure the DATBAS register on re-attachClaudiu Beznea1-0/+16
During re-attach, the device may change its position in the i3c->addrs[] array. As a result, it may use a different Device Address Table Basic Register (DATBAS), which needs to be reconfigured. Reconfigure the DATBAS register on re-attach. Along with it update software caches. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-5-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Follow the reset deassert order used in probeClaudiu Beznea1-6/+6
Use the same reset deassert order in the resume and probe paths to avoid potential failures due to ordering differences. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-4-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Restore STDBR and EXTBR registers on resumeClaudiu Beznea1-4/+6
The Renesas RZ/G3S supports a power saving state where power to the most SoC componentes (including I3C) is lost. The STDBR and EXTBR are configured in initialization phase though the struct i3c_master_controller_ops::bus_init. Set them on resume function as well to keep the same state of the controller after a suspend with power loss and a similar initialization sequence as in bus_init. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-3-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Check that the transfer is valid before accessing itClaudiu Beznea1-7/+45
The Renesas I3C driver uses an asynchronous model to transfer data. It prepares a struct renesas_i3c_xfer, enqueues it, and waits for completion. The interrupt handler dequeues the transfer, updates/uses it, and signals the waiting thread. If the completion times out, the waiting thread dequeues the transfer and free it. If an interrupt fires after that, the handler may access freed memory, leading to crashes. Check that the transfer is still valid before accessing it in the interrupt handler. With it clear any status flags and disable all the interrupts to avoid triggering the same interrupts again. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-2-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Add driver for AMD AXI I3C master controllerManikanta Guntupalli4-0/+1148
Add an I3C master driver and maintainers fragment for the AMD I3C bus controller. The driver currently supports the I3C bus operating in SDR mode, with features including Dynamic Address Assignment, private data transfers, and CCC transfers in both broadcast and direct modes. It also supports operation in I2C mode. The controller's data FIFOs are accessed big-endian; the driver performs this conversion locally using ioread32be()/iowrite32be() with the helpers, so it does not depend on any core FIFO-endianness helpers. Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Co-developed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Co-developed-by: Shubham Patil <shubhamsanjay.patil@amd.com> Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260709064233.1451482-3-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31dt-bindings: i3c: Add AMD I3C master controller supportManikanta Guntupalli1-0/+58
Add device tree binding documentation for the AMD I3C master controller version 1.0. Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Co-developed-by: Shubham Patil <shubhamsanjay.patil@amd.com> Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260709064233.1451482-2-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Add optional_bytes for variable-length GET CCC validationAdrian Ng Ho Yin2-6/+25
Add optional_bytes to struct i3c_ccc_cmd_payload so callers describe variable-length GET CCC responses. GETMRL and GETMXDS set optional_bytes at the call site. Extend i3c_ccc_validate_payload_len() to honour it. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/2e07dc944eab1c4358be1da87fa5000e711ac8bd.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Validate GET CCC payload length and retry Direct GET onceAdrian Ng Ho Yin2-4/+60
Add retries to struct i3c_ccc_cmd. Validate GET payload length in i3c_master_send_ccc_cmd_locked() after a successful transfer. Retry failed Direct GET CCCs up to cmd->retries times when the driver reports failure or an I3C error; validation failures are not retried. SET CCCs are not retried by default. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/b467f01edfaaa0710f30e719ce7f2753b06c1a3f.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: dw: Map CCC hardware errors to I3C M0/M2Adrian Ng Ho Yin1-5/+23
Map DesignWare I3C master CCC hardware errors to I3C M0/M2 error codes. I3C_ERROR_M2 is reported only for broadcast address-header NACK (RESPONSE_ERROR_IBA_NACK). Target address NACK remains -EIO. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/05994f0479041f3d8d199babe2a4535d6dcba3bf.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Report actual GET CCC payload length on successAdrian Ng Ho Yin7-13/+32
Set dests[].payload.actual_len on successful GET CCC transfers in I3C master drivers so the core can distinguish requested and received buffer lengths. Switch core GET helpers to use actual_len instead of len when interpreting GET CCC results. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/6c66571ae7166aa4b87616d900e6d643631ac355.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: ccc: Add actual_len to struct i3c_ccc_cmd_payloadAdrian Ng Ho Yin1-1/+3
Add actual_len to struct i3c_ccc_cmd_payload so drivers can report how many bytes were received on a GET CCC without overwriting the requested buffer length in len. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/e452777c3a9be734a97e20b9822d8a4264ceadba.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Fix device_register() error pathAdrian Hunter1-0/+2
When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260701203053.8F3971F000E9@smtp.kernel.org/ Fixes: cab63f6488761 ("i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260702183644.60827-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: dw: avoid shift-out-of-bounds when DAA assigns no devicesJakub Kicinski1-1/+9
On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260630172904.2662160-1-kuba@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: svc: bound IBI payload to the requested max_payload_lenMaoyi Xie1-1/+9
svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Cc: stable@vger.kernel.org Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/178227747353.2931373.15868718612134648277@maoyixie.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: svc: report timeout waiting for STOP idlePengpeng Hou1-2/+6
svc_i3c_master_xfer() emits STOP or force-exit for the final transfer and then waits for the controller state to become idle, but ignores readl_poll_timeout(). The function can therefore return success while the controller is still not idle. Return the idle-wait error through the existing warning/FIFO cleanup path so the caller observes the failed transfer without emitting a second STOP after the final STOP or force-exit has already been sent. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20260623060821.23238-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: adi: initialize the lock before enabling interruptsRunyu Xiao1-8/+7
adi_i3c_master_probe() requests the IRQ and unmasks REG_IRQ_PENDING_CMDR before the controller's IBI state, transfer queue list and transfer queue lock are initialized. A pending CMDR interrupt can therefore run adi_i3c_master_irq() and take master->xferqueue.lock before the dynamic lock has been initialized. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the probe ordering and the IRQ path adi_i3c_master_probe() -> adi_i3c_master_irq() -> xferqueue.lock, with a pending CMDR interrupt arriving after REG_IRQ_PENDING_CMDR is unmasked. Lockdep reported: INFO: trying to register non-static key. you didn't initialize this object before use? lock_acquire+0xbb/0x290 _raw_spin_lock_irqsave+0x36/0x60 adi_i3c_master_irq+0x32/0x56 [vuln_msv] adi_i3c_master_probe+0x5a/0xf47 [vuln_msv] Initialize the transfer queue and IBI state before requesting and unmasking the IRQ. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260617150138.628578-1-runyu.xiao@seu.edu.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31arm64: Add override for ID_AA64MMFR4_EL1.NV_fracMarc Zyngier4-1/+15
In a very unsurprising turn of events, there is a large class of firmware that is totally unable to deal with FEAT_NV3, and doesn't set the required SCR2_EL3.NV3En bit, leading to an UNDEF exception or an unhandled trap to EL3, depending on the implementation. Allow the unfortunate user to override ID_AA64MMFR4_EL1.NV_frac and get a working system. Hopefully firmware will be fixed before actually HW ships, but I have been there before... :-/ Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-30-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: selftest: Add NVHCR_EL2 to get-reg-listMarc Zyngier1-0/+2
Since we now expose a new system register on NV3-capable HW when the guest is exposed to it, add it to the existing checker. FWIW. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-29-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Expose FEAT_NV3 to guestsMarc Zyngier1-2/+4
Further enable FEAT_NV3 by making it visible to NV guests. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-28-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add FEAT_NV3 detectionMarc Zyngier1-0/+7
Now that everything is in place to engage the FEAT_NV3 fast-path, add the detection code to cpufeature.c. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-27-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Engage NV3 TLBI trap elisionMarc Zyngier1-0/+13
Similarly to the ERET elision mechanism, FEAT_NV3 can elide TLBIs that only affects the guest's S1 translation. Enable this, with the express condition that the guest isn't NV2 aware, as we otherwise need to trap these TLBIs to deal with VNCR mappings. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-26-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Engage NV3 ERET trap elisionMarc Zyngier2-0/+14
When running on NV3 HW, always engage ERET trap elision when running the L1 context, as there is no benefit in not doing so. An L1 can itself engage trap elision by setting its own view of HCRX_EL2.NVTGE==1, which will subsequently be honored. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-25-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add NVHCR_EL2 context switchingMarc Zyngier2-2/+19
Since NVHCR_EL2 represents the HCR_EL2 state of the EL1 guest, it must be dealt with in some particular way: - for a guest in hyp context (an L1 by definition), NVHCR_EL2 directly reflects HCR_EL2 as read and written by the guest itself. It must therefore be eagerly synced back with the emulation code which only knows about HCR_EL2. This is unconditional if NV3 is available on the host. - For an L2 guest, NVHCR_EL2 is controlled by the L1 guest, and we just context switch it like any other EL1 register. Yes, EL1, as that's where this thing runs from the PoV of L1. This is conditioned on the guest using NV3. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-24-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add routing for NVHCR_EL2 trapMarc Zyngier1-0/+13
NVHCR_EL2 accesses from EL1 are taken to EL2 when HCRX_EL2.NVTGE==0 and HCR_EL2.NV==1. Describe this in the exception routing tables. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-23-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add NVHCR_EL2 handling to the sysreg arrayMarc Zyngier1-0/+28
Expose NVHCR_EL2 to userspace, and treat the direct access as UNDEF, as that would only outline a bug in our exception routing. The generic accessors are also updated to deal with the relatively uncommon location of that register. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-22-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add sanitisation for NVHCR_EL2Marc Zyngier2-0/+19
Just like any other VNCR-based register, NVHCR_EL2 requires some level of sanitisation. Being specified as a live copy of HCR_EL2, it adopts the exact same format, but depends on FEAT_NV3 instead. A subtle aspect is that we only want to apply the sanitisation if FEAT_NV3 is actually present, as the VNCR location is otherwise used to back accesses to HCR_EL2. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-21-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Make HCR_EL2 a non-VNCR registerMarc Zyngier3-2/+12
FEAT_NV3 makes a fundamental change to the architecture, by moving guest-initiated HCR_EL2 accesses to the NVHCR_EL2 register. As the names suggests, this is HCR_EL2 for a NV guest. But where do NVHCR_EL2 accesses from a guest go? The are redirected to the VNCR page, right where HCR_EL2 is stored in the NV2 case. Does it hurt? Good. There's more coming. The challenge here is to make KVM work seamlessly, without rewriting everything. Which implies that things such as __vcpu_sys_reg(HCR_EL2) must work, no matter the underlying NV implementation. A simple way to deal with it is to move HCR_EL2's canonical storage outside of VNCR for the vast majority of the KVM code, and only have a copy at entry/exit times. Given that we don't really support NV3 yet, this is pretty simple. In the process, advertise NVHCR_EL2 as the register that now holds offset 0x78 in the VNCR page. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-20-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 07:02:44 +0000