* Re: [PATCH v4 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: sashiko-bot @ 2026-06-16 10:04 UTC (permalink / raw)
To: Akhil R; +Cc: linux-hwmon, conor+dt, robh, devicetree, Frank.Li, linux-i3c
In-Reply-To: <20260616095429.3947205-2-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
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=1
^ permalink raw reply
* Re: [PATCH 3/4] iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel
From: Nuno Sá @ 2026-06-16 10:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Lechner (TI), Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <ajECNvjntVg_GjwR@ashevche-desk.local>
On Tue, Jun 16, 2026 at 10:58:46AM +0300, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 05:00:01PM -0500, David Lechner (TI) wrote:
> > Implement support for the programmable gain amplifier on the internal
> > short SYS_MON channel. This channel is used for calibration, so it is
> > useful to be able to set the PGA to the same gain as the external
> > channels. The gain setting is implemented via the `_scale` attribute.
> >
> > In the future, we may want to support different reference voltages for
> > this channel, so the scale_available table is populated during probe
> > rather than being a static table.
>
...
> > +
> > + for (i = 0; i < ARRAY_SIZE(ads112c14_pga_gains_x10); i++) {
> > + int *scale_avail = &data->sys_mon_chan_short_scale_available[i][0];
> > + u32 gain_x10 = ads112c14_pga_gains_x10[i];
> > +
> > + /* NB: slightly odd arrangement to avoid overflow. */
> > + scale_avail[0] = div_u64_rem(div_u64((u64)NANO * 10 /
> > + (MICRO / MILLI) * vref_uV /
> > + gain_x10,
> > + BIT(fsr_bits)),
> > + NANO, &scale_avail[1]);
>
> Oh, what about temporary variable for the inner division? Also note one trick
> to avoid casting (and making it shorter).
>
> u64 foo;
>
> foo = div_u64(10ULL * NANO / (MICRO / MILLI) * vref_uV / gain_x10, BIT(fsr_bits));
>
> /* NB: slightly odd arrangement to avoid overflow. */
> scale_avail[0] = div_u64_rem(foo, NANO, &scale_avail[1]);
>
> Now, with much more readability, it's visible that the first division is just a right shift.
>
> u64 foo;
>
> /* ...a comment to explain voodoo calculations... */
> foo = (10ULL * NANO / (MICRO / MILLI) * vref_uV / gain_x10) >> fsr_bits;
Did not looked enough time but also looks like maybe mul_u64_u32_shr()
could be used? And given that it handles things nicely (even uses 128bit
when possible), might open the door for more simplifications.
Anyways, agree with Andy that in the current patch it's a bit of a pain
to the eyes :).
- Nuno Sá
>
> scale_avail[0] = div_u64_rem(foo, NANO, &scale_avail[1]);
>
> > + }
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v9 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Konrad Dybcio @ 2026-06-16 10:01 UTC (permalink / raw)
To: Stanislav Zaikin, devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, dmitry.baryshkov
In-Reply-To: <20260608143329.252033-3-zstaseg@gmail.com>
On 6/8/26 4:33 PM, Stanislav Zaikin wrote:
> Xiaomi 12 Lite 5G is a handset released in 2022
>
> This commit has the following features working:
> - Display (with simple fb)
> - Touchscreen
> - UFS
> - Power and volume buttons
> - Pinctrl
> - RPM Regulators
> - Remoteprocs - wifi, bluetooth
> - USB (Device Mode)
>
> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
> ---
[...]
> +&ipa {
> + firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
> +
> + status = "okay";
> +};
From make dtbs_check:
qcom/sm7325-xiaomi-taoyao.dtb: ipa@1e40000 (qcom,sc7280-ipa): 'memory-region' is a required property
Please fix that (or disable IPA)
Otherwise:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Joey Lu @ 2026-06-16 10:01 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Hui-Ping Chen, Neil Armstrong, Conor Dooley, Vinod Koul,
devicetree, Catalin Marinas, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel, Joey Lu, Jacky Huang,
Arnd Bergmann, linux-phy, Shan-Chun Hung
In-Reply-To: <178153082322.1456470.14205688450934768854.robh@kernel.org>
On 6/15/2026 9:40 PM, Rob Herring (Arm) wrote:
> On Mon, 15 Jun 2026 13:49:09 +0800, Joey Lu wrote:
>> The MA35D1 has two USB PHY ports managed by the same hardware block:
>>
>> - PHY0 (index 0): OTG port shared between the DWC2 gadget controller
>> and EHCI0/OHCI0 host controllers. A hardware mux follows the USB
>> ID pin automatically.
>>
>> - PHY1 (index 1): dedicated host-only port for EHCI1/OHCI1.
>>
>> Extend the existing binding to cover both ports:
>>
>> - The PHY node is now a child of the system-management syscon node
>> with a reg property. The nuvoton,sys phandle and clocks
>> properties are removed; the driver derives the regmap from its
>> parent, and clock gating is owned by each individual USB controller.
>>
>> - #phy-cells changes from 0 to 1: the cell selects the PHY port.
>>
>> - Two optional board-tuning properties are added: nuvoton,rcalcode
>> for per-port resistor trim and nuvoton,oc-active-high for
>> over-current polarity.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> .../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 ++++++++++++++-----
>> 1 file changed, 48 insertions(+), 14 deletions(-)
>>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): '#address-cells', '#size-cells', 'usb-phy@60' do not match any of the regexes: '^pinctrl-[0-9]+$'
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): compatible: ['nuvoton,ma35d1-reset', 'syscon', 'simple-mfd'] is too long
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): reg: [[0, 1078329344], [0, 512]] is too long
> from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260615054911.48821-2-a0987203069@gmail.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
I will fix it.
^ permalink raw reply
* [PATCH v4 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 v4 11/12] hwmon: spd5118: Add I3C support
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 v4 10/12] hwmon: spd5118: Remove 16-bit addressing
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 v4 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 a2a4b88c2017..fbe8dca22f07 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -1856,11 +1856,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,
@@ -1869,7 +1870,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 v4 08/12] i3c: dw-i3c-master: Add a quirk to skip clock and reset
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-1-akhilrajeev@nvidia.com>
Some ACPI-enumerated devices like Tegra410 do not have clock and reset
resources exposed via the clk/reset frameworks. Unlike device tree,
ACPI on Arm does not model such provider functions. The hardware is
expected to be brought out of reset and have its clocks enabled by the
firmware before the OS takes over. Any data to be shared with the OS is
passed using the _DSD property.
Add match data for such devices to skip acquiring clock and reset controls
during probe and read the clock rate from the "clock-frequency" _DSD
property. Note that the "clock-frequency" here is the controller's core
clock and not the bus speed. I3C specifies the bus speed separately using
"i3c-scl-hz" and "i2c-scl-hz" and hence this should not cause any conflict.
Also, move match data parsing before clock/reset acquisition so the quirk
is available early enough.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master/dw-i3c-master.c | 66 ++++++++++++++++++++----------
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 3e510fddf06c..a2a4b88c2017 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,28 @@ 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->quirks & DW_I3C_ACPI_SKIP_CLK_RST))
+ return clk_get_rate(master->core_clk);
+
+ 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 +631,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,18 +1593,33 @@ 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);
- if (IS_ERR(master->core_clk))
- return PTR_ERR(master->core_clk);
-
- master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
- if (IS_ERR(master->pclk))
- return PTR_ERR(master->pclk);
+ if (has_acpi_companion(&pdev->dev)) {
+ quirks = (unsigned long)device_get_match_data(&pdev->dev);
+ } else if (pdev->dev.of_node) {
+ drvdata = device_get_match_data(&pdev->dev);
+ if (drvdata)
+ quirks = drvdata->flags;
+ }
+ master->quirks = quirks;
- master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
- "core_rst");
- if (IS_ERR(master->core_rst))
- return PTR_ERR(master->core_rst);
+ if (master->quirks & DW_I3C_ACPI_SKIP_CLK_RST) {
+ master->core_clk = NULL;
+ master->pclk = NULL;
+ master->core_rst = NULL;
+ } else {
+ master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
+ if (IS_ERR(master->core_clk))
+ return PTR_ERR(master->core_clk);
+
+ master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
+ if (IS_ERR(master->pclk))
+ return PTR_ERR(master->pclk);
+
+ master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
+ "core_rst");
+ if (IS_ERR(master->core_rst))
+ return PTR_ERR(master->core_rst);
+ }
spin_lock_init(&master->xferqueue.lock);
INIT_LIST_HEAD(&master->xferqueue.list);
@@ -1636,15 +1667,6 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
master->has_ibi_data = true;
writel(thld_ctrl, master->regs + QUEUE_THLD_CTRL);
- if (has_acpi_companion(&pdev->dev)) {
- quirks = (unsigned long)device_get_match_data(&pdev->dev);
- } else if (pdev->dev.of_node) {
- drvdata = device_get_match_data(&pdev->dev);
- if (drvdata)
- quirks = drvdata->flags;
- }
- master->quirks = quirks;
-
/* Keep controller enabled by preventing runtime suspend */
if (master->quirks & DW_I3C_DISABLE_RUNTIME_PM_QUIRK)
pm_runtime_get_noresume(&pdev->dev);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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.
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 971b429b76bc..3e510fddf06c 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 v4 06/12] i3c: master: match I3C device through DT and ACPI
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 be matched through Device Tree or ACPI.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index bcc9c2d29c34..1bd545447b81 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>
@@ -345,15 +346,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 v4 05/12] i3c: master: Add support for devices without PID
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 557332d93257..bcc9c2d29c34 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1963,8 +1963,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,
@@ -2357,8 +2366,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;
@@ -2372,8 +2391,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;
}
@@ -2804,9 +2827,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);
@@ -2829,10 +2858,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 v4 04/12] i3c: master: Add support for devices using SETAASA
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 f0e05bcac26d..557332d93257 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>
@@ -1092,6 +1093,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
@@ -1852,6 +1898,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(i3cdev, 0);
+ if (ret)
+ goto err_detach_dev;
+
+ return 0;
+ }
+
ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
i3cdev->boardinfo->init_dyn_addr);
if (ret)
@@ -2206,6 +2268,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.
@@ -2696,7 +2764,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)
@@ -2714,7 +2782,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;
@@ -2724,6 +2799,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)) ||
@@ -3358,6 +3436,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 22b10cff476c..9323b6af051c 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 v4 03/12] i3c: master: Support ACPI enumeration of child devices
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
drivers/i3c/master.c | 149 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 141 insertions(+), 8 deletions(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 3b19a5e8f46d..f0e05bcac26d 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>
@@ -2596,6 +2597,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)
@@ -2612,6 +2662,13 @@ 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)
+ return ret;
} else {
return -EINVAL;
}
@@ -2626,9 +2683,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);
@@ -2683,8 +2737,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;
@@ -2708,6 +2762,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;
@@ -2719,7 +2841,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;
}
@@ -2787,8 +2915,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 v4 02/12] i3c: master: Use unified device property interface
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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 109aa50eb1f8..3b19a5e8f46d 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) {
@@ -827,7 +829,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 = {
@@ -1034,7 +1036,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);
}
@@ -1902,7 +1904,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) {
@@ -2594,8 +2597,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;
@@ -2605,9 +2608,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
@@ -2623,14 +2630,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;
@@ -2653,7 +2660,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;
@@ -2670,14 +2677,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;
@@ -2685,7 +2692,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;
@@ -2694,25 +2701,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;
}
@@ -2722,10 +2729,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;
@@ -2780,7 +2787,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;
@@ -2899,7 +2906,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;
@@ -2908,7 +2916,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);
@@ -3209,7 +3219,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;
@@ -3228,13 +3238,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 f73cede87d36..22b10cff476c 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 v4 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Akhil R @ 2026-06-16 9:54 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: <20260616095429.3947205-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
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 v4 00/12] Support ACPI and SETAASA device discovery
From: Akhil R @ 2026-06-16 9:54 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.
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 a quirk to skip clock and reset
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 | 371 +++++++++++++++---
drivers/i3c/master/dw-i3c-master.c | 75 ++--
include/dt-bindings/i3c/i3c.h | 4 +
include/linux/i3c/ccc.h | 1 +
include/linux/i3c/master.h | 20 +-
9 files changed, 485 insertions(+), 153 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Enable cameras
From: Hongyang Zhao @ 2026-06-16 7:29 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rosh, Hongyang Zhao
Enable the two Raspberry Pi camera connectors on RubikPi 3 with
IMX219 sensors. CAM1 is connected to CCI1 and CSIPHY1, while CAM2
is connected to CCI0 and CSIPHY4.
Add the shared 24 MHz camera oscillator, camera power enable
regulators, CAMSS endpoints, CCI sensor nodes and privacy LED GPIOs.
Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com>
---
Enable the two Raspberry Pi camera connectors on Thundercomm RUBIK Pi 3.
Both connectors are populated with IMX219 camera modules.
CAM1 is wired to CCI1 and CSIPHY1, while CAM2 is wired to CCI0 and
CSIPHY4. Add the fixed 24 MHz camera oscillator, camera power enable
regulators, CAMSS endpoints, CCI sensor nodes, and the privacy LED GPIOs.
The cameras were validated on RUBIK Pi 3 with two IMX219 modules. Both
sensors enumerate through CAMSS and can capture 3280x2464 RGGB frames. The
privacy LEDs are also toggled by the V4L2 subdev privacy LED support while
streaming.
---
.../boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 204 +++++++++++++++++++++
1 file changed, 204 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
index f47efca42d48..280ce9316f50 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
@@ -47,6 +47,12 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ cam_osc_24m: clock-24000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -61,6 +67,27 @@ key-volume-up {
};
};
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ pinctrl-0 = <&cam1_privacy_led_state>, <&cam2_privacy_led_state>;
+ pinctrl-names = "default";
+
+ cam1_privacy_led: led-camera1 {
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <1>;
+ gpios = <&tlmm 18 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cam2_privacy_led: led-camera2 {
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <2>;
+ gpios = <&tlmm 19 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
hdmi-connector {
compatible = "hdmi-connector";
type = "a";
@@ -128,6 +155,38 @@ fan0: pwm-fan {
pinctrl-names = "default";
};
+ vreg_cam1_pwr: regulator-camera1-pwr {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg_camera1_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 57 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam1_pwr_en>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_vcc3v3_output>;
+ };
+
+ vreg_cam2_pwr: regulator-camera2-pwr {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg_camera2_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam2_pwr_en>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_vcc3v3_output>;
+ };
+
vreg_eth_1v8: regulator-eth-1v8 {
compatible = "regulator-fixed";
@@ -214,6 +273,23 @@ vreg_usbhub_rest_1v8: regulator-usbhub-rest-1v8 {
regulator-boot-on;
};
+ vreg_vcc3v3_output: regulator-vcc3v3-output {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vcc3v3_output";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&vcc3v3_output_en>;
+ pinctrl-names = "default";
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vph_pwr: regulator-vph-pwr {
compatible = "regulator-fixed";
@@ -694,6 +770,94 @@ vreg_bob_3p296: bob {
};
};
+&camss {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CAM1 is routed to CSI1 / CSIPHY1. */
+ port@1 {
+ reg = <1>;
+
+ csiphy1_ep: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&cam1_imx219_ep>;
+ };
+ };
+
+ /* CAM2 is routed to CSI4 / CSIPHY4. */
+ port@4 {
+ reg = <4>;
+
+ csiphy4_ep: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&cam2_imx219_ep>;
+ };
+ };
+ };
+};
+
+&cci0 {
+ status = "okay";
+};
+
+&cci0_i2c0 {
+ cam2_imx219: camera@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+
+ clocks = <&cam_osc_24m>;
+
+ VANA-supply = <&vreg_cam2_pwr>;
+ VDIG-supply = <&vreg_l18b_1p8>;
+ VDDL-supply = <&vreg_cam2_pwr>;
+
+ leds = <&cam2_privacy_led>;
+ led-names = "privacy";
+
+ port {
+ cam2_imx219_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <456000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c0 {
+ cam1_imx219: camera@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+
+ clocks = <&cam_osc_24m>;
+
+ VANA-supply = <&vreg_cam1_pwr>;
+ VDIG-supply = <&vreg_l18b_1p8>;
+ VDDL-supply = <&vreg_cam1_pwr>;
+
+ leds = <&cam1_privacy_led>;
+ led-names = "privacy";
+
+ port {
+ cam1_imx219_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <456000000>;
+ remote-endpoint = <&csiphy1_ep>;
+ };
+ };
+ };
+};
+
&gcc {
protected-clocks = <GCC_CFG_NOC_LPASS_CLK>,
<GCC_MSS_CFG_AHB_CLK>,
@@ -1243,6 +1407,14 @@ usb_eth_power: usb-eth-power-state {
bias-disable;
};
+ vcc3v3_output_en: vcc3v3-output-en-state {
+ pins = "gpio14";
+ function = "gpio";
+ drive-strength = <8>;
+ output-high;
+ bias-disable;
+ };
+
wifi_reset_active: wifi-reset-active-state {
pins = "gpio16";
function = "gpio";
@@ -1258,6 +1430,22 @@ bt_reset: bt-reset-state {
bias-disable;
};
+ cam1_privacy_led_state: cam1-privacy-led-state {
+ pins = "gpio18";
+ function = "gpio";
+ drive-strength = <8>;
+ output-low;
+ bias-disable;
+ };
+
+ cam2_privacy_led_state: cam2-privacy-led-state {
+ pins = "gpio19";
+ function = "gpio";
+ drive-strength = <8>;
+ output-low;
+ bias-disable;
+ };
+
lt9611_irq_pin: lt9611-irq-state {
pins = "gpio20";
function = "gpio";
@@ -1358,6 +1546,22 @@ m2_vcc_pin: m2-vcc-state {
input-disable;
};
+ cam1_pwr_en: cam1-pwr-en-state {
+ pins = "gpio57";
+ function = "gpio";
+ drive-strength = <8>;
+ output-low;
+ bias-disable;
+ };
+
+ cam2_pwr_en: cam2-pwr-en-state {
+ pins = "gpio58";
+ function = "gpio";
+ drive-strength = <8>;
+ output-low;
+ bias-disable;
+ };
+
lt9611_vcc_pin: lt9611-vcc-pin-state {
pins = "gpio83";
function = "gpio";
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260616-rubikpi-next-20260615-462417aa865a
Best regards,
--
Hongyang Zhao <hongyang.zhao@thundersoft.com>
^ permalink raw reply related
* Re: [PATCH 07/23] driver core: platform: provide platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-06-16 9:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, linux-kernel, netdev,
linux-arm-msm, linux-sound, driver-core, devicetree, linuxppc-dev,
linux-i2c, iommu, linux-pm, imx, linux-arm-kernel, intel-xe,
dri-devel, linux-usb, linux-mips, platform-driver-x86,
Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <ajEcDq0S067wMFaK@black.igk.intel.com>
On Tue, 16 Jun 2026 11:49:02 +0200, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Thu, Jun 04, 2026 at 05:32:27AM -0700, Bartosz Golaszewski wrote:
>> On Tue, 2 Jun 2026 23:41:53 +0200, Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> said:
>> > On Thu, May 21, 2026 at 10:36:30AM +0200, Bartosz Golaszewski wrote:
>> >> Provide a helper function encapsulating the logic of assigning firmware
>> >> nodes to platform devices created with platform_device_alloc(). Make the
>> >> kerneldoc state that this is the proper interface for assigning firmware
>> >> nodes to dynamically allocated platform devices. This will allow us to
>> >> switch to counting the references of the device's firmware nodes in the
>> >> future, not only the OF nodes.
>> >
>> > But why different for of_node and fwnode to begin with?!
>>
>> I'm not following. What are you suggesting?
>
> After re-reading of this thread, I think I'm suggesting the same what you have
> in plans to do in the future as you put it as "This will allow us to switch to
> counting the references of the device's firmware nodes in the future, not only
> the OF nodes."
>
> // Offtopic
> I haven't heard from you for more than a month on this:
> https://lore.kernel.org/r/af18zdP5HF3_P9Vo@black.igk.intel.com
> Anything should I do? Please, answer to that thread.
>
Eek, sorry, must have flown under the radar.
I'll pull it now, I will do a second PR for this merge window anyway.
Bart
^ permalink raw reply
* Re: [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Konrad Dybcio @ 2026-06-16 9:50 UTC (permalink / raw)
To: Mohd Ayaan Anwar, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bjorn Andersson, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260612-shikra_ethernet-v1-8-f0f4a1d19929@oss.qualcomm.com>
On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
> Enable the first Gigabit Ethernet controller. The board layout is
> identical to the CQM EVK.
>
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 119 ++++++++++++++++++++++++++++
> 1 file changed, 119 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> index 26ff8007a819e46bbc9ffa3dddc6fee6530a4a7a..1f2e4f6dd7cca436f62ba9f09cd328e5a2079095 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -7,6 +7,7 @@
>
> #include "shikra-cqm-som.dtsi"
> #include "shikra-evk.dtsi"
> +#include <dt-bindings/net/ti-dp83867.h>
>
> / {
> model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
> @@ -60,6 +61,92 @@ vreg_pmu_ch1: ldo4 {
> };
> };
>
> +ðernet0 {
> + status = "okay";
'status' should go last, with a \n before it
> + phy-handle = <ðphy0>;
> + phy-mode = "rgmii-id";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet0_defaults>;
property-n
property-names
in this order, please
[...]
> +&tlmm {
> + ethernet0_defaults: ethernet0-defaults-state {
s/defaults/default
Please move this definition to shikra.dtsi
> + rgmii-rx-pins {
> + pins = "gpio121", "gpio122", "gpio123",
> + "gpio124", "gpio125", "gpio126";
> + function = "rgmii";
> + bias-disable;
> + drive-strength = <16>;
Let's move drive-strength before bias (that's the order used in other
places)
> + };
> + rgmii-tx-pins {
Please separate subsequent subnodes with \n
> + pins = "gpio127", "gpio128", "gpio129",
> + "gpio130", "gpio131", "gpio132";
> + function = "rgmii";
> + bias-pull-up;
> + drive-strength = <16>;
> + };
> + rgmii-mdio-pins {
> + pins = "gpio133", "gpio134";
> + function = "rgmii";
> + bias-pull-up;
> + drive-strength = <16>;
> + };
> + };
> +
> + emac0_phy_en_hog: emac0-phy-en-hog {
> + gpio-hog;
> + gpios = <149 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "emac0-phy-en";
> + };
This looks like a hack - what does this pin actually do?
Konrad
^ permalink raw reply
* Re: [PATCH 07/23] driver core: platform: provide platform_device_set_fwnode()
From: Andy Shevchenko @ 2026-06-16 9:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, linux-kernel, netdev,
linux-arm-msm, linux-sound, driver-core, devicetree, linuxppc-dev,
linux-i2c, iommu, linux-pm, imx, linux-arm-kernel, intel-xe,
dri-devel, linux-usb, linux-mips, platform-driver-x86,
Bartosz Golaszewski
In-Reply-To: <CAMRc=McLN9Ovoqo3om-3uC=q+=rcKCoiWMctC=yvwiaHacU0PQ@mail.gmail.com>
On Thu, Jun 04, 2026 at 05:32:27AM -0700, Bartosz Golaszewski wrote:
> On Tue, 2 Jun 2026 23:41:53 +0200, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Thu, May 21, 2026 at 10:36:30AM +0200, Bartosz Golaszewski wrote:
> >> Provide a helper function encapsulating the logic of assigning firmware
> >> nodes to platform devices created with platform_device_alloc(). Make the
> >> kerneldoc state that this is the proper interface for assigning firmware
> >> nodes to dynamically allocated platform devices. This will allow us to
> >> switch to counting the references of the device's firmware nodes in the
> >> future, not only the OF nodes.
> >
> > But why different for of_node and fwnode to begin with?!
>
> I'm not following. What are you suggesting?
After re-reading of this thread, I think I'm suggesting the same what you have
in plans to do in the future as you put it as "This will allow us to switch to
counting the references of the device's firmware nodes in the future, not only
the OF nodes."
// Offtopic
I haven't heard from you for more than a month on this:
https://lore.kernel.org/r/af18zdP5HF3_P9Vo@black.igk.intel.com
Anything should I do? Please, answer to that thread.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/3] powercap: qcom: Add SPEL powercap driver
From: Konrad Dybcio @ 2026-06-16 9:45 UTC (permalink / raw)
To: Daniel Lezcano, Manaf Meethalavalappu Pallikunhi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm, Gaurav Kohli
In-Reply-To: <c85b658c-ea61-4d34-8327-2a0be2618611@oss.qualcomm.com>
On 6/15/26 2:07 PM, Daniel Lezcano wrote:
> Hi Konrad,
>
> Le 09/06/2026 à 15:31, Konrad Dybcio a écrit :
>> On 6/9/26 3:23 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>> Hi Konrad,
>>>
>>>
>>> On 5/21/2026 4:46 PM, Konrad Dybcio wrote:
>>>> On 5/19/26 12:49 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>>>> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
>>>>> based power monitoring and limiting capabilities for various power
>>>>> domains including System, SoC, CPU clusters, GPU, and various other
>>>>> subsystems.
>>>>>
>>>>> The driver integrates with the Linux powercap framework, exposing SPEL
>>>>> capabilities through powercap sysfs interfaces.
>>>>>
>>>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>>>>> ---
>>
>> [...]
>>
>>>>> +static void spel_remove(struct platform_device *pdev)
>>>>> +{
>>>>> + struct spel_system *sp = platform_get_drvdata(pdev);
>>>>> + int i;
>>>>> +
>>>>> + if (!sp)
>>>>> + return;
>>>>> +
>>>>> + /* Unregister in reverse order: children first, then SOC, then SYS */
>>>>> + for (i = SPEL_DOMAIN_MAX - 1; i >= 0; i--)
>>>>> + powercap_unregister_zone(sp->control_type, &sp->domains[i].power_zone);
>>>>
>>>> Could you try adding a devm_ variant of these register functions?
>>>
>>> Powercap framework doesn't support any devm_* API, you meant add this support in framework in this series ?
>>
>> Yes, this should be fairly trivial - look at e.g.
>>
>> drivers/regulator/devres.c : devm_of_regulator_get
>
> Given how structured is the powercap framework, I'm not sure it is so trivial. May be it is, but I doubt.
>
> I don't think it is worth to investigate adding devm_ variant now (for a few lines saved) and diverge from the objective of this series
Might as well be, looks like the powercap zones are "namespaced" inside
powercap controllers, so it's not that trivial
Konrad
^ permalink raw reply
* Re: [PATCH v3 6/8] pinctrl: qcom: Acknowledge IRQs for PDC interrupt controller
From: sashiko-bot @ 2026-06-16 9:45 UTC (permalink / raw)
To: Maulik Shah; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260616-hamoa_pdc_v3-v3-6-4d8e1504ea75@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch adds `IRQCHIP_EOI_THREADED` to `msm_gpio_irq_chip.flags`, which alters the EOI timing for all threaded interrupts, but this functional change is completely undocumented in the commit message.
--
commit c69ba699fb1e70baa301113c62200fca65540992
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
pinctrl: qcom: Acknowledge IRQs for PDC interrupt controller
This commit updates the MSM GPIO driver to properly acknowledge incoming
GPIO interrupts for the PDC interrupt controller. For edge-triggered IRQs,
it uses handle_fasteoi_ack_irq() as the IRQ handler and forwards the
irq_ack() callback to the parent IRQ chip.
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 11db6564c44df..17665e1a9dbcb 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
[ ... ]
> @@ -1395,6 +1408,7 @@ static const struct irq_chip msm_gpio_irq_chip = {
> .flags = (IRQCHIP_MASK_ON_SUSPEND |
> IRQCHIP_SET_TYPE_MASKED |
> IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND |
> + IRQCHIP_EOI_THREADED |
> IRQCHIP_IMMUTABLE),
> };
[Severity: Medium]
The commit message does not mention the addition of IRQCHIP_EOI_THREADED.
Does this change belong in a separate patch, or should the commit message
be updated to explain why it is needed?
Adding this flag alters the EOI timing for oneshot threaded interrupts
handled by this chip, deferring the irq_eoi() callback until after the
threaded handler completes.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-hamoa_pdc_v3-v3-0-4d8e1504ea75@oss.qualcomm.com?part=6
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: sashiko-bot @ 2026-06-16 9:43 UTC (permalink / raw)
To: Maulik Shah; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260616-hamoa_pdc_v3-v3-5-4d8e1504ea75@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Read-Modify-Write (RMW) operations on `irq_cfg_reg` race with asynchronous hardware updates to the latched status bit, risking lost interrupts.
--
commit 5bfc60b86ecb20a923a4f052f469cb8a8237153f
Author: Maulik Shah <maulik.shah@oss.qualcomm.com>
irqchip/qcom-pdc: Configure PDC to pass through mode
This commit configures the PDC to pass through mode using an SCM write
access. If the write fails, it falls back to a secondary controller mode
where GPIO IRQs are latched at the PDC and sent to the GIC as level
interrupts.
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 1aa6be42307ca..c6f2935ff7887 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
[ ... ]
> @@ -231,6 +260,30 @@ static void pdc_enable_intr_bank(int pin_out, bool on)
> pdc_reg_write(pdc->regs->irq_en_reg, index, enable);
> }
>
> +static void pdc_clear_gpio_cfg(int pin_out)
> +{
> + unsigned long gpio_sts;
> +
> + if (pdc->version < PDC_VERSION_3_0)
> + return;
> +
> + gpio_sts = pdc_reg_read(pdc->regs->irq_cfg_reg, pin_out);
> + __clear_bit(pdc->cfg_fields->gpio_irq_sts, &gpio_sts);
> + pdc_reg_write(pdc->regs->irq_cfg_reg, pin_out, gpio_sts);
> +}
> +
> +static void pdc_unmask_gpio_cfg(int pin_out, bool unmask)
> +{
> + unsigned long gpio_mask;
> +
> + if (pdc->version < PDC_VERSION_3_0)
> + return;
> +
> + gpio_mask = pdc_reg_read(pdc->regs->irq_cfg_reg, pin_out);
> + __assign_bit(pdc->cfg_fields->gpio_irq_mask, &gpio_mask, !unmask);
> + pdc_reg_write(pdc->regs->irq_cfg_reg, pin_out, gpio_mask);
[Severity: High]
Could this read-modify-write operation accidentally clear a pending interrupt?
Since pdc_clear_gpio_cfg() clears the hardware latch by setting gpio_irq_sts
to 0, it appears this is a Write-0-to-Clear (W0C) register bit.
If a new interrupt arrives and the hardware sets gpio_irq_sts to 1 right
after the read but before the write completes:
CPU
pdc_unmask_gpio_cfg()
gpio_mask = pdc_reg_read(...) // reads gpio_irq_sts as 0
Hardware
Interrupt arrives, sets gpio_irq_sts to 1
CPU
pdc_unmask_gpio_cfg()
pdc_reg_write(..., gpio_mask) // writes 0 back to gpio_irq_sts
Will this write of 0 inadvertently clear the newly latched interrupt before
it can be processed by the system?
> +}
> +
> static void pdc_enable_intr_cfg(int pin_out, bool on)
> {
> unsigned long enable = pdc_reg_read(pdc->regs->irq_cfg_reg, pin_out);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-hamoa_pdc_v3-v3-0-4d8e1504ea75@oss.qualcomm.com?part=5
^ permalink raw reply
* Re: [PATCH 08/23] driver core: platform: provide platform_device_set_of_node_from_dev()
From: Andy Shevchenko @ 2026-06-16 9:41 UTC (permalink / raw)
To: Johan Hovold
Cc: Bartosz Golaszewski, Lee Jones, Mark Brown, Thierry Reding,
Sebastian Hesselbarth, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Srinivas Kandagatla,
Greg Kroah-Hartman, Vinod Koul, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <aiZpJkQBXg2pcczy@hovoldconsulting.com>
On Mon, Jun 08, 2026 at 09:03:02AM +0200, Johan Hovold wrote:
> On Fri, Jun 05, 2026 at 05:53:04PM +0300, Andy Shevchenko wrote:
> > On Fri, Jun 05, 2026 at 02:16:17PM +0200, Johan Hovold wrote:
> > > On Wed, Jun 03, 2026 at 12:44:55AM +0300, Andy Shevchenko wrote:
> > > > On Thu, May 21, 2026 at 10:36:31AM +0200, Bartosz Golaszewski wrote:
> > > > > Provide a platform-specific variant of device_set_of_node_from_dev(). In
> > > > > addition to bumping the reference count of the OF node being assigned,
> > > > > it also assigns the fwnode of the platform device.
> > > >
> > > > Can we rather investigate the way how to make that of node reuse thingy
> > > > (which is used solely by pin control) differently and then drop this confusing
> > > > device_set_of_node_from_dev() call altogether?
> > >
> > > No, that call is needed. See commit 4e75e1d7dac9 ("driver core: add
> > > helper to reuse a device-tree node") for details.
> >
> > Bart fixes the problem with the platform driver. At the result this will be
> > the only device_set_node() + 'reused = true'. As for 'reused' flag, the need
> > is only for pinmux/pin control stuff.
>
> And any other resource which may (eventually) be claimed by driver core
> or bus code.
>
> > The question here is if there is a better
> > way to make that 'reused' be done automatically without need of setting some
> > flag explicitly.
>
> That's not really relevant to the series at hand.
It's not, but it's relevant in a long-term for understanding how we can get
this done in a better way.
> If this is something we want to merge then you need to continue setting
> the flag in order not to cause regressions.
Yes, that's how it's now.
--
With Best Regards,
Andy Shevchenko
^ 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