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)
echanude has quit [Ping timeout: 480 seconds]
<jenneron[m]> steev: if you're interested I have 6.1.7 branch for flex 5g with a recent glink patchset and working camera https://gitlab.com/jenneron/linux/-/commits/flex-5g-6.1.7
<jenneron[m]> however it is really mess
<jenneron[m]> I didn't put efforts to make it clean
<jenneron[m]> for making it cleaner we would want a common kernel tree for surface, flex 5g and galaxy book s until everything is upstreamed
<jenneron[m]> also, those GPU glitches don't happen on 6.1.7, that was some linux-next problem
<jenneron[m]> of*
<steev> oh, i may give that a shot, eyah
<jenneron[m]> also, i still couldn't get modem to work
<jenneron[m]> has anyone actually tried it?
<jenneron[m]> on flex 5g
<jenneron[m]> and i sometimes get [drm:dpu_encoder_frame_done_timeout:2388] [dpu error]enc31 frame done timeout
<steev> yeah, that's not uncommon, i've seen that before, used to see it a lot on the c630, but i don't recall what abnihav did to fix it, or if we ever did or if it just became so rare that i ignored it
<steev> i haven't tried modem at all, i'm not rich enough to have a mobile connection on my laptop
<jenneron[m]> i'm daily driving this laptop and this thing is a little annoying
<jenneron[m]> steev: i'm lucky that it's pretty cheap in my country
<jenneron[m]> i pay 6$ for 1 TB / month
<jenneron[m]> however this tariff is not for everyone
<jenneron[m]> <steev> "yeah, that's not uncommon, i'..." <- i think nothing
kettenis has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> i... i wish i could pay 6$ for 1TB
<jenneron[m]> well.. useless without working modem
<steev> sure
<jenneron[m]> i dropped windows from my laptop
<jenneron[m]> overall i feel good
<steev> ah yeah, that guy will throw me emails every so often, but i've never been able to reproduce most of his issues
<steev> i keep telling him to join irc and he keeps saying he's "not good enough"
<steev> and i dunno what else to say
<jenneron[m]> not good enough?
<steev> i have no idea what he means by it
<steev> like he's not worthy of talking in here or something
<jenneron[m]> btw does anyone have flex 5g schematics?
<steev> i do not
<jenneron[m]> there are available on the internet, but for money
<steev> the only schematics i have are for the efikamx :D
<jenneron[m]> I finally have panel + gpu on initramfs stage
<steev> qzed: I screwed up somewhere -
<jenneron[m]> fun fact: 8cx scores less in glmark2 on wayland than exynos 5420
iivanov has joined #aarch64-laptops
juergh is now known as Guest2472
juergh has joined #aarch64-laptops
albertobasaglia has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
juergh is now known as juergh[m][m]
juergh[m][m] is now known as _juergh[m]
Guest2472 is now known as juergh
_juergh[m] is now known as juergh[m][m]
kettenis has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<qzed> steev: huh, I have no idea why that happened... it failing in efivar_lock() us weird
<ardb> that just means efivars == NULL afaict
<ardb> i mean __efivars
<qzed> Ah, right it only checks for ops
iivanov has quit [Quit: Leaving...]
<jhovold> qzed, ardb: not sure how steev managed to hit that, but I guess it's with the forthcoming v2 series.
<jhovold> either way, I think this series should prevent it:
<qzed> jhovold: from what I can tell from the locks, there's a problem initializing qcom_scm
<qzed> qcom_scm: firmware:scm: error -ENXIO: IRQ index 0 not found
<qzed> so my guess is that the custom efivar ops aren't even registered
<qzed> that would fit __efivars being NULL
<jhovold> yeah, that's what it looks like, but the series I linked to above would have added a check for a NULL __efivars at mount time which should have prevented the NULL deref
<qzed> right, I know too little about fs stuff, so I assume that an error in efivarfs_fill_super() ensures that efivarfs_kill_sb() is never called?
<jhovold> I would have thought so, but perhaps steev is using my series and that's where the bug really is
<qzed> I'm just wondering how this works, because the efivarfs_kill_sb() seems like a cleanup function? so I guess something in the setup errors out (which could be due to your check)
<qzed> so maybe a similar check is required in efivarfs_kill_sb()?
<jhovold> yeah, that's what I fear. Checking now
<jhovold> qzed, ardb: yes, that's it. My patch was buggy, preparing a fix
<jhovold> steev: this should address the efivarfs NULL-deref (but not the scm driver error):
albertobasaglia has quit [Quit: WeeChat 3.8]
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<juergh> abelvesa, I'm getting 'UBSAN: shift-out-of-bounds in drivers/soc/qcom/llcc-qcom.c:772:45' on an x13s. in my setup slice_id goes all the way up to 36.
echanude has joined #aarch64-laptops
<abelvesa> juergh: which kernel version are you running with ?
<abelvesa> juergh: wait, it is in the pastebin
<juergh> abelvesa, linux-next
<juergh> well that is an ubuntu abomination of 6.2-rc4 with some next patches
iivanov has quit [Ping timeout: 480 seconds]
<steev> jhovold: qzed: will give that a spin - as for how... well, i have no idea what i'm doing, so i had added the qsee-com entry but not an scm entry because i don't know what scm should be, and previous iteration didn't require it, but that gave the same null deref, so i simply backed out the dts changes, but left qseecom and efivars enabled (but nothing in the device tree, afaik)
<steev> and yeah, it's with the forthcoming v2 series
<steev> that is what i had, was getting the exino
<steev> and then kernel panic
<qzed> yeah, so with the fix from jhovold you shouldn't be getting the panic any more
<qzed> I'm still not entirely sure why the enxio is happening though...
<bamse> with jhovold's efivarfs fix i'm tripping a NULL pointer dereference in a mutex_lock() 100% during boot...
<bamse> haven't debugged it yet, but i suspect it's because i'm doing something unexpected
<jhovold> bamse: which fix? you'd need both what's in next and the one linked to above
<qzed> steev: ah, I think that's an optional IRQ, so all should be fine and it just complains I guess?
<bamse> jhovold: straight off linux-next is crashing for me
<jhovold> right, and if you apply this one:
<jhovold> sorry, wrong link
<bamse> that seems applicable
<bamse> thanks
<jhovold> steev, and anyone else using 6.2-rc for the X13s: I've just pushed a new branch based on rc5:
<jhovold> changes since last branch (rc1), include:
<jhovold> - rtc support
<jhovold> - display support updated (v7)
<jhovold> - pmic glink updated (v2)
<jhovold> - johan_defconfig updated
<jhovold> - sound enabled in dts, but not in config due to incomplete driver support
<jhovold> - mdss iommu identity domain
<jhovold> - efivarfs fixes
<steev> jhovold: oh spiffy, I’ll pull those changes down.
<steev> Would the rtc support also work for sdm845? Or is it specific to the 8280xp?
<jhovold> the implementation is generic, but for the X13s I'm using a few PMIC registers to store the RTC time which may not be available on the sdm845
<jhovold> If that machine uses UEFI, you may be able to use the UEFI RTC support after just enabling it in the dts
<jhovold> so either you need to find some non-volatile storag (and nvmem cell) and add that to the dts, or
<jhovold> you define the rtc nodes and specify 'qcom,uefi-rtc-info'
<jhovold> I'd check first if that system has the following 12-byte UEFI variable:
<jhovold> 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo
<jhovold> well, actually the driver will not probe if that variable is missing so just adding that property does not hurt
alfredo has joined #aarch64-laptops
<juergh> abelvesa, Looks good, UBSAN seems happy now. Is there anything else that changes with this patch that should be noticeable? I'll reply to the email as well. thanks for the quick turn around.
<abelvesa> juergh: seems I messed up something, so I need to send v2 soon
<steev> jhovold: aside from a weird not recognizing panel thing, seems fine - https://paste.debian.net/hidden/0142eb56/
alfredo has quit [Quit: alfredo]
<selmer443[m]> Clover did you ever get the battery support back on the x13s? Im taking it into school today and I have no battery indicator still haha
<clover[m]> no i rolled back to steevs older kernel
<clover[m]> it has the patches for reading battery capacity
<steev> did y'all check if that patch i mentioned is in the sources?
<steev> but v2 of bamse's pmic_glink stuff should fix it too, iirc
<selmer443[m]> I’ll roll back to the other kernel when I get home
echanude has quit [Ping timeout: 480 seconds]
<steev> jhovold: also, fwiw... that didn't happen the next time i booted it
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops