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