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

[Raviteja Laggyshetty]

On 9/7/2026 10:20 PM, Marc Zyngier wrote:
> 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:
> 
Compared to Hamoa, some PCIe ports are removed on Purwa.
Let me share you an updated patch to try.

> 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.
> 
>