On Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote:
> On 07/09/2022 01.10, Rob Herring wrote:
> >> So at this point, I think it would make sense if I post a v2 with all
> >> the updates so far (sorry, given the long drawn out discussions on
> >> this, I've lost track of what changes have been made to the code, so
> >> I won't include a detailed change log.)
> >
> > As I said elsewhere, sub-nodes is probably the right choice here. I
> > think they need compatible strings in the child nodes, and addressing
> > has to be sorted out which it seems may also break OpenBSD.
>
> So addressing only makes sense for GPIO, out of the nodes we have so far
> - that's the only thing with two discrete instances whose access can be
> entirely described by a single base key name, and which are otherwise
> compatible.
>
> Everything else is pretty much single-instance, and talks to multiple
> keys, so there isn't one single "address" key that would make semantic
> sense to use as the node address.
Unit-addresses are just the first address in 'reg'. So multiple
addresses or not doesn't really matter.
> There are some indexed keys, but at a
> deeper level (e.g. multiple battery cells part of the charge control
> subsystem, multiple Type C ports as part of the AC/power input
> subsystem, etc.). And in those cases, these subdevices are mostly
> homogeneous and we would never need multiple nodes for them at the DT
> level, they'd just be implicitly handled by those drivers.
Type-C will be fun depending on how much of the muxing/altmode
details have to get exposed.
> GPIO is quite special in that 1) it only has a single key type (which is
> overloaded using advanced features to provide, effectively,
> sub-registers to control all the GPIO features per pin), 2) a single key
> represents a single pin, 3) keys are numbered in a reasoanble way, and
> 4) there are two prefixes for two discrete GPIO controllers. For pretty
> much everything else SMC does, we just have a bag of keys with no real
> rhyme nor reason from the point of view of an "address space".
>
> Given that, how would this work? Is it legal/reasonable for only the
> gpio nodes to have addressing/reg properties, and everything else to
> just have a node name with no concept of address?
Not ideal, but allowed.
> Does it even make
> sense to special case gpio in this way, vs. just having something like
> gpio {} / gpio-sec {} (if we ever even need gpio-sec, which is an open
> question)?
If not unit-addresses, the 2nd choice we do is 'gpio-0', 'gpio-1', etc.
Though that is mainly in the GPIO based consumer bindings like gpio-pwm,
spi-gpio, etc. where there's really not anything to use for an address.
If only those 2 nodes, then I really don't care so much and gpio-sec
would be fine. It's 1 node in 1 binding.
Rob
