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

[Marc Zyngier <maz@kernel.org>]

On Mon, 07 Sep 2026 09:18:38 +0100,
Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> wrote:
> 
> 
> 
> On 9/7/2026 1:39 PM, Marc Zyngier wrote:
> > On Wed, 02 Sep 2026 14:00:52 +0100,
> > Mostafa Saleh <smostafa@google.com> wrote:
> >>
> >> On Wed, May 27, 2026 at 05:37:10AM +0000, Raviteja Laggyshetty wrote:
> >>> Enable QoS configuration for master ports with predefined priority
> >>> and urgency forwarding.
> >>>
> >>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
> >>
> >> Testing with Linus's tree, this patch broke my Lenovo IdeaCenter Mini X
> >> booting, the board resets very early during boot.
> >> I see that the last patch (device tree) is missing from the tree, I
> >> included it, but that doesn't fix it, disabling the driver also
> >> doesn't help. I can boot again by reverting this patch.
> >>
> >> I have my own device tree as my device is Purwa based [1]
> >>
> >> [1] https://lore.kernel.org/all/20260429141815.827157-1-smostafa@google.com/
> > 
> > Same here. My Mini-X hard reboots after 2.45s in the kernel. Example
> > from the serial console:
> 
> Is the Mini-X based on Purwa ?

Yes. At least the one I have in the rack.

> 
> > 
> > <quote>
> > [    2.280289] VFIO - User Level meta-driver version: 0.3
> > [    2.286872] usbcore: registered new interface driver usb-storage
> > [    2.307218] i2c_dev: i2c /dev entries driver
> > [    2.316386] efifb: probing for efifb
> > [    2.320065] efifb: framebuffer at 0xe4800000, using 8100k, total 8100k
> > [    2.326768] efifb: mode is 1920x1080x32, linelength=7680, pages=1
> > [    2.333026] efifb: scrolling: redraw
> > [    2.336704] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> > [    2.346518] Console: switching to colour frame buffer device 240x67
> > [    2.356787] fb0: EFI VGA frame buffer device
> > [    2.361793] clocksource: arch_mmio_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
> > [    2.372947] arch-timer-mmio 17800000.timer: mmio timer running at 19.20MHz (virt)
> > [    2.380860] usbcore: registered new interface driver usbhid
> > [    2.386577] usbhid: USB HID core driver
> > [    2.391899] hw perfevents: enabled with armv8_pmuv3 PMU driver, 13 (0,80000fff) counters available
> > [    2.403182] NET: Registered PF_INET6 protocol family
> > [    2.408516] Segment Routing with IPv6
> > [    2.412289] In-situ OAM (IOAM) with IPv6
> > [    2.416326] NET: Registered PF_PACKET protocol family
> > [    2.421533] 9pnet: Installing 9P2000 support
> > [    2.425923] Key type dns_resolver registered
> > [    2.430357] NET: Registered PF_VSOCK protocol family
> > [    2.440369] registered taskstats version 1
> > [    2.444633] Loading compiled-in X.509 certificates
> > [    2.451480] Demotion targets for Node 0: null
> > Format: Log Type - Time(microsec) - Message - Optional Info
> > Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
> > S - QC_IMAGE_VERSION_STRING=BOOT.MXF.2.4-00541-HAMOA-1
> > S - IMAGE_VARIANT_STRING=SocHamoaWP
> > S - OEM_IMAGE_VERSION_STRING=ip-10-195-202-30
> > S - Boot Interface: SPI
> > S - Secure Boot: On
> > S - Boot Config @ 0x221c8600 = 0x00000001
> > S - JTAG ID @ 0x221c8744 = 0x002ad0e1
> > S - OEM ID @ 0x221c8700 = 0x00000040
> > S - Serial Number @ 0x221c8610 = 0x00000460d5171bbb
> > S - Feature Config Row 0 @ 0x221c21e0 = 0x0000000000000000
> > S - Feature Config Row 1 @ 0x221c21e8 = 0x0000000000000000
> > S - Core 0 Frequency, 1363 MHz
> > S - PBL Patch Ver: 0
> > S - PBL freq: 600 MHZ
> > S - Cluster: 0, Core: 0
> > </quote>
> > 
> > I'm also seeing spurious resets on my "X1E001DE Snapdragon Devkit for
> > Windows" when doing large file transfers over the network (30GB+).
> > With this patch reverted on top of 7.3-rc1, both machines are as solid
> > as they were before it.
> >
> 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.

	M.

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