16:05 <lumag> z3ntu1, regarding the qcom,hfpll. Let's maybe deprecate the old compatible in schema?

16:05 <z3ntu1> lumag: So get rid of qcom,hfpll completely? Just keep e.g. "qcom,msm8974-hfpll" as single compatible?

16:06 <lumag> You can add deprecated:true to the sole qcom,hfpll compat string

16:10 <z3ntu1> lumag: but there's no qcom,hfpll alone in yaml? Only allowed in my v1 is e.g. "qcom,msm8974-hfpll", "qcom,hfpll"

16:10 <lumag> I think that's what krzk didn't like. Maybe I'm misreading his email.

16:10 <z3ntu1> why document qcom,hfpll alone (as deprecated) if it never has been properly allowed?

16:11 <z3ntu1> not that anybody validated against the .txt but even there it was always two compatibles

16:11 <lumag> Ack :D

16:20 <z3ntu1> lumag: I would've just removed qcom,hfpll from the driver completely but I'm sure somebody would've complained about dt backwards compatibility so I kept it with a comment but seems that also wasn't the best idea, dunno

16:21 <lumag> I think we need it for backwards capability. I suppose one of krzk's comments were related to sole qcom,hfpll not being documented in schema.

16:21 <z3ntu1> that's because it's not allowed?

16:22 <z3ntu1> I'll wait a few more days before sending v2 with at least the binding comments addresses so that part moves forward at least

18:55 <krzk> my comments were about mixing bindings and driver.... whether comaptible is allowed or is not allowed alone in the bindings, does not really affect the driver. These are independent choices.

21:17 <z3ntu1> krzk: so more about commit message rather than content?

21:32 <krzk> z3ntu1: both :). The content did not look correct and commit msg did not explain that. The code could be correct, but I just did not see it and commit msg did not help.

21:34 <krzk> z3ntu1: but there is nothing wrong in driver binding to a valid compatible, evem if that compatible is not really generic enough. I would argue that existing state is exactly what bamse wanted, when we discussed whether to use generic fallback compatibles or not. I argued: no, do not use generic fallbacks but specific fallbacks. bamse argued to use generic fallbacks.

21:35 <z3ntu1> Another approach I'd have is adding qcom,qcs404-hfpll in driver with the renamed qcs404 driver data, then we have both qcom,hfpll and qcom,qcs404-hfpll pointing to the same data, which I'd also think some people have comments about

21:36 <z3ntu1> Or just drop the commit, pretend the 'problem' doesn't exist and when I add qcom,msm8974-hfpll just add new driver data and keep the qcom,hfpll in the driver for qcs404 only

21:37 <z3ntu1> but fundamentally from what I can tell, the hfpll driver data (so the register values) is not generic across SoCs so having qcom,hfpll being something is not really great imo

21:41 <alexeymin> hi, seems there are problems with mmc in 6.7-rc8 on sdm660 device, anyone seen these? https://paste.sr.ht/~minlexx/14c329904d0e59bd5da2c15b3fea7675a3edd6d4

21:41 <alexeymin> mmc2: Card appears overclocked; req 400000 Hz, actual 50000000 Hz

22:00 <flamingradian[m]> oh yeah, opp doesn't have 400000 Hz so it picks the closest one

22:00 <flamingradian[m]> in sdm630.dtsi

22:02 <alexeymin> but opp was there since addition to mainline I think, and it all worked fine at least up to linux-6.6, something must have changed

22:09 <alexeymin> alright, hacking entry with 400000 into opp tables did something, mmcs are there now

22:10 <flamingradian[m]> yeah, it's probably same bug as sdm670, which I remember testing on -next December 18