07:20 <lag> CounterPillow: There is no documentation to differentiate between; ACPI, I2C, SPI, DT, MFD, Auxbus or raw Platform Device registration because the choice between, at least the last 4, in the list is highly nuanced - often any will do the job

07:21 <lag> Forty-Bot: CounterPillow Auxbus is about 5 years old, MFD has been around for 20 years - personally I don't know anything about auxbus, it looks like a very simple shim layer over the Driver layer - MFD works at the Platform layer (one level down)

07:23 <lag> I believe Auxbus came into fruition because some devices simply do not fit in the Platform Devices realm (like PCI for example) - so pushing them through MFD, which turns the subdevices into Platform Devices was frowned upon

07:24 <lag> If you have a Platform Device that you wish to split-up into more Platform Devices, then MFD is the canonical choice

07:27 <lag> Again, I can't comment on Auxbus, but MFD is pretty flexible - pinning it down in documentation to work only within a particular remit would be tricky and would, as you've seen from the old articles you referenced become out-of-date pretty quickly

07:30 <lag> I stand by the fact that MFD is still simple enough, even after 20 years, not to require documentation (which would read "splits up multi-function devices, registers them as Platform Devices and handles shared resources")

07:32 <lag> Not asking for advice because you feared not getting a reply (if that was even a consideration before the fact) was not a good decision IMHO

07:35 <lag> Ref: "because none of you do it", who is "you" here? That's a crazy thing to say. This is a community. Plenty of people author documentation when it is applicable. Are you really trying to distance or elevate yourself over it?

07:54 <CounterPillow> "Are you really trying to distance or elevate yourself over it?" it's always a community effort when code already merged needs work but always on the submitter to do "while you're at it" when new code that tangentially touches something that needs work, it's not me who's doing the distancing I don't think. FWIW, auxbus is documented, and explains its nuance: https://docs.kernel.org/driver-api/auxiliary_bus.html "These individual devices

07:54 <CounterPillow> split from the core cannot live on the platform bus as they are not physical devices that are controlled by DT/ACPI. The same argument applies for not using MFD in this scenario as MFD relies on individual function devices being physical devices."

08:00 <CounterPillow> I'd like to at some point get actual things done instead of constantly doing stuff like https://lore.kernel.org/all/20250623-byeword-update-v2-0-cf1fc08a2e1f@collabora.com/ or https://lore.kernel.org/all/20250620-perf-pmu-cap-docs-v2-1-97d7752fefac@collabora.com/ so I won't be the one documenting MFD (which it sounds like you'd reject anyway on the basis that documenting intended mutual exclusion guarantees is totally unnecessary)

08:10 <geertu> CounterPillow: Nice! Several Renesas RZ/* SoCs also use hiword masks in e.g. clock registers (but lots of masks are non-const)

08:10 <geertu> prabhakalad: ^

08:12 <CounterPillow> geertu: so does Intel, and yet I still had to defend the whole idea of this living in a generic header to a maintainer who dismissed it outright as unnecessary and clearly just a vendor-specific convention ;D

08:30 <lag> CounterPillow: I wouldn't reject he documentation if it adds value

08:31 <lag> I could have sworn that linusw__ drafted something up about a decade ago - not sure where that went (or whether I just imagined the whole thing)

09:13 <geertu> CounterPillow: I am also having a hard time defending non-const field_{prep,get}() variants...

09:14 <prabhakalad> geertu: good point. I will get it switched to constants.

09:26 <geertu> prabhakalad: You can't for many, as you access most fields by number

09:30 <prabhakalad> Ah right!

09:50 <robmur01> CounterPillow: thanks for the reminder that I should revive my series to majorly churn the PMU caps to make them less silly :)

09:51 <robmur01> (and feel free to hit me up if you just want PMU driver help in a hurry)

09:52 <CounterPillow> robmur01: thanks for the offer <3 I'm currently no longer actively working on that PMU driver as I got snatched by a different project, but I may come back to it in the future

09:54 <robmur01> heh, my interrupt stack is currently upstream work > PMU driver > PMU driver > PMU driver > massive panic

10:08 <Xogium> no oops ? I thought oops always were precursor to panics

10:09 <Xogium> or do you mean panic in real life ;)

10:22 <robmur01> if it carries on being this hot, it's possible I may oops as well :)

10:32 <Xogium> true

10:32 <Xogium> I'm rather lucky to be in a region where the heat isn't so extreme

10:33 <Xogium> mind you, we're still going to hit 27 today, but 27 is nothing compared to some places

13:48 <Forty-Bot> CounterPillow: thanks for sending that perf patch; I took a stab at creating a perf driver a while back and had no clue what flags to set

14:35 <lag> robmur01: 34C where I am over the weekend :'-p

14:36 <lag> robmur01: I thought it would be even hotter down south?

14:37 <robmur01> lag: yikes! My sensor says 31.4 outside right now...

14:37 <lag> robmur01: 31.8C ;-)

14:38 <lag> Same as my inside sensor (I work in a converted garden room at the bottom of my garden!

14:38 <lag> [I really should start proof reading my replies before hitting return] :)

14:39 <lag> https://i.imgur.com/kKdIOq8.png

14:41 <headless> 33C in Moscow

14:43 <headless> (~150 year record broken)

15:23 <maz> robmur01: come and taste the aircon!

15:29 <robmur01> maz: what does it taste of over there, rainwater and lighting failures? :P

15:59 <Xogium> no worse than spain/portugal at least :/ 46.6c 2 weeks ago

16:05 <maz> robmur01: it hasn't really rained in a while, so it's still pretty dry! :)

21:08 <linusw__> lag: hm did I do that... I will go and check my gits.

22:42 <linusw__> lag: I seem to have written Documentation/devicetree/bindings/mfd/mfd.txt and it was merged and all.

22:46 <linusw__> It does talk a bit about MFD in general.