02:18 <robclark> jhovold: rebased.. and within a day I get the reboot.. I don't really have anything more to add, probably someone who has a CRD will need to try and repro?

10:03 <jhovold> robclark: hmm, I've been using my t14s more than ususal this last week to see if I can trigger this but still no resets

10:04 <jhovold> I assume you still run with a bunch of additional patches on top of my wip branch, is that just drm work?

10:05 <jhovold> using wlroots, no bluetooth and not the latest ath12k fw

10:07 <jhovold> if the reset bamse hit on the xps is the same issue, he should have hit it with sway too

13:11 <robclark> jhovold: https://gitlab.freedesktop.org/robclark/msm/-/commits/sparse-newest .. it is a subset of the patches I had before (stuff that got merged in v6.16 merge window).. nothing that I didn't have before

13:11 <robclark> bt didn't survive the rebase :-(

13:11 <robclark> it would be nice if I didn't have to keep rebasing the 7x ec :-)

13:12 <robclark> looks like wifi isn't working atm.. I hadn't noticed because I have eth via usb-c monitor..

13:13 <robclark> maybe I overlooked some .config change.. I did catch the usb thing that was renamed

13:53 <Jasper[m]> The laptop I'm trying to get USB working on has an internal USB hub that needs a vdd-supply in the DT, I'm trying to figure out what tlmm pin is used for that regulator but I don't necessarily know what I'm looking for in the DSDT

14:08 <alexVinarskis[m]> jasper: if you are sure there is usb hub with extra vreg, search for TLMMGPIO, compare to existing devices without this extra vreg, eg. Xps 9345. Lots of gpios are eg. Data lines for I2C, or reset for pcie, its easy to tell by the parent. Example is 0x22 (first occurance in dsdt is tlmmgpio) is Thibkook 16 g7, which is uvc camera vreg gpio. You need to find something similar in yours. You can then try ro set it high via

14:08 <alexVinarskis[m]> gpiod and see if you hub came up

14:10 <alexVinarskis[m]> there is a possibility that the gpio you are looking for is not mentioned in dsdt, but instead in AeoB files (you can decompile there as per example, and analyze in a similar way, though it has a lot of random stuff), or it may be controlled directly by some windows driver, in that case there is no simple and non-risky way to find it...

14:15 <Jasper[m]> There aren't that many sc7280 laptops out there with acpi dumps and the phone equivalent chips generally don't have multiple usb ports

14:15 <Jasper[m]> in that regard this thing is a bit unique

14:19 <Jasper[m]> as for the suggestion to use gpiod, it's a bit of a chicken and eg story since I don't have a DT that gets me to userspace currently :P

14:19 <Jasper[m]> that's what I'm trying to get USB up for

14:20 <Jasper[m]> I will however make a copy of the driverstore contents to get some AeoB dumps;

14:20 <Jasper[m]> * I will however make a copy of the driverstore contents to get some AeoB dumps

14:30 <alexVinarskis[m]> ohh i see. is pcie up? could deploy image to ssd from external device and boot that (if its removable)?

14:30 <alexVinarskis[m]> Also, are you sure there is a USB vreg? not much familiar with sc7280, but on x1/x1e they are all root hubs, phy are powered from pmics, so external usb ports just work.

14:31 <Jasper[m]> UFS :P

14:31 <Jasper[m]> But I did check the dt-bindings for that hub, they do indeed not seem to be required

14:32 <alexVinarskis[m]> you could also i guess find any TLMMGPIO which is set as output (dont recall if the next line after gpio number or next-next-next is 1=output, 0=input) and not part of IO or PCIE lines and set them all high in dts? if its output line it should be safe for force it high.

15:57 <Jasper[m]> I just left it the way it was and tried to continue getting usb working, but no dice

15:57 <Jasper[m]> Doesn't help that I have no idea what I'm doing :/

16:41 <nirik> FWIW, I am running 6.16rc3+jhovold's patchset + bluetooth on my 7x and have not seen any reboots at all here. I am on an old bios tho (never bothered to update it).

16:45 <valpackett> huh, rereading the Dell BIOS changelog, I thought it was only security stuff but 2.9.0 actually mentions "Fixed the issue where the system fan stops working and the system shuts down"

16:45 <valpackett> could that somehow have been it? 0.o

16:46 <valpackett> even though I wouldn't describe a hard freeze as "shuts down"

16:53 <lynxy> i'm running 6.16rc3+jhovold's patchset on the dell bios 2.7.1 and i think i've experienced a couple instances of what feel like an entirely impromped overhead and reboot

16:53 <lynxy> i'll check for an update

16:53 <lynxy> overheat*

16:53 <lynxy> unprompted overhead* - come on fingers

16:53 <lynxy> smh you know what i mean

16:54 <valpackett> mine wouldn't overheat, it would just hard freeze (no sysrq no nothing, not a panic) and get rebooted by the watchdog, but it was on 2.7.0 before when that was happening yeah

16:55 <valpackett> at random moments with low casual load, like when just moving the mouse around in a browser, typing in a terminal, etc.

16:55 <lynxy> on a side-note- dell's support assist and such, various selection of 'tools' are quite utterly useless and dysfunctional and the support site is equally aggravating

16:56 <lynxy> scrap your js monstrosity and just give me a download link

16:57 <valpackett> was pretty straightforward for me, https://www.dell.com/support/product-details/en-us/product/latitude-14-7455-laptop/drivers → system bios in the list

16:57 <valpackett> "The Universal (Windows/MS DOS) format can be used to install from any Windows or MS DOS environment." lmao

16:58 <JensGlathe[m]> lynxy: That's SOP to keep you away

16:58 <lynxy> SOP?

16:58 <alexVinarskis[m]> To be fair, dell bios update is very simple on linux - just put .exe on efi partition or usb stick, reboot, and update from uefi itself.

16:58 <valpackett> they don't actually describe it well on the website, but you don't need windows nor ms-dos (lolwat, on arm?), you can just feed the windows exe from a flash drive to the firmware setup

16:59 <JensGlathe[m]> Standard Operations Procedure

16:59 <valpackett> to be fair UEFI is kind of a "64-bit MS-DOS from the future" but lol

17:32 <valpackett> ugh, why is github. wanted to send the audio/cam patches as a PR to Jens Glathe's kernel.. but pushing to my existing linux fork results in a massive push over github's 2gb limit

17:32 <valpackett> and i can't just make a new fork in the same account (would have to make an org or lose the existing fork that has some changes for some phones)

17:32 <valpackett> time to just make the v2 and mail it to upstream i guess heheh

17:33 <JensGlathe[m]> The fork limit is an issue for anything derived from torvalds/linux

17:34 <JensGlathe[m]> my fork is from Merck Hung, but ofc it derives eventually from torvalds/linux

18:13 <valpackett> I guess the big divergence comes from next and stable being completely different repos upstream on git.kernel.org(?)

18:15 <valpackett> Anyway I just realized that I haven't seen the dmidecode/fwupd UUID stuff from the Inspiron so I'm not 100% sure they can be distinguished on the dtb level.. /cc bryanodonoghue

18:33 <alexVinarskis[m]> They definitely can, as per dmidecode from PM, you have "Latitude 7455". Inspiron will for sure say Inspiron. If model and SKUs are different, i cannot imagine UUIDs are the same

19:00 <valpackett> yeah, I do expect a difference in UUIDs, but I'd like to see it with my own eyes :)

19:28 <jhovold> robclark: your wifi is likely broken by the same reason as the bluetooth (pwrctrl patch)

19:28 <jhovold> an early bluetooth probe deferal brings down the wifi, which can't be powered on later

19:29 <jhovold> iirc, you ran into this very issue before with that same oot patch

19:30 <jhovold> pwrctrl not working on x1e is a real issue which "someone" needs to to fix too at some point, but it can be worked around by making sure bluetooth doesn't probe too early for example

19:31 <jhovold> anyway, I'm inclined to say that at least the t14s does not suffer from this issue with mainline or my rc3

19:32 <jhovold> other machines, with further oot patches, may be a different story (e.g. due to guess work about regulators or similar)

19:33 <jhovold> in your case, the bt/wifi/pwrctrl issue may be involved in the reset too

19:34 <jhovold> then we still have the known issue of missing thermal mitigation, which could potentially cause resets, but that does not seem to be what these reports are about

19:55 <jhovold> robclark: btw, you should drop the audio and ath11k patch you have on top as those have been rejected/superseded

19:56 <jhovold> and i'm not seeing any bt patch for slim7x in that branch...

19:58 <JensGlathe[m]> [bt patch for Yoga Slim 7x](https://lore.kernel.org/all/4f026872-f600-4940-a6a0-ccb0b677be5b@oss.qualcomm.com/) got reviewed.

20:03 <robclark> the bt patch that I dropped was (an earlier version?) of JensGlathe[m]'s patch.. I don't really need it so I didn't bother dealing with the conflicts

20:07 <jhovold> robclark: ah, sorry, thought I was looking at your tree from before the rebase

20:10 <robclark> anyways, it does seem there is a diff btwn v6.15 and v6.16... there are some drm (mostly dpu) patches that I didn't have before, but most of the patches that I would have suspected (like ACD) were already in my v6.15 based branch. I guess if whoever has CRDs can use them as daily drivers on v6.16 for a few days, that might be the most useful thing for tracking this down

20:10 <jhovold> well, it at least used to be possible to have wifi also without the bt/pwrctrl patch...

20:12 <robclark> I'm not entirely sure what linux-firmware version I have, so don't want to rule that out as an issue.. recently I've been using eth via usb-c monitor so I can't say for sure that it was working before

20:12 <jhovold> yeah, the may release broke ath12k, haven't tested the supposed fixed version yet

20:13 <jhovold> lots of distros reverted the ath12k fw though

20:16 <JensGlathe[m]> I removed ath12k hardware as far as I could

20:55 <bryanodonoghue> valpackett which two Dell devices are you trying to differentiate

20:55 <bryanodonoghue> there are GPIOs we can read

21:37 <bryanodonoghue> valpackett posted my 14p UCM config to github

21:37 <bryanodonoghue> You're right it looks 1:1 with the Latitude

21:38 <bryanodonoghue> I have been able to get sound through the speakers and headphones with scripts but - due to a lack of knowledge of soundwire/pulseaudio and friends have not been able to get the gnome/hyperland plugins to "see" my soundcard properly

21:38 <bryanodonoghue> so I have't submitted

21:39 <bryanodonoghue> TBH I'd appreciate a n00b/idiot's guide to what to use with these UCM files

21:39 <bryanodonoghue> v frustrating to know the hardware config is working but not know why user-space won't play with it

21:39 <bryanodonoghue> operator error is the answer

21:54 <alexVinarskis[m]> bryanodonoghue: not sure if its the root cause to your issue, but you were including yoga slim's conf, not newly added inspiron, left a comment. Otherwise, I assume you are not using Ubuntu Concept image, but its a nice base for testing - on XPS after DT change I only had to follow alsa UCM's deploy guide (copy recursively ucm and ucm2), compile and place propely topology file, and it just worked - perhaps worth trying

21:54 <alexVinarskis[m]> to rule out other soundswire/pulseaudio related issues?

21:55 <bryanodonoghue> nope running arch linux

21:55 <bryanodonoghue> UCM deploy guide

21:55 <bryanodonoghue> hmm was not aware of this guide

21:55 <bryanodonoghue> thx I'll google

21:56 <alexVinarskis[m]> well, not as nicely done multi page doc guide :) https://github.com/alsa-project/alsa-ucm-conf?tab=readme-ov-file#installation

21:57 <alexVinarskis[m]> TL:DR; copy recursively ucm, ucm2 to /usr/share/alsa/, reboot

22:01 <bryanodonoghue> hmm, I don't remember how I installed those files - perhaps too selectively

22:01 <bryanodonoghue> I'll try to dump them in thx

22:12 <alexVinarskis[m]> bryanodonoghue: just remembered, could you please share output of dmidecode -t 1 from Inspiron at some point? Wanted to open MRs to Ubuntu's concept repos for Inspiron,Latitide and it uses some of the output for magic dtb auto-selection during first boot of the installler.

22:13 <lynxy> for what it's worth, i'm also on an xps running arch linux and performing these steps hasn't appeard to have fixed my sound [:

22:14 <valpackett> bryanodonoghue: yeah, dmidecode is one thing, the other is fwupdtool hwids

22:16 <alexVinarskis[m]> lynxy: hmmm is sound card detected when running alsamixer and pressing F6 to list cards?

22:17 <valpackett> re: sound not working in gnome, i think i dealt with that at some point while bringing it up

22:20 <valpackett> https://oftc.catirclogs.org/aarch64-laptops/2025-06-01#34331072 is what was in the logs

22:20 <valpackett> but that was because i had speakers turned off in the bios

22:21 <lynxy> sound card is not detected in alsamixer

22:21 <valpackett> then i had to uncomment missing soundwires in dts

22:21 <lynxy> already uncommented, using dts patches from alex's repo

22:22 <valpackett> (i was talking more about the issue bryanodonoghue had with soundcard showing up but not being picked up in gnome i.e. by pipewire)

22:23 <lynxy> ah sorry ^^

22:23 <valpackett> lynxy: check dmesg?

22:23 <valpackett> do you have the audioreach config installed?

22:24 <valpackett> build from https://github.com/linux-msm/audioreach-topology

22:24 <lynxy> i have both audioreach config installed and the alsa-ucm-conf files :]

22:24 <lynxy> i'll grab dmesg in a sec,

22:38 <valpackett> jhovold: which thermal mitigation is missing btw? there's a bunch of trip points in the dtsi, cpu-critical, gpu-critical..

22:38 <valpackett> plus on my machine it seems to just happen in firmware? during high load it keeps one particular cpu sensor precisely at 90°

22:39 <lynxy> seem to be getting the qcom-soundwire SWR CMD error that i've seen mention on the ubuntu-concept thread, as well as WSA Playback: codec dai not found

22:39 <lynxy> nothing else much stands out to me in the dmesg regarding sound, bar ALSA complaining about finding no devices

22:42 <alexVinarskis[m]> probably an obvious one, but is module snd_soc_x1e80100 loaded?

22:42 <lynxy> yup

22:43 <valpackett> lynxy: ok, now you too go check if speakers are disabled in the bios :)

22:43 <lynxy> i'm entirely sure they're enabled- i just reset the bios a couple of hours ago while debugging the bios update not sticking in windows lol

22:43 <lynxy> it was one of the options i checked

22:43 <alexVinarskis[m]> valpackett: did you disable them yourslef before btw?

22:44 <lynxy> i'll double check tho

22:44 <alexVinarskis[m]> lynxy: by BIOS update not sticking you mean its not getting installed?

22:44 <valpackett> yes lmao, when bringing up audio i was wondering why there were SWR CMD errors and such, ended up being that

22:45 <lynxy> currently running bios 2.7.1, but bios 2.8.0 won't install either in windows or when flashed in one-time boot uefi

22:46 <alexVinarskis[m]> my audio related parts of dmesg (working sound):... (full message at <https://matrix.org/oftc/media/v1/media/download/AfTjoZWuyP4iwllDnJG6wPLcMHl_g4Zq7tq368HAW7yLgXo4E4l0l0wEYCSe-0WntazrHxzMIpOc_DJsduyFMxVCeYBfeujQAG1hdHJpeC5vcmcvZkpuSFpSTEtrSlRDQlhrYldBc2xaU0Fs>)

22:47 <valpackett> you can run alsamixer -D sysdefault to mess with the actual raw soundcard params (and possibly ruin the alsa state)

22:48 <alexVinarskis[m]> lynxy: aaahhha i justtt resolved this issue after ~6 months of struggle and a replaced motherboard.... I bet you have more than one EFI (or otherwise, EFI-like looking fat32) partitions? that wont work :)

22:48 <alexVinarskis[m]> it seems that windows/UEFI installer installs capsule update to the first partition 'EFI'. But on boot UEFI scans last 'EFI' partition for capsule files to pull in. either move *capsule* files from 1st to last Fat32 partition, or make sure you only have one.

22:49 <lynxy> oh wow

22:49 <lynxy> *that's* the problem??

22:49 <alexVinarskis[m]> funny enough, you also cannot just disable internal SSD in bios to install update - it will legit say 'I want at least 120MB EFI partition'.

22:50 <valpackett> wow, having 2 ESPs sounds very strange, i can totally see why they wouldn't have anticipated that situation

22:50 <valpackett> 2 on the same drive i mean

22:51 <lynxy> yeah, one efi partition generated by windows, one separate for linux- same as if you have one drive per os except that it's on the same drive

22:51 <lynxy> yeah i can see how that could break it but honestly it really shouldn'y

22:51 <lynxy> shouldn't

22:51 <lynxy> thanks for the heads up tho lol

22:51 <alexVinarskis[m]> i was stuck on 2.0.0 on one of my XPS since the time 2.2.0 came out.... eventualy reached out to support, they did diagnostic and decided to replace motherboard. you can image my face when we boot new one, and update still won't stick o_O. Only SSD stayed the same, figuring that one out from there onwards was rather easy

22:52 <alexVinarskis[m]> same, had dedicated EFI partition for 'shady installs'.

22:54 <lynxy> lemme just message the dell technicians back lol

22:54 <lynxy> tell them it' okay

22:54 <lynxy> i know what the issue is

22:54 <valpackett> oh on the XPS 2.8.0 is the june bios i see.. and 2.7.1 is the one that mentions the "system fan stops working and the system shuts down" thing like 2.9.0 on thena

22:54 <alexVinarskis[m]> maybe tell them what the issue is, hopefully it makes it to firmwre department

22:55 <lynxy> i will, though- it won't be high prio for them

22:59 <lynxy> (unless you can find some way to turn it into a security issue, and generate a cve for it ;] )

23:01 <lynxy> yeah, i'm definitely not getting the same snd-x1e80100 sound message as you so mayhaps i'm missing something or i've done it wrong. i'll go through the steps again tomorrow and see how it goes- for now, it's late

23:07 <alexVinarskis[m]> I actually did find a big security issue as well :D waiting for my contact to report it now.

23:07 <alexVinarskis[m]> in case of broken update its probably a simple sort/reverse sort issue though since installer installs to first part, UEFI trying to load from last. Replacing motherboards is pretty expesnive, so I would think they would be motivated to have it fixed.

23:07 <lynxy> the support agent i'm talking to just responds to any new info with "please kindly wait until we've heard back from the internal team" so they're not going to be helpful

23:21 <valpackett> what's the hold up with upstreaming the camss nodes in x1e80100.dtsi?

23:22 <alexVinarskis[m]> Indeed, been hanging on the lists for a while now

23:38 <valpackett> hm in the reviews i've been told (about ps8830 retimers) "I'd assume these are ps8833 instead, IIRC there's a pair of ID registers"

23:38 <valpackett> does anyone know which register it is?

23:43 <valpackett> oop there was some discussion of the "[vreg_vcn] regulators are actually part of the removable M.2 card" in my thread... because i still had that comment copy-pasted

23:43 <valpackett> .......while in reality the wifi card is soldered here

23:51 <alexVinarskis[m]> Have you confirmed this by opening up the device? If yes, its a valid answer. Its also soldered on XPS.

23:52 <alexVinarskis[m]> re: registers of ps883x - i guess check the driver?

23:53 <alexVinarskis[m]> Or perhaps visual inspection, if you are anyway opening the laptop up. On XPS retime* are under a huge shield so I can't just 'see it'. On Zenbook they are open and clearly say ps8833.

23:53 <alexVinarskis[m]> retime*=retimers

23:54 <valpackett> the driver doesn't say anything about an ID register

23:54 <valpackett> i've swapped the ssd a few times, heh

23:56 <valpackett> looking at the pcb photo i have, there's a smol shield where the ports are, i can easily unscrew it \o/