* [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:41 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, Srinivas Kandagatla
For some reason we ended up adding only 4 out of 11 compute cb's for
CDSP, add the missing compute cb. This will also improve the end
user-experience by enabling running multiple AI usecases in parallel.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 10e799dd4a78..38fbd44c7d8f 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -7739,6 +7739,55 @@ compute-cb@4 {
<&apps_smmu 0x1964 0x0400>;
dma-coherent;
};
+
+ compute-cb@5 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <&apps_smmu 0x19c5 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@6 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <6>;
+ iommus = <&apps_smmu 0x19c6 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@7 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <7>;
+ iommus = <&apps_smmu 0x19c7 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@8 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <8>;
+ iommus = <&apps_smmu 0x19c8 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@9 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <9>;
+ iommus = <&apps_smmu 0x19c9 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@11 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xb>;
+ iommus = <&apps_smmu 0x19cb 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@12 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xc>;
+ iommus = <&apps_smmu 0x19cc 0x000>;
+ dma-coherent;
+ };
};
};
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 15:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <acUzKYUCbUOIOrw2@baldur>
On 3/26/26 1:24 PM, Bjorn Andersson wrote:
> On Thu, Mar 26, 2026 at 12:58:34PM +0000, Srinivas Kandagatla wrote:
>> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> [..]
>> +
>> + compute-cb@b {
>
> That doesn't match the patternProperties "(compute-)?cb@[0-9]*$".
>
> Is the reg an index, or an "address"? Should we use base 10, or should
> we fix the yaml?
Ah.. sorry for this, will fix this in next spin,
--srini
>
> Regards,
> Bjorn
>
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <0xb>;
>> + iommus = <&apps_smmu 0x19cb 0x0400>;
>> + dma-coherent;
>> + };
>> +
>> + compute-cb@c {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <0xc>;
>> + iommus = <&apps_smmu 0x19cc 0x000>;
>> + dma-coherent;
>> + };
>> };
>> };
>> };
>> --
>> 2.47.3
>>
^ permalink raw reply
* Re: [PATCH 04/22] dt-bindings: dma: renesas,rz-dmac: Document optional DMA ACK cell
From: Geert Uytterhoeven @ 2026-03-26 15:27 UTC (permalink / raw)
To: John Madieu
Cc: Kuninori Morimoto, Vinod Koul, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260319155334.51278-5-john.madieu.xa@bp.renesas.com>
Hi John,
On Thu, 19 Mar 2026 at 16:55, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Some peripherals on RZ/V2H, RZ/V2N, and RZ/G3E SoCs require explicit
> ACK signal routing through the ICU. Document the optional second cell
> in the DMA specifier for specifying the ACK signal number.
>
> The first cell remains unchanged and specifies the encoded MID/RID and
> channel configuration. The optional second cell specifies the DMA ACK
> signal number for peripherals requiring level-based handshaking.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Thanks for your patch!
Just a quick head-up, as I haven't read the actual secion in the
documentation yet.
> --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> @@ -63,17 +63,27 @@ properties:
> - const: register
>
> '#dma-cells':
> - const: 1
> - description:
> + description: |
> The cell specifies the encoded MID/RID or the REQ No values of
> the DMAC port connected to the DMA client and the slave channel
> configuration parameters.
> + Use 1 cell for basic DMA configuration.
> + Use 2 cells when DMA ACK signal routing through ICU is required
> + (RZ/V2H, RZ/V2N, RZ/G3E audio peripherals such as SSIU, SPDIF, SRC, DVC).
> +
> + First cell:
> bits[0:9] - Specifies the MID/RID or the REQ No value
> bit[10] - Specifies DMA request high enable (HIEN)
> bit[11] - Specifies DMA request detection type (LVL)
> bits[12:14] - Specifies DMAACK output mode (AM)
> bit[15] - Specifies Transfer Mode (TM)
>
> + Second cell (optional, when #dma-cells = <2>):
> + bits[6:0] - DMA acknowledge signal number (from ICU ACK table),
> + where 0 is a valid signal number.
> + Required for peripherals using level-based DMA
> + handshaking (SSIU, SPDIF, RSPI, SCU, ADC, PDM).
How do you expect this to work? #dma-cells applies to all DMA consumers
of this provider, and these SoCs already have DMA users relying on
#dma-cells being one.
In addition, you cannot have optional cells: if #dma-cells is two,
then all consumers must supply two cells (of course we could switch
all of them to two cells at once). However, as zero is a valid signal
number, we cannot use that as a dummy when no DMA acknowledge signal
number is needed (we could use e.g. 0xffffffff instead).
Is there any other way to provide this information?
E.g. could we have a table in the driver that contains this info for
the (presumably few) MID/RID values that need it?
> +
> dma-channels:
> const: 16
>
> @@ -212,6 +222,20 @@ allOf:
> - renesas,icu
> - resets
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r9a09g057-dmac
> + then:
> + properties:
> + '#dma-cells':
> + enum: [1, 2]
> + else:
> + properties:
> + '#dma-cells':
> + const: 1
> +
> - if:
> properties:
> compatible:
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: sound: Convert pcm3060 to DT schema
From: Padmashree S S @ 2026-03-26 15:30 UTC (permalink / raw)
To: k.marinushkin, lgirdwood, broonie
Cc: robh, conor+dt, krzk+dt, linux-sound, devicetree, linux-kernel,
Padmashree S S
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
.../devicetree/bindings/sound/pcm3060.txt | 23 ----------
.../devicetree/bindings/sound/pcm3060.yaml | 45 +++++++++++++++++++
2 files changed, 45 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt b/Documentation/devicetree/bindings/sound/pcm3060.txt
deleted file mode 100644
index 97de66932d44..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm3060.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-PCM3060 audio CODEC
-
-This driver supports both I2C and SPI.
-
-Required properties:
-
-- compatible: "ti,pcm3060"
-
-- reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Optional properties:
-
-- ti,out-single-ended: "true" if output is single-ended;
- "false" or not specified if output is differential.
-
-Examples:
-
- pcm3060: pcm3060@46 {
- compatible = "ti,pcm3060";
- reg = <0x46>;
- ti,out-single-ended = "true";
- };
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.yaml b/Documentation/devicetree/bindings/sound/pcm3060.yaml
new file mode 100644
index 000000000000..a0455c9dad73
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/pcm3060.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/pcm3060.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCM3060 audio CODEC
+
+maintainers:
+ - Kirill Marinushkin <k.marinushkin@gmail.com>
+
+properties:
+ compatible:
+ const: ti,pcm3060
+
+ reg:
+ maxItems: 1
+ description: |
+ The I2C address of the device
+ or SPI chip select number.
+
+ ti,out-single-ended:
+ type: boolean
+ description: |
+ If present, the output is single-ended.
+ If absent, the output is differential.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcm3060: audio-codec@46 {
+ compatible = "ti,pcm3060";
+ reg = <0x46>;
+ ti,out-single-ended;
+ };
+ };
\ No newline at end of file
2.43.0
^ permalink raw reply related
* [PATCH v5 8/8] i2c: rtl9300: add RTL9607C i2c controller 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 support for the internal I2C controllers of RTL9607C series based
SoCs. Add register definitions, chip-specific functions and macros too.
Make use of the clk introduced from the previous patch to get the clk_div
value and use it during the rtl9607c channel configuration.
Introduce a new EXT_SCK_5MS field to the reg fields struct which is going
to be initialized by rtl9607c init function at the end of the probe.
This patch depends on all the previous patches in this patch series.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 70 ++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index b718b74afe0d..8cedffbb2964 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -57,6 +57,7 @@ enum rtl9300_i2c_reg_fields {
F_SDA_SEL,
F_BUSY,
F_CLK_DIV,
+ F_EXT_SCK_5MS,
/* keep last */
F_NUM_FIELDS
@@ -77,8 +78,10 @@ struct rtl9300_i2c_drv_data {
#define RTL9300_I2C_MUX_NCHAN 8
#define RTL9310_I2C_MUX_NCHAN 12
+#define RTL9607_I2C_MUX_NCHAN 1
#define RTL9300_I2C_MAX_DATA_LEN 16
+#define RTL9607_I2C_MAX_DATA_LEN 4
struct rtl9300_i2c {
struct regmap *regmap;
@@ -127,6 +130,14 @@ struct rtl9300_i2c_xfer {
#define RTL9310_I2C_MST_MEMADDR_CTRL 0x4
#define RTL9310_I2C_MST_DATA_CTRL 0x8
+#define RTL9607_I2C_CONFIG 0x22f50
+#define RTL9607_IO_MODE_EN 0x23014
+#define RTL9607_I2C_IND_WD 0x0
+#define RTL9607_I2C_IND_ADR 0x8
+#define RTL9607_I2C_IND_CMD 0x10
+#define RTL9607_I2C_IND_RD 0x18
+#define RTL9607_REG_ADDR_8BIT_LEN 0
+
static int rtl9300_i2c_reg_addr_set(struct rtl9300_i2c *i2c, u32 reg, u16 len)
{
int ret;
@@ -178,6 +189,27 @@ static int rtl9300_i2c_config_chan(struct rtl9300_i2c *i2c, struct rtl9300_i2c_c
return 0;
}
+static int rtl9607_i2c_config_chan(struct rtl9300_i2c *i2c, struct rtl9300_i2c_chan *chan)
+{
+ const struct rtl9300_i2c_drv_data *drv_data;
+ int ret;
+
+ if (i2c->sda_num == chan->sda_num)
+ return 0;
+
+ ret = regmap_field_write(i2c->fields[F_CLK_DIV], chan->clk_div);
+ if (ret)
+ return ret;
+
+ drv_data = device_get_match_data(i2c->dev);
+ ret = drv_data->select_scl(i2c, i2c->scl_num);
+ if (ret)
+ return ret;
+
+ i2c->sda_num = chan->sda_num;
+ return 0;
+}
+
static void rtl9300_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *chan)
{
struct rtl9300_i2c *i2c = chan->i2c;
@@ -202,6 +234,13 @@ static void rtl9300_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *ch
}
}
+static void rtl9607_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *chan)
+{
+ struct rtl9300_i2c *i2c = chan->i2c;
+
+ chan->clk_div = clk_get_rate(i2c->clk) / clock_freq - 1;
+}
+
static int rtl9300_i2c_read(struct rtl9300_i2c *i2c, u8 *buf, u8 len)
{
u32 vals[4] = {};
@@ -422,6 +461,11 @@ static int rtl9300_i2c_init(struct rtl9300_i2c *i2c)
return regmap_field_write(i2c->fields[F_RD_MODE], 0);
}
+static int rtl9607_i2c_init(struct rtl9300_i2c *i2c)
+{
+ return regmap_field_write(i2c->fields[F_EXT_SCK_5MS], 1);
+}
+
static int rtl9300_i2c_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -574,6 +618,31 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
.reg_addr_8bit_len = RTL9300_REG_ADDR_8BIT_LEN,
};
+static const struct rtl9300_i2c_drv_data rtl9607_i2c_drv_data = {
+ .field_desc = {
+ [F_SCL_SEL] = GLB_REG_FIELD(RTL9607_IO_MODE_EN, 13, 14),
+ [F_EXT_SCK_5MS] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 26, 26),
+ [F_DEV_ADDR] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 14, 20),
+ [F_MEM_ADDR_WIDTH] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 12, 13),
+ [F_DATA_WIDTH] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 10, 11),
+ [F_CLK_DIV] = MST_REG_FIELD(RTL9607_I2C_CONFIG, 0, 9),
+ [F_I2C_FAIL] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 3, 3),
+ [F_BUSY] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 2, 2),
+ [F_RWOP] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 1, 1),
+ [F_I2C_TRIG] = MST_REG_FIELD(RTL9607_I2C_IND_CMD, 0, 0),
+ [F_MEM_ADDR] = MST_REG_FIELD(RTL9607_I2C_IND_ADR, 0, 31),
+ },
+ .select_scl = rtl9310_i2c_select_scl,
+ .config_chan = rtl9607_i2c_config_chan,
+ .config_clock = rtl9607_i2c_config_clock,
+ .misc_init = rtl9607_i2c_init,
+ .rd_reg = RTL9607_I2C_IND_RD,
+ .wd_reg = RTL9607_I2C_IND_WD,
+ .max_nchan = RTL9607_I2C_MUX_NCHAN,
+ .max_data_len = RTL9607_I2C_MAX_DATA_LEN,
+ .reg_addr_8bit_len = RTL9607_REG_ADDR_8BIT_LEN,
+};
+
static const struct of_device_id i2c_rtl9300_dt_ids[] = {
{ .compatible = "realtek,rtl9301-i2c", .data = (void *) &rtl9300_i2c_drv_data },
{ .compatible = "realtek,rtl9302b-i2c", .data = (void *) &rtl9300_i2c_drv_data },
@@ -583,6 +652,7 @@ static const struct of_device_id i2c_rtl9300_dt_ids[] = {
{ .compatible = "realtek,rtl9311-i2c", .data = (void *) &rtl9310_i2c_drv_data },
{ .compatible = "realtek,rtl9312-i2c", .data = (void *) &rtl9310_i2c_drv_data },
{ .compatible = "realtek,rtl9313-i2c", .data = (void *) &rtl9310_i2c_drv_data },
+ { .compatible = "realtek,rtl9607-i2c", .data = (void *) &rtl9607_i2c_drv_data },
{}
};
MODULE_DEVICE_TABLE(of, i2c_rtl9300_dt_ids);
--
2.53.0
^ permalink raw reply related
* [PATCH v5 7/8] i2c: rtl9300: intoduce new function properties 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>
Due to the very nature of differences between RTL9607C i2c controller
and RTL9300 / RTL9310 that are incompatible with each other in some areas
of this driver, for example in clock configuration, channel configuration
and initialization at the end of the probe, introduce new function
properties to the driver data struct to handle those differences.
With these new properties, create configuration functions for RTL9300 and
RTL9310 and assign them to their respective driver data structs.
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/i2c/busses/i2c-rtl9300.c | 66 +++++++++++++++++++++-----------
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9300.c
index 16af49ccd1dd..b718b74afe0d 100644
--- a/drivers/i2c/busses/i2c-rtl9300.c
+++ b/drivers/i2c/busses/i2c-rtl9300.c
@@ -65,6 +65,9 @@ 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);
+ int (*config_chan)(struct rtl9300_i2c *i2c, struct rtl9300_i2c_chan *chan);
+ void (*config_clock)(u32 clock_freq, struct rtl9300_i2c_chan *chan);
+ int (*misc_init)(struct rtl9300_i2c *i2c);
u32 rd_reg;
u32 wd_reg;
u8 max_nchan;
@@ -175,6 +178,30 @@ static int rtl9300_i2c_config_chan(struct rtl9300_i2c *i2c, struct rtl9300_i2c_c
return 0;
}
+static void rtl9300_i2c_config_clock(u32 clock_freq, struct rtl9300_i2c_chan *chan)
+{
+ struct rtl9300_i2c *i2c = chan->i2c;
+
+ switch (clock_freq) {
+ case I2C_MAX_STANDARD_MODE_FREQ:
+ chan->bus_freq = RTL9300_I2C_STD_FREQ;
+ break;
+ case I2C_MAX_FAST_MODE_FREQ:
+ chan->bus_freq = RTL9300_I2C_FAST_FREQ;
+ break;
+ case RTL9300_I2C_MAX_SUPER_FAST_FREQ:
+ chan->bus_freq = RTL9300_I2C_SUPER_FAST_FREQ;
+ break;
+ case RTL9300_I2C_MAX_SLOW_FREQ:
+ chan->bus_freq = RTL9300_I2C_SLOW_FREQ;
+ break;
+ default:
+ dev_warn(i2c->dev, "SDA%d clock-frequency %d not supported using default\n",
+ chan->sda_num, clock_freq);
+ break;
+ }
+}
+
static int rtl9300_i2c_read(struct rtl9300_i2c *i2c, u8 *buf, u8 len)
{
u32 vals[4] = {};
@@ -322,7 +349,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);
+ ret = drv_data->config_chan(i2c, chan);
if (ret)
return ret;
@@ -389,6 +416,12 @@ static struct i2c_adapter_quirks rtl9300_i2c_quirks = {
.max_write_len = 16,
};
+static int rtl9300_i2c_init(struct rtl9300_i2c *i2c)
+{
+ /* only use standard read format */
+ return regmap_field_write(i2c->fields[F_RD_MODE], 0);
+}
+
static int rtl9300_i2c_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -453,27 +486,11 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
if (ret)
clock_freq = I2C_MAX_STANDARD_MODE_FREQ;
- switch (clock_freq) {
- case I2C_MAX_STANDARD_MODE_FREQ:
- chan->bus_freq = RTL9300_I2C_STD_FREQ;
- break;
- case I2C_MAX_FAST_MODE_FREQ:
- chan->bus_freq = RTL9300_I2C_FAST_FREQ;
- break;
- case RTL9300_I2C_MAX_SUPER_FAST_FREQ:
- chan->bus_freq = RTL9300_I2C_SUPER_FAST_FREQ;
- break;
- case RTL9300_I2C_MAX_SLOW_FREQ:
- chan->bus_freq = RTL9300_I2C_SLOW_FREQ;
- break;
- default:
- dev_warn(i2c->dev, "SDA%d clock-frequency %d not supported using default\n",
- sda_num, clock_freq);
- break;
- }
-
chan->sda_num = sda_num;
chan->i2c = i2c;
+
+ drv_data->config_clock(clock_freq, chan);
+
adap = &i2c->chans[i].adap;
adap->owner = THIS_MODULE;
adap->algo = &rtl9300_i2c_algo;
@@ -491,8 +508,7 @@ static int rtl9300_i2c_probe(struct platform_device *pdev)
}
i2c->sda_num = 0xff;
- /* only use standard read format */
- ret = regmap_field_write(i2c->fields[F_RD_MODE], 0);
+ ret = drv_data->misc_init(i2c);
if (ret)
return ret;
@@ -521,6 +537,9 @@ static const struct rtl9300_i2c_drv_data rtl9300_i2c_drv_data = {
[F_BUSY] = MST_REG_FIELD(RTL9300_I2C_MST_CTRL1, 0, 0),
},
.select_scl = rtl9300_i2c_select_scl,
+ .config_chan = rtl9300_i2c_config_chan,
+ .config_clock = rtl9300_i2c_config_clock,
+ .misc_init = rtl9300_i2c_init,
.rd_reg = RTL9300_I2C_MST_DATA_WORD0,
.wd_reg = RTL9300_I2C_MST_DATA_WORD0,
.max_nchan = RTL9300_I2C_MUX_NCHAN,
@@ -545,6 +564,9 @@ static const struct rtl9300_i2c_drv_data rtl9310_i2c_drv_data = {
[F_BUSY] = MST_REG_FIELD(RTL9310_I2C_MST_CTRL, 0, 0),
},
.select_scl = rtl9310_i2c_select_scl,
+ .config_chan = rtl9300_i2c_config_chan,
+ .config_clock = rtl9300_i2c_config_clock,
+ .misc_init = rtl9300_i2c_init,
.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 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
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