ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Arrow canceled my order for the Dev Kit wow
<zdykstra>
Which dev kit is that?
<JensGlathe[m]>
Snapdragon Dev Kit
<JensGlathe[m]>
... and apparently killed my account or something
<HdkR>
Dang, I see an unpopulated PCIe slot on that board. What a shame
<JensGlathe[m]>
yep
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
I wonder how far one would get by just populating those spots yourself, not the most difficult things to solder
<SpieringsAE>
all the chips around the hdmi port seem to be there, hell, maybe design your own daughterboard with DP instead of HDMI
<SpieringsAE>
the PCIE slot seems to have something hijacking part of it
<SpieringsAE>
ah no its just a cable managment clip stuck on there
alfredo has joined #aarch64-laptops
<MrCatfood[m]>
even windows cant handle the lid properly, every time i start my laptop, i need to close the lid and open it up again for it to show the login screen -.-
iivanov has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
macc24 has joined #aarch64-laptops
<macc24>
kuruczgy: i wrote a piece of rust code that talks to ec over i2c
<anonymix007[m]>
abelvesa: USB-A works now! But I'm getting a lot of warnings in dmesg: https://katb.in/wazucasiqof
bluerise_ has joined #aarch64-laptops
dlg has quit [Remote host closed the connection]
dlg has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
<hogliux>
Has anyone had any experience with USB4 PCIe tunneling/thunderbolt alt mode? I have a PCIe NIC I need for work in a thunderbolt enclosure. It works on Windows on the yoga slim 7x. Nothing happens on Linux even with all the recent patches to the retimer (i.e. DP alt mode works for me in Linux).
<craftyguy>
any reason why I can't enable CONFIG_CRYPTO_DEV_QCE on the x13s?
<craftyguy>
"CONFIG_CRYPTO_DEV_QCE", I mean 🙃
<travmurav[m]>
doesn't look like it was ever added to 8280
<craftyguy>
it seems like performance with luks isn't great, and it seems like hw accel for crypto isn't enabled in jhovold's kernel. but I'm not sure if that's for any particular reason or not
<craftyguy>
that was kinda a guess as to which kconfig I might need to enable for it... is there something else I would need to enable? or is hw crypto accel not a think on the 8280?
<travmurav[m]>
it's probably there in hardware but it was never described in the dts
<travmurav[m]>
so even if you enable it, it won't work
<HdkR>
hogliux: Thunderbolt/PCIe tunneling isn't wired up in Linux. Sad day I know
<craftyguy>
travmurav[m]: oh gosh
<craftyguy>
is there a "enabling crypto in dts for dummies" I could study?
<travmurav[m]>
well the main problem is like... knowing at what address it's located and which iommu lines it uses which is like ugh...
<craftyguy>
how is that stuff typically discovered/known?
<travmurav[m]>
by someone who works at quic I'd say :P
<craftyguy>
🤦
<travmurav[m]>
craftyguy: quick look at it seems to suggest that it might even be protected since there is a comment in 8350 (same ish generation mobile platform) that enabling related dma crashes the system
<bamse>
craftyguy: do you know how to test qce? i have the patches ready, the driver probes, but i don't know how to test it
<craftyguy>
oh really?
<craftyguy>
I'd probably test it by enabling the kconfig option for QCE (mentioned above) and see if performance improved for my rootfs that is on luks. I assume that's a valid test, but .. heh
<bamse>
yeah, that might be a relevant test case...i could post the patches and state that they are untested...
<craftyguy>
if you're worried, you could DM me the branch location, or pastbin the patch, or email it to me. I won't distribute, but would be suuuper happy to help test
<bamse>
yeah, i guess i can push them somewhere...let me do that
<craftyguy>
emailing me a patch also works if that's too much trouble. I'm just happy I don't have to stumble my way through making a patch myself 😅
<bamse>
i was hoping to figure out that i can just throw one of the kcapi test tools at it and get a "test ok" out...and then the patches just sat there
<craftyguy>
bamse: ping me once you're ready to share and I'll give it a try, and report back. thanks :D
<abelvesa>
anonymix007[m]: yeah, that's the usb_2 controller which I was talking about. I only enabled it because I thought there might be something connected to it (e.g. fprint sensor). Not having schematics made me push the boundaries a bit. Thanks for reporting this. Doesn't show up on my t14s.
<abelvesa>
anonymix007[m]: just drop this commit and you will not see that splat anymore:
<steev>
bamse: tested it here, and i get a deferred device for 1dfa000 but no serror
<bamse>
steev: sounds like we/you are missing some dependency then?
<steev>
possibly
<steev>
i'll let craftyguy look into it though :D
<bamse>
well...i have the crd running, so let me cherry-pick and take it for a spin...
<steev>
all i did was those 2 patches and make CRYPTO_DEV_QCE a module
<bamse>
applied the one patch ontop of linux-next, built defconfig, booted the crd and "ls /sys/devices/platform/soc@0/1dfa000.crypto" returns stuff
<bamse>
steev: do you not have CONFIG_QCOM_BAM_DMA ?
<steev>
i see stuff in there too
<bamse>
ahh, so then it did come up after all :) nice
<bamse>
now we just need to know how to test it...
<steev>
it's up but it says its still deferred?
<steev>
and no, i don't have qcom_bam_dma
<bamse>
ahh, of course...forgot that you will have some stuff in there...
<steev>
let me enable bam dma too
paddymahoney has quit [Ping timeout: 480 seconds]
<steev>
yeah, it was the missing bam_dma :)
paddymahoney has joined #aarch64-laptops
<macc24>
i've went through most ec writes that could do /something/ on lenovo yoga slim 7x and nothing changed except now my wifi is down for some reason
<robclark>
there is a physical rf-kill switch.. maybe that goes to the EC and you've triggered the sw equiv?
<robclark>
(or is it a camera-kill?)
<macc24>
it's a camera-kill
<macc24>
i *think* i triggered the software switch
<robclark>
ahh, ok, makes sense then why it doesn't do anything on linux
<macc24>
that enable/disable ec stuff in dsdt just enables or disables ec interrupts
<craftyguy>
bamse: I enabled bam_dma and the dce kconfig options, rebooted and the system reboots when it loads the module (I think, not totally clear since I haven't figured out how to get logs from kernel when it happens)
<bamse>
craftyguy: would you expect that loading loading the module would cause the device to be used immediately?
<bamse>
craftyguy: i'm able to load the module and probe the device just fine on my devices (and steev did as well)...but we don't use it...
<steev>
not yet :( the 6.12 kernel, i might be okay with doing an encrypted rootfs
<steev>
it would be nice if someone at qualcomm *cough cough* would get the venus firmware in
<minecrell>
bamse: qcom,controlled-remotely works only in combination with clocks/icc or static num-channels/qcom,num-ees properties. Otherwise you rely on pure luck that the BAM is powered on while trying to auto detect those