17:28 <julian[m]12> bamse: Thanks for your response. I don't really know what these values do, I just noticed that what it is set to during boot is usually too low to enable charging. Is usb-charge-current-limit the limit to how much current in total can flow through usb?

17:29 <julian[m]12> So I don't know what would happen if it is set to some large value

17:37 <bamse> julian[m]12: it defines the amount of current the charging block is allowed to pull from usb

17:38 <bamse> julian[m]12: and it depends on what's on the other end of the usb cable

17:39 <bamse> julian[m]12: iirc if you don't know the max is 100mA, when you have a PC on the other side you typically can pull 500mA and if you have a dedicated charger you can pull as much as it gives

17:39 <bamse> julian[m]12: but i don't think a PC would give you more than 500mA anyways, so setting it high always seems to work...but is violating the 100mA limit for the case where you haven't yet done the handshake with the other side

17:41 <julian[m]12> bamse: oh, I see. So it "should" be set to a correct value already without the driver doing anything, but for some reason it is not?

17:42 <julian[m]12> and the driver doesn't know how high it should be set so it plays it safe and sets it to 100mA?

17:49 <julian[m]12> I change my last guess: The driver doesn't touch the max charge current unless it finds it in the .dts?

17:50 <julian[m]12> or unless it is not between 100mA and 2.5A

17:50 <bamse> julian[m]12: the .dts option is a hack...the right approach is to set it at 100mA and then through some interaction with the usb stack get to know when it can be elevated to 500mA or some high number

17:51 <bamse> iirc we never documented the dt property...just because it's not supposed to be used

17:51 <bamse> but if you care more about charging your device than adhering to what the specification says, then you can use the property

17:51 <bamse> it's just not the right way...

17:54 <julian[m]12> bamse: Ideally I would like to adhere to the specification AND be able to charge my device ;) But I have never done kernel development, so I don't know how reasonable it is to aim for that

17:55 <julian[m]12> But that means the interaction with the usb stack is something that should be implemented in qcom_smbb.c ?

17:56 <minecrell> bamse: The whole charger detection stuff is a real mess though, somehow there are at least 2-3 different approaches in the kernel for that. There is extcon, something in power supply and probably yet another way i'm not aware of yet

17:56 <minecrell> bamse: And it doesn't really help that often there are different components involved for USB/charger detection. Sometimes extra chips, sometimes type-c stuff I guess, sometimes the USB PHY, ... :(

17:56 <minecrell> Ignoring the standard is kind of the more convenient option with all this complication

18:00 <julian[m]12> And how is it with the other devices which have that pm8941, does charging work for them?

18:09 <bamse> minecrell: right, the typec framework seems to clear up some of the apis, but i don't think it covers this part...and it doesn't solve the pre-typec issues we're seeing anyways

19:45 <DavidHeidelberg[m]> Mis012 log in from oftc webclient and you can see if it works ))

19:47 <DavidHeidelberg[m]> блять

19:50 <DavidHeidelberg[m]> you discovered me... btw. recompiling kernel with some lockups -> panic -> reboot options, hopefully will kernel reboots when it catches rcu stall

19:50 <DavidHeidelberg[m]> since getting data from pstore after pwr-off and pwr-on is not so lucky every trial

21:03 <DavidHeidelberg[m]> were do I get this cool ECC

21:04 <DavidHeidelberg[m]> can I push it as cmdline param?

21:07 <DavidHeidelberg[m]> pstore.ecc=16 to the moon

21:07 <DavidHeidelberg[m]> I'm not insane. I'm not talking to myself. I hear voices in the Matrix

21:08 <DavidHeidelberg[m]> you're not helping minecrell

21:18 <Mis012[m]> certificates are vastly superior to passwords for this usecase for sure

21:18 <Mis012[m]> preferably autogenerated ones

21:18 <Mis012[m]> minecrell[m]: well, am I gettting through to irc now?

21:19 <minecrell> yes

21:19 <DavidHeidelberg[m]> [ 0.048066] ramoops: found existing invalid buffer, size 2148009988, start 805306373

21:19 <DavidHeidelberg[m]> hmm, even ecc=16 is not enough, the power outage between off-on is too long

21:19 <DavidHeidelberg[m]> few times it worked was probably pure luck

21:20 <Mis012[m]> bamse: I was trying to talk to you earlier, but it seems that my fancy bouncer f'd up... should I copy it as text or is an image fine? :D

21:21 <Mis012[m]> the screenshot has the positive that it can't be mangled by the bridge

21:22 <Mis012[m]> > <@okias:matrix.org> [ 0.048066] ramoops: found existing invalid buffer, size 2148009988, start 805306373

21:22 <Mis012[m]> just put it in a freezer

21:22 <Mis012[m]> > hmm, even ecc=16 is not enough, the power outage between off-on is too long

21:23 <Mis012[m]> subambient RAM watercooling: the real usecase

21:23 <DavidHeidelberg[m]> I'll cold spray it and extract the encryption keys from it... oh wait, the dmesg..

21:24 <Mis012[m]> could probably do that with SoC swap? please noone tell qcom

21:24 <Mis012[m]> not sure if TZ keeps the keys in RAM though

21:24 <Mis012[m]> not like it would matter

21:25 <Mis012[m]> you would need actual proper encryption with a password of an appreciable strength to keep your data safe

21:26 <Mis012[m]> none of this four numbers with TZ counting number of tries

21:27 <Mis012[m]> with qcom's big bloated TZ there will probably always be some way in if you have enough resources to throw at it

21:27 <Mis012[m]> though I saw something about trustlet sandboxing, not a bad idea

21:31 <DavidHeidelberg[m]> btw. managed to do boot with just killing one driver in _probe function, so it's the driver or some driver depending on it

22:19 <DavidHeidelberg[m]> such a great feeling, when you realize that fix merged into LTS fixes problem which you used ugly hack for many kernels :) (sadly the patch didn't collided in codebase when rebasing)

22:50 <Mis012[m]> LTS and mainlining don't usually coincide...

23:00 <DavidHeidelberg[m]> well, until today, -next even didn't gave me pstore dmesg. Now at least I have -next log https://paste.sr.ht/~okias/04b09b15a88a307a0881207e4af87a75a8c56a51

23:00 <DavidHeidelberg[m]> and it still seems to misses some link to mmc