ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev>
they really should label it wont-fix not cant-fix
<amstan>
yeah, that's pretty bad
<steev>
clover[m]: fwiw, we're all just developers at the end of the day
<amstan>
their bootloader simply won't support device trees, therefore it's not really good for ARM, is it?
<steev>
i mean, the init system swallowed a bootloader... and they're complaining about embedding ftd?
<amstan>
lol
<steev>
also oops, forgot to charge the lenovo again
<steev>
hopefully next week we can maybe get battery things :(
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<qzed>
steev: you saw the `alg: akcipher: sign test failed. err -22` on next too, right?
<qzed>
also on the flex? seems like that's a thing on sc8180x too
<steev>
qzed: i haven't tested the flex on next yet
<steev>
still waiting on bamse to quit slacking and resubmit
<steev>
disclaimer: i don't really believe bamse is slacking, and i owe him many tasty beverage of choice
<qzed>
heh, would be great to have a sc8180x dt, if only for me to finally have a reason to clean up and submit the SAM patches
<steev>
i do see the self test failures on the x13s
<qzed>
also: I still had to revert that driver probe stuff :/
<qzed>
multiple? I only see one, yay
<steev>
qzed: I thought it was unrelated to what you see
<steev>
That said, have you looked at jhovold’s next stuff? He’s got some pcie stuffs
<qzed>
I meant the stuff for the edp display probe-defer thing
<steev>
Oh, right
<steev>
The broken display on next
<qzed>
not really, but I've replaced the one efi-reset-hack from shawn with his, his seemed cleaner
<steev>
I had completely forgotten that, and wasn’t even running it on the flex
<qzed>
also ssh over the usb-ethernet adapter is pretty choppy...
<steev>
I haven’t revisited the mp usb stuff recently, I do need to
<qzed>
seems better when I download something, or run ping
<qzed>
so maybe some power-saving thing
<steev>
ayy, the good news is, the deferred audio device on c630 isn't anything in my patches, just tried a next with none of my stuff on top, and just the bwmon patchset and yeah... deferred device
<steev>
xnox: whenever you're around, how does ubuntu do it so that the triggers like update-grub only happens once when removing multiple kernels and such?
<robclark>
amstan: tbf, the fw is the thing (according to spec) that should be loading the dtb
<robclark>
(whether that is a good idea or not.. I'll leave to others to debate.. with uefi it is doable because of the "e" part of "uefi")
<steev>
qzed: hm, for some reason, i'm running into an issue here; using your 4 patches, against 20220722 next, and in sdm845.dtsi, i have the compatible, i see it on the c630 in /proc/devicetree/firmware but... the variables aren't in /sys/firmware/efi/efivars is... empty
<qzed>
I've tested 20220722 on the spx a couple minutes ago, seemed to work fine
<qzed>
can you try mounting efivarfs manually?
<steev>
i'm wondering if there's some bad interaction between this bwmon thing
<steev>
sure, one moment
<steev>
oh god damn it
<qzed>
bwmon?
<steev>
it's not a bad interaction
<steev>
wtaf
<steev>
EFIVAR_FS=y but trying to mount, i get unknown filesystem type
<qzed>
huh
<steev>
so the differences where it's working, in terms of config, EFIVARS_FS=m (working) =y (not working); EFI_BOOTLOADER_CONTROL=m (working) is not set (not working)
<qzed>
I don't have the next config on hand any more, but I have EFIVARS_FS=y in the 5.19 config
<qzed>
[ 2.245867] request_module fs-efivarfs succeeded, but still no fs?
<qzed>
wtaf
<qzed>
so as far as I can tell the uefisecapp stuff registers properly
<steev>
that's what i said!
<qzed>
so we have
<qzed>
[ 0.264678] Registered efivars operations
<qzed>
and later even
<qzed>
[ 0.270715] pstore: Registered efi as persistent store backend
<qzed>
which IIRC doesn't work without efivars
<qzed>
although no clue whether it actually works
<steev>
it's... weird
<qzed>
although... I think generic efivars also use that... let me check my log
<qzed>
oh huh right, I get the "Registered efivars operations" two times... so I guess the one you get is just the generic one... means it's not loading
<qzed>
I should probably add a dev_info or something when it's loaded successfully
<qzed>
do you have a driver node under `/sys/bu/platform/devices/firmware:tee-uefisecapp`?
<steev>
Let me look
<steev>
i do
<steev>
it points to bus platform drivers qcom_tee_uefisecapp
<qzed>
so the driver is loaded...
<qzed>
could you try unbinding and re-binding it?
<steev>
how do i unbind it? i'm not sure what the bus id should be
<qzed>
I think `echo -n firmware:tee-uefisecapp /sys/bus/platform/drivers/qcom_tee_uefisecapp/unbind`
<steev>
i'm able to echo that, but nothing changes
<qzed>
oh wait, I forgot the `>`
<steev>
oh derp lmao
<steev>
i had that and i removed it
<qzed>
so echo to that path... unless you already did that
<steev>
write error, no such device
<qzed>
hmm... maybe just `tee-uefisecapp`?
<qzed>
so I also see the `pstore: Registered efi as persistent store backend` even if I don't have the uefisecapp stuff enabled
<steev>
aha
<steev>
it's firmware:tee-uefisecapp
<steev>
and i am an idiot who wasn't doing the full secapp
<steev>
that does give me Unregistered efivars operations
<qzed>
okay, so then there should be no more efivars (neither generic nor normal)
<steev>
and doing the same to bind, i get Registered efivars operations
<steev>
but then nothing
<qzed>
huh
<qzed>
did you remount efivarfs?
<qzed>
I think output-wise that's normal
<steev>
remounting says, no such filesystem
<qzed>
did you do a proper mount or -o remount?
<steev>
mount -t
<qzed>
that should have worked...
<steev>
trying -o remount, says mountpoint not mounted
<qzed>
yeah, that's what I'd have expected
<steev>
and there is 0 output in dmesg
<steev>
i'm gonna test something else here
<qzed>
okay
<steev>
nope, that wasn't it, okay
irl25519 has quit [Quit: irl25519]
<steev>
i wanted to make sure it wasn't an interaction with the bwmon patches because he'd mentioned secure world
irl25519 has joined #aarch64-laptops
<steev>
this is next with bamse's i2c fixes, your uefisecapp and then my patch to the sdm845 dtsi, nothing else
<steev>
so
<steev>
i'm gonna try bouncing back to 20220720, because i know that it works there, on the thinkpad
<qzed>
20220722 with the whole bunch of spx patches worked too... and the hard dependencies are essentially just QCOM_SCM
<steev>
hm
<qzed>
can you enable debug output for the module and then try re-binding?
<qzed>
and mounting efivarfs again?
<steev>
if you tell me how, yes
<qzed>
that should at least show us if there are some calls to the efivar functions
<qzed>
1sec
<qzed>
need to figure out how to do that again myself xD
<steev>
:D
<qzed>
ah, defconfig has dynamic_debug disabled :/
<qzed>
so not sure if you have that
<qzed>
but if: `echo "qcom_tee_uefisecapp +p" > /sys/kernel/debug/dynamic_debug/control` should do the trick
<qzed>
okay, so I have no clue what's going on in efivarfs but there are two options I think: either it is some problem with that, or it is some issue in the uefisecapp driver that causes some sort of error when mounting which prevents the mount and causes that error
<qzed>
oh nice
<steev>
I know it works, because I previously tested it on the 5.19.0-rc7
<qzed>
but there at least don't seem to be any further scm calls, so it doesn't get to that... meaning at least the trustzone stuff can't mysteriously act up
<qzed>
can you add a
<qzed>
`pr_info("%s\n", __func__);` to the beginning of these functions:
<qzed>
and just to make sure: EFI_BOOTLOADER_CONTROL=y works as well...
<qzed>
I think I'm gonna send them off now
<steev>
:D
<steev>
The Qualcomm QCNFA765 module uses Intel Bluetooth chipset, You need to install the WiFi and Bluetooth drivers separately.
<steev>
that... seems odd?
<qzed>
haven't heard anything from bamse wrt where I should put them, so I guess he can complain on the mailing list
<qzed>
interesting
<steev>
that's what we have in the thinkpad
<qzed>
I guessed so :)
<clover[m]>
Want to self host a custom Pacman repo next. That's the next plan and hopefully secure it with a GPG key. I'll have the steev kernel and the firmware for battery charging. Idk what else yet.
<HdkR>
Let's see if I can copy some a690 stuff in to a DTS and hope for the best