* [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Milos crypto engine
From: Alexander Koskovich @ 2026-04-06 2:10 UTC (permalink / raw)
To: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-crypto, linux-arm-msm, devicetree, linux-kernel,
Alexander Koskovich
In-Reply-To: <20260405-milos-qce-v1-0-6996fb0b8a9c@pm.me>
Document the crypto engine on the Milos platform.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index 79d5be2548bc..74a121d8b2a5 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -46,6 +46,7 @@ properties:
- items:
- enum:
- qcom,kaanapali-qce
+ - qcom,milos-qce
- qcom,qcs615-qce
- qcom,qcs8300-qce
- qcom,sa8775p-qce
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: qcom: milos: Add QCrypto support
From: Alexander Koskovich @ 2026-04-06 2:09 UTC (permalink / raw)
To: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-crypto, linux-arm-msm, devicetree, linux-kernel,
Alexander Koskovich
Add the dt-bindings and device tree nodes for the Qualcomm Crypto
Engine (QCE) and its associated BAM DMA controller on the Milos
platform.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Alexander Koskovich (2):
dt-bindings: crypto: qcom-qce: Document the Milos crypto engine
arm64: dts: qcom: milos: Add QCrypto nodes
.../devicetree/bindings/crypto/qcom-qce.yaml | 1 +
arch/arm64/boot/dts/qcom/milos.dtsi | 32 ++++++++++++++++++++++
2 files changed, 33 insertions(+)
---
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
change-id: 20260405-milos-qce-a90710570bcf
Best regards,
--
Alexander Koskovich <akoskovich@pm.me>
^ permalink raw reply
* [PATCH] dt-bindings: rtc: moxa,moxart-rtc: convert to YAML
From: Avi Radinsky @ 2026-04-06 1:31 UTC (permalink / raw)
To: alexandre.belloni, robh
Cc: krzk+dt, conor+dt, linux-rtc, devicetree, linux-kernel
Convert the MOXA ART Real Time Clock text binding to YAML schema.
Signed-off-by: Avi Radinsky <avi.radinsky@gmail.com>
---
.../bindings/rtc/moxa,moxart-rtc.txt | 17 --------
.../bindings/rtc/moxa,moxart-rtc.yaml | 43 +++++++++++++++++++
2 files changed, 43 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
deleted file mode 100644
index 1374df7bf9d6..000000000000
--- a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-MOXA ART real-time clock
-
-Required properties:
-
-- compatible : Should be "moxa,moxart-rtc"
-- rtc-sclk-gpios : RTC sclk gpio, with zero flags
-- rtc-data-gpios : RTC data gpio, with zero flags
-- rtc-reset-gpios : RTC reset gpio, with zero flags
-
-Example:
-
- rtc: rtc {
- compatible = "moxa,moxart-rtc";
- rtc-sclk-gpios = <&gpio 5 0>;
- rtc-data-gpios = <&gpio 6 0>;
- rtc-reset-gpios = <&gpio 7 0>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
new file mode 100644
index 000000000000..9693c96a9f27
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/moxa,moxart-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MOXA ART Real Time Clock
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ const: moxa,moxart-rtc
+
+ rtc-sclk-gpios:
+ maxItems: 1
+ description: GPIO line for the RTC serial clock.
+
+ rtc-data-gpios:
+ maxItems: 1
+ description: GPIO line for the RTC data input/output.
+
+ rtc-reset-gpios:
+ maxItems: 1
+ description: GPIO line for the RTC reset.
+
+required:
+ - compatible
+ - rtc-sclk-gpios
+ - rtc-data-gpios
+ - rtc-reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc {
+ compatible = "moxa,moxart-rtc";
+ rtc-sclk-gpios = <&gpio 5 0>;
+ rtc-data-gpios = <&gpio 6 0>;
+ rtc-reset-gpios = <&gpio 7 0>;
+ };
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 2/7] dt-bindings: display/msm: dp-controller: Allow DAI on SM8650
From: Dmitry Baryshkov @ 2026-04-06 1:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Krzysztof Kozlowski, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kuogee Hsieh, Neil Armstrong, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel
In-Reply-To: <c17e30a7-6aeb-44d8-b3ad-b417bd188dd3@kernel.org>
On Sun, Apr 05, 2026 at 08:54:14AM +0200, Krzysztof Kozlowski wrote:
> On 05/04/2026 00:04, Dmitry Baryshkov wrote:
> > On Thu, Apr 02, 2026 at 01:45:13PM +0200, Krzysztof Kozlowski wrote:
> >> DisplayPort on Qualcomm SM8650 (and compatible SM8750) supports audio
> >> and there is DTS already having cells and sound-name-prefix. Add SM8650
> >> to the list of SoCs referencing the dai-common.yaml schema to solve
> >> dtbs_check warnings like:
> >>
> >> sm8650-hdk-display-card-rear-camera-card.dtb:
> >> displayport-controller@af54000 (qcom,sm8650-dp): Unevaluated properties are not allowed ('sound-name-prefix' was unexpected)
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >> ---
> >> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> index e4f17d29343b..f8daaee8d065 100644
> >> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> @@ -210,6 +210,7 @@ allOf:
> >> enum:
> >> - qcom,glymur-dp
> >> - qcom,sa8775p-dp
> >> + - qcom,sm8650-dp
> >> - qcom,x1e80100-dp
> >> then:
> >> $ref: /schemas/sound/dai-common.yaml#
> >
> > This clause is for the platforms which can work either with the eDP
> > (aux-bus) or DP (sound-dai-cells) setup. Instead please extend the else
> > clause to $ref dai-common.yaml.
>
> OK, this binding is not getting readable...
Feel free to propose ways to improve it, constructive feedback is really
appreciated.
>
> Best regards,
> Krzysztof
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/3] iio: adc: qcom-pm8xxx-xoadc: remove redundant error logs when reading values
From: Dmitry Baryshkov @ 2026-04-06 1:07 UTC (permalink / raw)
To: Antony Kurniawan Soemardi
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, linux-arm-msm, devicetree, linux-kernel,
linux-iio, phone-devel
In-Reply-To: <20260405-pm8xxx-xoadc-label-v3-2-9fe179c283ec@smankusors.com>
On Sun, Apr 05, 2026 at 04:52:18PM +0000, Antony Kurniawan Soemardi wrote:
> Drop dev_err() logging for -EINVAL and -ETIMEDOUT cases and rely on
> return values to report errors, reducing unnecessary log noise.
>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> drivers/iio/adc/qcom-pm8xxx-xoadc.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: sm8750: Correct DPU VBIF address space size
From: Dmitry Baryshkov @ 2026-04-06 1:00 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh, Neil Armstrong,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-display-regs-v2-8-34f4024c65dc@oss.qualcomm.com>
On Sun, Apr 05, 2026 at 04:34:04PM +0200, Krzysztof Kozlowski wrote:
> VBIF register range is 0x3000 long, so correct the code even though
> missing part seems without practical impact.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/8] dt-bindings: display/msm: qcom,eliza-mdss: Correct DPU and DP ranges in example
From: Dmitry Baryshkov @ 2026-04-06 0:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh, Neil Armstrong,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-display-regs-v2-5-34f4024c65dc@oss.qualcomm.com>
On Sun, Apr 05, 2026 at 04:34:01PM +0200, Krzysztof Kozlowski wrote:
> VBIF register range is 0x3000 long. DisplayPort block has few too short
> ranges and misses four more address spaces. Similarly first part of DSI
> space should be 0x300 long.
>
> No practical impact, except when existing code is being re-used in new
> contributions.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> .../bindings/display/msm/qcom,eliza-mdss.yaml | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/8] dt-bindings: display/msm: dp-controller: Allow DAI on SM8650 and others
From: Dmitry Baryshkov @ 2026-04-06 0:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh, Neil Armstrong,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-display-regs-v2-2-34f4024c65dc@oss.qualcomm.com>
On Sun, Apr 05, 2026 at 04:33:58PM +0200, Krzysztof Kozlowski wrote:
> DisplayPort on Qualcomm SoCs like SM8650 and compatible SM8750 supports
> audio and there is already DTS having cells and sound-name-prefix. The
> "else:" clause for non-EDP and non-aux-bus cases already requires
> '#sound-dai-cells', so it should actually reference the dai-common.yaml
> for other properties, as pointed out by dtbs_check warnings like:
>
> sm8650-hdk-display-card-rear-camera-card.dtb:
> displayport-controller@af54000 (qcom,sm8650-dp): Unevaluated properties are not allowed ('sound-name-prefix' was unexpected)
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v2:
> 1. Add dai-common.yaml reference (Dmitry)
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCh v3 11/14] ASoC: rsnd: src: Add SRC reset and clock support for RZ/G3E
From: Kuninori Morimoto @ 2026-04-06 0:15 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Geert Uytterhoeven, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
magnus.damm, Philipp Zabel, Claudiu.Beznea, Biju Das,
john.madieu@gmail.com, linux-sound@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <TY6PR01MB173772234146C4A8970EE404EFF5EA@TY6PR01MB17377.jpnprd01.prod.outlook.com>
Hi John
> > > + /*
> > > + * Below values will be filled in rsnd_src_probe()
> > > + */
> > > + struct clk *clk_scu;
> > > + struct clk *clk_scu_x2;
> > > + struct clk *clk_scu_supply;
> >
> > It is SRC specific.
> > Please move it to rsnd_src instead of rsnd_priv.
>
> Agreed. However, since rsnd_src is a per-SRC instance structure,
> I'll rather have these variables static in src.c, as the clocks
> are shared across all SRC instances but used only in that file.
> I hope this is fine for you ?
Ah, OK.
So how about to create new struct rsnd_src_clk or something,
and has above clocks, instead of using file-static, like below.
struct rsnd_priv {
...
+ void *src_clk; // I'm not sure the name ;)
void *src;
int src_nr;
...
};
+ struct rsnd_src_clk { // I'm not sure the name :)
+ struct clk *scu;
+ struct clk *scu_x2;
+ struct clk *scu_supply;
+ };
+ #define rsnd_priv_to_src_clk(priv) ((struct rsnd_src_clk *)(priv)->src_clk)
if (rsnd_priv_to_src_clk(priv))
...
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCh v3 07/14] ASoC: rsnd: ssui: Add RZ/G3E SSIU BUSIF support
From: Kuninori Morimoto @ 2026-04-06 0:05 UTC (permalink / raw)
To: John Madieu
Cc: Mark Brown, Liam Girdwood, Geert Uytterhoeven, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
magnus.damm, Philipp Zabel, Claudiu.Beznea, Biju Das,
john.madieu@gmail.com, linux-sound@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <TY6PR01MB17377F16AF407BE9C71A0E1BCFF5EA@TY6PR01MB17377.jpnprd01.prod.outlook.com>
Hi John
> > > - for (i = 0; i < 4; i++) {
> > > + for (unsigned int i = 0; i < priv->ssiu_busif_count; i++) {
> > > u32 reg = SSI_SYS_STATUS(i * 2) + offset;
> > > u32 status = rsnd_mod_read(mod, reg);
> > > u32 val = 0xf << (shift * 4);
> >
> > ssiu_busif_count is for SSIU specific, no need to have it on priv.
> > Please move it on rsnd_ssiu.
>
> Agreed. However, since this is per-SoC, I would rather use a
> file-static variable, rather thatn per ssiu instance in rsnd_ssiu.
> I hope this is fine for you.
From "meaning" point of view, both inside/outside ssiu instance are OK.
But I don't like to have it as file-static. Because it could be
overlookooked if some kind of updated was required around here in the
future (= people will consider ssiu instance).
Unless there is absolutely necessary, please keep current style.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Kuninori Morimoto @ 2026-04-05 23:52 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260403112655.167593-4-phucduc.bui@gmail.com>
Hi
Thank you for the patch
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> The FSI on r8a7740 requires the SPU clock to be enabled
> before accessing its registers.
> Without this clock, register access may lead to a system
> hang.
> Retrieve the "spu" clock in probe and enable it during
> DAI startup. Disable the clock on shutdown to match the
> audio stream lifecycle.
> This ensures safe register access and prevents system
> hangs during audio playback.
> This is required even if the FSI functional clock is
> enabled, as internal units depend on the SPU clock.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
(snip)
> @@ -1554,6 +1555,11 @@ static int fsi_dai_startup(struct snd_pcm_substream *substream,
> struct snd_soc_dai *dai)
> {
> struct fsi_priv *fsi = fsi_get_priv(substream);
> + int ret;
> +
> + ret = clk_prepare_enable(fsi->master->clk_spu);
> + if (ret)
> + return ret;
>
> fsi_clk_invalid(fsi);
If it is needed for register access, you need to call it on
fsi_hw_startup/shutdown() which cares suspend/resume too.
And I guess it need to count user, because we have FSI-A / FSI-B ?
> @@ -1963,6 +1970,13 @@ static int fsi_probe(struct platform_device *pdev)
> master->core = core;
> spin_lock_init(&master->lock);
>
> + /* SPU clock is required for FSI register access */
> + master->clk_spu = devm_clk_get(&pdev->dev, "spu");
> + if (IS_ERR(master->clk_spu)) {
> + dev_err(&pdev->dev, "Failed to get spu clock\n");
> + return PTR_ERR(master->clk_spu);
> + }
As Mark mentioned, it should be optional. Otherwise it breaks compatibility.
And we already have fsi_clk_init() for clock initialize.
spu should be handled in it.
Now, it is called if clock master (A.
(A) if (fsi_is_clk_master(fsi)) {
if (fsi->clk_cpg)
fsi_clk_init(dev, fsi, 0, 1, 1,
fsi_clk_set_rate_cpg);
else
fsi_clk_init(dev, fsi, 1, 1, 0,
fsi_clk_set_rate_external);
}
I think it (A) can be checked inside fsi_clk_init().
fsi_clk_init() is now called when .set_fmt, but it can be called
at _probe() timing ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
From: Marek Vasut @ 2026-04-05 23:44 UTC (permalink / raw)
To: devicetree
Cc: Marek Vasut, Baojun Xu, Conor Dooley, Kevin Lu,
Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Rob Herring,
Shenghao Ding, linux-kernel, linux-sound
Add missing sound-sai-cells for this codec into schema.
At the same time, drop trailing spaces from description.
Fixes: 506e0825a4c9 ("ASoC: dt-bindings: Convert ti,tas2552 to DT schema")
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Baojun Xu <baojun.xu@ti.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Kevin Lu <kevin-lu@ti.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Shenghao Ding <shenghao-ding@ti.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-sound@vger.kernel.org
---
V2: Add missing ref to dai-common and unevaluatedProperties
---
.../devicetree/bindings/sound/ti,tas2552.yaml | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2552.yaml b/Documentation/devicetree/bindings/sound/ti,tas2552.yaml
index 10369aa5f0a86..85e3ebd2acd84 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas2552.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,tas2552.yaml
@@ -12,8 +12,8 @@ maintainers:
- Baojun Xu <baojun.xu@ti.com>
description: >
- The TAS2552 can receive its reference clock via MCLK, BCLK, IVCLKIN pin or
- use the internal 1.8MHz. This CLKIN is used by the PLL. In addition to PLL,
+ The TAS2552 can receive its reference clock via MCLK, BCLK, IVCLKIN pin or
+ use the internal 1.8MHz. This CLKIN is used by the PLL. In addition to PLL,
the PDM reference clock is also selectable: PLL, IVCLKIN, BCLK or MCLK.
For system integration the dt-bindings/sound/tas2552.h header file provides
@@ -34,6 +34,9 @@ properties:
maxItems: 1
description: gpio pin to enable/disable the device
+ '#sound-dai-cells':
+ const: 0
+
required:
- compatible
- reg
@@ -41,7 +44,10 @@ required:
- iovdd-supply
- avdd-supply
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -54,6 +60,7 @@ examples:
audio-codec@41 {
compatible = "ti,tas2552";
reg = <0x41>;
+ #sound-dai-cells = <0>;
vbat-supply = <®_vbat>;
iovdd-supply = <®_iovdd>;
avdd-supply = <®_avdd>;
--
2.53.0
^ permalink raw reply related
* [net-next,PATCH v6 3/3] net: phy: realtek: Add property to enable SSC
From: Marek Vasut @ 2026-04-05 23:29 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, David S. Miller, Aleksander Jan Bajkowski,
Andrew Lunn, Conor Dooley, Eric Dumazet, Florian Fainelli,
Heiner Kallweit, Ivan Galkin, Jakub Kicinski, Krzysztof Kozlowski,
Michael Klein, Paolo Abeni, Rob Herring, Russell King,
Vladimir Oltean, devicetree
In-Reply-To: <20260405233008.148974-1-marek.vasut@mailbox.org>
Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
follows EMI improvement application note Rev. 1.2 for these PHYs.
The current implementation enables SSC for both RXC and SYSCLK clock
signals. Introduce DT properties 'realtek,clkout-ssc-enable',
'realtek,rxc-ssc-enable' and 'realtek,sysclk-ssc-enable' which control
CLKOUT, RXC and SYSCLK SSC spread spectrum clocking enablement on these
signals.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Ivan Galkin <ivan.galkin@axis.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Klein <michael@fossekall.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: netdev@vger.kernel.org
---
V2: Split SSC clock control for each CLKOUT, RXC, SYSCLK signal
V3: Update RTL8211FVD PHYCR2 comment to state this PHY has PHYCR2 register,
but SSC configuration is not supported due to different layout.
V4: - Perform all SSC configuration before disabling CLKOUT
- Perform all SSC configuration in the same order as in the SSC appnote
- Rebase on current next, retest using spectrum analyzer again
V5: s@SCC@SSC@ typo
V6: Drop RTL8211F_SSC_CLKOUT write in favor of setting PHYCR2 bit 7,12,13
---
drivers/net/phy/realtek/realtek_main.c | 127 +++++++++++++++++++++++++
1 file changed, 127 insertions(+)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 023e47ad605bd..f31969de3ba99 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -75,10 +75,18 @@
#define RTL8211F_PHYCR2 0x19
#define RTL8211F_CLKOUT_EN BIT(0)
+#define RTL8211F_SYSCLK_SSC_EN BIT(3)
#define RTL8211F_PHYCR2_PHY_EEE_ENABLE BIT(5)
+#define RTL8211F_CLKOUT_SSC_EN BIT(7)
+#define RTL8211F_CLKOUT_SSC_CAP GENMASK(13, 12)
#define RTL8211F_INSR 0x1d
+/* RTL8211F SSC settings */
+#define RTL8211F_SSC_PAGE 0xc44
+#define RTL8211F_SSC_RXC 0x13
+#define RTL8211F_SSC_SYSCLK 0x17
+
/* RTL8211F LED configuration */
#define RTL8211F_LEDCR_PAGE 0xd04
#define RTL8211F_LEDCR 0x10
@@ -215,6 +223,9 @@ MODULE_LICENSE("GPL");
struct rtl821x_priv {
bool enable_aldps;
bool disable_clk_out;
+ bool enable_clkout_ssc;
+ bool enable_rxc_ssc;
+ bool enable_sysclk_ssc;
struct clk *clk;
/* rtl8211f */
u16 iner;
@@ -278,6 +289,12 @@ static int rtl821x_probe(struct phy_device *phydev)
"realtek,aldps-enable");
priv->disable_clk_out = of_property_read_bool(dev->of_node,
"realtek,clkout-disable");
+ priv->enable_clkout_ssc = of_property_read_bool(dev->of_node,
+ "realtek,clkout-ssc-enable");
+ priv->enable_rxc_ssc = of_property_read_bool(dev->of_node,
+ "realtek,rxc-ssc-enable");
+ priv->enable_sysclk_ssc = of_property_read_bool(dev->of_node,
+ "realtek,sysclk-ssc-enable");
phydev->priv = priv;
@@ -707,6 +724,104 @@ static int rtl8211f_config_phy_eee(struct phy_device *phydev)
RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
}
+static int rtl8211f_config_clkout_ssc(struct phy_device *phydev)
+{
+ struct rtl821x_priv *priv = phydev->priv;
+ struct device *dev = &phydev->mdio.dev;
+ int ret;
+
+ /* The value is preserved if the device tree property is absent */
+ if (!priv->enable_clkout_ssc)
+ return 0;
+
+ /* RTL8211FVD has PHYCR2 register, but configuration of CLKOUT SSC
+ * is not currently supported by this driver due to different bit
+ * layout.
+ */
+ if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
+ return 0;
+
+ /* Unnamed registers from EMI improvement parameters application note 1.2 */
+ ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
+ if (ret < 0) {
+ dev_err(dev, "CLKOUT SSC initialization failed: %pe\n", ERR_PTR(ret));
+ return ret;
+ }
+
+ /* Enable CLKOUT SSC and CLKOUT SSC Capability using PHYCR2
+ * bits 7, 12, 13. This matches the register 25 write 0x38C3
+ * from the EMI improvement parameters application note 1.2
+ * section 2.3, without affecting unrelated bits.
+ */
+ ret = phy_set_bits(phydev, RTL8211F_PHYCR2,
+ RTL8211F_CLKOUT_SSC_CAP | RTL8211F_CLKOUT_SSC_EN);
+ if (ret < 0) {
+ dev_err(dev, "CLKOUT SSC enable failed: %pe\n", ERR_PTR(ret));
+ return ret;
+ }
+
+ return 0;
+}
+
+static int rtl8211f_config_rxc_ssc(struct phy_device *phydev)
+{
+ struct rtl821x_priv *priv = phydev->priv;
+ struct device *dev = &phydev->mdio.dev;
+ int ret;
+
+ /* The value is preserved if the device tree property is absent */
+ if (!priv->enable_rxc_ssc)
+ return 0;
+
+ /* RTL8211FVD has PHYCR2 register, but configuration of RXC SSC
+ * is not currently supported by this driver due to different bit
+ * layout.
+ */
+ if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
+ return 0;
+
+ ret = phy_write_paged(phydev, RTL8211F_SSC_PAGE, RTL8211F_SSC_RXC, 0x5f00);
+ if (ret < 0) {
+ dev_err(dev, "RXC SSC configuration failed: %pe\n", ERR_PTR(ret));
+ return ret;
+ }
+
+ return 0;
+}
+
+static int rtl8211f_config_sysclk_ssc(struct phy_device *phydev)
+{
+ struct rtl821x_priv *priv = phydev->priv;
+ struct device *dev = &phydev->mdio.dev;
+ int ret;
+
+ /* The value is preserved if the device tree property is absent */
+ if (!priv->enable_sysclk_ssc)
+ return 0;
+
+ /* RTL8211FVD has PHYCR2 register, but configuration of SYSCLK SSC
+ * is not currently supported by this driver due to different bit
+ * layout.
+ */
+ if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
+ return 0;
+
+ ret = phy_write_paged(phydev, RTL8211F_SSC_PAGE, RTL8211F_SSC_SYSCLK, 0x4f00);
+ if (ret < 0) {
+ dev_err(dev, "SYSCLK SSC configuration failed: %pe\n", ERR_PTR(ret));
+ return ret;
+ }
+
+ /* Enable SSC */
+ ret = phy_set_bits(phydev, RTL8211F_PHYCR2, RTL8211F_SYSCLK_SSC_EN);
+ if (ret < 0) {
+ dev_err(dev, "SYSCLK SSC enable failed: %pe\n", ERR_PTR(ret));
+ return ret;
+ }
+
+ return 0;
+}
+
static int rtl8211f_config_init(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
@@ -723,6 +838,18 @@ static int rtl8211f_config_init(struct phy_device *phydev)
if (ret)
return ret;
+ ret = rtl8211f_config_rxc_ssc(phydev);
+ if (ret)
+ return ret;
+
+ ret = rtl8211f_config_sysclk_ssc(phydev);
+ if (ret)
+ return ret;
+
+ ret = rtl8211f_config_clkout_ssc(phydev);
+ if (ret)
+ return ret;
+
ret = rtl8211f_config_clk_out(phydev);
if (ret) {
dev_err(dev, "clkout configuration failed: %pe\n",
--
2.53.0
^ permalink raw reply related
* [net-next,PATCH v6 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,*-ssc-enable property
From: Marek Vasut @ 2026-04-05 23:29 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, Krzysztof Kozlowski, David S. Miller,
Aleksander Jan Bajkowski, Andrew Lunn, Conor Dooley, Eric Dumazet,
Florian Fainelli, Heiner Kallweit, Ivan Galkin, Jakub Kicinski,
Krzysztof Kozlowski, Michael Klein, Paolo Abeni, Rob Herring,
Russell King, Vladimir Oltean, devicetree
In-Reply-To: <20260405233008.148974-1-marek.vasut@mailbox.org>
Document support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. Introduce DT properties
'realtek,clkout-ssc-enable', 'realtek,rxc-ssc-enable' and
'realtek,sysclk-ssc-enable' which control CLKOUT, RXC and SYSCLK
SSC spread spectrum clocking enablement on these signals. These
clock are not exposed via the clock API, therefore assigned-clock-sscs
property does not apply.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Ivan Galkin <ivan.galkin@axis.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Klein <michael@fossekall.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: netdev@vger.kernel.org
---
V2: Split SSC clock control for each CLKOUT, RXC, SYSCLK signal
V3: - Add RB from krzk
- Update commit subject, use realtek,*-ssc-enable to be accurate
V4: No change
V5: No change
V6: No change
---
.../devicetree/bindings/net/realtek,rtl82xx.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
index eafcc2f3e3d66..45033c31a2d51 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
@@ -50,6 +50,21 @@ properties:
description:
Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
+ realtek,clkout-ssc-enable:
+ type: boolean
+ description:
+ Enable CLKOUT SSC mode, CLKOUT SSC mode default is disabled after hardware reset.
+
+ realtek,rxc-ssc-enable:
+ type: boolean
+ description:
+ Enable RXC SSC mode, RXC SSC mode default is disabled after hardware reset.
+
+ realtek,sysclk-ssc-enable:
+ type: boolean
+ description:
+ Enable SYSCLK SSC mode, SYSCLK SSC mode default is disabled after hardware reset.
+
wakeup-source:
type: boolean
description:
--
2.53.0
^ permalink raw reply related
* [net-next,PATCH v6 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted
From: Marek Vasut @ 2026-04-05 23:29 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, Rob Herring (Arm), David S. Miller,
Aleksander Jan Bajkowski, Andrew Lunn, Conor Dooley, Eric Dumazet,
Florian Fainelli, Heiner Kallweit, Ivan Galkin, Jakub Kicinski,
Krzysztof Kozlowski, Michael Klein, Paolo Abeni, Russell King,
Vladimir Oltean, devicetree
Sort the documented properties alphabetically, no functional change.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Ivan Galkin <ivan.galkin@axis.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Klein <michael@fossekall.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: netdev@vger.kernel.org
---
V2: No change
V3: No change
V4: Add AB from Rob
V5: No change
V6: No change
---
.../devicetree/bindings/net/realtek,rtl82xx.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
index 2b5697bd7c5df..eafcc2f3e3d66 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
@@ -40,15 +40,15 @@ properties:
leds: true
- realtek,clkout-disable:
+ realtek,aldps-enable:
type: boolean
description:
- Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
+ Enable ALDPS mode, ALDPS mode default is disabled after hardware reset.
- realtek,aldps-enable:
+ realtek,clkout-disable:
type: boolean
description:
- Enable ALDPS mode, ALDPS mode default is disabled after hardware reset.
+ Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
wakeup-source:
type: boolean
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Bryan O'Donoghue @ 2026-04-05 23:02 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <20260405204722.GF1213462@killaraus.ideasonboard.com>
On 05/04/2026 21:47, Laurent Pinchart wrote:
>> So actually I've shifted my focus on Hamoa to IFE/IPP.
> I'd love to get stats out of the IFE 🙂
Yeah, I'm fiddling with stats on Hamoa IFE right now.
---
bod
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Doug Anderson @ 2026-04-05 22:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rafael J . Wysocki, Danilo Krummrich, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <2026040539-sponge-publisher-2b42@gregkh>
Hi,
On Sat, Apr 4, 2026 at 10:28 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Apr 03, 2026 at 05:04:54PM -0700, Douglas Anderson wrote:
> > NOTE: one potentially "controversial" choice I made in some patches
> > was to always reserve a flag ID even if a flag is only used under
> > certain CONFIG_ settings. This is a change from how things were
> > before. Keeping the numbering consistent and allowing easy
> > compile-testing of both CONFIG settings seemed worth it, especially
> > since it won't take up any extra space until we've added a lot more
> > flags.
>
> Nah, this is fine, I don't see any problems with this as the original
> code kind of was doing the same thing with the "hole" in the structure
> if those options were not enabled.
>
> > I only marked the first patch as a "Fix" since it is the only one
> > fixing observed problems. Other patches could be considered fixes too
> > if folks want.
> >
> > I tested the first patch in the series backported to kernel 6.6 on the
> > Pixel phone that was experiencing the race. I added extra printouts to
> > make sure that the problem was hitting / addressed. The rest of the
> > patches are tested with allmodconfig with arm32, arm64, ppc, and
> > x86. I boot tested on an arm64 Chromebook running mainline.
>
> I'm guessing your tests passed? :)
Yup, all the tests that I've run have passed. I also threw in an
"allnoconfig" compile test just for good measure.
> Anyway, this looks great, unless there are any objections, other than
> the "needs to be undefined", which a follow-on patch can handle, I'll
> queue them up next week for 7.1-rc1.
Thanks. As per the other thread, I'm happy if you or Danilo want to
apply it, and I'm happy if you want to make minor fixups when
applying.
When I see the patches applied, I'll send a followup patch to address
the "needs to be undefined" comment, unless Danilo makes that change
himself when applying.
-Doug
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: net: wireless: ath11k: Document WCN6755 WiFi
From: Jeff Johnson @ 2026-04-05 22:28 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexander Koskovich,
Liam Girdwood, Mark Brown, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Johannes Berg, Jeff Johnson
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-3-393322b27c5f@fairphone.com>
On 4/3/2026 6:52 AM, Luca Weiss wrote:
> Document the WCN6755 WiFi using a fallback to WCN6750 since the two
> chips seem to be completely pin and software compatible. In fact the
> original downstream kernel just pretends the WCN6755 is a WCN6750.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Bjorn, will you take this entire series through your tree?
Acked-by: Jeff Johnson <jjohnson@kernel.org>
^ permalink raw reply
* Re: [net-next,PATCH v5 3/3] net: phy: realtek: Add property to enable SSC
From: Marek Vasut @ 2026-04-05 21:59 UTC (permalink / raw)
To: Aleksander Jan Bajkowski, netdev
Cc: David S. Miller, Andrew Lunn, Conor Dooley, Eric Dumazet,
Florian Fainelli, Heiner Kallweit, Ivan Galkin, Jakub Kicinski,
Krzysztof Kozlowski, Michael Klein, Paolo Abeni, Rob Herring,
Russell King, Vladimir Oltean, devicetree
In-Reply-To: <a03960a2-f313-4c12-98f2-d032ce4a45ad@wp.pl>
On 4/5/26 10:23 PM, Aleksander Jan Bajkowski wrote:
Hi,
>> +static int rtl8211f_config_clkout_ssc(struct phy_device *phydev)
>> +{
>> + struct rtl821x_priv *priv = phydev->priv;
>> + struct device *dev = &phydev->mdio.dev;
>> + int ret;
>> +
>> + /* The value is preserved if the device tree property is absent */
>> + if (!priv->enable_clkout_ssc)
>> + return 0;
>> +
>> + /* RTL8211FVD has PHYCR2 register, but configuration of CLKOUT SSC
>> + * is not currently supported by this driver due to different bit
>> + * layout.
>> + */
>> + if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
>> + return 0;
>> +
>> + /* Unnamed registers from EMI improvement parameters application
>> note 1.2 */
>> + ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
>> + if (ret < 0) {
>> + dev_err(dev, "CLKOUT SSC initialization failed: %pe\n",
>> ERR_PTR(ret));
>> + return ret;
>> + }
>> +
>> + ret = phy_write(phydev, RTL8211F_SSC_CLKOUT, 0x38c3);
>
> Only registers 0x10–0x17 require paged operations. The remaining registers
> are mapped directly into the PHY address space. This is mentioned in commit
> 650e55f224a575cdb18c984b95036109519502d1. Paged and direct access return
> the same results. With this in mind, I believe that RTL8211F_SSC_CLKOUT is
> an alias for RTL8211F_PHYCR2 and is described on page 45 of the
> datasheet[1].
>
> 1. RTL8211F(I)-CG/RTL8211FD(I)-CG Datasheet
This is a good point indeed, I think I can simply set PHYCR2 bits
7,12,13 to enable the CLKOUT SSC ?
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: rp1: Add PWM node
From: Uwe Kleine-König @ 2026-04-05 21:48 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <ef79e974c6680202294a4cfde7cc791753bf1b3e.1775223441.git.andrea.porta@suse.com>
[-- Attachment #1: Type: text/plain, Size: 149 bytes --]
Hello,
The "rp1" in the Subject is very irritating. Better make this:
arm64: dts: broadcom: rpi-5: Add rp1 PWM node
or similar.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next,PATCH v5 3/3] net: phy: realtek: Add property to enable SSC
From: Marek Vasut @ 2026-04-05 21:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, David S. Miller, Aleksander Jan Bajkowski, Andrew Lunn,
Conor Dooley, Eric Dumazet, Florian Fainelli, Heiner Kallweit,
Ivan Galkin, Krzysztof Kozlowski, Michael Klein, Paolo Abeni,
Rob Herring, Russell King, Vladimir Oltean, devicetree
In-Reply-To: <20260330185721.4b94ed30@kernel.org>
On 3/31/26 3:57 AM, Jakub Kicinski wrote:
> On Thu, 26 Mar 2026 22:06:35 +0100 Marek Vasut wrote:
>> +/* RTL8211F SSC settings */
>> +#define RTL8211F_SSC_PAGE 0xc44
>> +#define RTL8211F_SSC_RXC 0x13
>> +#define RTL8211F_SSC_SYSCLK 0x17
>> +#define RTL8211F_SSC_CLKOUT 0x19
>
>> + /* Unnamed registers from EMI improvement parameters application note 1.2 */
>> + ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
>> + if (ret < 0) {
>> + dev_err(dev, "CLKOUT SSC initialization failed: %pe\n", ERR_PTR(ret));
>> + return ret;
>> + }
>> +
>> + ret = phy_write(phydev, RTL8211F_SSC_CLKOUT, 0x38c3);
>> + if (ret < 0) {
>> + dev_err(dev, "CLKOUT SSC configuration failed: %pe\n", ERR_PTR(ret));
>> + return ret;
>> + }
>
> AI flags that this, did you mean to write to the SSC_PAGE here?
No, see commit 650e55f224a5 ("net: phy: realtek: simplify bogus paged
operations")
"
net: phy: realtek: simplify bogus paged operations
Only registers 0x10~0x17 are affected by the value in the page
selection register 0x1f. Hence there is no point in using paged
operations when accessing any other registers.
...
"
Register 0x19 is not affected by paged operations.
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-05 21:45 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <28e29fbfc20c0b8a115d006233c2759d8f49e639.1775223441.git.andrea.porta@suse.com>
[-- Attachment #1: Type: text/plain, Size: 10393 bytes --]
Hello Andrea,
On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> From: Naushir Patuck <naush@raspberrypi.com>
>
> The Raspberry Pi RP1 southbridge features an embedded PWM
> controller with 4 output channels, alongside an RPM interface
> to read the fan speed on the Raspberry Pi 5.
>
> Add the supporting driver.
>
> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
> drivers/pwm/Kconfig | 10 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-rp1.c | 244 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 255 insertions(+)
> create mode 100644 drivers/pwm/pwm-rp1.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376a..22e4fc6385da2 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -625,6 +625,16 @@ config PWM_ROCKCHIP
> Generic PWM framework driver for the PWM controller found on
> Rockchip SoCs.
>
> +config PWM_RP1
I prefer PWM_RASPBERRYPI1, or PWM_RASPBERRYPI_RP1 here.
> + tristate "RP1 PWM support"
> + depends on MISC_RP1 || COMPILE_TEST
> + depends on HWMON
> + help
> + PWM framework driver for Raspberry Pi RP1 controller
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-rp1.
> +
> config PWM_SAMSUNG
> tristate "Samsung PWM support"
> depends on PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0dc0d2b69025d..895a7c42fe9c0 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_PWM_RENESAS_RZG2L_GPT) += pwm-rzg2l-gpt.o
> obj-$(CONFIG_PWM_RENESAS_RZ_MTU3) += pwm-rz-mtu3.o
> obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
> obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> +obj-$(CONFIG_PWM_RP1) += pwm-rp1.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o
> obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o
> diff --git a/drivers/pwm/pwm-rp1.c b/drivers/pwm/pwm-rp1.c
> new file mode 100644
> index 0000000000000..0a1c1c1dd27e9
> --- /dev/null
> +++ b/drivers/pwm/pwm-rp1.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pwm-rp1.c
> + *
> + * Raspberry Pi RP1 PWM.
> + *
> + * Copyright © 2026 Raspberry Pi Ltd.
> + *
> + * Author: Naushir Patuck (naush@raspberrypi.com)
> + *
> + * Based on the pwm-bcm2835 driver by:
> + * Bart Tanghe <bart.tanghe@thomasmore.be>
> + */
Please add a paragraph here named "Limitations" in the same format as
several other drivers describing how the driver behaves on disable and
configuration changes (can glitches occur? Is the currently running
period completed or aborted?)
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +#define PWM_GLOBAL_CTRL 0x000
> +#define PWM_CHANNEL_CTRL(x) (0x014 + ((x) * 0x10))
> +#define PWM_RANGE(x) (0x018 + ((x) * 0x10))
> +#define PWM_PHASE(x) (0x01C + ((x) * 0x10))
> +#define PWM_DUTY(x) (0x020 + ((x) * 0x10))
> +
> +/* 8:FIFO_POP_MASK + 0:Trailing edge M/S modulation */
> +#define PWM_CHANNEL_DEFAULT (BIT(8) + BIT(0))
> +#define PWM_CHANNEL_ENABLE(x) BIT(x)
> +#define PWM_POLARITY BIT(3)
> +#define SET_UPDATE BIT(31)
> +#define PWM_MODE_MASK GENMASK(1, 0)
> +
> +#define NUM_PWMS 4
Please prefix all #defines by something driver specific (e.g. RP1_PWM_).
> +
> +struct rp1_pwm {
> + void __iomem *base;
> + struct clk *clk;
> +};
> +
> +static const struct hwmon_channel_info * const rp1_fan_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
> + NULL
> +};
> +
> +static umode_t rp1_fan_hwmon_is_visible(const void *data, enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + umode_t mode = 0;
> +
> + if (type == hwmon_fan && attr == hwmon_fan_input)
> + mode = 0444;
> +
> + return mode;
> +}
> +
> +static int rp1_fan_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + if (type != hwmon_fan || attr != hwmon_fan_input)
> + return -EOPNOTSUPP;
> +
> + *val = readl(rp1->base + PWM_PHASE(2));
> +
> + return 0;
> +}
I don't like having hwmon bits in pwm drivers. Is the PWM only usable
for a fan? I guess the hwmon parts should be dropped and a pwm-fan
defined in dt.
> +static const struct hwmon_ops rp1_fan_hwmon_ops = {
> + .is_visible = rp1_fan_hwmon_is_visible,
> + .read = rp1_fan_hwmon_read,
> +};
> +
> +static const struct hwmon_chip_info rp1_fan_hwmon_chip_info = {
> + .ops = &rp1_fan_hwmon_ops,
> + .info = rp1_fan_hwmon_info,
> +};
> +
> +static void rp1_pwm_apply_config(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + u32 value;
> +
> + value = readl(rp1->base + PWM_GLOBAL_CTRL);
> + value |= SET_UPDATE;
> + writel(value, rp1->base + PWM_GLOBAL_CTRL);
> +}
> +
> +static int rp1_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> +
> + writel(PWM_CHANNEL_DEFAULT, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
Please add a comment about what this does.
> + return 0;
> +}
> +
> +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + u32 value;
> +
> + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> + value &= ~PWM_MODE_MASK;
> + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> +
> + rp1_pwm_apply_config(chip, pwm);
What is the purpose of this call?
> +}
> +
> +static int rp1_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> + unsigned long clk_rate = clk_get_rate(rp1->clk);
> + unsigned long clk_period;
> + u32 value;
> +
> + if (!clk_rate) {
> + dev_err(&chip->dev, "failed to get clock rate\n");
> + return -EINVAL;
> + }
> +
> + /* set period and duty cycle */
> + clk_period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, clk_rate);
DIV_ROUND_CLOSEST is wrong here. (I don't go into details as .apply()
should be dropped.)
> + writel(DIV_ROUND_CLOSEST(state->duty_cycle, clk_period),
Dividing by the result of a division loses precision.
> + rp1->base + PWM_DUTY(pwm->hwpwm));
> +
> + writel(DIV_ROUND_CLOSEST(state->period, clk_period),
> + rp1->base + PWM_RANGE(pwm->hwpwm));
> +
> + /* set polarity */
> + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> + if (state->polarity == PWM_POLARITY_NORMAL)
> + value &= ~PWM_POLARITY;
> + else
> + value |= PWM_POLARITY;
> + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> +
> + /* enable/disable */
> + value = readl(rp1->base + PWM_GLOBAL_CTRL);
> + if (state->enabled)
> + value |= PWM_CHANNEL_ENABLE(pwm->hwpwm);
> + else
> + value &= ~PWM_CHANNEL_ENABLE(pwm->hwpwm);
> + writel(value, rp1->base + PWM_GLOBAL_CTRL);
> +
> + rp1_pwm_apply_config(chip, pwm);
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops rp1_pwm_ops = {
> + .request = rp1_pwm_request,
> + .free = rp1_pwm_free,
> + .apply = rp1_pwm_apply,
Please implement the waveform callbacks instead of .apply().
> +};
> +
> +static int rp1_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device *hwmon_dev;
> + struct pwm_chip *chip;
> + struct rp1_pwm *rp1;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, NUM_PWMS, sizeof(*rp1));
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + rp1 = pwmchip_get_drvdata(chip);
> +
> + rp1->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(rp1->base))
> + return PTR_ERR(rp1->base);
> +
> + rp1->clk = devm_clk_get_enabled(dev, NULL);
> + if (IS_ERR(rp1->clk))
> + return dev_err_probe(dev, PTR_ERR(rp1->clk), "clock not found\n");
Please start error messages with a capital letter.
> +
> + ret = devm_clk_rate_exclusive_get(dev, rp1->clk);
After this call you can determine the rate just once and fail if it's ==
0.
> + if (ret)
> + return dev_err_probe(dev, ret, "fail to get exclusive rate\n");
> +
> + chip->ops = &rp1_pwm_ops;
> +
> + platform_set_drvdata(pdev, chip);
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register PWM chip\n");
> +
> + hwmon_dev = devm_hwmon_device_register_with_info(dev, "rp1_fan_tach", rp1,
> + &rp1_fan_hwmon_chip_info,
> + NULL);
> +
> + if (IS_ERR(hwmon_dev))
> + return dev_err_probe(dev, PTR_ERR(hwmon_dev),
> + "failed to register hwmon fan device\n");
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_suspend(struct device *dev)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(rp1->clk);
> +
> + return 0;
> +}
> +
> +static int rp1_pwm_resume(struct device *dev)
> +{
> + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(rp1->clk);
Hmm, if this fails and then the driver is unbound, the clk operations
are not balanced.
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(rp1_pwm_pm_ops, rp1_pwm_suspend, rp1_pwm_resume);
> +
> +static const struct of_device_id rp1_pwm_of_match[] = {
> + { .compatible = "raspberrypi,rp1-pwm" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, rp1_pwm_of_match);
> +
> +static struct platform_driver rp1_pwm_driver = {
> + .probe = rp1_pwm_probe,
> + .driver = {
> + .name = "rp1-pwm",
> + .of_match_table = rp1_pwm_of_match,
> + .pm = pm_ptr(&rp1_pwm_pm_ops),
> + },
> +};
> +module_platform_driver(rp1_pwm_driver);
> +
> +MODULE_DESCRIPTION("RP1 PWM driver");
> +MODULE_AUTHOR("Naushir Patuck <naush@raspberrypi.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.35.3
>
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Bryan O'Donoghue @ 2026-04-05 21:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <20260405204722.GF1213462@killaraus.ideasonboard.com>
On 05/04/2026 21:47, Laurent Pinchart wrote:
> Temporal denoising can also be more tricky in an inline ISP.
Funny you should mention that, to my knowledge, this is the only
functional thing BPS/IPE has that IFE/PIX does not.
---
bod
^ permalink raw reply
* Re: [PATCH net-next v2 8/9] net: dsa: lan9645x: add mdb management
From: Jens Emil Schulz Ostergaard @ 2026-04-05 21:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195637.2789256-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> Subject: net: dsa: lan9645x: add mdb management
>
> Add support for dsa mdb callbacks. L2 multicast and IP multicast is
> handled differently. IP multicast stores the port group mask inline in
> the mac table. L2 multicast points to a PGID index, which encodes the
> port group mask.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c
> > new file mode 100644
> > index 000000000000..4cf92887a4eb
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_mdb.c
> > @@ -0,0 +1,391 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (C) 2026 Microchip Technology Inc.
> > + */
> > +
> > +#include "lan9645x_main.h"
>
> [ ... ]
>
> > +static void lan9645x_mdb_encode_mac(unsigned char *mac,
> > + struct lan9645x_mdb_entry *mdb_entry,
> > + enum macaccess_entry_type type)
> > +{
> > + ether_addr_copy(mac, mdb_entry->mac);
> > +
> > + /* The HW encodes the portmask in the high bits of the mac for ip
> > + * multicast entries, to save on the limited PGID resources.
> > + *
> > + * IPv4 Multicast DMAC: 0x01005Exxxxxx
> > + * IPv6 Multicast DMAC: 0x3333xxxxxxxx
> > + *
> > + * which gives us 24 or 16 bits to encode the portmask.
> > + */
> > + if (type == ENTRYTYPE_MACV4) {
> > + mac[0] = 0;
> > + mac[1] = mdb_entry->ports >> 8;
> > + mac[2] = mdb_entry->ports & 0xff;
> > + } else if (type == ENTRYTYPE_MACV6) {
> > + mac[0] = mdb_entry->ports >> 8;
> > + mac[1] = mdb_entry->ports & 0xff;
> > + }
> > +}
>
> Does this code need to mask out BIT(CPU_PORT) from mdb_entry->ports?
>
> For L2 multicast, the CPU port is explicitly stripped from the PGID portmask
> to avoid conflicting instructions, since CPU_PORT forwarding is handled by the
> cpu_copy flag. Here, the IP multicast portmask is encoded directly into the
> MAC address using the full mdb_entry->ports. Could this cause hardware to
> receive conflicting instructions (forwarding to port 9 and copying to the CPU
> extraction queue), leading to duplicate multicast packets for the CPU?
>
No this is fine.
> [ ... ]
>
> > +static struct lan9645x_pgid_entry *
> > +lan9645x_mdb_pgid_entry_create(struct lan9645x *lan9645x, u16 ports)
> > +{
> > + struct lan9645x_pgid_entry *pgid_entry = NULL;
> > + int index;
> > +
> > + for (index = PGID_GP_START; index < PGID_GP_END; index++) {
>
> Is it safe to start the search at PGID_GP_START (defined as CPU_PORT)?
>
> Hardware uses ANA_PGID(DEST_IDX) to forward unicast traffic, and MAC table
> entries for the CPU have DEST_IDX = 9. When the first L2 multicast group is
> added, it appears this loop will allocate PGID index 9, overwriting the
> unicast portmask for the CPU port. Could this cause all unicast traffic
> destined for the CPU to be flooded to the external physical ports in the
> multicast group instead?
>
No this is safe, PGID 9 is not used to forward anything to the CPU.
> > + bool used = false;
> > +
> > + list_for_each_entry(pgid_entry, &lan9645x->pgid_entries, list) {
> > + if (pgid_entry->index == index) {
> > + used = true;
> > + break;
> > + }
> > + }
> > +
> > + if (!used)
> > + return lan9645x_pgid_entry_alloc(lan9645x, index,
> > + ports);
> > + }
> > +
> > + return ERR_PTR(-ENOSPC);
> > +}
>
> [ ... ]
>
> > +static int __lan9645x_mdb_add(struct lan9645x *lan9645x, int chip_port,
> > + const unsigned char addr[ETH_ALEN], u16 vid,
> > + enum macaccess_entry_type type)
> > +{
> > + struct lan9645x_pgid_entry *old_pgid, *new_pgid;
> > + struct lan9645x_mdb_entry *mdb_entry;
> > + unsigned char mac[ETH_ALEN];
> > + int err, pgid_index;
> > + bool cpu_copy;
> > +
> > + mdb_entry = lan9645x_mdb_entry_lookup(lan9645x, addr, vid);
> > + if (!mdb_entry) {
> > + mdb_entry = lan9645x_mdb_entry_alloc(lan9645x, addr, vid);
> > + if (IS_ERR(mdb_entry))
> > + return PTR_ERR(mdb_entry);
> > + }
> > +
> > + if (mdb_entry->ports & BIT(chip_port))
> > + return 0;
> > +
> > + mdb_entry->ports |= BIT(chip_port);
> > +
> > + /* Encode mac for IP mc */
> > + lan9645x_mdb_encode_mac(mac, mdb_entry, type);
> > +
> > + /* Update PGID ptr for non-IP entries (L2 multicast) */
> > + old_pgid = mdb_entry->pgid;
> > + new_pgid = lan9645x_mdb_pgid_entry_get(lan9645x, mdb_entry, type);
> > + if (IS_ERR(new_pgid)) {
> > + /* Out of PGIDs or mem. Continue forwarding to old port
> > + * group, or remove if fresh mdb_entry.
> > + */
> > + mdb_entry->ports &= ~BIT(chip_port);
> > + if (!mdb_entry->ports)
> > + lan9645x_mdb_entry_dealloc(lan9645x, mdb_entry);
> > +
> > + return PTR_ERR(new_pgid);
> > + }
> > + mdb_entry->pgid = new_pgid;
> > +
> > + cpu_copy = !!(mdb_entry->ports & BIT(CPU_PORT));
> > + pgid_index = lan9645x_mdb_pgid_index(mdb_entry, type);
> > +
> > + /* Make sure to write on top of existing entry, so we do not disrupt
> > + * flowing traffic.
> > + */
> > + err = lan9645x_mact_learn_cpu_copy(lan9645x, pgid_index, mac,
> > + mdb_entry->vid, type, cpu_copy);
> > + lan9645x_pgid_entry_put(lan9645x, old_pgid);
> > + return err;
> > +}
>
> What happens if lan9645x_mact_learn_cpu_copy() fails and returns an error?
>
> The software MDB state (mdb_entry->ports and mdb_entry->pgid) is updated and
> the old PGID reference is dropped via lan9645x_pgid_entry_put() before
> verifying if the hardware MAC table update succeeds.
>
> If the hardware update fails, the software state isn't rolled back, leaving
> them out of sync. Furthermore, the dropped old_pgid reference could allow the
> index to be reallocated to a new multicast group while the hardware still
> points to the old PGID index, potentially causing silent traffic cross-talk.
>
I will change the mac table write error path, so hw/sw stay synced.
> > +
> > +static int __lan9645x_mdb_del(struct lan9645x *lan9645x, int chip_port,
> > + const unsigned char addr[ETH_ALEN], u16 vid,
> > + enum macaccess_entry_type type)
> > +{
> > + struct lan9645x_pgid_entry *old_pgid, *new_pgid;
> > + struct lan9645x_mdb_entry *mdb_entry;
> > + unsigned char mac[ETH_ALEN];
> > + int err, pgid_index;
> > + bool cpu_copy;
> > +
> > + mdb_entry = lan9645x_mdb_entry_lookup(lan9645x, addr, vid);
> > + if (!mdb_entry)
> > + return -ENOENT;
> > +
> > + if (!(mdb_entry->ports & BIT(chip_port)))
> > + return 0;
> > +
> > + mdb_entry->ports &= ~BIT(chip_port);
> > +
> > + /* Encode mac for IP mc */
> > + lan9645x_mdb_encode_mac(mac, mdb_entry, type);
> > +
> > + /* Update PGID ptr for non-IP entries (L2 multicast) */
> > + old_pgid = mdb_entry->pgid;
> > + new_pgid = lan9645x_mdb_pgid_entry_get(lan9645x, mdb_entry, type);
> > + if (IS_ERR(new_pgid)) {
> > + /* Continue forwarding to old port group. */
> > + mdb_entry->ports |= BIT(chip_port);
> > + return PTR_ERR(new_pgid);
> > + }
> > + mdb_entry->pgid = new_pgid;
> > +
> > + if (!mdb_entry->ports) {
> > + lan9645x_mact_forget(lan9645x, mac, mdb_entry->vid, type);
> > + lan9645x_pgid_entry_put(lan9645x, old_pgid);
> > + lan9645x_mdb_entry_dealloc(lan9645x, mdb_entry);
> > + return 0;
> > + }
>
> Similar to the addition path above, if lan9645x_mact_forget() fails, its
> return value is ignored, and the software MDB entry and PGID are freed
> anyway. This could also lead to hardware/software state desynchronization.
>
> > +
> > + cpu_copy = !!(mdb_entry->ports & BIT(CPU_PORT));
> > + pgid_index = lan9645x_mdb_pgid_index(mdb_entry, type);
> > +
> > + err = lan9645x_mact_learn_cpu_copy(lan9645x, pgid_index, mac,
> > + mdb_entry->vid, type, cpu_copy);
> > + lan9645x_pgid_entry_put(lan9645x, old_pgid);
> > + return err;
> > +}
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: platform: introduce EC for Dell XPS 13 9345
From: Aleksandrs Vinarskis @ 2026-04-05 20:50 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans de Goede, Ilpo Järvinen, linux-arm-msm,
devicetree, linux-kernel, platform-driver-x86, laurentiu.tudor1,
Abel Vesa, Tobias Heider, Val Packett, Krzysztof Kozlowski
In-Reply-To: <e69ebf4a-126e-48c7-970b-1ba2a40a4492@linaro.org>
On Sunday, April 5th, 2026 at 02:05, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> > Add bindings for Embedded Controller (EC) in Dell XPS 13 9345 (platform
> > codename 'tributo'). It may be partially or fully compatible with EC
> > found in Snapdragon-based Dell Latitude, Inspiron ('thena').
> >
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > ---
> > .../embedded-controller/dell,xps13-9345-ec.yaml | 91 ++++++++++++++++++++++
> > MAINTAINERS | 5 ++
> > 2 files changed, 96 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..e14dbf2f1a6af8cc7511890fbef08c6c717c0aa6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
>
> I believe the part name of this embedded controller is the "mec5200" so
> instead of calling it dell,xps13-9345-ec suggest "dell,mec5200"
Correct, its Microchip MEC5200. I remember reading some series discussion
about not naming driver after IC its based on, but rather platform its
used for since driver depends on firmware which is platform specific...
cannot find that discussion now.
>
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/embedded-controller/dell,xps13-9345-ec.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dell XPS 13 9345 Embedded Controller
> > +
> > +maintainers:
> > + - Aleksandrs Vinarskis <alex@vinarskis.com>
> > +
> > +description:
> > + The Dell XPS 13 9345 has an Embedded Controller (EC) which handles thermal
> > + and power management. It is communicating with SoC over multiple i2c busses.
> > + Among other things, it handles fan speed control, thermal shutdown, peripheral
> > + power supply including trackpad, touch-row, display. For these functions, it
> > + requires frequently updated thermal readings from onboard thermistors.
> > +
> > +properties:
> > + compatible:
> > + const: dell,xps13-9345-ec
>
> Ditto the compat - name it after the IC not the laptop its a "mec5200"
> or "mec5200-ec" - I suspect the -ec postfix is a tautology the ec bit in
> "mec" probably captures.
I'm not sure I agree regarding the compatible, its supposed to be as exact as
possible. "dell,mec5200" will not allow us to differentiate between EC drivers
of "tributo" and "thena" for example.
Suggestion:
- Schema filename to be generalized "dell,mec5200-ec.yaml"
- Driver filename to be generalized "dell-mec5200-ec.c"
- Config to be generalized "EC_DELL_MEC5200"
- Compatible to stay specific "dell,xps13-9345-ec", with fallback to
"dell,mec5200-ec".
I would also keep "-ec" to stay consistent with naming convention of
existing drivers and bindings.
Let me know if this would work for you.
Alex
>
> > +
> > + reg:
> > + const: 0x3b
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + io-channels:
> > + description:
> > + ADC channels connected to the 7 onboard thermistors on PMK8550.
> > + EC requires frequent thermal readings of these channels to perform
> > + automated fan speed control.
> > + items:
> > + - description: ADC channel for sys_therm0
> > + - description: ADC channel for sys_therm1
> > + - description: ADC channel for sys_therm2
> > + - description: ADC channel for sys_therm3
> > + - description: ADC channel for sys_therm4
> > + - description: ADC channel for sys_therm5
> > + - description: ADC channel for sys_therm6
> > +
> > + io-channel-names:
> > + items:
> > + - const: sys_therm0
> > + - const: sys_therm1
> > + - const: sys_therm2
> > + - const: sys_therm3
> > + - const: sys_therm4
> > + - const: sys_therm5
> > + - const: sys_therm6
>
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - io-channels
> > + - io-channel-names
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h>
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + embedded-controller@3b {
> > + compatible = "dell,xps13-9345-ec";
> > + reg = <0x3b>;
> > + interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + io-channels = <&pmk8550_vadc PM8350_ADC7_GPIO3_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_GPIO4_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM1_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM2_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM3_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM4_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM5_100K_PU(1)>;
> > + io-channel-names = "sys_therm0",
> > + "sys_therm1",
> > + "sys_therm2",
> > + "sys_therm3",
> > + "sys_therm4",
> > + "sys_therm5",
> > + "sys_therm6";
> > + };
> > + };
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 96e0781f2201b41b976dfa69efd44d62c4ff0058..a5d175559f4468dfe363b319a1b08d3425f4d712 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7236,6 +7236,11 @@ S: Maintained
> > F: Documentation/ABI/testing/sysfs-class-firmware-attributes
> > F: drivers/platform/x86/dell/dell-wmi-sysman/
> >
> > +DELL XPS EMBEDDED CONTROLLER DRIVER
> > +M: Aleksandrs Vinarskis <alex@vinarskis.com>
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > +
> > DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> > M: Zev Weiss <zev@bewilderbeest.net>
> > L: linux-hwmon@vger.kernel.org
> >
>
>
^ 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