ChanServ changed the topic of #linux-msm to:
<vkoul> z3ntu: I would need to check which one is sm6350 derived from, the ee one was added in SM8350 onwards...
<vkoul> well that calculation is bit tricky :-) the offset is used to calculate the register offsets which are now differing, yes base falls outside but it is never used
lumag_ has quit [Ping timeout: 480 seconds]
<sepkov[m]> GM guys. After adding reset things to dts I get boot loop as I said before. I get kernel dump of crash from ramoops
<sepkov[m]> Would you mind take a look at what is wrong?
<sepkov[m]> I checked voltage regulators and values look normal
<sepkov[m]> It was whining previously about "reset control not found -2" after 3.194575
<sepkov[m]> Now it doesn't but phy doesn't seem to boot up back again
<sepkov[m]> This looks very similar to mine
<sepkov[m]> What did you find about this?
<Tooniis[m]> all the issues i was having turned out to be caused by missing `regulator-allow-set-load` in ufs regulators
<Tooniis[m]> making them stay in LPM and probably unable to deliver enough current to the UFS chip
<sepkov[m]> So all those .c file commits are for nothing?
<Tooniis[m]> yes, they dont do much
<sepkov[m]> So any tip about where can I determine them?
<sepkov[m]> Just try and error?
lumag_ has joined #linux-msm
<sepkov[m]> So ```qcom,set = <0x3>``` corresponds to ```regulator-allow-set-load```
<sepkov[m]> Right?
<sepkov[m]> It says regulator can be configured to active or sleep
<sepkov[m]> Guys?
<sepkov[m]> If it's not regulators too what can it be???
jhovold has joined #linux-msm
pevik_ has joined #linux-msm
dliviu has quit [Ping timeout: 480 seconds]
abhinav__5 has quit []
jessica_24 has quit [Quit: The Lounge - https://thelounge.chat]
abhinav__ has quit [Quit: The Lounge - https://thelounge.chat]
jessica_24 has joined #linux-msm
abhinav__ has joined #linux-msm
jessica_240 has joined #linux-msm
dliviu has joined #linux-msm
pespin has joined #linux-msm
nashpa has joined #linux-msm
dliviu has quit [Ping timeout: 480 seconds]
<wfranken[m]> I see `Unable to find vdd-hba-supply regulator, assuming enabled` in the dmesg. Did you specify vdd-hba-supply regulator in the UFS node of the devicetree?
<wfranken[m]> * sepkov: I see
pevik_ has quit [Read error: No route to host]
<sepkov[m]> No I didn't but it was 0uv in the android too
<sepkov[m]> And it was throwing the same error
<sepkov[m]> I don't think that's the issue
pevik_ has joined #linux-msm
<wfranken[m]> Ok, then I guess it is related to this: `qcom-qmp-phy 627000.phy: phy initialization timed-out`. So I am assuming some regulator, gpio or clock issue. You could try enabling debugfs and debug config for regulators, gpios and clocks so you get more info in the dmesg. You can then also check their configuration in debugfs and compare with the debugfs in downstream (somewhat, it doesn't map 100%).
<sepkov[m]> By debugfs you mean regulator values under /sys/kernel/debug/*/consumers?
<sepkov[m]> I forgot a regulator there
<sepkov[m]> Or is this another thing?
<aka_[m]> <vkoul> "z3ntu: I would need to check..." <- Sm7225 seems to be highest bin there
<wfranken[m]> sepkov[m]: Yes, I believe that is the path downstream. For upstream there is an overview of all regulators in /sys/kernel/debug/regulators/supply_map I think.
<sepkov[m]> I checked all of them
<sepkov[m]> They are same
<sepkov[m]> <sepkov[m]> "So ```qcom,set = <0x3>``` corres..." <- Except I'm not sure about this
<wfranken[m]> sepkov[m]: What does the downstream code says about `qcom,set`? (sorry, I don't have any experience in downstream devicetrees)
<z3ntu> vkoul: From what I saw it was added with kona / sm8250, not sm8350
<sepkov[m]> <sepkov[m]> "It says regulator can be..." <- This
<vkoul> z3ntu: okay then it might not be the case
<vkoul> does downstream use ee-offset property
<Mis012[m]> well, the proper way to see what is at that address would be to look at a FLAT :/
<z3ntu> So I'm a bit confused how / why sm8250 gpi apparently works in mainline without this property
<Mis012[m]> it wouldn't be the first time that downstream writes to registers which don't exist...
<Mis012[m]> aka_: or was it mainline even
<wfranken[m]> <sepkov[m]> "This" <- Hmm, I guess that is to allow the regulator to go in LPM. I guess this maps to `regulator-allowed-modes` but I am not sure. To be sure you should find out in downstream how this devicetree parameter is handled.
<sepkov[m]> Reverse engineering continues...
<wfranken[m]> sepkov[m]: You should be happy you have some code to reverse engineer, doing this with a blob is a lot harder 😉
<sepkov[m]> Yeah I know that feeling too 😅
<sepkov[m]> Especially stripped ones though I haven't came across unstripped blob but I believe I'll one day
<Mis012[m]> I can share unstripped msm8998/sdm845 hyp in exchange for code exec exploit :P
<sepkov[m]> What type of exploit are you looking for exactly?
<Mis012[m]> code execution from Linux
<Mis012[m]> on devices which don't ship with ownership included
<Mis012[m]> which is... 99% of devices on the market
<Mis012[m]> this is what you can do if your device comes with ownership included
<Mis012[m]> for the purposes of using sensors connected to SSC pins
<Mis012[m]> and custom SSC hexagon firmware would also be possible
lumag_ has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
lumag_ has joined #linux-msm
pevik_ has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
<abhinav__> bamse Hi, needed one help. QC is planning to post a new patchset for this series https://patchwork.freedesktop.org/series/101966/ with some of the comments addressed. Will you have time to test this out on your sc8180x setup and give Tested-by tag? In addition to our testing, we wanted to make sure this wont affect other eDP users upstream. We were
<abhinav__> hoping to validate it within the next couple of weeks. If you will not get a chance till then, then we will just use our validation