Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller

[Mark Kettenis <mark.kettenis@xxxxxxxxx>]

> Date: Tue, 6 Sep 2022 22:53:47 +0900
> From: Hector Martin <marcan@xxxxxxxxx>
> 
> On 06/09/2022 22.43, Russell King (Oracle) wrote:
> > In the case of gpio-macsmc, how would we later add support for the
> > slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"?
> > How do we tell the gpio-macsmc code to use a different set of keys?
> > Should DT describe the key "prefix" (in other words "gp" vs "gP"),
> > or should it describe it some other way. What if Apple decides to
> > instantiate another GPIO controller in a later platform with a
> > different prefix, could that be accomodated without breaking any
> > solution we come up today?
> > 
> > Maybe the solution to this would be to describe the key prefix in DT
> > as that's effectively its "reg". Or maybe we use "reg" to describe
> > it somehow (which is value of the key, which seems to have an
> > "address" like quality to it?)
> > 
> > We don't have to implement code for this now, we just need to get a
> > reasonably correct DT binding for the gpio controller.
> 
> I agree that this is something to think about (I was about to reply on
> the subject).
> 
> I can think of two ways: using `reg` for the key name, but that feels
> icky since it's ASCII and not *really* a register number/address, or
> something like this:
> 
> gpio@0 {
> 	apple,smc-key-base = "gP00";
> 	...
> }
> 
> gpio@1 {
> 	apple,smc-key-base = "gp00";
> 	...
> }

This would still require us to add a (one-cell) "reg" property and
would require adding the appropriate "#address-cells" and
"#size-cells" properties to the SMC node.

> But this ties back to the device enumeration too, since right now the DT
> does not drive that (we'd have to add the subdevice to the mfd subdevice
> list somehow anyway, if we don't switch to compatibles).
> 
> I'd love to hear Rob's opinion on this one, and also whether the
> existing Linux and OpenBSD code would currently find gpio@0 {} instead
> of gpio {} for backwards compat.

The OpenBSD driver does a lookup by name and the "@0" is part of that
name.  So that would break backwards compat.

Maybe just name the slave GPIO controller "gpio-slave"?  If we add
compatibles, the compatibles for the nodes should propbably be
different such that we can switch to do a lookup by compatible?