03:02 <xyzabc> This might be a stupid question, but for ubuntu concept, where can I find the changelog for the new  6.14.0-17.17 release package?

03:08 <xyzabc> ah I found it -> https://launchpad.net/~ubuntu-concept/+archive/ubuntu/x1e/+packages

03:08 <xyzabc> expand linux-qcom-x1e - 6.14.0-17.17 for kernel on oracular.

12:28 <Guest10485> Greetings! I'm debuging my Honor on Snapdragon which I use under OpenBSD and I have a question regarding USB and qcpas. The last one exists under Linux as qcom_q6v5_pas.c. The long story short: USB 3.0 not always allow to attach devices after boot. If I keep device attached on the boot, it may work, or may not. I had noticed that when it may not, a system can't load firmware to qcpas device. It loads, but give up on time

12:29 <Guest10485> Right now system waits 5 seconds before timeout occure. I feel that it is long enough and issue somewhere else. Frankly, it is quite often. Like 1 or out 2 or out of 3 boots.

12:29 <Guest10485> So, here the question: does it ring any bell?

12:31 <Jasper[m]> Yes it will reset the controller and the uuid of the usb device (iirc) will not be the same as when boot was initiated

12:32 <Guest10485> I see that all USB devices is reattached after boot the controller.

12:32 <Jasper[m]> If you don't let qcom_q6v5_pas load on boot, when booting from usb, it will not reset the controller

12:33 <Guest10485> Yep, but question is different: does it need some quirkcs?

12:33 <Jasper[m]> on fedora this is fixed by adding the modprobe.blacklist=qcom_q6v5_pas cmdline parameter

12:34 <Guest10485> Right now it loads firmware to the controler each boot. I see that devices is deattached, but never reattached if it timedout

12:34 <Jasper[m]> From what I remember they are reattached

12:34 <Jasper[m]> The partition uuid's will not be the same as before though, leading to the timeout

12:35 <Jasper[m]> (assuming that's how OpenBSD boots)

12:35 <Guest10485> but why it is happens not each boot when?

12:35 <Jasper[m]> From my (limited) experience it does

12:36 <Jasper[m]> But the issue is that the init system cannot find the rootfs it's trying to mount because it tries to find the partition it has detected before

12:36 <Guest10485> Ok, on my machine it timedout 1 boot out of 2 or 3. And it doesn't cold or hot boot.

12:36 <Jasper[m]> Guest10485: It will not work unless you blacklist the `qcom_q6v5_pas` driver when booting from usb

12:37 <Guest10485> It loads firmware from root partition, but the controler / device timedout and when it happens, here no USB-C devices

12:37 <Guest10485> Jasper[m], I boot the system from the internal drive, not USB.

12:38 <Jasper[m]> Guest10485: Yes, it will reset the controller, as I said

12:39 <Guest10485> but why it boots sometimes?

12:39 <Jasper[m]> Guest10485: Then I'm not sure what the problem is? Are you saying USB breaks entirely after reloading the firmware?

12:39 <Jasper[m]> Guest10485: It hasn't for many of us

12:40 <Jasper[m]> If you don't want the controller to reset during boot you need to blacklist qcom_q6v5_pas

12:40 <Guest10485> 1 out of 2/3 boot firmware not loaded, and when it is happens no USB-C ports on the left side of machine. The right side with USB-A works as expected.

12:40 <Guest10485> If firmware is loaded, USB-C ports on the left side is back. If it timed out -- no USB-C ports

12:42 <Guest10485> Before I thought that it is related to cold or hot boot, but after seires of test I don't see any corelation.

12:42 <Guest10485> nor machine on wall power or battery

12:42 <Guest10485> BTW, when it timed out, usually it stop charching as well

12:43 <Guest10485> but if I reattach the USB-C connection, it starts to charge again

12:53 <Jasper[m]> Not really running into this issue on my X13s, I'm only running into the known issue of it not detecting very well what the capabilities of a usb device is

12:55 <Guest10485> unfourtently Linux doesn't boot on this machine at all, so I can't be sure that it isn't OpenBSD specified things

12:55 <Guest10485> but by comparing logic of both drivers I don't see anything that may explains it

13:20 <Guest10485> BTW any chance to have a review for https://lore.kernel.org/linux-devicetree/87jzazzx17.wl-kirill@korins.ky/ ?

14:50 <Guest10485> well, seems that the controler in some wired state and waiting for long time (I've tried a minute) doesn't help. Nor re-mount and re-init everything.

15:30 <JensGlathe[m]> sudo systemctl reboot

15:35 <JensGlathe[m]> The problem is timing, and if you mounted rootfs from type-c before loading the adsp firmware. The adp firmware boot disrupts VBUS for the type-c ports shortly, leading to the re-enumeration - but your rootfs is inaccessible then. The only "safe" way to avoid this is not to boot from type-c, or not load adsp firmware at all.