* RE: [PATCh v3 11/14] ASoC: rsnd: src: Add SRC reset and clock support for RZ/G3E
From: John Madieu @ 2026-04-03 21:00 UTC (permalink / raw)
To: Kuninori Morimoto
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: <87h5psg6w9.wl-kuninori.morimoto.gx@renesas.com>
Hi Kuninori,
Thanks for your review.
> -----Original Message-----
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Sent: Friday, April 3, 2026 3:39 AM
> To: John Madieu <john.madieu.xa@bp.renesas.com>
> Subject: Re: [PATCh v3 11/14] ASoC: rsnd: src: Add SRC reset and clock
> support for RZ/G3E
>
>
> Hi John
>
> > The RZ/G3E SoC requires explicit SCU (Sampling Rate Converter Unit)
> > reset and clock management unlike previous R-Car generations:
> >
> > - scu_clk: SCU module clock
> > - scu_clkx2: SCU double-rate clock
> > - scu_supply_clk: SCU supply clock
> >
> > Without these clocks enabled, the SRC module cannot operate on RZ/G3E.
> > Add support for the shared SCU reset controller used by the SRC
> > modules on the Renesas RZ/G3E SoC. All SRC instances are gated by the
> same "scu"
> > reset line.
> >
> > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > ---
> (snip)
> > diff --git a/sound/soc/renesas/rcar/rsnd.h
> > b/sound/soc/renesas/rcar/rsnd.h index 2c5738926093..8700b39b535e
> > 100644
> > --- a/sound/soc/renesas/rcar/rsnd.h
> > +++ b/sound/soc/renesas/rcar/rsnd.h
> > @@ -632,6 +632,13 @@ struct rsnd_priv {
> > struct clk *audmapp_clk;
> > struct reset_control *audmapp_rstc;
> >
> > + /*
> > + * 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 ?
>
> > @@ -711,8 +720,9 @@ struct rsnd_mod *rsnd_src_mod_get(struct rsnd_priv
> > *priv, int id)
> >
> > int rsnd_src_probe(struct rsnd_priv *priv) {
> > - struct device_node *node;
> > struct device *dev = rsnd_priv_to_dev(priv);
> > + struct reset_control *rstc;
> > + struct device_node *node;
>
> Very nitpick. No need to move *node :)
>
Noted. I'll keep the original declaration.
Regards,
John
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* RE: [PATCh v3 11/14] ASoC: rsnd: src: Add SRC reset and clock support for RZ/G3E
From: John Madieu @ 2026-04-03 21:13 UTC (permalink / raw)
To: Mark Brown
Cc: Kuninori Morimoto, 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: <5098f90c-bdb6-4922-b5d5-3794ebc56ee6@sirena.org.uk>
Hi Mark,
Thanks for your review.
> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: Thursday, April 2, 2026 8:05 PM
> To: John Madieu <john.madieu.xa@bp.renesas.com>
> Subject: Re: [PATCh v3 11/14] ASoC: rsnd: src: Add SRC reset and clock
> support for RZ/G3E
>
> On Thu, Apr 02, 2026 at 06:24:33PM +0200, John Madieu wrote:
>
> > @@ -526,6 +527,12 @@ static int rsnd_src_init(struct rsnd_mod *mod,
> > if (ret < 0)
> > return ret;
> >
> > + ret = clk_prepare_enable(priv->clk_scu_supply);
> > + if (ret) {
> > + dev_err(dev, "Cannot enable scu_supply_clk\n");
> > + return ret;
> > + }
> > +
> > rsnd_src_activation(mod);
> >
> > rsnd_src_init_convert_rate(io, mod);
>
> Shouldn't this have some handling like the adg does for splitting prepare
> and enable for the same reasons?
Looking at the call chain, rsnd_src_init/quit are called from the PCM
open/close path, which is a non-atomic context, unlike the ADG case where
rsnd_adg_ssi_clk_try_start() is called from the trigger path (atomic).
So I thought prepare_enable/disable_unprepare were safe here.
I'll add a comment in the code to document this. If you'd prefer the split
anyway, for consistency, I'm happy to do so. Please let me know.
Regards,
John
^ permalink raw reply
* RE: [PATCh v3 12/14] ASoC: rsnd: Add rsnd_adg_mod_get() for PM support
From: John Madieu @ 2026-04-03 21:21 UTC (permalink / raw)
To: Kuninori Morimoto
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: <87fr5cg6cl.wl-kuninori.morimoto.gx@renesas.com>
Hi Kuninori,
Thanks for your review.
> -----Original Message-----
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Sent: Friday, April 3, 2026 3:50 AM
> To: John Madieu <john.madieu.xa@bp.renesas.com>
> Cc: Mark Brown <broonie@kernel.org>; Liam Girdwood <lgirdwood@gmail.com>;
> Geert Uytterhoeven <geert+renesas@glider.be>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Jaroslav Kysela <perex@perex.cz>; Takashi Iwai
> <tiwai@suse.com>; magnus.damm <magnus.damm@gmail.com>; Philipp Zabel
> <p.zabel@pengutronix.de>; Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Biju
> Das <biju.das.jz@bp.renesas.com>; john.madieu@gmail.com; linux-
> sound@vger.kernel.org; linux-renesas-soc@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCh v3 12/14] ASoC: rsnd: Add rsnd_adg_mod_get() for PM
> support
>
>
> Hi John
>
> > Add rsnd_adg_mod_get() to retrieve the ADG module handle.
> >
> > This is preparation for system suspend/resume support, where the PM
> > callbacks need to access the ADG module to manage its clock and reset
> > state. Other modules (SSI, SRC, CTU, MIX, DVC) already have their
> > getters exported.
> >
> > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > ---
>
> This is just a comment.
> The reason why other modules has getting function is it is needed on
> rsnd_parse_connect_xxx() which is called in __rsnd_dai_probe().
>
> > @@ -618,6 +618,7 @@ int rsnd_adg_set_cmd_timsel_gen2(struct rsnd_mod
> *cmd_mod,
> > #define rsnd_adg_clk_disable(priv) rsnd_adg_clk_control(priv, 0)
> > int rsnd_adg_clk_control(struct rsnd_priv *priv, int enable); void
> > rsnd_adg_clk_dbg_info(struct rsnd_priv *priv, struct seq_file *m);
> > +struct rsnd_mod *rsnd_adg_mod_get(struct rsnd_priv *priv);
>
> The user of rsnd_adg_mod_get() is only ADG, no need to add it on rsnd.h ?
>
Agreed. FYI, I'll simply drop this patch and merge the getter helper
while adding suspend/resume for SRC.
Regards,
John
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* Re: media: iris: enable SM8350 and SC8280XP support
From: Steev Klimaszewski @ 2026-04-03 21:41 UTC (permalink / raw)
To: vikash.garodia
Cc: abhinav.kumar, andersson, bod, bryan.odonoghue, conor+dt, david,
devicetree, dikshita.agarwal, dmitry.baryshkov, johan+linaro,
konrad.dybcio, konradybcio, krzk+dt, linux-arm-msm, linux-kernel,
linux-media, mchehab, robh, stanimir.varbanov, threeway
In-Reply-To: <a1dcd0e3-db1c-4752-9473-7934e69198a3@oss.qualcomm.com>
Hi Vikash,
>> This is not just with totem, showtime shows the same issue. If I let the video
>> play, it plays just fine, however, if I attempt to skip forward, back, or even
>> play *after* the video has played, then I see the smmu fault
>>
>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xd51e3e00, fsynr=0x600002, cbfrsynra=0x2a00, cb=6
> please log the info about which "iova=0xd51e3e00" buffer is faulting in
> this case
I will include the diff that I applied against my kernel, in case this isn't the
correct information, but I get the following output in EL2:
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xd516d400, fsynr=0x600002, cbfrsynra=0x2a00, cb=6
arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x2a00
arm-smmu 15000000.iommu: FSYNR0 = 00600002 [S1CBNDX=96 PLVL=2]
qcom-iris aa00000.video-codec: sys error (type: 1, session id:ff, data1:11, data2:deadbead)
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:79756000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
And the following output in EL2:
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xd516d400, fsynr=0x600002, cbfrsynra=0x2a00, cb=6
arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x2a00
arm-smmu 15000000.iommu: FSYNR0 = 00600002 [S1CBNDX=96 PLVL=2]
qcom-iris aa00000.video-codec: sys error (type: 1, session id:ff, data1:1, data2:deadbead)
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: session error for command: 0, event id:1004, session id:28644000
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000dd000000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=3 idx=0 iova=0x00000000d7800000 size=5652480 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=0 iova=0x00000000d8c00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=1 iova=0x00000000d8a00000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=2 iova=0x00000000d8800000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=3 iova=0x00000000d8600000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=8 idx=4 iova=0x00000000d8400000 size=1445888 attr=0x4
qcom-iris aa00000.video-codec: buf_type=9 idx=0 iova=0x00000000dd780000 size=498176 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000da000000 size=19472128 attr=0x4
qcom-iris aa00000.video-codec: buf_type=10 idx=0 iova=0x00000000d6000000 size=19472128 attr=0x4
And the diff I had to come up with to get this output is:
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
index 8e864c239e29..a57a0e4971c8 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
@@ -214,7 +214,7 @@ static void iris_hfi_gen1_event_seq_changed(struct iris_inst *inst,
iris_inst_sub_state_change_drc_last(inst);
}
-static void
+static noinline void
iris_hfi_gen1_sys_event_notify(struct iris_core *core, void *packet)
{
struct hfi_msg_event_notify_pkt *pkt = packet;
@@ -235,7 +235,25 @@ iris_hfi_gen1_sys_event_notify(struct iris_core *core, void *packet)
schedule_delayed_work(&core->sys_error_handler, msecs_to_jiffies(10));
}
-static void
+static noinline void iris_dump_inst_buffers(struct iris_inst *inst)
+{
+ struct iris_buffer *buf;
+ int i;
+
+ for (i = 0; i < BUF_TYPE_MAX; i++) {
+ list_for_each_entry(buf, &inst->buffers[i].list, list) {
+ if (!buf->device_addr)
+ continue;
+ dev_err(inst->core->dev,
+ "buf_type=%d idx=%u iova=%pad size=%zu attr=0x%x\n",
+ i, buf->index,
+ &buf->device_addr, buf->buffer_size,
+ buf->attr);
+ }
+ }
+}
+
+static noinline void
iris_hfi_gen1_event_session_error(struct iris_inst *inst, struct hfi_msg_event_notify_pkt *pkt)
{
switch (pkt->event_data1) {
@@ -263,7 +281,7 @@ iris_hfi_gen1_event_session_error(struct iris_inst *inst, struct hfi_msg_event_n
}
}
-static void iris_hfi_gen1_session_event_notify(struct iris_inst *inst, void *packet)
+static noinline void iris_hfi_gen1_session_event_notify(struct iris_inst *inst, void *packet)
{
struct hfi_msg_event_notify_pkt *pkt = packet;
@@ -593,7 +611,7 @@ static const struct iris_hfi_gen1_response_pkt_info pkt_infos= {
},
};
-static void iris_hfi_gen1_handle_response(struct iris_core *core, void *response)
+static noinline void iris_hfi_gen1_handle_response(struct iris_core *core, void *response)
{
struct hfi_pkt_hdr *hdr = (struct hfi_pkt_hdr *)response;
const struct iris_hfi_gen1_response_pkt_info *pkt_info;
@@ -631,6 +649,8 @@ static void iris_hfi_gen1_handle_response(struct iris_core *core, void *response
if (inst) {
mutex_lock(&inst->lock);
iris_hfi_gen1_session_event_notify(inst, hdr);
+ if (inst->state == IRIS_INST_ERROR)
+ iris_dump_inst_buffers(inst);
mutex_unlock(&inst->lock);
} else {
iris_hfi_gen1_sys_event_notify(core, hdr);
diff --git a/drivers/media/platform/qcom/iris/iris_utils.c b/drivers/media/platform/qcom/iris/iris_utils.c
index cfc5b576ec56..45f349bd8b71 100644
--- a/drivers/media/platform/qcom/iris/iris_utils.c
+++ b/drivers/media/platform/qcom/iris/iris_utils.c
@@ -74,9 +74,9 @@ int iris_wait_for_session_response(struct iris_inst *inst, bool is_flush)
return 0;
}
-struct iris_inst *iris_get_instance(struct iris_core *core, u32 session_id)
+noinline struct iris_inst *iris_get_instance(struct iris_core *core, u32 session_id)
{
- struct iris_inst *inst;
+ struct iris_inst *inst = NULL;
mutex_lock(&core->lock);
list_for_each_entry(inst, &core->instances, list) {
diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
index bd38d84c9cc7..5cc47e900c83 100644
--- a/drivers/media/platform/qcom/iris/iris_vidc.c
+++ b/drivers/media/platform/qcom/iris/iris_vidc.c
@@ -168,17 +168,8 @@ int iris_open(struct file *filp)
mutex_init(&inst->lock);
mutex_init(&inst->ctx_q_lock);
- INIT_LIST_HEAD(&inst->buffers[BUF_BIN].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_ARP].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_COMV].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_NON_COMV].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_LINE].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_DPB].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_PERSIST].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_SCRATCH_1].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_SCRATCH_2].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_VPSS].list);
- INIT_LIST_HEAD(&inst->buffers[BUF_PARTIAL].list);
+ for (int i = 0; i < BUF_TYPE_MAX; i++)
+ INIT_LIST_HEAD(&inst->buffers[i].list);
init_completion(&inst->completion);
init_completion(&inst->flush_completion);
Please let me know if this is the information you are after, and if not, could
you provide a patch to help me get it? I had to noinline a lot of things, as
you can see, otherwise I was just getting null dereferences when trying to get
the buffers.
> Regards,
> Vikash
-- steev
^ permalink raw reply related
* Re: [PATCH v7 2/2] arm64: dts: qcom: lemans-evk: Enable secondary USB controller in host mode
From: Dmitry Baryshkov @ 2026-04-03 21:43 UTC (permalink / raw)
To: Swati Agarwal
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260403100753.3477925-3-swati.agarwal@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 03:37:53PM +0530, Swati Agarwal wrote:
> Enable secondary USB controller in host mode on lemans EVK Platform.
>
> Secondary USB controller is connected to a Genesys Logic USB HUB GL3590
> having 4 ports. The ports of hub that are present on lemans EVK standalone
> board are used as follows:-
> 1) port-1 is connected to HD3SS3220 Type-C port controller.
> 2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
> for Bluetooth. This port is to be used only if user optionally replaces the
> WiFi card with the NFA765 chip which uses USB for Bluetooth.
>
> Remaining 2 ports will become functional when the interface plus mezzanine
> board is stacked on top of corekit:
>
> 3) port-2 is connected to another hub which is present on the mezz through
> which 4 type-A ports are connected.
> 4) port-3 is used for the M.2 B key for a 5G card when the mezz is
> connected.
>
> Secondary USB Controller
> ↓
> GL3590 USB Hub (4 ports)
> |
> |-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
> |
> |-- Port 2 → Mezzanine USB Hub (when mezz attached)
> |
> |-- Port 3 → M.2 B‑Key Slot (when mezz attached)
> |
> |-- Port 4 → M.2 E‑Key Slot
> (Default: BT via UART;
> USB only if NFA765 module is installed)
>
> Mark the second USB controller as host only capable and add the HD3SS3220
> Type-C port controller along with Type-C connector for controlling vbus
> supply.
>
> Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/lemans-evk.dts | 206 ++++++++++++++++++++++++
> 1 file changed, 206 insertions(+)
>
> +
> + port@2 {
> + reg = <2>;
> +
> + usb1_con_sbu_ep: endpoint {
> + };
If SBU isn't actually connected, you can ommit the port.
> + };
> + };
> + };
> +
> connector-2 {
> compatible = "gpio-usb-b-connector", "usb-b-connector";
> label = "micro-USB";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_hub_2_1: endpoint {
> + remote-endpoint = <&usb1_con_hs_ep>;
> + };
> + };
> +
> + /*
> + * Port-2 and port-3 are not connected to anything on corekit.
> + */
Then please don't list those.
> + port@2 {
> + reg = <2>;
> +
> + usb_hub_2_2: endpoint {
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> +
> + usb_hub_2_3: endpoint {
> + };
> + };
> +
> + /*
> + * Port-4 is connected to M.2 E key connector on corekit.
> + */
> + port@4 {
> + reg = <4>;
> +
> + usb_hub_2_4: endpoint {
> + };
> + };
> + };
> + };
> +
> + usb_hub_3_x: hub@2 {
> + compatible = "usb5e3,625";
> + reg = <2>;
> +
> + peer-hub = <&usb_hub_2_x>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_hub_3_1: endpoint {
> + remote-endpoint = <&hd3ss3220_1_out_ep>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + usb_hub_3_2: endpoint {
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> +
> + usb_hub_3_3: endpoint {
> + };
> + };
The same here.
> +
> + port@4 {
> + reg = <4>;
> +
> + usb_hub_3_4: endpoint {
> + };
> + };
> + };
> + };
> +};
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 0/3] Add support for Renesas CAN-FD Bus-Off recovery mode selection
From: Marc Kleine-Budde @ 2026-04-03 21:44 UTC (permalink / raw)
To: Biju
Cc: Vincent Mailhol, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Fabrizio Castro,
linux-can, devicetree, linux-renesas-soc, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260403095003.104542-1-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
On 03.04.2026 10:49:57, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The CAN-FD IP supports the below Bus-Off recovery modes:
> 1) ISO11898-1 compliant
> 2) Entry to Channel Halt mode automatically at bus-off entry
> 3) Entry to Channel Halt mode automatically at bus-off end
> 4) Entry to Channel Halt mode (in bus-off state) by program request
>
> Add support for Bus-Off recovery mode selection via the
> renesas,bus-off-recovery-mode device tree property. If the property is
> absent, it defaults to RCANFD_CCTR_BOM_BENTRY (entry to Channel Halt mode
> automatically at bus-off entry) for backward compatibility.
Using DT properties for configuration is not the best way to go. I think
we first have to get the CAN error state handling fixed, before you add
new features.
Can you explain a bit more what the controller does in the different
modes?
In the current driver when the bus off IRQ (RCANFD_CERFL_BOEF) fires,
the driver calls can_bus_off(), which triggers the configured bus off
handling.
What the Linux driver should do is once the HW is in bus off mode,
switch off the HW and let the .do_set_mode(CAN_MODE_START) callback
restart the hardware.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 6/7] clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC
From: Dmitry Baryshkov @ 2026-04-03 21:46 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
Richard Cochran, Shawn Guo, Deepti Jaggi, linux-arm-msm,
linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <20260403-nord-clks-v1-6-018af14979fd@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 04:10:54PM +0200, Bartosz Golaszewski wrote:
> From: Taniya Das <taniya.das@oss.qualcomm.com>
>
> The global clock controller on the Nord SoC is partitioned into
> GCC, SE_GCC, NE_GCC, and NW_GCC. Introduce driver support for each
> of these controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> [Shawn: Drop include of <linux/of.h> as the driver doesn't use any OF APIs]
> Co-developed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 10 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gcc-nord.c | 1901 +++++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/negcc-nord.c | 1987 +++++++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/nwgcc-nord.c | 688 ++++++++++++++
> drivers/clk/qcom/segcc-nord.c | 1609 +++++++++++++++++++++++++++++++++
> 6 files changed, 6196 insertions(+)
>
> +
> +static const struct qcom_cc_desc se_gcc_nord_desc = {
> + .config = &se_gcc_nord_regmap_config,
> + .clks = se_gcc_nord_clocks,
> + .num_clks = ARRAY_SIZE(se_gcc_nord_clocks),
> + .resets = se_gcc_nord_resets,
> + .num_resets = ARRAY_SIZE(se_gcc_nord_resets),
> + .gdscs = se_gcc_nord_gdscs,
> + .num_gdscs = ARRAY_SIZE(se_gcc_nord_gdscs),
> + .driver_data = &se_gcc_nord_driver_data,
use_rpm = true?
(here and in other drivers)
> +};
> +
> +static const struct of_device_id se_gcc_nord_match_table[] = {
> + { .compatible = "qcom,nord-segcc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, se_gcc_nord_match_table);
> +
> +static int se_gcc_nord_probe(struct platform_device *pdev)
> +{
> + return qcom_cc_probe(pdev, &se_gcc_nord_desc);
> +}
> +
> +static struct platform_driver se_gcc_nord_driver = {
> + .probe = se_gcc_nord_probe,
> + .driver = {
> + .name = "segcc-nord",
> + .of_match_table = se_gcc_nord_match_table,
> + },
> +};
> +
> +module_platform_driver(se_gcc_nord_driver);
> +
> +MODULE_DESCRIPTION("QTI SEGCC NORD Driver");
> +MODULE_LICENSE("GPL");
>
> --
> 2.47.3
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: qcom: pm8921: add labels for ADC channels
From: Dmitry Baryshkov @ 2026-04-03 21:47 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, Konrad Dybcio
In-Reply-To: <20260403-pm8xxx-xoadc-label-v2-1-29b50bf821e6@smankusors.com>
On Fri, Apr 03, 2026 at 09:23:14AM +0000, Antony Kurniawan Soemardi wrote:
> Add label properties to all XOADC ADC channel nodes in the PM8921 PMIC
> device tree. This allows userspace and drivers to identify channels by
> name rather than relying on datasheet name.
>
> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> arch/arm/boot/dts/qcom/pm8921.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: qcom-pm8xxx-xoadc: remove redundant error logging in pm8xxx_read_raw
From: Dmitry Baryshkov @ 2026-04-03 21:54 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: <20260403-pm8xxx-xoadc-label-v2-2-29b50bf821e6@smankusors.com>
On Fri, Apr 03, 2026 at 09:23:18AM +0000, Antony Kurniawan Soemardi wrote:
> Remove dev_err() for missing channels and rely on -EINVAL to report
> failures, reducing unnecessary log noise.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Does it also prevent users from spamming the dmesg?
>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> drivers/iio/adc/qcom-pm8xxx-xoadc.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: adc: qcom-pm8xxx-xoadc: add support for reading channel labels
From: Dmitry Baryshkov @ 2026-04-03 21:57 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: <20260403-pm8xxx-xoadc-label-v2-3-29b50bf821e6@smankusors.com>
On Fri, Apr 03, 2026 at 09:23:21AM +0000, Antony Kurniawan Soemardi wrote:
> Implement the .read_label callback to allow userspace to identify ADC
> channels via the "label" property in the device tree. The name field in
> pm8xxx_chan_info is renamed to label to better reflect its purpose. If
> no label is provided in the device tree, it defaults to the hardware
> datasheet name.
>
> The change has been tested on Sony Xperia SP (PM8921).
>
> Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
> ---
> drivers/iio/adc/qcom-pm8xxx-xoadc.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: media: iris: enable SM8350 and SC8280XP support
From: Dmitry Baryshkov @ 2026-04-03 21:59 UTC (permalink / raw)
To: Steev Klimaszewski
Cc: vikash.garodia, abhinav.kumar, andersson, bod, bryan.odonoghue,
conor+dt, david, devicetree, dikshita.agarwal, johan+linaro,
konrad.dybcio, konradybcio, krzk+dt, linux-arm-msm, linux-kernel,
linux-media, mchehab, robh, stanimir.varbanov
In-Reply-To: <20260403214140.7307-1-threeway@gmail.com>
On Fri, Apr 03, 2026 at 04:41:39PM -0500, Steev Klimaszewski wrote:
> Hi Vikash,
>
> >> This is not just with totem, showtime shows the same issue. If I let the video
> >> play, it plays just fine, however, if I attempt to skip forward, back, or even
> >> play *after* the video has played, then I see the smmu fault
> >>
> >> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xd51e3e00, fsynr=0x600002, cbfrsynra=0x2a00, cb=6
>
> > please log the info about which "iova=0xd51e3e00" buffer is faulting in
> > this case
>
> I will include the diff that I applied against my kernel, in case this isn't the
> correct information, but I get the following output in EL2:
But these logs don't capture, which buffers are causing the IOMMU error.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 0/2] Add USB Ethernet controller (LAN7500) node in VAR-SOM-OM44 devicetree
From: Jakub Kicinski @ 2026-04-03 22:15 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Thomas Richard, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <2f843cc38fce1c5df9291c2e4b064241@tipi-net.de>
On Fri, 03 Apr 2026 22:33:26 +0200 Nicolai Buchwitz wrote:
> On 3.4.2026 22:18, Jakub Kicinski wrote:
> > On Fri, 03 Apr 2026 21:02:22 +0200 Thomas Richard wrote:
> >> The goal of this series is to add the USB Ethernet controller node in
> >> the
> >> VAR-SOM-OM44 devicetree in order to allow the bootloader to patch the
> >> devicetree and pass a MAC address to the smsc75xx driver. This was
> >> also a
> >> good opportunity to create the schema file for LAN75XX devices.
> >
> > But there's no driver for it yet, right?
> > IDK what the best practices are here, just unusual to see a schema
> > without a driver, is all.
>
> The smsc75xx driver has been in the tree since 2010 (d0cad871703b) and
> already reads local-mac-address/mac-address from devicetree via
> platform_get_ethdev_address() in smsc75xx_init_mac_address(), so the
> binding should be covered on the driver side.
Curious. So USB core can tie the right USB device to the DT / OF
information automatically? I was thrown by the fact that there
are no matches on the compatibles anywhere in the kernel.
^ permalink raw reply
* Re: [PATCH 0/2] Add USB Ethernet controller (LAN7500) node in VAR-SOM-OM44 devicetree
From: Nicolai Buchwitz @ 2026-04-03 22:21 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Thomas Richard, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260403151500.5225681d@kernel.org>
On 4.4.2026 00:15, Jakub Kicinski wrote:
> On Fri, 03 Apr 2026 22:33:26 +0200 Nicolai Buchwitz wrote:
>> On 3.4.2026 22:18, Jakub Kicinski wrote:
>> > On Fri, 03 Apr 2026 21:02:22 +0200 Thomas Richard wrote:
>> >> The goal of this series is to add the USB Ethernet controller node in
>> >> the
>> >> VAR-SOM-OM44 devicetree in order to allow the bootloader to patch the
>> >> devicetree and pass a MAC address to the smsc75xx driver. This was
>> >> also a
>> >> good opportunity to create the schema file for LAN75XX devices.
>> >
>> > But there's no driver for it yet, right?
>> > IDK what the best practices are here, just unusual to see a schema
>> > without a driver, is all.
>>
>> The smsc75xx driver has been in the tree since 2010 (d0cad871703b) and
>> already reads local-mac-address/mac-address from devicetree via
>> platform_get_ethdev_address() in smsc75xx_init_mac_address(), so the
>> binding should be covered on the driver side.
>
> Curious. So USB core can tie the right USB device to the DT / OF
> information automatically? I was thrown by the fact that there
> are no matches on the compatibles anywhere in the kernel.
Yes, USB core matches DT nodes by port topology (reg property), not by
compatible (usb_of_get_device_node() in drivers/usb/core/of.c if you
want to have a deeper look).
The existing microchip,lan95xx.yaml binding works the same way.
For example Raspberry Pi models before the Pi 4 use exactly this
pattern to pass the MAC address via firmware -> devicetree to the
smsc95xx driver.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Nicolai Buchwitz @ 2026-04-03 22:27 UTC (permalink / raw)
To: Thomas Richard
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260403-b4-var-som-om44-lan7500-v1-1-0dadde850143@bootlin.com>
On 3.4.2026 21:02, Thomas Richard wrote:
> Create schema for LAN75XX compatible USB Ethernet controllers. The
> smsc75xx
> driver only supports LAN7500 and LAN7505 devices.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52
> ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
> b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
> new file mode 100644
> index
> 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
> +
> +maintainers:
> + - Thomas Richard <thomas.richard@bootlin.com>
> +
> +description:
> + Device tree properties for LAN75XX compatible USB Ethernet
> controller.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - usb424,7500
> + - usb424,7505
> +
> + reg:
> + maxItems: 1
> +
> + local-mac-address: true
> + mac-address: true
> + nvmem-cells: true
> + nvmem-cell-names: true
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
nit: not required by the example
> +
> + usb {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@1 {
> + compatible = "usb424,7500";
> + reg = <1>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Thanks
Nicolai
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: ti: var-som-om44: Add USB Ethernet controller node
From: Nicolai Buchwitz @ 2026-04-03 22:28 UTC (permalink / raw)
To: Thomas Richard
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260403-b4-var-som-om44-lan7500-v1-2-0dadde850143@bootlin.com>
On 3.4.2026 21:02, Thomas Richard wrote:
> Add USB tree description, including the Gigabit Ethernet controller
> (LAN7500). Adding the LAN7500 node will allow the bootloader to patch
> the
> devicetree and set the MAC address.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> arch/arm/boot/dts/ti/omap/omap4-var-som-om44.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ti/omap/omap4-var-som-om44.dtsi
> b/arch/arm/boot/dts/ti/omap/omap4-var-som-om44.dtsi
> index
> 37d56b3010cff0f6ea6208289da0aba7328067d5..9e04aa70f98227ac0054fea6cd4521ed1323ecbd
> 100644
> --- a/arch/arm/boot/dts/ti/omap/omap4-var-som-om44.dtsi
> +++ b/arch/arm/boot/dts/ti/omap/omap4-var-som-om44.dtsi
> @@ -322,4 +322,18 @@ &usbhshost {
>
> &usbhsehci {
> phys = <&hsusb1_phy>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usbhub: hub@1 {
> + compatible = "usb424,2514";
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet: ethernet@3 {
> + compatible = "usb424,7500";
> + reg = <3>;
> + };
> + };
> };
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Thanks
Nicolai
^ permalink raw reply
* [PATCH v1 0/2] Load cros_ec_ucsi from OF and ACPI nodes
From: Jameson Thies @ 2026-04-03 22:33 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski
Cc: gregkh, devicetree, chrome-platform, linux-usb, linux-kernel,
Jameson Thies
Hey everyone,
I sent these patches up as part of a larger series in late 2025 which
hasn't mergerd. The initial series modified dt-bindings, mfd and usb
subsystems, but had not been reviewed by mfd maintainers. Additionally,
it had not been acked by maintainers all land through one development
tree.
For context, here is the previous series
https://lore.kernel.org/all/20251013203331.398517-1-jthies@google.com/
I've split the series up, this is just the usb and dt-bindings update.
It builds independent from the mfd change.
Given the time since this was previously under review (~oct 2025), I've
cleared the exising review tags. Please take a look and let me know if
you have any questions.
Jameson Thies (2):
dt-bindings: chrome: Add cros-ec-ucsi compatibility to typec binding
usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
.../bindings/chrome/google,cros-ec-typec.yaml | 19 +++++++++++---
drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 +++++++++++++++++--
2 files changed, 39 insertions(+), 6 deletions(-)
base-commit: 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply
* [PATCH v1 1/2] dt-bindings: chrome: Add cros-ec-ucsi compatibility to typec binding
From: Jameson Thies @ 2026-04-03 22:33 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski
Cc: gregkh, devicetree, chrome-platform, linux-usb, linux-kernel,
Jameson Thies
In-Reply-To: <20260403223357.1896403-1-jthies@google.com>
Chrome OS devices with discrete power delivery controllers (PDCs) allow
the host to read port status and control port behavior through a USB
Type-C Connector System Software (UCSI) interface with the embedded
controller (EC). This uses a separate interface driver than other
Chrome OS devices with a Type-C port manager in the EC FW. Those use
a host command interface supported by cros-ec-typec. Add a cros-ec-ucsi
compatibility string to the existing cros-ec-typec binding.
Additionally, update maintainer list to reflect cros-ec-ucsi and
cros-ec-typec driver maintainers.
Signed-off-by: Jameson Thies <jthies@google.com>
---
.../bindings/chrome/google,cros-ec-typec.yaml | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
index 9f9816fbecbc..fd1a459879bd 100644
--- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
+++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
@@ -8,17 +8,28 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
maintainers:
- Benson Leung <bleung@chromium.org>
- - Prashant Malani <pmalani@chromium.org>
+ - Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
+ - Andrei Kuchynski <akuchynski@chromium.org>
+ - Łukasz Bartosik <ukaszb@chromium.org>
+ - Jameson Thies <jthies@google.com>
description:
Chrome OS devices have an Embedded Controller(EC) which has access to
Type C port state. This node is intended to allow the host to read and
- control the Type C ports. The node for this device should be under a
- cros-ec node like google,cros-ec-spi.
+ control the Type C ports. This binding is compatible with both the
+ cros-ec-typec and cros-ec-ucsi drivers. The cros-ec-typec driver
+ supports the host command interface used by the Chrome OS EC with a
+ built-in Type-C port manager and external Type-C Port Controller
+ (TCPC). The cros-ec-ucsi driver supports the USB Type-C Connector
+ System Software (UCSI) interface used by the Chrome OS EC when the
+ platform has a separate power delivery controller (PDC). The node for
+ this device should be under a cros-ec node like google,cros-ec-spi.
properties:
compatible:
- const: google,cros-ec-typec
+ enum:
+ - google,cros-ec-typec
+ - google,cros-ec-ucsi
'#address-cells':
const: 1
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Jameson Thies @ 2026-04-03 22:33 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski
Cc: gregkh, devicetree, chrome-platform, linux-usb, linux-kernel,
Jameson Thies
In-Reply-To: <20260403223357.1896403-1-jthies@google.com>
Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
compatible devices and "GOOG0021" ACPI nodes.
Signed-off-by: Jameson Thies <jthies@google.com>
---
drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
index 6bca2dce211c..251aa7251ce6 100644
--- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
+++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
@@ -5,11 +5,13 @@
* Copyright 2024 Google LLC.
*/
+#include <linux/acpi.h>
#include <linux/container_of.h>
#include <linux/dev_printk.h>
#include <linux/jiffies.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_data/cros_ec_commands.h>
#include <linux/platform_data/cros_usbpd_notify.h>
#include <linux/platform_data/cros_ec_proto.h>
@@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
static int cros_ucsi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
struct cros_ucsi_data *udata;
int ret;
@@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
if (!udata)
return -ENOMEM;
+ /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
+ * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
+ * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
+ */
udata->dev = dev;
+ if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
+ udata->ec = dev_get_drvdata(dev->parent);
+ else
+ udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
- udata->ec = ec_data->ec_dev;
if (!udata->ec)
return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
@@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
};
MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
+static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
+ { "GOOG0021", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
+
+static const struct of_device_id cros_ucsi_of_match[] = {
+ { .compatible = "google,cros-ec-ucsi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
+
static struct platform_driver cros_ucsi_driver = {
.driver = {
.name = KBUILD_MODNAME,
.pm = &cros_ucsi_pm_ops,
+ .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
+ .of_match_table = cros_ucsi_of_match,
},
.id_table = cros_ucsi_id,
.probe = cros_ucsi_probe,
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: chrome: Add cros-ec-ucsi compatibility to typec binding
From: Benson Leung @ 2026-04-03 22:45 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski, gregkh, devicetree, chrome-platform, linux-usb,
linux-kernel
In-Reply-To: <20260403223357.1896403-2-jthies@google.com>
[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]
On Fri, Apr 03, 2026 at 10:33:26PM +0000, Jameson Thies wrote:
> Chrome OS devices with discrete power delivery controllers (PDCs) allow
> the host to read port status and control port behavior through a USB
> Type-C Connector System Software (UCSI) interface with the embedded
> controller (EC). This uses a separate interface driver than other
> Chrome OS devices with a Type-C port manager in the EC FW. Those use
> a host command interface supported by cros-ec-typec. Add a cros-ec-ucsi
> compatibility string to the existing cros-ec-typec binding.
>
> Additionally, update maintainer list to reflect cros-ec-ucsi and
> cros-ec-typec driver maintainers.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
> ---
> .../bindings/chrome/google,cros-ec-typec.yaml | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> index 9f9816fbecbc..fd1a459879bd 100644
> --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> @@ -8,17 +8,28 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
>
> maintainers:
> - Benson Leung <bleung@chromium.org>
> - - Prashant Malani <pmalani@chromium.org>
> + - Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> + - Andrei Kuchynski <akuchynski@chromium.org>
> + - Łukasz Bartosik <ukaszb@chromium.org>
> + - Jameson Thies <jthies@google.com>
>
> description:
> Chrome OS devices have an Embedded Controller(EC) which has access to
> Type C port state. This node is intended to allow the host to read and
> - control the Type C ports. The node for this device should be under a
> - cros-ec node like google,cros-ec-spi.
> + control the Type C ports. This binding is compatible with both the
> + cros-ec-typec and cros-ec-ucsi drivers. The cros-ec-typec driver
> + supports the host command interface used by the Chrome OS EC with a
> + built-in Type-C port manager and external Type-C Port Controller
> + (TCPC). The cros-ec-ucsi driver supports the USB Type-C Connector
> + System Software (UCSI) interface used by the Chrome OS EC when the
> + platform has a separate power delivery controller (PDC). The node for
> + this device should be under a cros-ec node like google,cros-ec-spi.
>
> properties:
> compatible:
> - const: google,cros-ec-typec
> + enum:
> + - google,cros-ec-typec
> + - google,cros-ec-ucsi
>
> '#address-cells':
> const: 1
> --
> 2.53.0.1213.gd9a14994de-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] media: iris: enable SM8350 and SC8280XP support
From: Dmitry Baryshkov @ 2026-04-03 22:46 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Abhinav Kumar, Bjorn Andersson, David Heidelberg,
Stanimir Varbanov, linux-media, linux-arm-msm, devicetree,
linux-kernel, Konrad Dybcio, Johan Hovold, Bryan O'Donoghue
In-Reply-To: <c7094fbc-deb7-4d76-ad97-9c56b81c7a71@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 12:51:30AM +0530, Vikash Garodia wrote:
>
> On 3/12/2026 8:44 PM, Dmitry Baryshkov wrote:
> > In order to enable wider testing of the Iris driver on the HFI Gen1
> > platforms enable support for Qualcomm SM8350 and SC8280XP platforms.
> >
> > Note, this has been tested only with the Iris driver. Venus driver fails
> > to boot the Iris core on SM8350 pointing out the UC_REGION error.
> >
> > Note, the firmware for SM8250 isn't compatible with SM8350 (nor with
> > SC8280XP). Please use corresponding firmware, extracted from the Windows
> > / Android data.
> >
> > On SM8350 with the Iris driver:
> >
>
> could you list the failing cases and compare the result with sm8250 ?
Failing on SM8350, but not on SM8250 (note, on SM8350 they also work
with FFmpeg, but fail with Gstreamer).
- AMP_E_Hisilicon_3
- AMP_F_Hisilicon_3
- DELTAQP_A_BRCM_4
- SAODBLK_A_MainConcept_4
- TILES_A_Cisco_2
- VPSSPSPPS_A_MainConcept_1 (this one timeouts with ffmpeg on both
SM8250 and SM 8350 and fails with Gstreamer on SM8350)
- vp90-2-14-resize-10frames-fp-tiles-8-4-2-1.webm
- vp90-2-14-resize-fp-tiles-8-16.webm
- vp90-2-22-svc_1280x720_1.webm (works with ffmpeg, fails with
Gstreamer)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Benson Leung @ 2026-04-03 22:47 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski, gregkh, devicetree, chrome-platform, linux-usb,
linux-kernel
In-Reply-To: <20260403223357.1896403-3-jthies@google.com>
[-- Attachment #1: Type: text/plain, Size: 3053 bytes --]
On Fri, Apr 03, 2026 at 10:33:27PM +0000, Jameson Thies wrote:
> Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
> compatible devices and "GOOG0021" ACPI nodes.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
> ---
> drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> index 6bca2dce211c..251aa7251ce6 100644
> --- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> +++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> @@ -5,11 +5,13 @@
> * Copyright 2024 Google LLC.
> */
>
> +#include <linux/acpi.h>
> #include <linux/container_of.h>
> #include <linux/dev_printk.h>
> #include <linux/jiffies.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/platform_data/cros_ec_commands.h>
> #include <linux/platform_data/cros_usbpd_notify.h>
> #include <linux/platform_data/cros_ec_proto.h>
> @@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
> static int cros_ucsi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
> struct cros_ucsi_data *udata;
> int ret;
>
> @@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
> if (!udata)
> return -ENOMEM;
>
> + /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
> + * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
> + * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
> + */
> udata->dev = dev;
> + if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
> + udata->ec = dev_get_drvdata(dev->parent);
> + else
> + udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
>
> - udata->ec = ec_data->ec_dev;
> if (!udata->ec)
> return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
>
> @@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
>
> +static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
> + { "GOOG0021", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
> +
> +static const struct of_device_id cros_ucsi_of_match[] = {
> + { .compatible = "google,cros-ec-ucsi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
> +
> static struct platform_driver cros_ucsi_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> .pm = &cros_ucsi_pm_ops,
> + .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
> + .of_match_table = cros_ucsi_of_match,
> },
> .id_table = cros_ucsi_id,
> .probe = cros_ucsi_probe,
> --
> 2.53.0.1213.gd9a14994de-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH V4 0/3] net: stmmac: Fix Tegra234 MGBE clock
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Jon Hunter
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, thierry.reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260401102941.17466-1-jonathanh@nvidia.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 11:29:38 +0100 you wrote:
> The name of the PTP ref clock for the Tegra234 MGBE ethernet controller
> does not match the generic name in the stmmac platform driver. Despite
> this basic ethernet is functional on the Tegra234 platforms that use
> this driver and as far as I know, we have not tested PTP support with
> this driver. Hence, the risk of breaking any functionality is low.
>
> The previous attempt to fix this in the stmmac platform driver, by
> supporting the Tegra234 PTP clock name, was rejected [0]. The preference
> from the netdev maintainers is to fix this in the DT binding for
> Tegra234.
>
> [...]
Here is the summary with links:
- [V4,1/3] net: stmmac: Fix PTP ref clock for Tegra234
https://git.kernel.org/netdev/net/c/1345e9f4e3f3
- [V4,2/3] dt-bindings: net: Fix Tegra234 MGBE PTP clock
https://git.kernel.org/netdev/net/c/fb22b1fc5bca
- [V4,3/3] arm64: tegra: Fix Tegra234 MGBE PTP clock
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: media: iris: enable SM8350 and SC8280XP support
From: Bryan O'Donoghue @ 2026-04-04 0:00 UTC (permalink / raw)
To: Dmitry Baryshkov, Steev Klimaszewski
Cc: vikash.garodia, abhinav.kumar, andersson, bod, conor+dt, david,
devicetree, dikshita.agarwal, johan+linaro, konrad.dybcio,
konradybcio, krzk+dt, linux-arm-msm, linux-kernel, linux-media,
mchehab, robh, stanimir.varbanov
In-Reply-To: <uiv4w3eptbniohzanp753f3wtwt4efjxupdro7kom2kgycco7f@nks5b4ctxty7>
On 03/04/2026 22:59, Dmitry Baryshkov wrote:
> On Fri, Apr 03, 2026 at 04:41:39PM -0500, Steev Klimaszewski wrote:
>> Hi Vikash,
>>
>>>> This is not just with totem, showtime shows the same issue. If I let the video
>>>> play, it plays just fine, however, if I attempt to skip forward, back, or even
>>>> play*after* the video has played, then I see the smmu fault
>>>>
>>>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xd51e3e00, fsynr=0x600002, cbfrsynra=0x2a00, cb=6
>>> please log the info about which "iova=0xd51e3e00" buffer is faulting in
>>> this case
>> I will include the diff that I applied against my kernel, in case this isn't the
>> correct information, but I get the following output in EL2:
>
> But these logs don't capture, which buffers are causing the IOMMU error.
I'd be interested to see if we can run this test on venus - instead of iris.
Konrad's patches are still floating around somewhere.
---
bod
^ permalink raw reply
* Re: media: iris: enable SM8350 and SC8280XP support
From: Dmitry Baryshkov @ 2026-04-04 0:04 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Steev Klimaszewski, vikash.garodia, abhinav.kumar, andersson, bod,
conor+dt, david, devicetree, dikshita.agarwal, johan+linaro,
konrad.dybcio, konradybcio, krzk+dt, linux-arm-msm, linux-kernel,
linux-media, mchehab, robh, stanimir.varbanov
In-Reply-To: <47061b6c-8589-492b-888e-3550c878e072@linaro.org>
On Sat, 4 Apr 2026 at 03:00, Bryan O'Donoghue
<bryan.odonoghue@linaro.org> wrote:
>
> On 03/04/2026 22:59, Dmitry Baryshkov wrote:
> > On Fri, Apr 03, 2026 at 04:41:39PM -0500, Steev Klimaszewski wrote:
> >> Hi Vikash,
> >>
> >>>> This is not just with totem, showtime shows the same issue. If I let the video
> >>>> play, it plays just fine, however, if I attempt to skip forward, back, or even
> >>>> play*after* the video has played, then I see the smmu fault
> >>>>
> >>>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xd51e3e00, fsynr=0x600002, cbfrsynra=0x2a00, cb=6
> >>> please log the info about which "iova=0xd51e3e00" buffer is faulting in
> >>> this case
> >> I will include the diff that I applied against my kernel, in case this isn't the
> >> correct information, but I get the following output in EL2:
> >
> > But these logs don't capture, which buffers are causing the IOMMU error.
>
> I'd be interested to see if we can run this test on venus - instead of iris.
At least when I tried testing it, venus wouldn't even boot the
firmware on SC8280XP, citing UC_REGION error:
2026-04-03T01:51:05.376407+03:00 rohan kernel: qcom-venus
aa00000.video-codec: non legacy binding
2026-04-03T01:51:05.437232+03:00 rohan kernel: qcom-venus
aa00000.video-codec: invalid setting for UC_REGION
2026-04-03T01:51:05.437838+03:00 rohan kernel: qcom-venus
aa00000.video-codec: failed to reset venus core
2026-04-03T01:51:05.437850+03:00 rohan kernel: qcom-venus
aa00000.video-codec: probe with driver qcom-venus failed with error
-22
>
> Konrad's patches are still floating around somewhere.
I think it was captured by Steev:
> This is much better than the previous venus patchset where accessing the
> hardware decoding would cause the machine to hard reset at least!
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v4 0/9] driver core: Fix some race conditions
From: Douglas Anderson @ 2026-04-04 0:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Saravana Kannan, Christoph Hellwig, Eric Dumazet, Johan Hovold,
Leon Romanovsky, Alexander Lobakin, Alexey Kardashevskiy,
Robin Murphy, Douglas Anderson, 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
The main goal of this series is to fix the observed bug talked about
in the first patch ("driver core: Don't let a device probe until it's
ready"). That patch fixes a problem that has been observed in the real
world and could land even if the rest of the patches are found
unacceptable or need to be spun.
That said, during patch review Danilo correctly pointed out that many
of the bitfield accesses in "struct device" are unsafe. I added a
bunch of patches in the series to address each one.
Danilo said he's most worried about "can_match", so I put that one
first. After that, I tried to transition bitfields to flags in reverse
order to when the bitfield was added.
Even if transitioning from bitfields to flags isn't truly needed for
correctness, it seems silly (and wasteful of space in struct device)
to have some in bitfields and some as flags. Thus I didn't spend time
for each bitfield showing that it's truly needed for correctness.
Transition was done semi manually. Presumably someone skilled at
coccinelle could do a better job, but I just used sed in a heavy-
handed manner and then reviewed/fixed the results, undoing anything my
script got wrong. My terrible/ugly script was:
var=can_match
caps="${var^^}"
for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
echo $f
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
done
From v3 to v4, I transitioned to accessor functions with another ugly
sed script. I had git format the old patches, then transformed them
with:
for f in *.patch; do
echo $f
sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
done
...and then did a few manual touchups for spacing.
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.
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.
Changes in v4:
- Use accessor functions for flags
Changes in v3:
- Use a new "flags" bitfield
- Add missing \n in probe error message
Changes in v2:
- Instead of adjusting the ordering, use "ready_to_probe" flag
Douglas Anderson (9):
driver core: Don't let a device probe until it's ready
driver core: Replace dev->can_match with dev_can_match()
driver core: Replace dev->dma_iommu with dev_dma_iommu()
driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
driver core: Replace dev->state_synced with dev_state_synced()
driver core: Replace dev->dma_coherent with dev_dma_coherent()
driver core: Replace dev->of_node_reused with dev_of_node_reused()
driver core: Replace dev->offline + ->offline_disabled with accessors
arch/arc/mm/dma.c | 4 +-
arch/arm/mach-highbank/highbank.c | 2 +-
arch/arm/mach-mvebu/coherency.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 4 +-
arch/arm/mm/dma-mapping.c | 28 ++--
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/mm/dma-mapping.c | 2 +-
arch/mips/mm/dma-noncoherent.c | 2 +-
arch/powerpc/kernel/dma-iommu.c | 8 +-
.../platforms/pseries/hotplug-memory.c | 4 +-
arch/riscv/mm/dma-noncoherent.c | 2 +-
drivers/acpi/scan.c | 2 +-
drivers/base/core.c | 53 +++++---
drivers/base/cpu.c | 4 +-
drivers/base/dd.c | 28 ++--
drivers/base/memory.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/dma/ti/k3-udma-glue.c | 6 +-
drivers/dma/ti/k3-udma.c | 6 +-
drivers/iommu/dma-iommu.c | 9 +-
drivers/iommu/iommu.c | 5 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +-
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 120 ++++++++++++------
include/linux/dma-map-ops.h | 6 +-
include/linux/dma-mapping.h | 2 +-
include/linux/iommu-dma.h | 3 +-
kernel/cpu.c | 4 +-
kernel/dma/mapping.c | 12 +-
mm/hmm.c | 2 +-
37 files changed, 206 insertions(+), 142 deletions(-)
--
2.53.0.1213.gd9a14994de-goog
^ 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