* Re: [PATCH 2/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree
From: Krzysztof Kozlowski @ 2026-06-24 10:26 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul
Cc: dinguyen@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4acdd3ee-c7eb-4871-bb59-c2e3eeedda28@altera.com>
On 24/06/2026 12:17, Nazle Asmade, Muhammad Nazim Amirul wrote:
>> SoC without any interface, serial or storage or network, is close to
>> useless one.
>>
>> I don't see a point in having it in mainline. Serial is usually ABSOLUTE
>> minimum.
>>
>> Best regards,
>> Krzysztof
>>
> Hi Krzysztof,
>
> Thank you for the review and fast response!
>
> I ran both dt_binding_check and dtbs_check (with CHECK_DTBS=y) locally —
> both passed without errors. Could you clarify which specific test you
> believe is failing?
I would expect simple-bus schema warning or W=1, because node is placed
outside of soc@, but maybe there is no such.
>
> Regarding "MMIO goes to MMIO" — are you referring to the GIC
Comments are placed in very specific and intentional place. Please read
guides how mailing list in-line review works before posting patches.
> (interrupt-controller@7000000) being placed at the root level instead of
> under the soc bus node?
>
> Regarding the serial console — the platform clock driver is not yet
> upstream, so the UART depends on clkmgr. Would adding the UART with
> clock-frequency be acceptable as an interim solution?
Add complete working serial. Why can't you use fixed placeholder clock?
There are probably multiple ways to solve it, not necessary
clock-frequency and I do not even remember if clock-frequency is allowed.
But if you cannot bring serial, then my comment stays valid: this is
unusable upstream thus is not ready to be posted and merged.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
Enable I3C subsystem (I3C), Synopsys DesignWare I3C master controller
(DW_I3C_MASTER), and SPD5118 hwmon temperature sensor (SENSORS_SPD5118)
as modules.
The NVIDIA Vera CPU uses SOCAMM LPDDR5X memory module, which contains
SPD5118 (JEDEC JESD300) compliant temperature sensor. This sensor is
accessible over the I3C bus through the DesignWare I3C controller present
on the SoC. Enabling these configs allows monitoring memory module
temperatures on platforms such as Vera Rubin. Vera is an ACPI-based
platform and does not use device tree.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f2e6ae93e533..65d9eb56e978 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -640,6 +640,8 @@ CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_XILINX=m
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I3C=m
+CONFIG_DW_I3C_MASTER=m
CONFIG_SPI=y
CONFIG_SPI_APPLE=m
CONFIG_SPI_ARMADA_3700=y
@@ -769,6 +771,7 @@ CONFIG_SENSORS_SL28CPLD=m
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_INA3221=m
+CONFIG_SENSORS_SPD5118=m
CONFIG_SENSORS_TMP102=m
CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
CONFIG_CPU_THERMAL=y
--
2.43.0
^ permalink raw reply related
* [PATCH v5 11/12] hwmon: spd5118: Add I3C support
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
Add a regmap config and a probe function to support I3C-based
communication with SPD5118 devices.
On an I3C bus, SPD5118 devices are enumerated via SETAASA and always
require an ACPI or device tree entry. Device matching is hence through
the OF match tables only and does not need an I3C class match table. The
device identity is verified in the type registers before proceeding to
the common probe function.
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/hwmon/Kconfig | 9 ++++---
drivers/hwmon/spd5118.c | 56 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d3ff5fce8..c4bf5475fcb3 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2354,12 +2354,15 @@ config SENSORS_INA3221
config SENSORS_SPD5118
tristate "SPD5118 Compliant Temperature Sensors"
- depends on I2C
+ depends on I3C_OR_I2C
select REGMAP_I2C
+ select REGMAP_I3C if I3C
help
If you say yes here you get support for SPD5118 (JEDEC JESD300)
- compliant temperature sensors. Such sensors are found on DDR5 memory
- modules.
+ compliant temperature sensors using I2C or I3C bus interface.
+ Such sensors are found on DDR5 memory modules.
+
+ This driver supports both I2C and I3C interfaces.
This driver can also be built as a module. If so, the module
will be called spd5118.
diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
index 6ba37a719300..9724cf70b61d 100644
--- a/drivers/hwmon/spd5118.c
+++ b/drivers/hwmon/spd5118.c
@@ -18,6 +18,7 @@
#include <linux/bits.h>
#include <linux/err.h>
#include <linux/i2c.h>
+#include <linux/i3c/device.h>
#include <linux/hwmon.h>
#include <linux/module.h>
#include <linux/mutex.h>
@@ -464,6 +465,27 @@ static const struct regmap_config spd5118_regmap8_config = {
.num_ranges = ARRAY_SIZE(spd5118_i2c_regmap_range_cfg),
};
+/*
+ * SPD5118 2-byte register address format (JESD300-5, Tables 7 & 20):
+ * Byte 1 (on wire first): MemReg | BlkAddr[0] | Address[5:0]
+ * Byte 2 (on wire second): 0000 | BlkAddr[4:1]
+ *
+ * The address byte (with MemReg and lower address bits) must be sent first,
+ * followed by the upper block address byte. With regmap 16-bit register
+ * format, this maps to little-endian: the low byte of the 16-bit value is
+ * transmitted first. No range config is needed since I3C does not use MR11
+ * page switching.
+ */
+static const struct regmap_config spd5118_regmap_i3c_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = 0x7ff,
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+ .writeable_reg = spd5118_writeable_reg,
+ .volatile_reg = spd5118_volatile_reg,
+ .cache_type = REGCACHE_MAPLE,
+};
+
static int spd5118_suspend(struct device *dev)
{
struct spd5118_data *data = dev_get_drvdata(dev);
@@ -701,7 +723,39 @@ static struct i2c_driver spd5118_i2c_driver = {
.address_list = IS_ENABLED(CONFIG_SENSORS_SPD5118_DETECT) ? normal_i2c : NULL,
};
-module_i2c_driver(spd5118_i2c_driver);
+/* I3C */
+
+static int spd5118_i3c_probe(struct i3c_device *i3cdev)
+{
+ struct device *dev = i3cdev_to_dev(i3cdev);
+ struct regmap *regmap;
+ u8 regval[2];
+ int err;
+
+ regmap = devm_regmap_init_i3c(i3cdev, &spd5118_regmap_i3c_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
+
+ err = regmap_bulk_read(regmap, SPD5118_REG_TYPE, regval, 2);
+ if (err)
+ return dev_err_probe(dev, err, "failed to read device type\n");
+
+ if (regval[0] != 0x51 || regval[1] != 0x18)
+ return -ENODEV;
+
+ return spd5118_common_probe(dev, regmap);
+}
+
+static struct i3c_driver spd5118_i3c_driver = {
+ .driver = {
+ .name = "spd5118_i3c",
+ .of_match_table = spd5118_of_ids,
+ .pm = pm_sleep_ptr(&spd5118_pm_ops),
+ },
+ .probe = spd5118_i3c_probe,
+};
+
+module_i3c_i2c_driver(spd5118_i3c_driver, &spd5118_i2c_driver);
MODULE_AUTHOR("René Rebe <rene@exactcode.de>");
MODULE_AUTHOR("Guenter Roeck <linux@roeck-us.net>");
--
2.43.0
^ permalink raw reply related
* [PATCH v5 10/12] hwmon: spd5118: Remove 16-bit addressing
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
The intent of introducing 16-bit addressing was to support I3C, but it
turns out that I3C does not require reading the Legacy Mode register,
nor any specific encoding for page translation. The testing of 16-bit
code was limited and there are no known users for this feature. Remove
the sections that support 16-bit addressing and prepare the driver to
support I3C appropriately.
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/hwmon/spd5118.c | 79 +++--------------------------------------
1 file changed, 5 insertions(+), 74 deletions(-)
diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
index cc40661cab21..6ba37a719300 100644
--- a/drivers/hwmon/spd5118.c
+++ b/drivers/hwmon/spd5118.c
@@ -66,9 +66,6 @@ static const unsigned short normal_i2c[] = {
#define SPD5118_EEPROM_BASE 0x80
#define SPD5118_EEPROM_SIZE (SPD5118_PAGE_SIZE * SPD5118_NUM_PAGES)
-#define PAGE_ADDR0(page) (((page) & BIT(0)) << 6)
-#define PAGE_ADDR1_4(page) (((page) & GENMASK(4, 1)) >> 1)
-
/* Temperature unit in millicelsius */
#define SPD5118_TEMP_UNIT (MILLIDEGREE_PER_DEGREE / 4)
/* Representable temperature range in millicelsius */
@@ -78,7 +75,6 @@ static const unsigned short normal_i2c[] = {
struct spd5118_data {
struct regmap *regmap;
struct mutex nvmem_lock;
- bool is_16bit;
};
/* hwmon */
@@ -348,12 +344,7 @@ static ssize_t spd5118_nvmem_read_page(struct spd5118_data *data, char *buf,
if (offset + count > SPD5118_PAGE_SIZE)
count = SPD5118_PAGE_SIZE - offset;
- if (data->is_16bit) {
- addr = SPD5118_EEPROM_BASE | PAGE_ADDR0(page) |
- (PAGE_ADDR1_4(page) << 8);
- } else {
- addr = page * 0x100 + SPD5118_EEPROM_BASE;
- }
+ addr = page * 0x100 + SPD5118_EEPROM_BASE;
err = regmap_bulk_read(regmap, addr + offset, buf, count);
if (err)
return err;
@@ -473,15 +464,6 @@ static const struct regmap_config spd5118_regmap8_config = {
.num_ranges = ARRAY_SIZE(spd5118_i2c_regmap_range_cfg),
};
-static const struct regmap_config spd5118_regmap16_config = {
- .reg_bits = 16,
- .val_bits = 8,
- .max_register = 0x7ff,
- .writeable_reg = spd5118_writeable_reg,
- .volatile_reg = spd5118_volatile_reg,
- .cache_type = REGCACHE_MAPLE,
-};
-
static int spd5118_suspend(struct device *dev)
{
struct spd5118_data *data = dev_get_drvdata(dev);
@@ -519,8 +501,7 @@ static int spd5118_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(spd5118_pm_ops, spd5118_suspend, spd5118_resume);
-static int spd5118_common_probe(struct device *dev, struct regmap *regmap,
- bool is_16bit)
+static int spd5118_common_probe(struct device *dev, struct regmap *regmap)
{
unsigned int capability, revision, vendor, bank;
struct spd5118_data *data;
@@ -537,8 +518,6 @@ static int spd5118_common_probe(struct device *dev, struct regmap *regmap,
if (!(capability & SPD5118_CAP_TS_SUPPORT))
return -ENODEV;
- data->is_16bit = is_16bit;
-
err = regmap_read(regmap, SPD5118_REG_REVISION, &revision);
if (err)
return err;
@@ -680,69 +659,21 @@ static int spd5118_i2c_init(struct i2c_client *client)
return 0;
}
-/*
- * 16-bit addressing note:
- *
- * If I2C_FUNC_I2C is not supported by an I2C adapter driver, regmap uses
- * SMBus operations as alternative. To simulate a read operation with a 16-bit
- * address, it writes the address using i2c_smbus_write_byte_data(), followed
- * by one or more calls to i2c_smbus_read_byte() to read the data.
- * Per spd5118 standard, a read operation after writing the address must start
- * with <Sr> (Repeat Start). However, a SMBus read byte operation starts with
- * <S> (Start). This resets the register address in the spd5118 chip. As result,
- * i2c_smbus_read_byte() always returns data from register address 0x00.
- *
- * A working alternative to access chips with 16-bit register addresses in the
- * absence of I2C_FUNC_I2C support is not known.
- *
- * For this reason, 16-bit addressing can only be supported with I2C if the
- * adapter supports I2C_FUNC_I2C.
- *
- * For I2C, the addressing mode selected by the BIOS must not be changed.
- * Experiments show that at least some PC BIOS versions will not change the
- * addressing mode on a soft reboot and end up in setup, claiming that some
- * configuration change happened. This will happen again after a power cycle,
- * which does reset the addressing mode. To prevent this from happening,
- * detect if 16-bit addressing is enabled and always use the currently
- * configured addressing mode.
- */
-
static int spd5118_i2c_probe(struct i2c_client *client)
{
- const struct regmap_config *config;
struct device *dev = &client->dev;
struct regmap *regmap;
- int err, mode;
- bool is_16bit;
+ int err;
err = spd5118_i2c_init(client);
if (err)
return err;
- mode = i2c_smbus_read_byte_data(client, SPD5118_REG_I2C_LEGACY_MODE);
- if (mode < 0)
- return mode;
-
- is_16bit = mode & SPD5118_LEGACY_MODE_ADDR;
- if (is_16bit) {
- /*
- * See 16-bit addressing note above explaining why it is
- * necessary to check for I2C_FUNC_I2C support here.
- */
- if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
- dev_err(dev, "Adapter does not support 16-bit register addresses\n");
- return -ENODEV;
- }
- config = &spd5118_regmap16_config;
- } else {
- config = &spd5118_regmap8_config;
- }
-
- regmap = devm_regmap_init_i2c(client, config);
+ regmap = devm_regmap_init_i2c(client, &spd5118_regmap8_config);
if (IS_ERR(regmap))
return dev_err_probe(dev, PTR_ERR(regmap), "regmap init failed\n");
- return spd5118_common_probe(dev, regmap, is_16bit);
+ return spd5118_common_probe(dev, regmap);
}
static const struct i2c_device_id spd5118_i2c_id[] = {
--
2.43.0
^ permalink raw reply related
* [PATCH v5 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
Update variable names to generic names and add Tegra410 ACPI ID to
support the I3C controller in Tegra410, which is a DesignWare I3C host
controller.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master/dw-i3c-master.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 8e40d178d500..0753f6c853b7 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -1855,11 +1855,12 @@ static const struct of_device_id dw_i3c_master_of_match[] = {
};
MODULE_DEVICE_TABLE(of, dw_i3c_master_of_match);
-static const struct acpi_device_id amd_i3c_device_match[] = {
+static const struct acpi_device_id dw_i3c_master_acpi_match[] = {
{ "AMDI0015", AMD_I3C_OD_PP_TIMING },
+ { "NVDA2018", DW_I3C_ACPI_SKIP_CLK_RST },
{ }
};
-MODULE_DEVICE_TABLE(acpi, amd_i3c_device_match);
+MODULE_DEVICE_TABLE(acpi, dw_i3c_master_acpi_match);
static struct platform_driver dw_i3c_driver = {
.probe = dw_i3c_probe,
@@ -1868,7 +1869,7 @@ static struct platform_driver dw_i3c_driver = {
.driver = {
.name = "dw-i3c-master",
.of_match_table = dw_i3c_master_of_match,
- .acpi_match_table = amd_i3c_device_match,
+ .acpi_match_table = dw_i3c_master_acpi_match,
.pm = &dw_i3c_pm_ops,
},
};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 08/12] i3c: dw-i3c-master: Add ACPI core clock frequency quirk
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
Some ACPI-enumerated devices like Tegra410 do not expose the controller
core clock through the clk framework. Unlike device tree, ACPI on Arm does
not model clock providers. The hardware is expected to have its clocks
enabled by firmware before the OS takes over.
Make the core clock optional and allow selected ACPI devices to provide the
core clock rate through the "clock-frequency" _DSD property when the core
clock is absent.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master/dw-i3c-master.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 29030fd9594a..8e40d178d500 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -242,6 +242,7 @@
/* List of quirks */
#define AMD_I3C_OD_PP_TIMING BIT(1)
#define DW_I3C_DISABLE_RUNTIME_PM_QUIRK BIT(2)
+#define DW_I3C_ACPI_SKIP_CLK_RST BIT(3)
struct dw_i3c_cmd {
u32 cmd_lo;
@@ -556,13 +557,33 @@ static void dw_i3c_master_set_intr_regs(struct dw_i3c_master *master)
writel(IBI_REQ_REJECT_ALL, master->regs + IBI_MR_REQ_REJECT);
}
+static unsigned long dw_i3c_master_get_core_rate(struct dw_i3c_master *master)
+{
+ unsigned int core_rate_prop;
+
+ if (master->core_clk)
+ return clk_get_rate(master->core_clk);
+
+ if (!(master->quirks & DW_I3C_ACPI_SKIP_CLK_RST)) {
+ dev_err(master->dev, "missing core clock\n");
+ return 0;
+ }
+
+ if (device_property_read_u32(master->dev, "clock-frequency", &core_rate_prop)) {
+ dev_err(master->dev, "missing clock-frequency property\n");
+ return 0;
+ }
+
+ return core_rate_prop;
+}
+
static int dw_i3c_clk_cfg(struct dw_i3c_master *master)
{
unsigned long core_rate, core_period;
u32 scl_timing;
u8 hcnt, lcnt;
- core_rate = clk_get_rate(master->core_clk);
+ core_rate = dw_i3c_master_get_core_rate(master);
if (!core_rate)
return -EINVAL;
@@ -615,7 +636,7 @@ static int dw_i2c_clk_cfg(struct dw_i3c_master *master)
u16 hcnt, lcnt;
u32 scl_timing;
- core_rate = clk_get_rate(master->core_clk);
+ core_rate = dw_i3c_master_get_core_rate(master);
if (!core_rate)
return -EINVAL;
@@ -1577,7 +1598,7 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
if (IS_ERR(master->regs))
return PTR_ERR(master->regs);
- master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
+ master->core_clk = devm_clk_get_optional_enabled(&pdev->dev, NULL);
if (IS_ERR(master->core_clk))
return PTR_ERR(master->core_clk);
--
2.43.0
^ permalink raw reply related
* [PATCH v5 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
Add SETAASA and SETHID to the supported list of CCC commands for
DesignWare I3C host controller.
SETAASA is a broadcast command that assigns predefined static addresses
to all I3C devices on the bus.
SETHID is to stop HID bit flipping by the SPD Hub to which the SPD devices
are connected. It is a prerequisite command to be sent before SETAASA as
recommended by JESD300-5 and JESD403 sideband bus specifications.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master/dw-i3c-master.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 2f8c0c4683e0..29030fd9594a 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -309,6 +309,8 @@ static bool dw_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
case I3C_CCC_GETSTATUS:
case I3C_CCC_GETMXDS:
case I3C_CCC_GETHDRCAP:
+ case I3C_CCC_SETAASA:
+ case I3C_CCC_VENDOR(0, true): /* SETHID */
return true;
default:
return false;
--
2.43.0
^ permalink raw reply related
* [PATCH v5 06/12] i3c: master: match I3C device through DT and ACPI
From: Akhil R @ 2026-06-24 10:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
SETAASA-based devices cannot always be identified by PID or DCR; the
standard I3C id_table matching may not be applicable. Allow such devices to
match through Device Tree or ACPI.
Emit OF and ACPI modaliases so firmware-matched devices can autoload their
drivers.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index bd0dc76c7ba1..f513169ac395 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -19,6 +19,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/pm_runtime.h>
#include <linux/property.h>
#include <linux/slab.h>
@@ -320,6 +321,15 @@ static int i3c_device_uevent(const struct device *dev, struct kobj_uevent_env *e
const struct i3c_device *i3cdev = dev_to_i3cdev(dev);
struct i3c_device_info devinfo;
u16 manuf, part, ext;
+ int rc;
+
+ rc = of_device_uevent_modalias(dev, env);
+ if (rc != -ENODEV)
+ return rc;
+
+ rc = acpi_device_uevent_modalias(dev, env);
+ if (rc != -ENODEV)
+ return rc;
if (i3cdev->desc)
devinfo = i3cdev->desc->info;
@@ -345,15 +355,32 @@ static int i3c_device_match(struct device *dev, const struct device_driver *drv)
{
struct i3c_device *i3cdev;
const struct i3c_driver *i3cdrv;
+ u8 static_addr_method = 0;
if (dev->type != &i3c_device_type)
return 0;
i3cdev = dev_to_i3cdev(dev);
i3cdrv = drv_to_i3cdrv(drv);
- if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
+
+ if (i3cdev->desc && i3cdev->desc->boardinfo)
+ static_addr_method = i3cdev->desc->boardinfo->static_addr_method;
+
+ /*
+ * SETAASA-based devices need not always have a matching ID since
+ * it is not mandatory for such devices to implement deviceinfo
+ * CCC commands. Allow them to register through DT or ACPI.
+ */
+ if (i3cdrv->id_table && i3c_device_match_id(i3cdev, i3cdrv->id_table))
return 1;
+ if (static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+ if (of_driver_match_device(dev, drv))
+ return 1;
+ if (acpi_driver_match_device(dev, drv))
+ return 1;
+ }
+
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v5 05/12] i3c: master: Add support for devices without PID
From: Akhil R @ 2026-06-24 10:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
Devices using SETAASA for address assignment are not required to have
a 48-bit PID according to the I3C specification. Allow such devices to
register and use the static address where PID was required.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master.c | 51 ++++++++++++++++++++++++++++++++++----------
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 3deae8cdae52..bd0dc76c7ba1 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1989,8 +1989,17 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
desc->dev->dev.type = &i3c_device_type;
desc->dev->dev.bus = &i3c_bus_type;
desc->dev->dev.release = i3c_device_release;
- dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
- desc->info.pid);
+
+ /*
+ * For devices without PID (e.g., SETAASA devices), use
+ * static address for naming instead.
+ */
+ if (desc->info.pid)
+ dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
+ desc->info.pid);
+ else
+ dev_set_name(&desc->dev->dev, "%d-%02x", master->bus.id,
+ desc->info.static_addr);
if (desc->boardinfo)
device_set_node(&desc->dev->dev,
@@ -2383,8 +2392,18 @@ static void i3c_master_attach_boardinfo(struct i3c_dev_desc *i3cdev)
struct i3c_dev_boardinfo *i3cboardinfo;
list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
- if (i3cdev->info.pid != i3cboardinfo->pid)
- continue;
+ /*
+ * For devices without PID (e.g., SETAASA devices), match by
+ * static address. For devices with PID, match by PID.
+ */
+ if (i3cboardinfo->pid) {
+ if (i3cdev->info.pid != i3cboardinfo->pid)
+ continue;
+ } else {
+ if (!i3cboardinfo->static_addr ||
+ i3cdev->info.static_addr != i3cboardinfo->static_addr)
+ continue;
+ }
i3cdev->boardinfo = i3cboardinfo;
i3cdev->info.static_addr = i3cboardinfo->static_addr;
@@ -2398,8 +2417,12 @@ i3c_master_search_i3c_dev_duplicate(struct i3c_dev_desc *refdev)
struct i3c_master_controller *master = i3c_dev_get_master(refdev);
struct i3c_dev_desc *i3cdev;
+ if (!refdev->info.pid)
+ return NULL;
+
i3c_bus_for_each_i3cdev(&master->bus, i3cdev) {
- if (i3cdev != refdev && i3cdev->info.pid == refdev->info.pid)
+ if (i3cdev != refdev && i3cdev->info.pid &&
+ i3cdev->info.pid == refdev->info.pid)
return i3cdev;
}
@@ -2832,9 +2855,15 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
- if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
- I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
- return -EINVAL;
+ /* For SETAASA devices, validate the static address instead of PID */
+ if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+ if (!boardinfo->static_addr)
+ return -EINVAL;
+ } else {
+ if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
+ I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
+ return -EINVAL;
+ }
boardinfo->init_dyn_addr = init_dyn_addr;
boardinfo->fwnode = fwnode_handle_get(fwnode);
@@ -2857,10 +2886,10 @@ static int i3c_master_add_of_dev(struct i3c_master_controller *master,
return ret;
/*
- * The manufacturer ID can't be 0. If reg[1] == 0 that means we're
- * dealing with an I2C device.
+ * I3C device should have either the manufacturer ID specified or the
+ * address discovery method specified. Else treat it as an I2C device.
*/
- if (!reg[1])
+ if (!reg[1] && !fwnode_property_present(fwnode, "mipi-i3c-static-method"))
ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
else
ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
--
2.43.0
^ permalink raw reply related
* [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
From: Akhil R @ 2026-06-24 10:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
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>
---
drivers/i3c/master.c | 83 +++++++++++++++++++++++++++++++++++++-
include/linux/i3c/ccc.h | 1 +
include/linux/i3c/master.h | 15 +++++++
3 files changed, 97 insertions(+), 2 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 4bba2bad897a..3deae8cdae52 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -5,6 +5,7 @@
* Author: Boris Brezillon <boris.brezillon@bootlin.com>
*/
+#include <dt-bindings/i3c/i3c.h>
#include <linux/acpi.h>
#include <linux/atomic.h>
#include <linux/bitmap.h>
@@ -1102,6 +1103,51 @@ static int i3c_master_rstdaa_locked(struct i3c_master_controller *master,
return ret;
}
+/**
+ * i3c_master_setaasa_locked() - start a SETAASA procedure (Set All Addresses to Static Address)
+ * @master: I3C master object
+ *
+ * Send a SETAASA CCC command to set all attached I3C devices' dynamic addresses to
+ * their static address.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * First, the SETHID CCC command is sent, followed by the SETAASA CCC.
+ *
+ * Return: 0 in case of success, a positive I3C error code if the error is
+ * one of the official Mx error codes, and a negative error code otherwise.
+ */
+static int i3c_master_setaasa_locked(struct i3c_master_controller *master)
+{
+ struct i3c_ccc_cmd_dest dest;
+ struct i3c_ccc_cmd cmd;
+ int ret;
+
+ /*
+ * Send SETHID CCC command. Though it is a standard CCC command specified
+ * in JESD300-5, we are not defining a separate macro to be explicit that
+ * the value falls under the vendor specific range.
+ */
+ i3c_ccc_cmd_dest_init(&dest, I3C_BROADCAST_ADDR, 0);
+ i3c_ccc_cmd_init(&cmd, false, I3C_CCC_VENDOR(0, true), &dest, 1);
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ i3c_ccc_cmd_dest_cleanup(&dest);
+ if (ret && cmd.err == I3C_ERROR_M2)
+ ret = 0;
+ if (ret)
+ return ret;
+
+ /* Send SETAASA CCC command */
+ i3c_ccc_cmd_dest_init(&dest, I3C_BROADCAST_ADDR, 0);
+ i3c_ccc_cmd_init(&cmd, false, I3C_CCC_SETAASA, &dest, 1);
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ i3c_ccc_cmd_dest_cleanup(&dest);
+ if (ret && cmd.err == I3C_ERROR_M2)
+ ret = 0;
+
+ return ret;
+}
+
/**
* i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
* procedure
@@ -1878,6 +1924,22 @@ static int i3c_master_early_i3c_dev_add(struct i3c_master_controller *master,
if (ret)
goto err_free_dev;
+ /*
+ * For devices using SETAASA instead of ENTDAA, the address is statically
+ * assigned. Update the dynamic address to the provided static address.
+ * Reattach the I3C device after updating the dynamic address with the same
+ * static address. It is not mandatory for such devices to implement CCC
+ * commands like GETPID, GETDCR etc. Hence, we can return after reattaching.
+ */
+ if (i3cdev->boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+ i3cdev->info.dyn_addr = i3cdev->boardinfo->static_addr;
+ ret = i3c_master_reattach_i3c_dev_locked(i3cdev, 0);
+ if (ret)
+ goto err_rstdaa;
+
+ return 0;
+ }
+
ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
i3cdev->boardinfo->init_dyn_addr);
if (ret)
@@ -2232,6 +2294,12 @@ static int i3c_master_bus_init(struct i3c_master_controller *master)
if (ret)
goto err_bus_cleanup;
+ if (master->addr_method & I3C_ADDR_METHOD_SETAASA) {
+ ret = i3c_master_setaasa_locked(master);
+ if (ret)
+ goto err_bus_cleanup;
+ }
+
/*
* Reserve init_dyn_addr first, and then try to pre-assign dynamic
* address and retrieve device information if needed.
@@ -2724,7 +2792,7 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
struct i3c_dev_boardinfo *boardinfo;
struct device *dev = &master->dev;
enum i3c_addr_slot_status addrstatus;
- u32 init_dyn_addr = 0;
+ u32 init_dyn_addr = 0, static_addr_method = 0;
boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
if (!boardinfo)
@@ -2742,7 +2810,14 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
boardinfo->static_addr = reg[0];
- if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
+ if (!fwnode_property_read_u32(fwnode, "mipi-i3c-static-method", &static_addr_method))
+ boardinfo->static_addr_method = static_addr_method &
+ (I3C_ADDR_METHOD_SETDASA | I3C_ADDR_METHOD_SETAASA);
+
+ if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
+ /* For SETAASA, static address is taken as the dynamic address. */
+ init_dyn_addr = boardinfo->static_addr;
+ } else if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
if (init_dyn_addr > I3C_MAX_ADDR)
return -EINVAL;
@@ -2752,6 +2827,9 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
return -EINVAL;
}
+ /* Update the address methods required for device discovery */
+ master->addr_method |= boardinfo->static_addr_method;
+
boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
@@ -3386,6 +3464,7 @@ int i3c_master_register(struct i3c_master_controller *master,
master->dev.release = i3c_masterdev_release;
master->ops = ops;
master->secondary = secondary;
+ master->addr_method = I3C_ADDR_METHOD_SETDASA;
INIT_LIST_HEAD(&master->boardinfo.i2c);
INIT_LIST_HEAD(&master->boardinfo.i3c);
diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
index ad59a4ae60d1..a145d766ab6f 100644
--- a/include/linux/i3c/ccc.h
+++ b/include/linux/i3c/ccc.h
@@ -32,6 +32,7 @@
#define I3C_CCC_DEFSLVS I3C_CCC_ID(0x8, true)
#define I3C_CCC_ENTTM I3C_CCC_ID(0xb, true)
#define I3C_CCC_ENTHDR(x) I3C_CCC_ID(0x20 + (x), true)
+#define I3C_CCC_SETAASA I3C_CCC_ID(0x29, true)
/* Unicast-only commands */
#define I3C_CCC_SETDASA I3C_CCC_ID(0x7, false)
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
index a16deb04b2e1..2dc139a217bf 100644
--- a/include/linux/i3c/master.h
+++ b/include/linux/i3c/master.h
@@ -174,6 +174,14 @@ struct i3c_device_ibi_info {
* assigned a dynamic address by the master. Will be used during
* bus initialization to assign it a specific dynamic address
* before starting DAA (Dynamic Address Assignment)
+ * @static_addr_method: Bitmap describing which methods of Dynamic Address
+ * Assignment from a Static Address are supported by this I3C Target.
+ * A value of 1 in a bit position indicates that the I3C target
+ * supports that method, and a value of 0 indicates that the I3C
+ * target does not support that method.
+ * Bit 0: SETDASA
+ * Bit 1: SETAASA
+ * All other bits are reserved.
* @pid: I3C Provisioned ID exposed by the device. This is a unique identifier
* that may be used to attach boardinfo to i3c_dev_desc when the device
* does not have a static address
@@ -189,6 +197,7 @@ struct i3c_dev_boardinfo {
struct list_head node;
u8 init_dyn_addr;
u8 static_addr;
+ u8 static_addr_method;
u64 pid;
struct fwnode_handle *fwnode;
};
@@ -517,6 +526,11 @@ struct i3c_master_controller_ops {
* @boardinfo.i2c: list of I2C boardinfo objects
* @boardinfo: board-level information attached to devices connected on the bus
* @bus: I3C bus exposed by this master
+ * @addr_method: Bitmap describing which methods of Address Assignment required
+ * to be run for discovering all the devices on the bus.
+ * Bit 0: SETDASA
+ * Bit 1: SETAASA
+ * All other bits are reserved.
* @wq: freezable workqueue which can be used by master
* drivers if they need to postpone operations that need to take place
* in a thread context. Typical examples are Hot Join processing which
@@ -552,6 +566,7 @@ struct i3c_master_controller {
struct list_head i2c;
} boardinfo;
struct i3c_bus bus;
+ u8 addr_method;
struct workqueue_struct *wq;
struct work_struct hj_work;
struct work_struct reg_work;
--
2.43.0
^ permalink raw reply related
* [PATCH v5 03/12] i3c: master: Support ACPI enumeration of child devices
From: Akhil R @ 2026-06-24 10:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
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>
---
drivers/i3c/master.c | 151 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 143 insertions(+), 8 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index b20f56f7b68e..4bba2bad897a 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -5,6 +5,7 @@
* Author: Boris Brezillon <boris.brezillon@bootlin.com>
*/
+#include <linux/acpi.h>
#include <linux/atomic.h>
#include <linux/bitmap.h>
#include <linux/bug.h>
@@ -2622,6 +2623,55 @@ EXPORT_SYMBOL_GPL(i3c_master_do_daa);
#define OF_I3C_REG1_IS_I2C_DEV BIT(31)
+#ifdef CONFIG_ACPI
+static int i3c_acpi_get_i2c_resource(struct acpi_resource *ares, void *data)
+{
+ struct i2c_dev_boardinfo *boardinfo = data;
+ struct acpi_resource_i2c_serialbus *sb;
+
+ if (boardinfo->base.addr || !i2c_acpi_get_i2c_resource(ares, &sb))
+ return 1;
+
+ boardinfo->base.addr = sb->slave_address;
+ if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+ boardinfo->base.flags |= I2C_CLIENT_TEN;
+
+ boardinfo->lvr = sb->lvr;
+
+ return 1;
+}
+
+static int i3c_acpi_add_i2c_boardinfo(struct i2c_dev_boardinfo *boardinfo,
+ struct fwnode_handle *fwnode)
+{
+ struct acpi_device *adev = to_acpi_device_node(fwnode);
+ LIST_HEAD(resources);
+ int ret;
+
+ boardinfo->base.fwnode = acpi_fwnode_handle(adev);
+ acpi_set_modalias(adev, dev_name(&adev->dev), boardinfo->base.type,
+ sizeof(boardinfo->base.type));
+
+ ret = acpi_dev_get_resources(adev, &resources,
+ i3c_acpi_get_i2c_resource, boardinfo);
+ if (ret < 0)
+ return ret;
+
+ acpi_dev_free_resource_list(&resources);
+
+ if (!boardinfo->base.addr)
+ return -ENODEV;
+
+ return 0;
+}
+#else
+static inline int i3c_acpi_add_i2c_boardinfo(struct i2c_dev_boardinfo *boardinfo,
+ struct fwnode_handle *fwnode)
+{
+ return -ENODEV;
+}
+#endif
+
static int
i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
struct fwnode_handle *fwnode, u32 *reg)
@@ -2638,6 +2688,15 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
if (ret)
return ret;
+
+ /* LVR is encoded in reg[2] for Device Tree. */
+ boardinfo->lvr = reg[2];
+ } else if (is_acpi_device_node(fwnode)) {
+ ret = i3c_acpi_add_i2c_boardinfo(boardinfo, fwnode);
+ if (ret) {
+ devm_kfree(dev, boardinfo);
+ return ret;
+ }
} else {
return -EINVAL;
}
@@ -2652,9 +2711,6 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
return -EOPNOTSUPP;
}
- /* LVR is encoded in reg[2]. */
- boardinfo->lvr = reg[2];
-
list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
fwnode_handle_get(fwnode);
@@ -2709,8 +2765,8 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
return 0;
}
-static int i3c_master_add_dev(struct i3c_master_controller *master,
- struct fwnode_handle *fwnode)
+static int i3c_master_add_of_dev(struct i3c_master_controller *master,
+ struct fwnode_handle *fwnode)
{
u32 reg[3];
int ret;
@@ -2734,6 +2790,74 @@ static int i3c_master_add_dev(struct i3c_master_controller *master,
return ret;
}
+#ifdef CONFIG_ACPI
+static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
+ struct fwnode_handle *fwnode)
+{
+ struct acpi_device *adev = to_acpi_device_node(fwnode);
+ acpi_bus_address adr;
+ u32 reg[3] = { 0 };
+ int ret;
+
+ /*
+ * If the ACPI table entry has _ADR method, it's an I3C device.
+ * Otherwise it may be an I2C device described by an I2cSerialBus
+ * resource. If no I2cSerialBus resource is found, ignore the entry.
+ */
+ if (!acpi_has_method(adev->handle, "_ADR")) {
+ ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
+ if (ret == -ENODEV)
+ return 0;
+
+ return ret;
+ }
+
+ adr = acpi_device_adr(adev);
+
+ /* For I3C devices, _ADR will have the 48 bit PID of the device */
+ reg[1] = upper_32_bits(adr);
+ reg[2] = lower_32_bits(adr);
+
+ fwnode_property_read_u32(fwnode, "mipi-i3c-static-address", ®[0]);
+
+ return i3c_master_add_i3c_boardinfo(master, fwnode, reg);
+}
+
+static u8 i3c_acpi_i2c_get_lvr(struct i2c_client *client)
+{
+ struct acpi_device *adev = to_acpi_device_node(client->dev.fwnode);
+ struct i2c_dev_boardinfo boardinfo = {};
+ LIST_HEAD(resources);
+ int ret;
+ u8 lvr;
+
+ lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
+
+ ret = acpi_dev_get_resources(adev, &resources,
+ i3c_acpi_get_i2c_resource, &boardinfo);
+ if (ret < 0)
+ return lvr;
+
+ if (boardinfo.base.addr)
+ lvr = boardinfo.lvr;
+
+ acpi_dev_free_resource_list(&resources);
+
+ return lvr;
+}
+#else
+static inline int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
+ struct fwnode_handle *fwnode)
+{
+ return -ENODEV;
+}
+
+static inline u8 i3c_acpi_i2c_get_lvr(struct i2c_client *client)
+{
+ return I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
+}
+#endif
+
static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
{
struct device *dev = &master->dev;
@@ -2745,7 +2869,13 @@ static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
return 0;
fwnode_for_each_available_child_node_scoped(fwnode, child) {
- ret = i3c_master_add_dev(master, child);
+ if (is_of_node(child))
+ ret = i3c_master_add_of_dev(master, child);
+ else if (is_acpi_device_node(child))
+ ret = i3c_master_add_acpi_dev(master, child);
+ else
+ continue;
+
if (ret)
return ret;
}
@@ -2813,8 +2943,13 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
u32 reg[3];
- if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
- lvr = reg[2];
+ if (is_of_node(client->dev.fwnode)) {
+ if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg",
+ reg, ARRAY_SIZE(reg)))
+ lvr = reg[2];
+ } else if (is_acpi_device_node(client->dev.fwnode)) {
+ lvr = i3c_acpi_i2c_get_lvr(client);
+ }
return lvr;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v5 02/12] i3c: master: Use unified device property interface
From: Akhil R @ 2026-06-24 10:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
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>
---
drivers/i3c/master.c | 78 +++++++++++++++++++++-----------------
include/linux/i3c/master.h | 5 ++-
2 files changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index f1be38a640ca..b20f56f7b68e 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -13,10 +13,12 @@
#include <linux/dma-mapping.h>
#include <linux/err.h>
#include <linux/export.h>
+#include <linux/i2c.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/of.h>
#include <linux/pm_runtime.h>
+#include <linux/property.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/workqueue.h>
@@ -491,7 +493,7 @@ static void i3c_bus_cleanup(struct i3c_bus *i3cbus)
mutex_unlock(&i3c_core_lock);
}
-static int i3c_bus_init(struct i3c_bus *i3cbus, struct device_node *np)
+static int i3c_bus_init(struct i3c_bus *i3cbus, struct fwnode_handle *fwnode)
{
int ret, start, end, id = -1;
@@ -501,8 +503,8 @@ static int i3c_bus_init(struct i3c_bus *i3cbus, struct device_node *np)
i3c_bus_init_addrslots(i3cbus);
i3cbus->mode = I3C_BUS_MODE_PURE;
- if (np)
- id = of_alias_get_id(np, "i3c");
+ if (fwnode && is_of_node(fwnode))
+ id = of_alias_get_id(to_of_node(fwnode), "i3c");
mutex_lock(&i3c_core_lock);
if (id >= 0) {
@@ -837,7 +839,7 @@ static void i3c_masterdev_release(struct device *dev)
WARN_ON(!list_empty(&bus->devs.i2c) || !list_empty(&bus->devs.i3c));
i3c_bus_cleanup(bus);
- of_node_put(dev->of_node);
+ fwnode_handle_put(dev->fwnode);
}
static const struct device_type i3c_masterdev_type = {
@@ -1044,7 +1046,7 @@ static void i3c_device_release(struct device *dev)
WARN_ON(i3cdev->desc);
- of_node_put(i3cdev->dev.of_node);
+ fwnode_handle_put(dev->fwnode);
kfree(i3cdev);
}
@@ -1928,7 +1930,8 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
desc->info.pid);
if (desc->boardinfo)
- desc->dev->dev.of_node = desc->boardinfo->of_node;
+ device_set_node(&desc->dev->dev,
+ fwnode_handle_get(desc->boardinfo->fwnode));
ret = device_register(&desc->dev->dev);
if (ret) {
@@ -2620,8 +2623,8 @@ EXPORT_SYMBOL_GPL(i3c_master_do_daa);
#define OF_I3C_REG1_IS_I2C_DEV BIT(31)
static int
-of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
- struct device_node *node, u32 *reg)
+i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
+ struct fwnode_handle *fwnode, u32 *reg)
{
struct i2c_dev_boardinfo *boardinfo;
struct device *dev = &master->dev;
@@ -2631,9 +2634,13 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
if (!boardinfo)
return -ENOMEM;
- ret = of_i2c_get_board_info(dev, node, &boardinfo->base);
- if (ret)
- return ret;
+ if (is_of_node(fwnode)) {
+ ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
+ if (ret)
+ return ret;
+ } else {
+ return -EINVAL;
+ }
/*
* The I3C Specification does not clearly say I2C devices with 10-bit
@@ -2649,14 +2656,14 @@ of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
boardinfo->lvr = reg[2];
list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
- of_node_get(node);
+ fwnode_handle_get(fwnode);
return 0;
}
static int
-of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
- struct device_node *node, u32 *reg)
+i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
+ struct fwnode_handle *fwnode, u32 *reg)
{
struct i3c_dev_boardinfo *boardinfo;
struct device *dev = &master->dev;
@@ -2679,7 +2686,7 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
boardinfo->static_addr = reg[0];
- if (!of_property_read_u32(node, "assigned-address", &init_dyn_addr)) {
+ if (!fwnode_property_read_u32(fwnode, "assigned-address", &init_dyn_addr)) {
if (init_dyn_addr > I3C_MAX_ADDR)
return -EINVAL;
@@ -2696,14 +2703,14 @@ of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
return -EINVAL;
boardinfo->init_dyn_addr = init_dyn_addr;
- boardinfo->of_node = of_node_get(node);
+ boardinfo->fwnode = fwnode_handle_get(fwnode);
list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
return 0;
}
-static int of_i3c_master_add_dev(struct i3c_master_controller *master,
- struct device_node *node)
+static int i3c_master_add_dev(struct i3c_master_controller *master,
+ struct fwnode_handle *fwnode)
{
u32 reg[3];
int ret;
@@ -2711,7 +2718,7 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master,
if (!master)
return -EINVAL;
- ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
+ ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
if (ret)
return ret;
@@ -2720,25 +2727,25 @@ static int of_i3c_master_add_dev(struct i3c_master_controller *master,
* dealing with an I2C device.
*/
if (!reg[1])
- ret = of_i3c_master_add_i2c_boardinfo(master, node, reg);
+ ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
else
- ret = of_i3c_master_add_i3c_boardinfo(master, node, reg);
+ ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);
return ret;
}
-static int of_populate_i3c_bus(struct i3c_master_controller *master)
+static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
{
struct device *dev = &master->dev;
- struct device_node *i3cbus_np = dev->of_node;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
int ret;
u32 val;
- if (!i3cbus_np)
+ if (!fwnode)
return 0;
- for_each_available_child_of_node_scoped(i3cbus_np, node) {
- ret = of_i3c_master_add_dev(master, node);
+ fwnode_for_each_available_child_node_scoped(fwnode, child) {
+ ret = i3c_master_add_dev(master, child);
if (ret)
return ret;
}
@@ -2748,10 +2755,10 @@ static int of_populate_i3c_bus(struct i3c_master_controller *master)
* on the bus are not supporting typical rates, or if the bus topology
* prevents it from using max possible rate.
*/
- if (!of_property_read_u32(i3cbus_np, "i2c-scl-hz", &val))
+ if (!device_property_read_u32(dev, "i2c-scl-hz", &val))
master->bus.scl_rate.i2c = val;
- if (!of_property_read_u32(i3cbus_np, "i3c-scl-hz", &val))
+ if (!device_property_read_u32(dev, "i3c-scl-hz", &val))
master->bus.scl_rate.i3c = val;
return 0;
@@ -2806,7 +2813,7 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
u32 reg[3];
- if (!of_property_read_u32_array(client->dev.of_node, "reg", reg, ARRAY_SIZE(reg)))
+ if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
lvr = reg[2];
return lvr;
@@ -2925,7 +2932,8 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
struct i2c_adapter *adap = i3c_master_to_i2c_adapter(master);
struct i2c_dev_desc *i2cdev;
struct i2c_dev_boardinfo *i2cboardinfo;
- int ret, id;
+ struct fwnode_handle *fwnode = dev_fwnode(&master->dev);
+ int ret, id = -1;
adap->dev.parent = master->dev.parent;
adap->owner = master->dev.parent->driver->owner;
@@ -2934,7 +2942,9 @@ static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
adap->timeout = HZ;
adap->retries = 3;
- id = of_alias_get_id(master->dev.of_node, "i2c");
+ if (fwnode && is_of_node(fwnode))
+ id = of_alias_get_id(to_of_node(fwnode), "i2c");
+
if (id >= 0) {
adap->nr = id;
ret = i2c_add_numbered_adapter(adap);
@@ -3235,7 +3245,7 @@ int i3c_master_register(struct i3c_master_controller *master,
return ret;
master->dev.parent = parent;
- master->dev.of_node = of_node_get(parent->of_node);
+ device_set_node(&master->dev, fwnode_handle_get(dev_fwnode(parent)));
master->dev.bus = &i3c_bus_type;
master->dev.type = &i3c_masterdev_type;
master->dev.release = i3c_masterdev_release;
@@ -3254,13 +3264,13 @@ int i3c_master_register(struct i3c_master_controller *master,
master->dev.coherent_dma_mask = parent->coherent_dma_mask;
master->dev.dma_parms = parent->dma_parms;
- ret = i3c_bus_init(i3cbus, master->dev.of_node);
+ ret = i3c_bus_init(i3cbus, dev_fwnode(&master->dev));
if (ret)
goto err_put_dev;
dev_set_name(&master->dev, "i3c-%d", i3cbus->id);
- ret = of_populate_i3c_bus(master);
+ ret = fwnode_populate_i3c_bus(master);
if (ret)
goto err_put_dev;
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
index 4d2a68793324..a16deb04b2e1 100644
--- a/include/linux/i3c/master.h
+++ b/include/linux/i3c/master.h
@@ -177,7 +177,8 @@ struct i3c_device_ibi_info {
* @pid: I3C Provisioned ID exposed by the device. This is a unique identifier
* that may be used to attach boardinfo to i3c_dev_desc when the device
* does not have a static address
- * @of_node: optional DT node in case the device has been described in the DT
+ * @fwnode: Firmware node (DT or ACPI) in case the device has been
+ * described in firmware
*
* This structure is used to attach board-level information to an I3C device.
* Not all I3C devices connected on the bus will have a boardinfo. It's only
@@ -189,7 +190,7 @@ struct i3c_dev_boardinfo {
u8 init_dyn_addr;
u8 static_addr;
u64 pid;
- struct device_node *of_node;
+ struct fwnode_handle *fwnode;
};
/**
--
2.43.0
^ permalink raw reply related
* [PATCH v5 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Akhil R @ 2026-06-24 10:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
In-Reply-To: <20260624102153.1770072-1-akhilrajeev@nvidia.com>
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>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
.../devicetree/bindings/i3c/i3c.yaml | 36 ++++++++++++++++---
include/dt-bindings/i3c/i3c.h | 4 +++
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
index e25fa72fd785..5603f2e7807d 100644
--- a/Documentation/devicetree/bindings/i3c/i3c.yaml
+++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
@@ -31,10 +31,12 @@ properties:
described in the device tree, which in turn means we have to describe
I3C devices.
- Another use case for describing an I3C device in the device tree is when
- this I3C device has a static I2C address and we want to assign it a
- specific I3C dynamic address before the DAA takes place (so that other
- devices on the bus can't take this dynamic address).
+ Other use-cases for describing an I3C device in the device tree are:
+ - When the I3C device has a static I2C address and we want to assign
+ it a specific I3C dynamic address before the DAA takes place (so
+ that other devices on the bus can't take this dynamic address).
+ - When the I3C device requires SETAASA for its discovery and uses a
+ pre-defined static address.
"#size-cells":
const: 0
@@ -145,7 +147,31 @@ patternProperties:
Dynamic address to be assigned to this device. In case static address is
present (first cell of the reg property != 0), this address is assigned
through SETDASA. If static address is not present, this address is assigned
- through SETNEWDA after assigning a temporary address via ENTDAA.
+ through SETNEWDA after assigning a temporary address via ENTDAA. If
+ SETAASA is used, this property is not used, and the static address itself
+ becomes the dynamic address.
+
+ mipi-i3c-static-method:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x1
+ maximum: 0x7
+ default: 1
+ description: |
+ Bitmap describing which methods of Dynamic Address Assignment from a
+ static address are supported by this I3C Target. For each defined bit
+ position, a set bit indicates support for that method and a cleared
+ bit 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.
+
+ This property follows the MIPI I3C specification. The primary use
+ of this property is to indicate support for SETAASA, i.e Bit 1, but
+ will allow other values mentioned in the specification so that it
+ mirrors the specification. SETDASA will remain as the default method
+ even if this property is not present.
required:
- reg
diff --git a/include/dt-bindings/i3c/i3c.h b/include/dt-bindings/i3c/i3c.h
index 373439218bba..78b8c634aad8 100644
--- a/include/dt-bindings/i3c/i3c.h
+++ b/include/dt-bindings/i3c/i3c.h
@@ -13,4 +13,8 @@
#define I2C_NO_FILTER_HIGH_FREQUENCY (1 << 5)
#define I2C_NO_FILTER_LOW_FREQUENCY (2 << 5)
+#define I3C_ADDR_METHOD_SETDASA (1 << 0)
+#define I3C_ADDR_METHOD_SETAASA (1 << 1)
+#define I3C_ADDR_METHOD_VENDOR (1 << 2)
+
#endif
--
2.43.0
^ permalink raw reply related
* [PATCH v5 00/12] Support ACPI and SETAASA device discovery
From: Akhil R @ 2026-06-24 10:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Frank Li, Miquel Raynal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Guenter Roeck, Philipp Zabel, Jon Hunter,
Thierry Reding, linux-i3c, devicetree, linux-hwmon, linux-tegra,
linux-kernel, Akhil R
This patch series adds SETAASA device discovery to the I3C subsystem,
enabling support for SPD5118 temperature sensors found on DDR5 memory
modules. The changes also add ACPI support for all existing DAA
methods like SETDASA, SETNEWDA as well as I2C devices on I3C bus.
SPD5118 and similar devices on DDR5 memory modules differ from typical
I3C devices in their initialization. They use SETAASA broadcast CCC
instead of ENTDAA for address assignment, and per JEDEC specification,
are not required to have a Provisioned ID or implement standard device
information CCC commands (GETPID, GETDCR, GETBCR).
The series enables describing all I3C and I2C devices on both Device
Tree and the ACPI table, using unified device property APIs throughout
the I3C core and the Synopsys DesignWare I3C master driver.
Please note that the series modifies drivers across multiple subsystems,
like Device Tree bindings, ACPI, I3C and HWMON.
v4->v5:
* Free ACPI I2C boardinfo when an ACPI child without an I2C resource is
ignored.
* Issue RSTDAA if SETAASA device attach fails after the static address is
used as the dynamic address.
* Emit OF and ACPI modaliases for firmware-matched I3C devices.
* Make the DesignWare core clock optional and use "clock-frequency" as
the fallback when core_clk is absent.
* Keep DesignWare pclk, reset, and match-data handling on their existing
optional paths.
v3->v4:
* Clarify mipi-i3c-static-method bit semantics and assigned-address
* Add I3C_ADDR_METHOD_VENDOR
* Fix fwnode reference handling while converting child property parsing
to use unified firmware-node APIs.
* Align ACPI child enumeration with the I2C core for multiple
I2cSerialBus resources, ignore ACPI child entries without an I2C
resource, and populate I2C modalias information from ACPI.
* Update SETAASA handling to use the static address as the dynamic
address, skip device-info retrieval for SETAASA devices, and tolerate
M2 for SETHID/SETAASA similarly to ENTDAA.
* Reorder DesignWare I3C clock/reset to include optional clock in the
ACPI skip clock/reset quirk.
* Add prints for missing ACPI clock-frequency and SPD5118 I3C
device type read failures.
* Fix grammar in comments and commit messages.
v2->v3:
* Fix maximum value and indent bit list for mipi-i3c-static-method.
* Move I3C_ADDR_METHOD_* macros to dt-bindings header.
* Drop ACPICA commit IDs, keep only the Link: tags.
* Revert the change which proceeds to register other devices if SETAASA
is not supported so that it aligns with the rest of the driver and to
avoid the issues pointed by Sashiko.
* Rework multiple commit messages.
v1->v2:
* Added patch to remove 16-bit addressing support for SPD5118
* Guard ACPI calls with #ifdef CONFIG_ACPI
* Remove CONFIG_OF guard for of_alias_get_highest_id()
* Mask mipi-i3c-static-method in the driver to select only valid values.
* Proceed to register other devices if SETAASA is not supported.
* Update commit message and links in the description of multiple commits.
Akhil R (12):
dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
i3c: master: Use unified device property interface
i3c: master: Support ACPI enumeration of child devices
i3c: master: Add support for devices using SETAASA
i3c: master: Add support for devices without PID
i3c: master: match I3C device through DT and ACPI
i3c: dw-i3c-master: Add SETAASA as supported CCC
i3c: dw-i3c-master: Add ACPI core clock frequency quirk
i3c: dw-i3c-master: Add ACPI ID for Tegra410
hwmon: spd5118: Remove 16-bit addressing
hwmon: spd5118: Add I3C support
arm64: defconfig: Enable I3C and SPD5118 hwmon
.../devicetree/bindings/i3c/i3c.yaml | 36 +-
arch/arm64/configs/defconfig | 3 +
drivers/hwmon/Kconfig | 9 +-
drivers/hwmon/spd5118.c | 119 +++---
drivers/i3c/master.c | 382 +++++++++++++++---
drivers/i3c/master/dw-i3c-master.c | 36 +-
include/dt-bindings/i3c/i3c.h | 4 +
include/linux/i3c/ccc.h | 1 +
include/linux/i3c/master.h | 20 +-
9 files changed, 476 insertions(+), 134 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v6 02/10] arm64: tegra: Remove fallback compatible for GPCDMA
From: Thierry Reding @ 2026-06-24 10:22 UTC (permalink / raw)
To: Rob Herring
Cc: Akhil R, Thierry Reding, Vinod Koul, Frank Li,
Krzysztof Kozlowski, Conor Dooley, Jonathan Hunter,
Laxman Dewangan, Philipp Zabel, dmaengine, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <CAL_Jsq+bbYZnE=Asv=2VnvTpSsLfKtdpcLvfPzn85hyiyp85cA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Tue, Jun 23, 2026 at 09:02:39AM -0500, Rob Herring wrote:
> On Tue, Mar 31, 2026 at 5:24 AM Akhil R <akhilrajeev@nvidia.com> wrote:
> >
> > Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA
> > in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the
> > register offset changes and absence of the reset property.
> >
> > Fixes: 65ef237e4810 ("arm64: tegra: Add Tegra264 support")
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > ---
> > arch/arm64/boot/dts/nvidia/tegra264.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thierry, Are you going to apply this? The binding change has been
> picked up and now there's a warning.
Yes, I have this in my tree of fixes for 7.1 and plan to send it out
towards the end of this week.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 2/2] arm64: dts: axiado: Add initial support for AX3005 SoC and eval board
From: Swark Yang @ 2026-06-24 10:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah
Cc: devicetree, linux-arm-kernel, linux-kernel, Swark Yang
In-Reply-To: <20260624-upstream-axiado-ax3005-upstream-v1-0-c05bd0bc9124@axiado.com>
Add initial device tree support for the AX3005 SoC and its evaluation
board. The AX3005 is a multi-core SoC featuring 4 Cortex-A53 cores, and
this adds the CPUs, timer, GPIO, UART, I2C, I3C, SPI and USB
controllers.
The AX3005 groups its low-speed controllers into four Slow Peripheral
(SP) blocks (SP0-SP3), each exposing its own I2C/I3C, SPI and UART
instances. The controllers are numbered by their per-SP hardware
instance ID, so the i2cN/spiN/uartN labels and their aliases are
intentionally non-contiguous and do not increase monotonically with
the register address.
Signed-off-by: Swark Yang <syang@axiado.com>
---
arch/arm64/boot/dts/axiado/Makefile | 1 +
arch/arm64/boot/dts/axiado/ax3005-evk.dts | 327 ++++++++++++
arch/arm64/boot/dts/axiado/ax3005.dtsi | 843 ++++++++++++++++++++++++++++++
3 files changed, 1171 insertions(+)
diff --git a/arch/arm64/boot/dts/axiado/Makefile b/arch/arm64/boot/dts/axiado/Makefile
index 6676ad07db61..e71a0850a451 100644
--- a/arch/arm64/boot/dts/axiado/Makefile
+++ b/arch/arm64/boot/dts/axiado/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_AXIADO) += ax3000-evk.dtb
+dtb-$(CONFIG_ARCH_AXIADO) += ax3005-evk.dtb
diff --git a/arch/arm64/boot/dts/axiado/ax3005-evk.dts b/arch/arm64/boot/dts/axiado/ax3005-evk.dts
new file mode 100644
index 000000000000..9187057eb7a5
--- /dev/null
+++ b/arch/arm64/boot/dts/axiado/ax3005-evk.dts
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DTS file for Axiado AX3005 SoC based EVK
+ * Copyright (c) 2026 Axiado Corporation.
+ */
+
+/dts-v1/;
+
+#include "ax3005.dtsi"
+
+/ {
+ model = "Axiado AX3005 EVK";
+ compatible = "axiado,ax3005-evk", "axiado,ax3005";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ serial5 = &uart5;
+ serial6 = &uart6;
+ serial7 = &uart7;
+ serial8 = &uart8;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ i2c12 = &i3c12;
+ i2c13 = &i3c13;
+ i2c14 = &i2c14;
+ i2c15 = &i2c15;
+ i2c16 = &i2c16;
+ i2c17 = &i2c17;
+ i2c18 = &i2c18;
+ i2c19 = &i2c19;
+ i2c20 = &i2c20;
+ i2c21 = &i2c21;
+ i2c22 = &i2c22;
+ i2c23 = &i2c23;
+ i2c24 = &i2c24;
+ i2c25 = &i2c25;
+ i2c26 = &i2c26;
+ i2c27 = &i2c27;
+ i2c28 = &i2c28;
+ i2c29 = &i2c29;
+ i2c30 = &i2c30;
+ i2c31 = &i2c31;
+ i2c32 = &i2c32;
+ i2c33 = &i2c33;
+ i2c34 = &i2c34;
+ i2c35 = &i2c35;
+ i2c36 = &i2c36;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ spi2 = &spi2;
+ spi3 = &spi3;
+ spi5 = &spi5;
+ spi6 = &spi6;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ /* Cortex-A53 will use following memory map */
+ reg = <0x0 0x81000000 0x0 0x7f000000>;
+ };
+};
+
+&gpio0 {
+ status = "okay";
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&gpio2 {
+ status = "okay";
+};
+
+&gpio3 {
+ status = "okay";
+};
+
+&gpio4 {
+ status = "okay";
+};
+
+&gpio5 {
+ status = "okay";
+};
+
+&gpio6 {
+ status = "okay";
+};
+
+&gpio7 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+};
+
+&i2c8 {
+ status = "okay";
+};
+
+&i2c9 {
+ status = "okay";
+};
+
+&i2c10 {
+ status = "okay";
+};
+
+&i2c11 {
+ status = "okay";
+};
+
+&i3c12 {
+ status = "okay";
+};
+
+&i3c13 {
+ status = "okay";
+};
+
+&i2c14 {
+ status = "okay";
+};
+
+&i2c15 {
+ status = "okay";
+};
+
+&i2c16 {
+ status = "okay";
+};
+
+&i2c17 {
+ status = "okay";
+};
+
+&i2c18 {
+ status = "okay";
+};
+
+&i2c19 {
+ status = "okay";
+};
+
+&i2c20 {
+ status = "okay";
+};
+
+&i2c21 {
+ status = "okay";
+};
+
+&i2c22 {
+ status = "okay";
+};
+
+&i2c23 {
+ status = "okay";
+};
+
+&i2c24 {
+ status = "okay";
+};
+
+&i2c25 {
+ status = "okay";
+};
+
+&i2c26 {
+ status = "okay";
+};
+
+&i2c27 {
+ status = "okay";
+};
+
+&i2c28 {
+ status = "okay";
+};
+
+&i2c29 {
+ status = "okay";
+};
+
+&i2c30 {
+ status = "okay";
+};
+
+&i2c31 {
+ status = "okay";
+};
+
+&i2c32 {
+ status = "okay";
+};
+
+&i2c33 {
+ status = "okay";
+};
+
+&i2c34 {
+ status = "okay";
+};
+
+&i2c35 {
+ status = "okay";
+};
+
+&i2c36 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+};
+
+&spi2 {
+ status = "okay";
+};
+
+&spi3 {
+ status = "okay";
+};
+
+&spi5 {
+ status = "okay";
+};
+
+&spi6 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&uart6 {
+ status = "okay";
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&uart8 {
+ status = "okay";
+};
+
+&usb2_0 {
+ status = "okay";
+};
+
+&usb2_1 {
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb3_1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/axiado/ax3005.dtsi b/arch/arm64/boot/dts/axiado/ax3005.dtsi
new file mode 100644
index 000000000000..3c2ce18082a9
--- /dev/null
+++ b/arch/arm64/boot/dts/axiado/ax3005.dtsi
@@ -0,0 +1,843 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2026 Axiado Corporation.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+/memreserve/ 0x80002fa0 0x00000008;
+/ {
+ model = "Axiado AX3005";
+ interrupt-parent = <&gic500>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80002fa0>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x1>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80002fa0>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ next-level-cache = <&l2>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x2>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80002fa0>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ next-level-cache = <&l2>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0 0x3>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80002fa0>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ cache-unified;
+ cache-size = <0x100000>;
+ cache-line-size = <64>;
+ cache-sets = <1024>;
+ cache-level = <2>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ clocks {
+ refclk: clock-125000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ pclk: clock-100000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ };
+
+ sysclk: clock-200000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <200000000>;
+ };
+
+ spiclk: clock-400000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <400000000>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&gic500>;
+ ranges;
+
+ gic500: interrupt-controller@40400000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x40400000 0x0 0x10000>,
+ <0x0 0x40500000 0x0 0xc0000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ #redistributor-regions = <1>;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ /* GPIO Controller banks 0 - 7 */
+ gpio0: gpio-controller@33000000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33000000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio1: gpio-controller@33080000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33080000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio2: gpio-controller@33100000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33100000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio3: gpio-controller@33180000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33180000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio4: gpio-controller@33200000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33200000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio5: gpio-controller@33280000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33280000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio6: gpio-controller@33300000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33300000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ gpio7: gpio-controller@33380000 {
+ compatible = "axiado,ax3000-gpio", "cdns,gpio-r1p02";
+ reg = <0x0 0x33380000 0x0 0x100>;
+ clocks = <&pclk>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@33000400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33000400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@33000800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33000800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@33080400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33080400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@33080800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33080800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@33100400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33100400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@33100800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33100800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c8: i2c@33200400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33200400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c9: i2c@33200800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33200800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c10: i2c@33280400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33280400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c11: i2c@33280800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33280800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i3c12: i3c@33300400 {
+ compatible = "axiado,ax3000-i3c", "cdns,i3c-master";
+ reg = <0x0 0x33300400 0x0 0x400>;
+ clock-names = "pclk", "sysclk";
+ clocks = <&pclk &sysclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ i2c-scl-hz = <100000>;
+ i3c-scl-hz = <400000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i3c13: i3c@33300800 {
+ compatible = "axiado,ax3000-i3c", "cdns,i3c-master";
+ reg = <0x0 0x33300800 0x0 0x400>;
+ clock-names = "pclk", "sysclk";
+ clocks = <&pclk &sysclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+ i2c-scl-hz = <100000>;
+ i3c-scl-hz = <400000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c14: i2c@33380400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33380400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c15: i2c@33380800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33380800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c16: i2c@33120400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33120400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c17: i2c@33021400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33021400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c18: i2c@33021800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33021800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c19: i2c@330c0400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x330c0400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c20: i2c@330c0800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x330c0800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c21: i2c@330c0c00 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x330c0c00 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c22: i2c@331a0800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x331a0800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c23: i2c@33302800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33302800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c24: i2c@33302c00 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33302c00 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c25: i2c@33303000 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33303000 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c26: i2c@33382000 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33382000 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c27: i2c@33382400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33382400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c28: i2c@33382800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33382800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c29: i2c@33382c00 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33382c00 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c30: i2c@33383000 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33383000 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c31: i2c@33383400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33383400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c32: i2c@33383800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33383800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c33: i2c@33282400 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33282400 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c34: i2c@33282800 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33282800 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c35: i2c@33282c00 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33282c00 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c36: i2c@33283000 {
+ compatible = "cdns,i2c-r1p14";
+ reg = <0x0 0x33283000 0x0 0x400>;
+ clocks = <&pclk>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi0: spi@33010000 {
+ compatible = "snps,dwc-ssi-1.01a";
+ reg = <0x0 0x33010000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&spiclk>;
+ num-cs = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ spi1: spi@33090000 {
+ compatible = "snps,dwc-ssi-1.01a";
+ reg = <0x0 0x33090000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&spiclk>;
+ num-cs = <1>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ spi2: spi@333c0000 {
+ compatible = "snps,dwc-ssi-1.01a";
+ reg = <0x0 0x333c0000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&spiclk>;
+ num-cs = <1>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ spi3: spi@330e0000 {
+ compatible = "snps,dwc-ssi-1.01a";
+ reg = <0x0 0x330e0000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&spiclk>;
+ num-cs = <1>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ spi5: spi@33390000 {
+ compatible = "snps,dwc-ssi-1.01a";
+ reg = <0x0 0x33390000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&spiclk>;
+ num-cs = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ spi6: spi@333a0000 {
+ compatible = "snps,dwc-ssi-1.01a";
+ reg = <0x0 0x333a0000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&spiclk>;
+ num-cs = <1>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart0: serial@33020000 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x33020000 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart1: serial@330a0000 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x330a0000 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart2: serial@33120000 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x33120000 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart3: serial@33020800 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x33020800 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart4: serial@331a0400 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x331a0400 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart5: serial@33381d00 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x33381d00 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart6: serial@33381e00 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x33381e00 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart7: serial@33381f00 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x33381f00 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ uart8: serial@330c0000 {
+ compatible = "axiado,ax3000-uart", "cdns,uart-r1p12";
+ reg = <0x0 0x330c0000 0x0 0x100>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "uart_clk", "pclk";
+ clocks = <&refclk &pclk>;
+ status = "disabled";
+ };
+
+ usb2_0: usb@41000000 {
+ compatible = "generic-xhci";
+ reg = <0x0 0x41000000 0x0 0x100000>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ usb2_1: usb@41100000 {
+ compatible = "generic-xhci";
+ reg = <0x0 0x41100000 0x0 0x100000>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ usb3_0: usb@41400000 {
+ compatible = "generic-xhci";
+ reg = <0x0 0x41400000 0x0 0x100000>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ usb3_1: usb@41500000 {
+ compatible = "generic-xhci";
+ reg = <0x0 0x41500000 0x0 0x100000>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: axiado: add AX3005 EVK
From: Swark Yang @ 2026-06-24 10:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah
Cc: devicetree, linux-arm-kernel, linux-kernel, Swark Yang
In-Reply-To: <20260624-upstream-axiado-ax3005-upstream-v1-0-c05bd0bc9124@axiado.com>
Add device tree binding schema for the Axiado AX3005 SoC and its
associated evaluation board. This binding will be used for the
board-level DTS files that support the AX3005 platforms.
Signed-off-by: Swark Yang <syang@axiado.com>
---
Documentation/devicetree/bindings/arm/axiado.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/axiado.yaml b/Documentation/devicetree/bindings/arm/axiado.yaml
index bfabe7b32e65..008d2b1d4e62 100644
--- a/Documentation/devicetree/bindings/arm/axiado.yaml
+++ b/Documentation/devicetree/bindings/arm/axiado.yaml
@@ -20,4 +20,10 @@ properties:
- axiado,ax3000-evk # Axiado AX3000 Evaluation Board
- const: axiado,ax3000 # Axiado AX3000 SoC
+ - description: AX3005 based boards
+ items:
+ - enum:
+ - axiado,ax3005-evk # Axiado AX3005 Evaluation Board
+ - const: axiado,ax3005 # Axiado AX3005 SoC
+
additionalProperties: true
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] arm64: Add Axiado AX3005 SoC and EVK support
From: Swark Yang @ 2026-06-24 10:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah
Cc: devicetree, linux-arm-kernel, linux-kernel, Swark Yang
This series adds initial device tree support for the Axiado AX3005 SoC
and its evaluation board (EVK).
The AX3005 uses Cadence-derived UART/I2C/I3C/GPIO and Synopsys
DesignWare SPI IP blocks. These are already described by
existing bindings, so the device tree reuses the "axiado,ax3000-*",
"cdns,*" and "snps,*" compatible strings; only a new SoC/board
level compatible is added.
Patch 1 adds the AX3005 board/SoC compatible strings to the Axiado
platform binding.
Patch 2 adds the AX3005 SoC dtsi, the EVK board dts, and the Makefile
entry. The EVK enables the CPUs, timer, GPIO, UART, I2C, I3C, SPI and
USB controllers.
Validated with:
- make CHECK_DTBS=y axiado/ax3005-evk.dtb
- make dt_binding_check DT_SCHEMA_FILES=axiado.yaml
- boot-tested on the AX3005 EVK (to init CLI via ramfs)
Signed-off-by: Swark Yang <syang@axiado.com>
---
Swark Yang (2):
dt-bindings: arm: axiado: add AX3005 EVK
arm64: dts: axiado: Add initial support for AX3005 SoC and eval board
Documentation/devicetree/bindings/arm/axiado.yaml | 6 +
arch/arm64/boot/dts/axiado/Makefile | 1 +
arch/arm64/boot/dts/axiado/ax3005-evk.dts | 327 +++++++++
arch/arm64/boot/dts/axiado/ax3005.dtsi | 843 ++++++++++++++++++++++
4 files changed, 1177 insertions(+)
---
base-commit: 2b414a95b8f7307d42173ba9e580d6d3e2bcbfce
change-id: 20260617-upstream-axiado-ax3005-upstream-bb09780a2fdf
Best regards,
--
Swark Yang <syang@axiado.com>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: sashiko-bot @ 2026-06-24 10:18 UTC (permalink / raw)
To: Jie Gan; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624-add-label-node-for-glymur-v1-1-87576107b999@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message incorrectly references the 'hamoa' device tree instead of 'glymur'.
--
commit 71aa487b99d4969110406291654e33f858011262
Author: Jie Gan <jie.gan@oss.qualcomm.com>
arm64: dts: qcom: glymur: Add label properties to CoreSight devices
This commit adds label properties to TPDM and CTI nodes to provide
human-readable identifiers for each CoreSight device.
> Add label properties to TPDM and CTI nodes in the hamoa device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
[Severity: Medium]
This isn't a bug, but the commit message explicitly states it is modifying
the "hamoa" device tree, while the patch subject and the actual modified
file (arch/arm64/boot/dts/qcom/glymur.dtsi) target "glymur". Could this
reference to "hamoa" be a copy-paste error from a similar patch?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-add-label-node-for-glymur-v1-1-87576107b999@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-06-24 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: dinguyen@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260624-infallible-diligent-bulldog-bcbab2@quoll>
On 24/6/2026 3:57 pm, Krzysztof Kozlowski wrote:
> On Tue, Jun 23, 2026 at 04:17:16AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> +
>> + psci {
>> + compatible = "arm,psci-0.2";
>> + method = "smc";
>> + };
>> +
>> + intc: interrupt-controller@7000000 {
>
> MMIO goes to MMIO, please read writing bindings and submitting patches docs in DT dir.
>
> I think this also fails tests (W=1). If that is true, then review should
> finish here, because instead of using machine to find issues you use
> community.
>
>> + compatible = "arm,gic-v3";
>> + reg = <0x0 0x7000000 0x0 0x10000>,
>> + <0x0 0x7080000 0x0 0x100000>;
>> + ranges;
>> + #interrupt-cells = <3>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + interrupt-controller;
>> + #redistributor-regions = <1>;
>> + redistributor-stride = <0x0 0x40000>;
>> +
>> + its: msi-controller@7040000 {
>> + compatible = "arm,gic-v3-its";
>> + reg = <0x0 0x7040000 0x0 0x20000>;
>> + msi-controller;
>> + #msi-cells = <1>;
>> + };
>> + };
>> +
>> + soc: soc@0 {
>> + compatible = "simple-bus";
>> + ranges = <0 0 0 0xffffffff>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> + interrupt-parent = <&intc>;
>> +
>> + smmu: iommu@c100000 {
>> + compatible = "arm,smmu-v3";
>> + reg = <0x0c100000 0x30000>;
>> + interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "eventq", "gerror", "priq";
>> + dma-coherent;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ocram: sram@0 {
>> + compatible = "mmio-sram";
>> + reg = <0x00000000 0x80000>;
>> + ranges = <0 0 0x80000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>
> SoC without any interface, serial or storage or network, is close to
> useless one.
>
> I don't see a point in having it in mainline. Serial is usually ABSOLUTE
> minimum.
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Thank you for the review and fast response!
I ran both dt_binding_check and dtbs_check (with CHECK_DTBS=y) locally —
both passed without errors. Could you clarify which specific test you
believe is failing?
Regarding "MMIO goes to MMIO" — are you referring to the GIC
(interrupt-controller@7000000) being placed at the root level instead of
under the soc bus node?
Regarding the serial console — the platform clock driver is not yet
upstream, so the UART depends on clkmgr. Would adding the UART with
clock-frequency be acceptable as an interim solution?
BR,
Nazim
^ permalink raw reply
* Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices
From: Krzysztof Kozlowski @ 2026-06-24 10:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Vishnu Reddy, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, Vikash Garodia, Robin Murphy, joro, will,
m.szyprowski, iommu, linux-kernel, dikshita.agarwal
In-Reply-To: <20260618151745.GD231643@ziepe.ca>
On 18/06/2026 17:17, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
>
>> Same with interrupt-map.
>
>> There are PCIe controller nodes which have interrupt-map and no
>> interrupts property ever uses them.
>
> PCIe is quite a different situation because we expect Linux to
> dynamically create the child nodes based on PCIe discovery, and the
> various maps are all searched based on the PCI BDF based on HW
> properties of real discovered child devices.
>
> Here they created "vpu_bus" and create a bunch of devices for some
> reason, but they are all hard coded in the driver. It is not a dynamic
> discovery, and it is not creating "real" child devices.
Yes, true.
>
>> Because DT person - me - told that creating child device nodes just to
>> configure iommus is abuse of DT. There are no child devices in terms of
>> hardware or firmware. The iommu ranges here are no real hardware.
>
> That doesn't seem to be what Vishnu is saying. Review the earlier two
> emails explaining what the HW issue is here:
>
> https://lore.kernel.org/all/bb59f07e-ca7e-f012-6a4b-0a148350b69c@oss.qualcomm.com/
> https://lore.kernel.org/all/cb37e7cc-4fb0-4c24-8f89-f6f9eb08a107@oss.qualcomm.com/
>
> The VPU HW diagram with different IOVA requirements for different
> stream IDs seems to be an entirely HW based thing: "each context bank
> enforces a different IOVA range"
>
> The original patches just created a 0 based IOVA space per stream and
> justified that by increasing the IOVA address space (make sense). The
> email above now says some of the streams only function with a limited
> range of IOVA because the HW uses the IOVA itself to select the
> streams (insane!)
>
> IOW this entire device is completely mis-designed if it is going to
> easially support the Linux DMA API :( That's all HW mess, which is
> motivating hacks to try to make the Linux DMA API do something usable
> by this device.
>
> Anyhow..
>
> In Linux if you use DT iommus the SW sets things up so every stream
> shares the same translation. If your driver/device doesn't like that
> there is no SW way to opt out of sharing. I think that is the first
> core issue that VPU was struggling with.
>
> If you have one "device" then I would argue the DT should describe all
> its streams using iommus in the normal way. The introduction of
> iommu-map for VPU is only being done because that is a convenient hack
> to allow Linux to unbundle the streams. It would be much harder to
> unbunble the streams directly from the DT iommus property, but that
> would probably be the cleanest, software agnostic, DT modeling.
>
> So, if we are going to do a hack in DT to accomodate Linux, I argue to
> choose explicit child devices so VPU does not need to create a special
> bus, call of_dma_configue, or hack in new DMA API things that only it
> will ever use. Then the explicit children can properly describe how
> the HW decodes IOVA into each streams in the DT (which sounds very
> much like a HW property to me) so that Linux produces IOVA that the HW
> mangling properly routes to the expected stream.
>
> Then the VPU driver just has to assemble itself from many struct
> devices, which I admit is also a troublesome task.
>
>> However, said all this, since I pushed folks to come with the iommu-map
>> approach, I will revoke my disagreement to child device nodes in DT, if
>> you really believe that is the approach. IOW, I will agree to device
>> nodes in DT representing fake hardware-children, just for the sake of
>> Linux driver model limitations.
>
> I would wait for Robin, he knows this better, but I belive this was
> broadly his point in the original email..
Thanks Jason for context and detailed arguments. Robin did not chime in
yet, but from what I understood the DT-child-node approach will be the
way we should go here.
I accept above point of view and I am fine with this, thus Vishnu and
Vikash - please go ahead with DT-child-node solution we had some time ago.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Jie Luo @ 2026-06-24 10:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R,
linux-kernel, linux-arm-msm, linux-clk, devicetree, netdev,
Kiran Kumar C.S.K, quic_linchen
In-Reply-To: <7095f7ba-bacb-4d03-89cf-ed43882d8213@lunn.ch>
On 6/23/2026 7:31 PM, Andrew Lunn wrote:
> On Tue, Jun 23, 2026 at 05:42:34PM +0800, Jie Luo wrote:
>>
>>
>> On 6/23/2026 4:10 PM, Andrew Lunn wrote:
>>>> Driver is not supported - in terms of how netdev understands supported
>>>> commitment - if maintainer does not care to receive the patches for its
>>>> code, so demote it to "maintained" to reflect true status.
>>>
>>> Maybe "Orphan" would be better, if the listed Maintainer is not doing
>>> any Maintainer work?
>>>
>>> Andrew
>>
>> Hello Andrew, Krzysztof,
>> I will continue to maintain the listed drivers, so their status can
>> remain Supported.
>
> Please understand that being a Maintainer requires that you respond to
> patches and questions about this driver, give Reviewed-by:, ask for
> patches to be changed etc. If you don't respond, ideally with 2 to 3
> days, the driver will be set to Orphaned.
>
> If you want to maintain the Supported status, we can help you set up
> the needed CI system, and get it registered so it reports the results.
>
> Andrew
Thank you Andrew, Krzysztof, for the clarification on what "Supported"
status entails and for the offer to help with CI setup. I would very
much appreciate the community's help in getting the CI system set up
and registered for this driver. In the mean time we will also look at
resources internally within Qualcomm, to understand how to support
testing using kernelCI/netdevCI for IPQ SoC. This will help us test
the driver continuously as well.
I fully understand and accept the maintainer responsibilities for this
driver, and commit to the below:
- Responding to patches and questions in a timely manner.
- Providing review comments and requesting changes where appropriate,
and providing Reviewed-by tags when needed.
I would also like to take a moment to provide an update on our current
efforts for IPQ SoC, if it can be of help. We have already re-started
our efforts for the drivers and are currently actively working to extend
the IPQ drivers to support more functionality and for newer SoC support
for same family. We plan to post these updates to the current drivers
once the review window reopens.
We feel maintaining the "Supported" status is appropriate and reflects
our genuine long-term commitment to IPQ SoC networking drivers in Linux
kernel. We request you to retain the current status for this driver if
acceptable.
Regarding the email ID change, we had attempted to rectify the
MAINTAINERS file a few months ago based on recommendation given
internally (please see below thread), however agree that such an update
in documentation is also required.
https://lore.kernel.org/all/20250903-maintainer_update-v1-1-2183fd2a3c44@oss.qualcomm.com/
^ permalink raw reply
* [PATCH] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: Jie Gan @ 2026-06-24 10:09 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
Add label properties to TPDM and CTI nodes in the hamoa device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..27cc30de940e 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5770,6 +5770,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -5834,6 +5835,7 @@ tpdm@1102c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -5852,6 +5854,7 @@ tpdm@11180000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -5871,6 +5874,7 @@ tpdm@11185000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -5890,6 +5894,7 @@ tpdm@11186000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6010,6 +6015,7 @@ cti@11193000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp";
};
cti_wpss: cti@111ab000 {
@@ -6018,6 +6024,7 @@ cti_wpss: cti@111ab000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_wpss";
};
tpdm@111d0000 {
@@ -6026,6 +6033,7 @@ tpdm@111d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-msrs-num = <32>;
@@ -6201,6 +6209,7 @@ tpdm@11207000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6219,6 +6228,7 @@ tpdm@1120b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_east_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6237,6 +6247,7 @@ tpdm@11213000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_west_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6255,6 +6266,7 @@ tpdm@11219000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6273,6 +6285,7 @@ tpdm@1121a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-msrs-num = <32>;
@@ -6291,6 +6304,7 @@ tpdm@1121b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qrng";
qcom,cmb-msrs-num = <32>;
@@ -6309,6 +6323,7 @@ tpdm@1121c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,dsb-msrs-num = <32>;
@@ -6327,6 +6342,7 @@ tpdm@1121d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cx";
qcom,cmb-msrs-num = <32>;
@@ -6345,6 +6361,7 @@ tpdm@1121e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxc";
qcom,cmb-msrs-num = <32>;
@@ -6363,6 +6380,7 @@ tpdm@1121f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxa";
qcom,cmb-msrs-num = <32>;
@@ -6381,6 +6399,7 @@ tpdm@11220000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center_dsb_1";
qcom,dsb-msrs-num = <32>;
@@ -6399,6 +6418,7 @@ tpdm@11224000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south2_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6417,6 +6437,7 @@ tpdm@11228000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6435,6 +6456,7 @@ tpdm@11470000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pcie_rscc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -6478,6 +6500,7 @@ tpdm@11c03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_4";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6656,6 +6679,7 @@ tpdm@11c09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6675,6 +6699,7 @@ tpdm@11c0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6694,6 +6719,7 @@ tpdm@11c0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6713,6 +6739,7 @@ tpdm@11c0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6732,6 +6759,7 @@ tpdm@11c0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-add-label-node-for-glymur-1ba59f479870
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-24 10:05 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <be2b54a5-ce9d-49a2-80e1-60da874350d9@oss.qualcomm.com>
On 24/06/2026 09:20, Fenglin Wu wrote:
>
> On 6/17/2026 6:42 PM, Krzysztof Kozlowski wrote:
>> On Tue, Jun 16, 2026 at 03:08:23AM -0700, Fenglin Wu wrote:
>>
>> Here - the first sentence - is where you mention merging
>> constraints/strategy/dependencies. Your MFD patch depends on ealier
>> ones.
>>
> Did you mean that these 2 MFD binding changes should be listed as the
> dependency of the MFD patch?
No. Act as maintainer. Clone Linus tree, apply the patch and see if
everything works. My claim is that nothing works and maintainer tree is
broken.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Daniel Thompson @ 2026-06-24 10:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-15-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:31AM +0300, Svyatoslav Ryhel wrote:
> Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> defined in the device tree.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox