* [PATCH v5 6/8] i2c: rtl9300: introduce clk struct for upcoming rtl9607 support
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
In RTL9607C i2c controller, there is 10 bit CLK_DIV field for
setting the clock of i2c interface which depends on the rate
of i2c clk (which seems be fixed to 62.5MHz according to Realtek SDK).
Introduce the clk struct and the respective F_CLK_DIV and clk_div
which are going to be used in the upcoming patch for rtl9607c i2c
controller support addition.
devm_clk_get_optional_enabled() function was used for cleaner code
as it automatically returns NULL if the clk is not present, which is
going to be the case for RTL9300 and RTL9310 i2c controllers.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index ffbc6c52861b..16af49ccd1dd 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
#include <linux/bits.h>
+#include <linux/clk.h>
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
#include <linux/mod_devicetable.h>
@@ -28,6 +29,7 @@ struct rtl9300_i2c_chan {
struct rtl9300_i2c *i2c;
enum rtl9300_bus_freq bus_freq;
u8 sda_num;
+ u32 clk_div;
};
enum rtl9300_i2c_reg_scope {
@@ -54,6 +56,7 @@ enum rtl9300_i2c_reg_fields {
F_SDA_OUT_SEL,
F_SDA_SEL,
F_BUSY,
+ F_CLK_DIV,
/* keep last */
F_NUM_FIELDS
@@ -85,6 +88,7 @@ struct rtl9300_i2c {
u8 scl_num;
u8 sda_num;
struct mutex lock;
+ struct clk *clk;
};
DEFINE_GUARD(rtl9300_i2c, struct rtl9300_i2c *, mutex_lock(&_T->lock), mutex_unlock(&_T->lock))
@@ -432,6 +436,10 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
if (ret)
return ret;
+ i2c->clk = devm_clk_get_optional_enabled(dev, NULL);
+ if (IS_ERR(i2c->clk))
+ return dev_err_probe(dev, PTR_ERR(i2c->clk), "Failed to enable i2c clock\n");
+
i = 0;
for_each_child_of_node_scoped(dev->of_node, child) {
struct rtl9300_i2c_chan *chan = &i2c->chans[i];
--
2.53.0
^ permalink raw reply related
* [PATCH v5 5/8] dt-bindings: i2c: realtek,rtl9301-i2c: extend for clocks and RTL9607C support
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
Add the "realtek,rtl9607-i2c" compatible for i2c controller on the
RTL9607C SoC series.
Add a clocks property to the properties to describe the i2c reference
clock and make it available for all the compatibles. This i2c reference
clock is assumed to be coming from switchcore region via Lexra bus as
the other SoC peripherals.
According to the info available about the existing devices, they also
have the i2c master controller clocks.
RTL9607C requires the "realtek,scl" and "clocks" to be specified
and so handle it under separate if check for "realtek,rtl9607-i2c".
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
.../bindings/i2c/realtek,rtl9301-i2c.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
index f9a449fee2b0..5873cfdc5b3e 100644
--- a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
@@ -15,6 +15,8 @@ description:
assigned to either I2C controller.
RTL9310 SoCs have equal capabilities but support 12 common SDA lines which
can be assigned to either I2C controller.
+ RTL9607C SoCs have equal capabilities but each controller only supports 1
+ SCL/SDA line.
properties:
compatible:
@@ -34,6 +36,7 @@ properties:
- enum:
- realtek,rtl9301-i2c
- realtek,rtl9310-i2c
+ - realtek,rtl9607-i2c
reg:
items:
@@ -51,6 +54,9 @@ properties:
The SCL line number of this I2C controller.
enum: [ 0, 1 ]
+ clocks:
+ maxItems: 1
+
patternProperties:
'^i2c@[0-9ab]$':
$ref: /schemas/i2c/i2c-controller.yaml
@@ -81,6 +87,15 @@ allOf:
then:
patternProperties:
'^i2c@[89ab]$': false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: realtek,rtl9607-i2c
+ then:
+ required:
+ - realtek,scl
+ - clocks
required:
- compatible
--
2.53.0
^ permalink raw reply related
* [PATCH v5 4/8] i2c: rtl9300: introduce a property for 8 bit width reg address
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
In RTL9607C i2c controller, in order to indicate that the width of
memory address is 8 bits, 0 is written to MEM_ADDR_WIDTH field as
opposed to 1 for RTL9300 and RTL9310.
Introduce a new property to a driver data to indicate what value
need to written to MEM_ADDR_WIDTH field for this case.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index e40b4692a3fa..ffbc6c52861b 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -66,6 +66,7 @@ struct rtl9300_i2c_drv_data {
u32 wd_reg;
u8 max_nchan;
u8 max_data_len;
+ u8 reg_addr_8bit_len;
};
#define RTL9300_I2C_MUX_NCHAN 8
@@ -111,6 +112,7 @@ struct rtl9300_i2c_xfer {
#define RTL9300_I2C_MST_DATA_WORD2 0x10
#define RTL9300_I2C_MST_DATA_WORD3 0x14
#define RTL9300_I2C_MST_GLB_CTRL 0x384
+#define RTL9300_REG_ADDR_8BIT_LEN 1
#define RTL9310_I2C_MST_IF_CTRL 0x1004
#define RTL9310_I2C_MST_IF_SEL 0x1008
@@ -305,6 +307,7 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *adap, u16 addr, unsigned s
union i2c_smbus_data *data)
{
struct rtl9300_i2c_chan *chan = i2c_get_adapdata(adap);
+ const struct rtl9300_i2c_drv_data *drv_data;
struct rtl9300_i2c *i2c = chan->i2c;
struct rtl9300_i2c_xfer xfer = {0};
int ret;
@@ -314,6 +317,7 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *adap, u16 addr, unsigned s
guard(rtl9300_i2c)(i2c);
+ drv_data = device_get_match_data(i2c->dev);
ret = rtl9300_i2c_config_chan(i2c, chan);
if (ret)
return ret;
@@ -321,7 +325,7 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *adap, u16 addr, unsigned s
xfer.dev_addr = addr & 0x7f;
xfer.write = (read_write == I2C_SMBUS_WRITE);
xfer.reg_addr = command;
- xfer.reg_addr_len = 1;
+ xfer.reg_addr_len = drv_data->reg_addr_8bit_len;
switch (size) {
case I2C_SMBUS_BYTE:
@@ -513,6 +517,7 @@ static const struct rtl9300_i2c_drv_data rtl9300_i2c_drv_data = {
.wd_reg = RTL9300_I2C_MST_DATA_WORD0,
.max_nchan = RTL9300_I2C_MUX_NCHAN,
.max_data_len = RTL9300_I2C_MAX_DATA_LEN,
+ .reg_addr_8bit_len = RTL9300_REG_ADDR_8BIT_LEN,
};
static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
@@ -536,6 +541,7 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
.wd_reg = RTL9310_I2C_MST_DATA_CTRL,
.max_nchan = RTL9310_I2C_MUX_NCHAN,
.max_data_len = RTL9300_I2C_MAX_DATA_LEN,
+ .reg_addr_8bit_len = RTL9300_REG_ADDR_8BIT_LEN,
};
static const struct of_device_id i2c_rtl9300_dt_ids[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v5 3/8] i2c: rtl9300: introduce F_BUSY to the reg_fields struct
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
In RTL9607C i2c controller the busy check operation is done on the
separate bit of the command register as opposed to self clearing
command trigger bit on the rtl9300 and rtl9310 i2c controllers.
Introduce a new F_BUSY field to the reg_fields struct for that
and change the regmap read poll function to use F_BUSY
instead of I2C_TRIG.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index 2cada6038b44..e40b4692a3fa 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -53,6 +53,7 @@ enum rtl9300_i2c_reg_fields {
F_SCL_SEL,
F_SDA_OUT_SEL,
F_SDA_SEL,
+ F_BUSY,
/* keep last */
F_NUM_FIELDS
@@ -262,7 +263,7 @@ static int rtl9300_i2c_do_xfer(struct rtl9300_i2c *i2c, struct rtl9300_i2c_xfer
if (ret)
return ret;
- ret = regmap_field_read_poll_timeout(i2c->fields[F_I2C_TRIG], val, !val, 100, 100000);
+ ret = regmap_field_read_poll_timeout(i2c->fields[F_BUSY], val, !val, 100, 100000);
if (ret)
return ret;
@@ -505,6 +506,7 @@ static const struct rtl9300_i2c_drv_data rtl9300_i2c_drv_data = {
[F_MEM_ADDR_WIDTH] = MST_REG_FIELD(RTL9300_I2C_MST_CTRL2, 2, 3),
[F_SCL_FREQ] = MST_REG_FIELD(RTL9300_I2C_MST_CTRL2, 0, 1),
[F_SDA_SEL] = GLB_REG_FIELD(RTL9300_I2C_MST_GLB_CTRL, 0, 7),
+ [F_BUSY] = MST_REG_FIELD(RTL9300_I2C_MST_CTRL1, 0, 0),
},
.select_scl = rtl9300_i2c_select_scl,
.rd_reg = RTL9300_I2C_MST_DATA_WORD0,
@@ -527,6 +529,7 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
[F_I2C_FAIL] = MST_REG_FIELD(RTL9310_I2C_MST_CTRL, 1, 1),
[F_I2C_TRIG] = MST_REG_FIELD(RTL9310_I2C_MST_CTRL, 0, 0),
[F_MEM_ADDR] = MST_REG_FIELD(RTL9310_I2C_MST_MEMADDR_CTRL, 0, 23),
+ [F_BUSY] = MST_REG_FIELD(RTL9310_I2C_MST_CTRL, 0, 0),
},
.select_scl = rtl9310_i2c_select_scl,
.rd_reg = RTL9310_I2C_MST_DATA_CTRL,
--
2.53.0
^ permalink raw reply related
* [PATCH v5 2/8] i2c: rtl9300: introduce max length property to driver data
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
In RTL9607C i2c controller, theoretical maximum the data length
can be is 4 bytes as opposed to 16 bytes on rtl9300 and rtl9310.
Introduce a new property to the driver data struct for that.
Adjust if statement in prepare_xfer function to follow that new
property instead of the hardcoded value.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index 9bf4c6b08e05..2cada6038b44 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -64,11 +64,14 @@ struct rtl9300_i2c_drv_data {
u32 rd_reg;
u32 wd_reg;
u8 max_nchan;
+ u8 max_data_len;
};
#define RTL9300_I2C_MUX_NCHAN 8
#define RTL9310_I2C_MUX_NCHAN 12
+#define RTL9300_I2C_MAX_DATA_LEN 16
+
struct rtl9300_i2c {
struct regmap *regmap;
struct device *dev;
@@ -210,9 +213,11 @@ static int rtl9300_i2c_writel(struct rtl9300_i2c *i2c, u32 data)
static int rtl9300_i2c_prepare_xfer(struct rtl9300_i2c *i2c, struct rtl9300_i2c_xfer *xfer)
{
+ const struct rtl9300_i2c_drv_data *drv_data;
int ret;
- if (xfer->data_len < 1 || xfer->data_len > 16)
+ drv_data = device_get_match_data(i2c->dev);
+ if (xfer->data_len < 1 || xfer->data_len > drv_data->max_data_len)
return -EINVAL;
ret = regmap_field_write(i2c->fields[F_DEV_ADDR], xfer->dev_addr);
@@ -505,6 +510,7 @@ static const struct rtl9300_i2c_drv_data rtl9300_i2c_drv_data = {
.rd_reg = RTL9300_I2C_MST_DATA_WORD0,
.wd_reg = RTL9300_I2C_MST_DATA_WORD0,
.max_nchan = RTL9300_I2C_MUX_NCHAN,
+ .max_data_len = RTL9300_I2C_MAX_DATA_LEN,
};
static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
@@ -526,6 +532,7 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
.rd_reg = RTL9310_I2C_MST_DATA_CTRL,
.wd_reg = RTL9310_I2C_MST_DATA_CTRL,
.max_nchan = RTL9310_I2C_MUX_NCHAN,
+ .max_data_len = RTL9300_I2C_MAX_DATA_LEN,
};
static const struct of_device_id i2c_rtl9300_dt_ids[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/8] i2c: rtl9300: split data_reg into read and write reg
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
In-Reply-To: <20260326152656.14030-1-adilov@disroot.org>
In RTL9607C i2c controller, there are 2 separate registers for reads
and writes as opposed the combined 1 on rtl9300 and rtl9310.
In preparation for RTL9607C support, split it up into rd_reg and wd_reg
properties and change the i2c read and write functions accordingly.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index 67a5c4228fc9..9bf4c6b08e05 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -61,7 +61,8 @@ enum rtl9300_i2c_reg_fields {
struct rtl9300_i2c_drv_data {
struct rtl9300_i2c_reg_field field_desc[F_NUM_FIELDS];
int (*select_scl)(struct rtl9300_i2c *i2c, u8 scl);
- u32 data_reg;
+ u32 rd_reg;
+ u32 wd_reg;
u8 max_nchan;
};
@@ -74,7 +75,8 @@ struct rtl9300_i2c {
struct rtl9300_i2c_chan chans[RTL9310_I2C_MUX_NCHAN];
struct regmap_field *fields[F_NUM_FIELDS];
u32 reg_base;
- u32 data_reg;
+ u32 rd_reg;
+ u32 wd_reg;
u8 scl_num;
u8 sda_num;
struct mutex lock;
@@ -171,7 +173,7 @@ static int rtl9300_i2c_read(struct rtl9300_i2c *i2c, u8 *buf, u8 len)
if (len > 16)
return -EIO;
- ret = regmap_bulk_read(i2c->regmap, i2c->data_reg, vals, ARRAY_SIZE(vals));
+ ret = regmap_bulk_read(i2c->regmap, i2c->rd_reg, vals, ARRAY_SIZE(vals));
if (ret)
return ret;
@@ -198,12 +200,12 @@ static int rtl9300_i2c_write(struct rtl9300_i2c *i2c, u8 *buf, u8 len)
vals[reg] |= buf[i] << shift;
}
- return regmap_bulk_write(i2c->regmap, i2c->data_reg, vals, ARRAY_SIZE(vals));
+ return regmap_bulk_write(i2c->regmap, i2c->wd_reg, vals, ARRAY_SIZE(vals));
}
static int rtl9300_i2c_writel(struct rtl9300_i2c *i2c, u32 data)
{
- return regmap_write(i2c->regmap, i2c->data_reg, data);
+ return regmap_write(i2c->regmap, i2c->wd_reg, data);
}
static int rtl9300_i2c_prepare_xfer(struct rtl9300_i2c *i2c, struct rtl9300_i2c_xfer *xfer)
@@ -268,14 +270,14 @@ static int rtl9300_i2c_do_xfer(struct rtl9300_i2c *i2c, struct rtl9300_i2c_xfer
if (!xfer->write) {
switch (xfer->type) {
case RTL9300_I2C_XFER_BYTE:
- ret = regmap_read(i2c->regmap, i2c->data_reg, &val);
+ ret = regmap_read(i2c->regmap, i2c->rd_reg, &val);
if (ret)
return ret;
*xfer->data = val & 0xff;
break;
case RTL9300_I2C_XFER_WORD:
- ret = regmap_read(i2c->regmap, i2c->data_reg, &val);
+ ret = regmap_read(i2c->regmap, i2c->rd_reg, &val);
if (ret)
return ret;
@@ -408,7 +410,8 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
if (device_get_child_node_count(dev) > drv_data->max_nchan)
return dev_err_probe(dev, -EINVAL, "Too many channels\n");
- i2c->data_reg = i2c->reg_base + drv_data->data_reg;
+ i2c->rd_reg = i2c->reg_base + drv_data->rd_reg;
+ i2c->wd_reg = i2c->reg_base + drv_data->wd_reg;
for (i = 0; i < F_NUM_FIELDS; i++) {
fields[i] = drv_data->field_desc[i].field;
if (drv_data->field_desc[i].scope == REG_SCOPE_MASTER)
@@ -499,7 +502,8 @@ static const struct rtl9300_i2c_drv_data rtl9300_i2c_drv_data = {
[F_SDA_SEL] = GLB_REG_FIELD(RTL9300_I2C_MST_GLB_CTRL, 0, 7),
},
.select_scl = rtl9300_i2c_select_scl,
- .data_reg = RTL9300_I2C_MST_DATA_WORD0,
+ .rd_reg = RTL9300_I2C_MST_DATA_WORD0,
+ .wd_reg = RTL9300_I2C_MST_DATA_WORD0,
.max_nchan = RTL9300_I2C_MUX_NCHAN,
};
@@ -519,7 +523,8 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
[F_MEM_ADDR] = MST_REG_FIELD(RTL9310_I2C_MST_MEMADDR_CTRL, 0, 23),
},
.select_scl = rtl9310_i2c_select_scl,
- .data_reg = RTL9310_I2C_MST_DATA_CTRL,
+ .rd_reg = RTL9310_I2C_MST_DATA_CTRL,
+ .wd_reg = RTL9310_I2C_MST_DATA_CTRL,
.max_nchan = RTL9310_I2C_MUX_NCHAN,
};
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/8] i2c: rtl9300: support for RTL9607C I2C controller
From: Rustam Adilov @ 2026-03-26 15:26 UTC (permalink / raw)
To: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
Cc: Rustam Adilov
This patch series for the RTL9300 I2C driver adds i2c support for
RTL9607C SoC. They are somewhat different to the RTL9300 and
RTL9310 but not enough to warrant a new whole driver.
The patch series was split into patches that add/change something in the
driver to smooth out the RTL9607C support addition in the end and for
ease of review. Because of that, the patch 8 depends on all the prior
patches before it.
RTL9607C primarly uses the i2c controller for communication with laser
driver over on i2c interface 1 or 2.
I have successfully tested the byte read operations on my RTL9607C board
which has GN25L95 laser driver in OpenWrt.
This patch series now depends on the patch [1] from Jan Kantert.
[1] -
https://lore.kernel.org/all/20260227111134.2163701-1-jan-kernel@kantert.net/
---
Changelog in v5
- reworded the commit message in Patch 5 to make it clear that the existing
devices also have i2c master controller clocks.
- Link to v4: https://lore.kernel.org/linux-i2c/20260323071337.15410-1-adilov@disroot.org/
Changelog in v4
- moved the patch 7 that changes bindings to be before patch 5 where clk
is introduced in the driver.
- changed the "realtek,rtl9607-i2c" compatible to require the "clocks" to
be specified and with it moved it out of "realtek,rtl9310-i2c" check to its
own place for cleanliness (how it was originally in v1).
- Link to v3: https://lore.kernel.org/linux-i2c/20260322123411.32102-1-adilov@disroot.org/
Changelog in v3
- Patch 7
- reworded the commit message to better describe i2c clock.
- make clocks property available for all compatibles.
- change "realtek,rtl9607-i2c" compatible to be under the same if statement
as "realtek,rtl9310-i2c" for "realtek,scl".
- Link to v2: https://lore.kernel.org/linux-i2c/20260319175753.32338-1-adilov@disroot.org/
Changelog in v2
- rebased on top of the patch from Jan Kantert.
- Patch 7 (to my best understanding of Krzysztof's request):
- added the "clocks: false" for compatibles that are not realtek,rtl9607-i2c.
- Link to v1: https://lore.kernel.org/linux-i2c/20260314082628.25206-1-adilov@disroot.org/
Rustam Adilov (8):
i2c: rtl9300: split data_reg into read and write reg
i2c: rtl9300: introduce max length property to driver data
i2c: rtl9300: introduce F_BUSY to the reg_fields struct
i2c: rtl9300: introduce a property for 8 bit width reg address
dt-bindings: i2c: realtek,rtl9301-i2c: extend for clocks and RTL9607C
support
i2c: rtl9300: introduce clk struct for upcoming rtl9607 support
i2c: rtl9300: intoduce new function properties to driver data
i2c: rtl9300: add RTL9607C i2c controller support
.../bindings/i2c/realtek,rtl9301-i2c.yaml | 15 ++
drivers/i2c/busses/i2c-rtl9300.c | 191 ++++++++++++++----
2 files changed, 171 insertions(+), 35 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Russell King (Oracle) @ 2026-03-26 15:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <044110c5-da1e-48c0-93fd-35553e86b271@lunn.ch>
On Thu, Mar 26, 2026 at 04:24:23PM +0100, Andrew Lunn wrote:
> On Thu, Mar 26, 2026 at 03:13:19PM +0000, Russell King (Oracle) wrote:
> > On Thu, Mar 26, 2026 at 01:04:15PM +0100, Louis-Alexis Eyraud wrote:
> > > +static int an8801r_set_wol(struct phy_device *phydev,
> > > + struct ethtool_wolinfo *wol)
> > > +{
> > > + struct net_device *attach_dev = phydev->attached_dev;
> > > + const unsigned char *macaddr = attach_dev->dev_addr;
> >
> > This isn't a criticism for this patch, but a discussion point for
> > phylib itself.
> >
> > It occurs to me that there's a weakness in the phylib interface for WoL,
> > specifically when WoL is enabled at the PHY, but someone then changes
> > the interface's MAC address - there doesn't seem to be a way for the
> > address programmed into the PHY to be updated. Should there be?
> >
> > Do we instead expect users to disable WoL before changing the MAC for
> > a network interface?
>
> Program the MAC address during suspend? I assume userspace is no
> longer active at this point, so the address should be stable.
What is the timing requirements for a system going into suspend vs a WoL
packet being sent? Should a WoL packet abort entry into suspend? If yes,
then we need to program the MAC before the PHY is suspended, because
suspend could already be in progress.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: usb: Add support for Terminus FE1.1s USB2.0 Hub controller
From: Rob Herring (Arm) @ 2026-03-26 15:26 UTC (permalink / raw)
To: Yixun Lan
Cc: linux-kernel, Inochi Amaoto, Greg Kroah-Hartman, spacemit,
Krzysztof Kozlowski, Conor Dooley, linux-usb, Matthias Kaehlcke,
devicetree, Junzhong Pan
In-Reply-To: <20260319-03-usb-hub-fe1-v2-1-e4e26809dd7d@kernel.org>
On Thu, 19 Mar 2026 07:51:03 +0000, Yixun Lan wrote:
> Terminus FE1.1s is USB2.0 protocol compliant 4-port USB HUB, It support
> MTT (Multiple Transaction Translator) mode, the upstream port supports
> high-speed 480MHz and full-speed 12MHz modes, also has integrated 5V to
> 3.3V, 1.8V regulator and Power-On-Reset circuit.
>
> Introduce the DT binding for it.
>
> Link: https://terminus-usa.com/wp-content/uploads/2024/06/FE1.1s-Product-Brief-Rev.-2.0-2023.pdf [1]
> Signed-off-by: Yixun Lan <dlan@kernel.org>
> ---
> .../devicetree/bindings/usb/terminus,fe11.yaml | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: hamoa-evk: Add DP0/DP1 audio playback support
From: Bjorn Andersson @ 2026-03-26 15:25 UTC (permalink / raw)
To: Le Qi
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20260210024037.3719191-1-le.qi@oss.qualcomm.com>
On Tue, Feb 10, 2026 at 10:40:37AM +0800, Le Qi wrote:
> The hamoa-evk DTS currently lacks DAI links for DP0 and DP1, preventing
> the sound card from exposing these playback paths. Add the missing links
> to enable audio output on both DP interfaces.
>
> ---
> Changelog:
>
> v2:
> - Changed commit message to explain motivation
> - Removed redundant sound-name-prefix properties for DP0/DP1, since these
> are already defined in the SoC DTSI.
> - v1-link: https://lore.kernel.org/all/20260209091139.622756-1-le.qi@oss.qualcomm.com/
>
> Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
This should be here, now I had to rebase my whole tree to fix the
missing s-o-b. Please use b4 to avoid such mistakes.
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> index 2390648a248f..4428c8f45493 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> @@ -616,6 +616,38 @@ platform {
> sound-dai = <&q6apm>;
> };
> };
> +
> + dp0-dai-link {
> + link-name = "DP0 Playback";
> +
> + codec {
> + sound-dai = <&mdss_dp0>;
> + };
> +
> + cpu {
> + sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> +
> + dp1-dai-link {
> + link-name = "DP1 Playback";
> +
> + codec {
> + sound-dai = <&mdss_dp1>;
> + };
> +
> + cpu {
> + sound-dai = <&q6apmbedai DISPLAY_PORT_RX_1>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> };
>
> usb-1-ss0-sbu-mux {
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3 09/10] dt-bindings: firmware: add arm,ras-cper
From: Rob Herring @ 2026-03-26 15:24 UTC (permalink / raw)
To: Ahmed Tiba
Cc: linux-acpi, devicetree, linux-cxl, Michael.Zhao2,
linux-arm-kernel, Dmitry.Lamerov, rafael, conor, will, bp,
catalin.marinas, krzk+dt, linux-doc, mchehab+huawei, tony.luck
In-Reply-To: <20260318-topics-ahmtib01-ras_ffh_arm_internal_review-v3-9-48e6a1c249ef@arm.com>
On Wed, Mar 18, 2026 at 08:48:06PM +0000, Ahmed Tiba wrote:
> Describe the DeviceTree node that exposes the Arm firmware-first
> CPER provider and hook the file into MAINTAINERS so the
> binding has an owner.
>
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
> ---
> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 71 ++++++++++++++++++++++
> MAINTAINERS | 5 ++
> 2 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> new file mode 100644
> index 000000000000..bd93cfb8d222
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arm RAS CPER provider
> +
> +maintainers:
> + - Ahmed Tiba <ahmed.tiba@arm.com>
> +
> +description: |
> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
> + a firmware-first CPER error source directly via DeviceTree. Firmware
> + provides the CPER Generic Error Status block and notifies the OS through
> + an interrupt.
> +
> +properties:
> + compatible:
> + const: arm,ras-cper
> +
> + reg:
> + minItems: 1
> + items:
> + - description:
> + CPER Generic Error Status block exposed by firmware
> + - description:
> + Optional 32- or 64-bit doorbell register used on platforms
> + where firmware needs an explicit "ack" handshake before overwriting
> + the CPER buffer. Firmware watches bit 0 and expects the OS to set it
> + once the current status block has been consumed.
> +
> + interrupts:
> + maxItems: 1
> + description:
> + Interrupt used to signal that a new status record is ready.
> +
> + memory-region:
> + $ref: /schemas/types.yaml#/definitions/phandle
memory-region already has a defined type. You just need to define how
many entries (maxItems: 1).
> + description:
> + Optional phandle to the reserved-memory entry that backs the status
> + buffer so firmware and the OS use the same carved-out region.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ras_cper_buffer: cper@fe800000 {
> + reg = <0x0 0xfe800000 0x0 0x1000>;
> + no-map;
> + };
> + };
> +
> + error-handler@fe800000 {
> + compatible = "arm,ras-cper";
> + reg = <0xfe800000 0x1000>,
Wait! Why is the reserved address here? There's 2 problems with that.
There shouldn't be same address in 2 places in the DT. The 2nd is
reserved memory should only be regions within DRAM (or whatever is
system memory).
Rob
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-26 15:24 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Heiner Kallweit,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <acVND6DdpM9czIwU@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 03:13:19PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 01:04:15PM +0100, Louis-Alexis Eyraud wrote:
> > +static int an8801r_set_wol(struct phy_device *phydev,
> > + struct ethtool_wolinfo *wol)
> > +{
> > + struct net_device *attach_dev = phydev->attached_dev;
> > + const unsigned char *macaddr = attach_dev->dev_addr;
>
> This isn't a criticism for this patch, but a discussion point for
> phylib itself.
>
> It occurs to me that there's a weakness in the phylib interface for WoL,
> specifically when WoL is enabled at the PHY, but someone then changes
> the interface's MAC address - there doesn't seem to be a way for the
> address programmed into the PHY to be updated. Should there be?
>
> Do we instead expect users to disable WoL before changing the MAC for
> a network interface?
Program the MAC address during suspend? I assume userspace is no
longer active at this point, so the address should be stable.
Andrew
^ permalink raw reply
* Re: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
From: Frank Li @ 2026-03-26 15:20 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel,
Guoniu Zhou
Cc: Frank Li, linux-media, devicetree, imx, linux-arm-kernel,
linux-kernel, Conor Dooley
In-Reply-To: <20251205-csi2_imx8ulp-v10-0-190cdadb20a3@nxp.com>
On Fri, 05 Dec 2025 17:07:42 +0800, Guoniu Zhou wrote:
> The serial adds MIPI CSI-2 support for i.MX8ULP.
>
>
Applied, thanks!
[5/5] arm64: dts: imx8ulp: Add CSI and ISI Nodes
commit: 73f3ca0f85285b2fc4ea05affb9a44bf899cd595
Add extra empty line between reg and child node.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 03/12] i3c: master: Use unified device property interface
From: Rob Herring @ 2026-03-26 15:18 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Guenter Roeck,
Philipp Zabel, Eric Biggers, Fredrik Markstrom, Miquel Raynal,
Thierry Reding, Jon Hunter, Suresh Mangipudi, linux-tegra,
linux-i3c, devicetree, linux-kernel, linux-acpi, acpica-devel,
linux-hwmon
In-Reply-To: <20260318172820.13771-4-akhilrajeev@nvidia.com>
On Wed, Mar 18, 2026 at 10:57:16PM +0530, Akhil R wrote:
> Replace all OF-specific functions with unified device property functions
> as a prerequisite to support both ACPI and device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
> drivers/i3c/master.c | 91 ++++++++++++++++++++++----------------
> include/linux/i3c/master.h | 5 ++-
> 2 files changed, 55 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index c32847bc4d0d..2c479fecbfdf 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[...]
> @@ -3300,11 +3310,14 @@ static int __init i3c_init(void)
> {
> int res;
>
> - res = of_alias_get_highest_id("i3c");
> - if (res >= 0) {
> - mutex_lock(&i3c_core_lock);
> - __i3c_first_dynamic_bus_num = res + 1;
> - mutex_unlock(&i3c_core_lock);
> + /* of_alias_get_highest_id is DT-specific, only call for DT systems */
> + if (IS_ENABLED(CONFIG_OF)) {
BTW, CONFIG_OF is *always* enabled on arm64.
> + res = of_alias_get_highest_id("i3c");
This will just return an error if not booting with DT or if CONFIG_OF is
disabled.
> + if (res >= 0) {
> + mutex_lock(&i3c_core_lock);
> + __i3c_first_dynamic_bus_num = res + 1;
> + mutex_unlock(&i3c_core_lock);
> + }
> }
>
> res = bus_register_notifier(&i2c_bus_type, &i2cdev_notifier);
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Russell King (Oracle) @ 2026-03-26 15:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Louis-Alexis Eyraud, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Andrew Lunn,
Heiner Kallweit, kevin-kw.huang, macpaul.lin, matthias.bgg,
kernel, netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <20260326-add-airoha-an8801-support-v2-4-1a42d6b6050f@collabora.com>
On Thu, Mar 26, 2026 at 01:04:15PM +0100, Louis-Alexis Eyraud wrote:
> +static int an8801r_set_wol(struct phy_device *phydev,
> + struct ethtool_wolinfo *wol)
> +{
> + struct net_device *attach_dev = phydev->attached_dev;
> + const unsigned char *macaddr = attach_dev->dev_addr;
This isn't a criticism for this patch, but a discussion point for
phylib itself.
It occurs to me that there's a weakness in the phylib interface for WoL,
specifically when WoL is enabled at the PHY, but someone then changes
the interface's MAC address - there doesn't seem to be a way for the
address programmed into the PHY to be updated. Should there be?
Do we instead expect users to disable WoL before changing the MAC for
a network interface?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: freescale: add i.MX91 9x9 QSB basic support
From: Andrew Lunn @ 2026-03-26 15:10 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel, Daniel Baluta
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-5-b991b81639e6@nxp.com>
> 4. Remove clock-frequency property from mdio node.
> +&eqos {
> + phy-handle = <ðphy1>;
> + phy-mode = "rgmii-id";
> + pinctrl-0 = <&pinctrl_eqos>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <5000000>;
???
Andrew
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: imx93-9x9-qsb: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:08 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-4-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:40PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Thanks for these patches.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/5] arm64: dts: imx93-11x11-evk: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:07 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-3-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:39PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/5] arm64: dts: imx91-11x11-evk: remove unused property clock-frequency from mdio node
From: Andrew Lunn @ 2026-03-26 15:07 UTC (permalink / raw)
To: Joy Zou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-2-b991b81639e6@nxp.com>
On Thu, Mar 26, 2026 at 03:51:38PM +0800, Joy Zou wrote:
> The clock-frequency property is not implemented. Remove it to clean up the
> device tree.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Rob Herring @ 2026-03-26 15:05 UTC (permalink / raw)
To: Conor Dooley
Cc: Akhil R, Alexandre Belloni, Frank Li, Krzysztof Kozlowski,
Conor Dooley, Rafael J . Wysocki, Robert Moore, Len Brown,
Guenter Roeck, Philipp Zabel, Eric Biggers, Fredrik Markstrom,
Miquel Raynal, Thierry Reding, Jon Hunter, Suresh Mangipudi,
linux-tegra, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260318-tweed-herbicide-eb924ef056b8@spud>
On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> > 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/specifications/disco
> >
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > ---
> > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> > 1 file changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > index e25fa72fd785..1705d90d4d79 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
> > @@ -147,6 +149,26 @@ patternProperties:
> > through SETDASA. If static address is not present, this address is assigned
> > through SETNEWDA after assigning a temporary address via ENTDAA.
> >
> > + mipi-i3c-static-method:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0x1
> > + maximum: 0xff
> > + default: 1
> > + description: |
> > + Bitmap describing which methods of Dynamic Address Assignment from a
> > + static address are supported by this I3C Target. A bit value of 1
> > + indicates support for that method, and 0 indicates lack of support.
>
> I really am not keen on properties that are bitmaps, why can't we just
> use the strings "setdasa", "setaasa" etc?
If this comes from a specification, then I'd tend to just copy it rather
than invent our own thing. Obviously if is something structured
fundamentally different from how DT is designed, then we wouldn't. But
this is just a simple property.
Rob
^ permalink raw reply
* Re: [PATCH v4 5/8] dt-bindings: i2c: realtek,rtl9301-i2c: extend for clocks and RTL9607C support
From: Rustam Adilov @ 2026-03-26 14:59 UTC (permalink / raw)
To: Conor Dooley
Cc: Chris Packham, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, linux-kernel
In-Reply-To: <20260324-musty-tapering-f7700d6ed947@spud>
On 2026-03-24 17:48, Conor Dooley wrote:
> On Tue, Mar 24, 2026 at 03:30:34PM +0000, Rustam Adilov wrote:
>> Hello,
>> On 2026-03-23 19:41, Conor Dooley wrote:
>> > On Mon, Mar 23, 2026 at 12:13:34PM +0500, Rustam Adilov wrote:
>> >> Add the "realtek,rtl9607-i2c" compatible for i2c controller on the
>> >> RTL9607C SoC series.
>> >>
>> >> Add a clocks property to the properties to describe the i2c reference
>> >> clock and make it available for all the compatibles. This i2c reference
>> >
>> > Why? I can see that you're doing that, and it's good to know that that
>> > is intentional, but why is it being done? Need to explain that all of
>> > these devices actually do have this clock etc.
>>
>> As far as available information goes, there are some datasheets that
>> note
>> the existence of these clocks. For example, RTL9310 Developer Guide
>> 1.0 in [1]
>> mentions "I2C master support 12 peripherals with 2 clocks" at page 19.
>
>> I hope this explains the whole intention behind it. And if there is
>> better way to explain
>> this in the commit message, let me know.
>
> What you need to say in the commit message effectively boils down to
> "the existing devices have these clocks too".
Alrighty then, will update the commit message in the next patch series.
Thanks,
Rustam
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: remoteproc: k3-r5f: Add memory-region-names
From: Rob Herring (Arm) @ 2026-03-26 14:53 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Vignesh Raghavendra, devicetree, linux-kernel, Kevin Hilman,
Akashdeep Kaur, linux-arm-kernel, Sebin Francis,
Krzysztof Kozlowski, Conor Dooley, Mathieu Poirier, Suman Anna,
Dhruva Gole, Vishal Mahaveer, Nishanth Menon, Kendall Willis,
Bjorn Andersson, Tero Kristo, linux-remoteproc
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-2-c41473cb23c3@baylibre.com>
On Wed, 18 Mar 2026 16:13:08 +0100, Markus Schneider-Pargmann (TI) wrote:
> Add names to the memory-region-names for easier identification of memory
> regions. As the meaning of the second memory region can be different
> also require the use of memory-region-names if memory-region is in use.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: remoteproc: k3-r5f: Split up memory regions
From: Rob Herring (Arm) @ 2026-03-26 14:53 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: linux-remoteproc, Vignesh Raghavendra, Dhruva Gole,
Kendall Willis, linux-kernel, Conor Dooley, Tero Kristo,
Kevin Hilman, linux-arm-kernel, Mathieu Poirier,
Krzysztof Kozlowski, Akashdeep Kaur, Bjorn Andersson, Suman Anna,
Vishal Mahaveer, Nishanth Menon, Sebin Francis, devicetree
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-1-c41473cb23c3@baylibre.com>
On Wed, 18 Mar 2026 16:13:07 +0100, Markus Schneider-Pargmann (TI) wrote:
> Split up the region reserved for the firmware image in more specific
> sections to expose the full fixed layout. Especially the LPM metadata
> section is important for bootloaders as it contains information about
> how to exit IO+DDR. This is read by the bootloader but is written by the
> firmware.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 29 ++++++++++++++--------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy @ 2026-03-26 14:49 UTC (permalink / raw)
To: Bryan O'Donoghue, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <5d7d5bf8-4420-4d75-b928-820bb9233e52@kernel.org>
On 3/26/26 16:42, Bryan O'Donoghue wrote:
> On 26/03/2026 10:28, Vladimir Zapolskiy wrote:
>> On 3/26/26 04:03, Bryan O'Donoghue wrote:
>>> On 26/03/2026 01:46, Vladimir Zapolskiy wrote:
>>>> On 3/26/26 03:04, Bryan O'Donoghue wrote:
>>>>> Add a base schema initially compatible with x1e80100 to describe MIPI
>>>>> CSI2
>>>>> PHY devices.
>>>>>
>>>>> The hardware can support both CPHY, DPHY and a special split-mode
>>>>> DPHY. We
>>>>> capture those modes as:
>>>>>
>>>>> - PHY_QCOM_CSI2_MODE_DPHY
>>>>> - PHY_QCOM_CSI2_MODE_CPHY
>>>>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>>>>
>>>> Distinction between PHY_QCOM_CSI2_MODE_DPHY and
>>>> PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>>>> is
>>>> 1) insufficient in just this simplistic form, because the assignment of
>>>> particular lanes is also needed,
>>>> 2) and under the assumption that the lane mapping is set somewhere else,
>>>> then
>>>> there should be no difference between PHY_QCOM_CSI2_MODE_{DPHY,SPLIT_DPHY},
>>>> it's just DPHY, and the subtype is deductible from data-lanes property on
>>>> the consumer side.
>>>>
>>>> So far the rationale is unclear, why anything above regular PHY_TYPE_DPHY
>>>> and PHY_TYPE_CPHY is needed here, those two are sufficient.
>>>
>>> Because knowing the split-mode exists and that you have asked about how
>>> such a thing would be supported, I thought about how to represent that
>>> mode right from the start, even if we don't support it.
>>
>> It is good to think about this hardware confguration in advance, however
>> the process of describing such hardware setup is incomplete.
>>
>>>
>>> To support split phy we will need to pass the parameter.
>>
>> What you call "split phy" is a DPHY, and "split phy" can not be supported
>> by adding this parameter, because it does not provide information about
>> lanes, and after removing this information it is just DPHY.
>
> That's just not true. If you read the camx source code you can see
> split/combo mode 2+1 1+1 data/clock mode requires special programming of
> the PHY to support.
Please do not reduce the upraised problem of proper hardware description
to some particular realisation in camx, this is irrelevant.
Here the description of hardware is done, and my point is that the new
PHY_QCOM_CSI2_MODE_SPLIT_DPHY phy type is simply not needed, since it's
possible to give a proper description of hardware without this invention.
> https://review.lineageos.org/c/LineageOS/android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#b285
>
> There is disjunction all over this file depending on the mode.
>
> https://review.lineageos.org/c/LineageOS/android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#b767
>
> And besides, think about it - you need different init sequences if one
> of the lanes is clock instead of data...
>
> If we use phy.h::PHY_TYPE_DPHY then that means to support split-mode in
> the future we need to get that mode represented in phy.h - but really
> this fixed split mode isn't a generic CSI2 PHY mode, its a Qualcommism.
>
> Nothing wrong with that - but then the mode should reflect the fact it
> is vendor specific and we absolutely 100% have to do different things in
> the PHY driver whether we are in regular DPHY mode or in split DPHY mode.
>
> If we use PHY_TYPE_DPHY as I did in the previous patch then we can't
> convert to a vendor type later on as its an ABI break.
>
> So we have both a sound technical reason hardware will require it to
> differentiate between DPHY and split-mode DPHY - and we also don't want
> to be bound to phy.h and then try to upstream a new DPHY_SPLIT_MODE here
> which a reviewer might reasonably say "why is this special mode from a
> specific vendor driving new defines in a shared file"
>
>>
>>> So we define those parameters upfront.
>>
>> This new header file has to be removed, it does not bring anything valuable.
>>
>>>>
>>>>>
>>>>> The CSIPHY devices have their own pinouts on the SoC as well as their own
>>>>> individual voltage rails.
>>>>>
>>>>> The need to model voltage rails on a per-PHY basis leads us to define
>>>>> CSIPHY devices as individual nodes.
>>>>>
>>>>> Two nice outcomes in terms of schema and DT arise from this change.
>>>>>
>>>>> 1. The ability to define on a per-PHY basis voltage rails.
>>>>> 2. The ability to require those voltage.
>>>>>
>>>>> We have had a complete bodge upstream for this where a single set of
>>>>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>>>>
>>>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI
>>>>> bus in
>>>>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>>>>
>>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>>> ---
>>>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 130 +++++++++++
>>>>> ++++++++++
>>>>> include/dt-bindings/phy/phy-qcom-mipi-csi2.h | 15 +++
>>>>> 2 files changed, 145 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-
>>>>> phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-
>>>>> phy.yaml
>>>>> new file mode 100644
>>>>> index 0000000000000..63114151104b4
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>>>> @@ -0,0 +1,130 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Qualcomm CSI2 PHY
>>>>> +
>>>>> +maintainers:
>>>>> + - Bryan O'Donoghue <bod@kernel.org>
>>>>> +
>>>>> +description:
>>>>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2
>>>>> sensors
>>>>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and
>>>>> D-PHY
>>>>> + modes.
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + const: qcom,x1e80100-csi2-phy
>>>>> +
>>>>> + reg:
>>>>> + maxItems: 1
>>>>> +
>>>>> + "#phy-cells":
>>>>> + const: 1
>>>>> + description:
>>>>> + The single cell specifies the PHY operating mode.
>>>>> + See include/dt-bindings/phy/phy-qcom-mipi-csi2.h for valid values.
>>>>
>>>> include/dt-bindings/phy/phy.h should be good enough as it's stated above.
>>>
>>> While include/dt-bindings/phy/phy.h provides generic definitions for
>>> D-PHY and C-PHY, it does not contain a definition for Qualcomm's
>>> proprietary Split D-PHY mode. Because this hardware supports a
>>
>> What Qualcomm's proprietary Split D-PHY mode is manifested by lane mapping,
>> there is no need to introduce another PHY mode, it is DPHY.
>>
>>> vendor-specific operating mode, introducing a vendor-specific header to
>>> define that state is necessary.
>>>
>>> This is exactly what we do with the QMP to support a similar use-case -
>>> the PHYs do vendor specific things, so we use vendor specific defines.
>>>
>>> If we lock to phy.h CPHY/DPHY only then we exclude the possibility of
>>> say adding split-mode to an upstream SoC as the DT ABI will not then
>>> facilitate the mode.
>>>
>>>>
>>>>> +
>>>>> + clocks:
>>>>> + maxItems: 2
>>>>> +
>>>>> + clock-names:
>>>>> + items:
>>>>> + - const: core
>>>>> + - const: timer
>>>>> +
>>>>> + interrupts:
>>>>> + maxItems: 1
>>>>> +
>>>>> + operating-points-v2:
>>>>> + maxItems: 1
>>>>> +
>>>>> + power-domains:
>>>>> + items:
>>>>> + - description: MXC or MXA voltage rail
>>>>> + - description: MMCX voltage rail
>>>>> +
>>>>> + power-domain-names:
>>>>> + items:
>>>>> + - const: mx
>>>>> + - const: mmcx
>>>>> +
>>>>> + vdda-0p9-supply:
>>>>> + description: Phandle to a 0.9V regulator supply to a PHY.
>>>>> +
>>>>> + vdda-1p2-supply:
>>>>> + description: Phandle to 1.2V regulator supply to a PHY.
>>>>> +
>>>>> +required:
>>>>> + - compatible
>>>>> + - reg
>>>>> + - "#phy-cells"
>>>>> + - clocks
>>>>> + - clock-names
>>>>> + - interrupts
>>>>> + - operating-points-v2
>>>>> + - power-domains
>>>>> + - power-domain-names
>>>>> + - vdda-0p9-supply
>>>>> + - vdda-1p2-supply
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> + - |
>>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>>>>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>>>>> + #include <dt-bindings/phy/phy-qcom-mipi-csi2.h>
>>>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>>>> +
>>>>> + csiphy4: csiphy@ace4000 {
>>>>> + compatible = "qcom,x1e80100-csi2-phy";
>>>>> + reg = <0x0ace4000 0x2000>;
>>>>> + #phy-cells = <1>;
>>>>> +
>>>>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>>>>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
>>>>> + clock-names = "core",
>>>>> + "timer";
>>>>> +
>>>>> + operating-points-v2 = <&csiphy_opp_table>;
>>>>> +
>>>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>>>> +
>>>>> + power-domains = <&rpmhpd RPMHPD_MX>,
>>>>> + <&rpmhpd RPMHPD_MMCX>;
>>>>> + power-domain-names = "mx",
>>>>> + "mmcx";
>>>>> +
>>>>> + vdda-0p9-supply = <&vreg_l2c_0p8>;
>>>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>>>> + };
>>>>> +
>>>>> + csiphy_opp_table: opp-table {
>>>>> + compatible = "operating-points-v2";
>>>>> +
>>>>> + opp-300000000 {
>>>>> + opp-hz = /bits/ 64 <300000000>;
>>>>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>>>>> + <&rpmhpd_opp_low_svs_d1>;
>>>>> + };
>>>>> +
>>>>> + opp-400000000 {
>>>>> + opp-hz = /bits/ 64 <400000000>;
>>>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>>>> + <&rpmhpd_opp_low_svs>;
>>>>> + };
>>>>> +
>>>>> + opp-480000000 {
>>>>> + opp-hz = /bits/ 64 <480000000>;
>>>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>>>> + <&rpmhpd_opp_low_svs>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + isp@acb7000 {
>>>>> + phys = <&csiphy4 PHY_QCOM_CSI2_MODE_DPHY>;
>>>>> + };
>>>>
>>>> This example is incomplete in sense that it does not include CAMSS
>>>> CSIPHY IP hardware configuration in whole.
>>>
>>>
>>> No that's not the way examples work. You don't replicate entire nodes
>>> from other schemas you just give a terse reference.
>>>
>>
>> If so, then this example makes no sense and it'd be better to remove it.
> You know you're right its not strictly necessary - its just there to be
> helpful.
>
> "Be less helpful" is not usually review feedback I give or take but,
> I'll drop this anyway.
>
Thank you.
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH net-next] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Ronald Claveau @ 2026-03-26 14:47 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
van Spriel
Cc: linux-wireless, devicetree, linux-kernel, Conor Dooley,
Ronald Claveau
Add bcm43752 compatible with its bcm4329 compatible fallback.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
The Khadas VIM4 board based on Amlogic A311D2 aka T7 features an AP6275s Wi-Fi/Bluetooth module with a BCM43752 chipset.
This patch aims to add this chipset with its fallback to bcm4329 compatible.
The original patch series is here:
https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr
---
Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index 3be7576787644..81fd3e37452a6 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -42,6 +42,7 @@ properties:
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
- brcm,bcm4366-fmac
+ - brcm,bcm43752-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
- infineon,cyw43439-fmac
---
base-commit: 45b2b84ac6fde39c427018d6cdf7d44258938faa
change-id: 20260326-add-bcm43752-compatible-e264a4f7973a
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
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