01:09 <calebccff> lumag: sorry for the late response, the subtype needs to be in the match data so we can read the compatible for the pmic->name property

01:10 <lumag> calebccff, but you can read subtype from the hw, can you not?

01:11 <calebccff> lumag: right, but we're re-using the match table as a subtype -> pmic name lookup table https://github.com/aospm/linux/blob/39aa34c68f045943a9caee98c33c8758e96cd866/drivers/mfd/qcom-spmi-pmic.c#L195

01:12 <calebccff> it also lets us ensure that the PMIC we're probing is the one in the compatible, though that wasn't enforced before

01:14 <lumag> calebccff, you can use of_match_device() instead

01:15 <lumag> Not sure about checking the compatible vs the real hardware. I don't think we do that for other devices.

01:15 <calebccff> lumag: oh riiight, apologies

01:15 <lumag> calebccff, n/p

01:15 <lumag> thank you for your work

01:16 <calebccff> ok, I'll switch to that and drop the subtype. Is it worth having a struct with a single property for the match data? Or should I just use the number of USIDs directly?

01:17 <calebccff> lumag: thanks, hopefully it ends up coming in useful for someone else!

01:17 <lumag> I'd say, use number directly (as we did for the subtype)

01:21 <calebccff> ack, thanks a lot

12:17 <Mis012[m]> calebccff: SPMI is a MIPI standard, so chances are some of the countless companies that have the docs leaked it ;)

16:03 <srinik> bamse, ndec: by any chance do we have access to SM8450 MTP schematics?

16:03 <srinik> bamse, ndec: wrong window!

23:56 <calebccff> I've been poking around the cpufreq driver, for some reason on my op6 running downstream it reads 2.8GHz as the max frequency on the big cores, on a different op6 running mainline it reads 2.65GHz as the max