03:55 <ichernev[m]> Hey guys, can I get some support on this https://lkml.org/lkml/2022/7/28/1023. Essentially I think ml is wrong but I dont have the balls to change it. Original author is MIA, any ref to linaro folks that might help?

08:43 <konradybcio> do you mean the buck change?

08:44 <konradybcio> unless it's way too early and i can't read, I think this only changes matching based on minimum revision?

08:49 <konradybcio> ok it's the former, i can't read... I guess the easiest way to check would be to dump the subtype from a pmic that we know has a hfs430 buck

08:58 <konradybcio> ichernev if that helps, i just grepped for this in xperia 10 II (sm6125 with pm6125 among others) and this is not present

09:31 <ichernev[m]> This one is present on pms405 or sth, check the referenced commit (the one adding the buck that is wrong according to ds). I have no doubt earlier pmic have smaller revision, this is why I suggested the fix to only include rev 4+. So you think this is acceptable (current state of patch, just split for readability)

10:14 <Mis012[m]> do you want to look at some pmic FLATs?

12:06 <konradybcio> ichernev: i am saying that the newer hf510 something something may not even be used on downstream.. what did SPMI say about this?

13:47 <ichernev[m]> Well the point is that buck/hfs430 and hfs510 are the same subtype, so if correct the old one should apply to earlier revisions

14:00 <ichernev[m]> I believe the 660 has this one

14:06 <ichernev[m]> Mis012: does the FLAT contain register values? Actually this might be useful. The current issue is with the mode register/value, which are different across 2 logical types, but according to mainline 3/10 is old, according to ds it uses new reg values

14:07 <ichernev[m]> * ```... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/LDdVFElQXurGwriCZsIGYXSj)

14:08 <ichernev[m]> the whole idea of pmics, being just a list of regs, then each reg is dynamically checked, introduces potential issues with buggy hardware and future compatibility. The current driver can't implement specific per-device handling of a given pmic. Well if it's in another driver with a different compat...

14:35 <z3ntu> Trying to get camss working on SM6350 but hitting `qcom-camss acb3000.camss: VFE reset timeout` errors for all the VFEs (and afterwards `qcom-camss acb3000.camss: Failed to power up pipeline: -5`); apparently I'm not getting an interrupt acknowledging the reset. I've looked through the reset code downstream vs mainline but didn't spot anything useful

14:36 <z3ntu> Downstream compatible is qcom,vfe170_150

14:49 <ichernev[m]> Pinctrl, pin high/low activation... something dumb?

14:51 <z3ntu> ichernev: as far as I am aware, there's no gpio or pinctrl involved with camss (apart from the sensors that are connected to it, but not camss itself)

14:52 <ichernev[m]> Well how do you receive the interrupt?

14:55 <z3ntu> arm gic

16:02 <Mis012[m]> ichernev: afaik, qcom's pmics just use specific drivers for specific register ranges like with mmio?

16:03 <Mis012[m]> ichernev: well, I guess I shouldn't be so generous with these, but here you have all the PMIC FLATs I have

16:22 <calebccff> z3ntu: fwiw this is where i think i got stuck on sdm845

16:26 <z3ntu> calebccff: oh what? So it doesn't even work on sdm845? Did it ever work? :D

16:26 <calebccff> z3ntu: it definitely *did* work on db845c, i need to check if it still does at some point...

16:27 <z3ntu> calebccff: let's move to sdm845 channel