Re: [PATCH] interconnect: qcom: icc-rpmh: Add opt-out parameter for QoS settings

[Marc Zyngier <maz@kernel.org>]

On Tue, 15 Sep 2026 13:12:30 +0100,
Thorsten Leemhuis <regressions@leemhuis.info> wrote:
> 
> On 9/8/26 10:42, Marc Zyngier wrote:
> > On Tue, 08 Sep 2026 08:34:18 +0100,
> > Abel Vesa <abel.vesa@oss.qualcomm.com> wrote:
> >> On 26-09-07 22:15:09, Marc Zyngier wrote:
> >>> On Mon, 07 Sep 2026 21:21:44 +0100,
> >>> Abel Vesa <abel.vesa@oss.qualcomm.com> wrote:
> >>>> On 26-09-07 18:17:29, Marc Zyngier wrote:
> >>>>> Recent addition of QoS configuration to the X1 variants resulted in
> >>>>> systems that spontaneously reset at boot time or under load.
> >>>>>
> >>>>> Given that this is both very unpleasant and hard to debug, give the
> >>>>> affected user the option to survive such event with a module parameter.
> >>>>>
> >>>>> Passing "icc_rpmh.enable_qos=0" to the kernel command-line will skip the
> >>>>> offending QoS setup.
> >>>>
> >>>> Lets not start doing this, please.
> >>>>
> >>>> Can we figure out which platform deosn't work and then maybe we can 
> >>>> add a quirk in DT per platform?
> >>>
> >>> We have at least 3 machines that are dysfunctional since [1] was
> >>> merged (mini-x, sp12 and devkit). Probably some more, but I'm not
> >>> going to be the one doing a survey.
> >>>
> >>> What really should happen is [1] to be reversed until QC figures out a
> >>> set of parameters that actually works, instead of making this platform
> >>> even more unreliable than it already is.
> >>
> >> I'd rather have the patch reverted than adding a module parameter which
> >> users might not know about and distros will probably never addopt.
> >>>
> >>> Just like [2] should have been reverted.
> >>>
> >>> Until then, we'll have to paper over this stuff.
> >>
> >> But a module parameter complicates things rather than just papering over.
> >>
> >> I suggest we get both reverted if they break existing platforms.
> > 
> > We're in violent agreement.
> Did anyone submit those reverts? Doesn't look like it from what I see.
> Do we maybe need to poke the subsystem maintainers?

Done: https://lore.kernel.org/r/20260915123703.3228329-1-maz@kernel.org

> Side note for the record (noticed it just by chance): afaics one fix for
> [2] was submitted meanwhile:
> 
> https://lore.kernel.org/all/20260914-x1-el2-unfuck-v1-1-00d8bc35a635@oldschoolsolutions.biz/

Ah, nice one. Hopefully this gets eventually merged.

	M.

-- 
Without deviation from the norm, progress is not possible.