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

[Marc Zyngier <maz@kernel.org>]

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.

Thanks,

	M.

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