01:35 <naoki> qschulz: rfkill for ROCK 5A is required/tested with Radxa A8 module (it's first class? tier1? device for us)

01:36 <naoki> I don't know rfkill for ROCK 5C yet... there is no driver for AIC8800 for mainline(latest) Linux

07:19 <naoki> hmm, thunderbird spell checker decide "typo" is correct but "copy-pasto" is not correct...

08:27 <naoki> Probably ROCK 5B+ will be arrived tomorrow, but I think I need some time to review my change myself...

09:52 <qschulz> naoki: if it's an m.2 connector which follows the spec, I don't see why people would be forced to use only Radxa A8 module :)

09:52 <qschulz> naoki: I've never heard of copy-pasto :)

10:44 <CounterPillow> "M.2 connector which follows the spec" is a whole can of worms, because the spec allows for many things to go over M.2, most of which will not be done by any system

10:45 <qschulz> CounterPillow: I meant more like "providing 12V power rail on a data lane" kind of "not following the spec" example

11:47 <naoki> I just ordered AX210 card for testing :)

14:22 <naoki> I ordered MT7922 too

15:28 <diederik> "20480: build(rk3568): add build configs for rk3568 | https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/20480" has been merged \o/

15:33 <qschulz> diederik: do we not need still https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/31265 ?

15:33 <qschulz> but yay nonetheless, progress :)

15:35 <diederik> qschulz: very much so, but indeed at least some progress ... and with that merged 31265 could get a 'Verified' checkmark

17:35 <wens> reminds me, some board has bluetooth over uart described in its dts, only that bluetooth module is on the m.2 slot and for many folks might not actually exist...

17:36 <qschulz> wens: should then be a dtso I believe

17:36 <wens> ROCK 3A that is, describes Radxa A8, but people are free to not buy it, or install some other module, like I have a realtek one

18:03 <diederik> With the Quartz64-A I always get errors in dmesg as I don't have the Wi-Fi/BT module

19:16 <hexdump0815> i have updated the kernel on my rk3288 veyron mighty chromebook to v6.12 and noticed that it does not shutdown properly anymore

19:17 <hexdump0815> it shuts down well on the linux side, but something still remains on so that a usb mouse still has power and it drains the battery quickly when "off" this way

19:18 <hexdump0815> i first manually bisected it across major linux versions and found that the problem appeared between v6.4 and v6.5

19:19 <hexdump0815> then i bisected between those two versions and found the bad commit to be 4fec8a5a85c495851007084e632b7f3f87cb7bdb - "mfd: rk808: Convert to device managed resources"

19:19 <hexdump0815> i.e.: https://github.com/gregkh/linux/commit/4fec8a5a85c495851007084e632b7f3f87cb7bdb

19:20 <hexdump0815> this is part of this series: https://patchwork.kernel.org/project/linux-rockchip/cover/20230504173618.142075-1-sebastian.reichel@collabora.com/

19:20 <hexdump0815> does anyone here have any idea what around all this is breaking the proper power-off of veyron chromebooks?

19:22 <hexdump0815> besides that: can anyone else with a veryron chromebook try to reproduce the problem? this is with vanilla v6.12 mainline without any patches

19:23 <hexdump0815> an easy way to reproduce it is to run such a kernel, shutdown from linux and try to power it on again via a short press of the power button - if it powers on its ok if it does not power on and first requires pressing the power button for 20sec to be able to power on again then the problem is there

19:26 <hexdump0815> urja: amstan: mmind00: sre: ^ any idea maybe?

21:19 <urja> hexdump0815: yeah i already bisected that and reported it

21:21 <urja> and a fix was suggested by the author and i tested it ... and i guess the fix never got upstreamed? i'm not sure if 6.12 i new enough

21:22 <urja> hexdump0815: https://github.com/urjaman/linux-for-my-autobuilder/commit/4a34bceaa8a5be727ed5a49782235f9606571d1f there's the interim fix the author suggested

21:34 <diederik> https://lore.kernel.org/linux-rockchip/20240730180903.81688-1-sebastian.reichel@collabora.com/ is probably more useful

21:36 <urja> yeah i try to stay as far as possible from mailing lists (and the github that's being used by my cronjobs is also not supposed to be a release platform, mostly a backup lol)

21:38 <diederik> to get things upstreamed, MLs are (pretty much) a requirement

21:40 <urja> yeah i've given up on doing anything except report regressions with them (but also, i'm not producing anything to upstream either..)

21:41 <urja> I am happy to know that 6.12 is supposed to boot on veyron; i feel a bit safer when updating this laptop next time (to what that cronjob has built :P)

21:44 <urja> i prefer sitting by the fireplace and staring into it, nightnight

22:01 <hexdump0815> urja: diederik: thanks a lot for the quick response - i'll give the proposed solutions a try and report the results back here ...

22:03 <diederik> Reporting it to the ML would be (much more) useful ...