Re: [PATCH v2 2/3] interconnect: qcom: x1e80100: enable QoS configuration

[Marc Zyngier]

On Mon, 07 Sep 2026 15:34:35 +0100,
Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> 
> On 9/7/26 3:34 PM, Marc Zyngier wrote:
> > On Mon, 07 Sep 2026 14:20:26 +0100,
> > Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> >>
> >> On 9/7/26 10:49 AM, Marc Zyngier wrote:
> >>> On Mon, 07 Sep 2026 09:18:38 +0100,
> >>> Raviteja Laggyshetty <raviteja.laggyshetty@xxxxxxxxxxxxxxxx> wrote:
> 
> [...]
> 
> >>>> The current patch enable QoS for Hamoa SoC, which get programmed only during
> >>>> driver probe. This shouldn't impact or cause any spurious resets once the 
> >>>> device is booted up and probe is successful.
> >>>
> >>> And yet it absolutely does break things.
> >>>
> >>> With this patch applied, the box resets within 5GB of heavy network
> >>> traffic, probably because some transaction get delayed, and a watchdog
> >>> fires. With the patch reverted, the box keeps receiving packets, and
> >>> everything is hunky dory (100GB+ so far).
> >>>
> >>> Which makes me think that the set of hardcoded parameters in this
> >>> patch is not universal at all.
> >>
> >> They are, provided the configuration is for the right SoC..
> > 
> > Is x1e001de different from x1e80100? AFAIK, it is only a binned
> > version of the same SoC. How do you explain the above regression?
> 
> I somehow skimmed over the fact you said it's on the devkit and not
> on the mini-x mentioned before.
> 
> I pulled the Hamoa settings I could find, there are some updates but
> none seem particularly related (maybe the PCIe one? I don't know how
> the network card is connected), please give the attached patch a try.

I cherry-picked the Hamoa-specific patch, and gave it a go. Same
result (hard reset while synchronising a bunch of files), but this
time with a nice little message:

[  272.468031] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0xffff
[  272.468039] nvme nvme0: Does your device have a faulty power saving mode enabled?
[  272.468039] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug

indicating that PCIe has died.

None of that happens without the QoS stuff.

> If nothing else, please "bisect" the QoS additions until it stops
> crashing. Although perhaps applying only some of the settings may
> have its own set of dragons..

That's not exactly encouraging, is it? And if the "recommended" set of
tunables is not up to scratch, surely there should be a way to opt-out
until someone figures out what's wrong. Something like this:

diff --git a/drivers/interconnect/qcom/icc-rpmh.c b/drivers/interconnect/qcom/icc-rpmh.c
index 3b445acefece7..3a4743c364dac 100644
--- a/drivers/interconnect/qcom/icc-rpmh.c
+++ b/drivers/interconnect/qcom/icc-rpmh.c
@@ -224,6 +224,9 @@ static int qcom_icc_rpmh_configure_qos(struct qcom_icc_provider *qp)
 	return ret;
 }
 
+static bool enable_qos = true;
+module_param(enable_qos, bool, 0660);
+
 int qcom_icc_rpmh_probe(struct platform_device *pdev)
 {
 	const struct qcom_icc_desc *desc;
@@ -308,6 +311,11 @@ int qcom_icc_rpmh_probe(struct platform_device *pdev)
 		struct resource *res;
 		void __iomem *base;
 
+		if (!enable_qos) {
+			dev_info(dev, "Skipping QoS (command line)\n");
+			goto skip_qos_config;
+		}
+
 		/* Try parent's regmap first */
 		qp->regmap = dev_get_regmap(dev->parent, NULL);
 		if (!qp->regmap) {

At least people stuck with Purwa or other abandonware (such as the
devkit) would still have a usable machine.

	M.


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