On Sat, Dec 12, 2020 at 01:51:59PM +0100, Linus Walleij wrote: > On Sat, Dec 12, 2020 at 10:23 AM Geert Uytterhoeven > <geert@xxxxxxxxxxxxxx> wrote: > > > As the names are specified in DT, I think the biggest "use case" for > > collisions is GPIO chips on expansion boards, if multiple instances > > of the same board can be connected. > > The actual case that happens in reality is GPIO chips on USB. > For example if you plug in two FTDI adapters (these have GPIOs) > and they have named their lines statically in the driver. > > This is what Johan points out and also what I find from Googling. > > So I would say hot-pluggable buses. Greybus would have the > same issue I think. But it could be anything that provides default names, such as some controller connected over i2c. Having the driver provide default names that then can (but does not have to be) overridden in devicetree if you really want to make sure the lines are unique (or just named for the particular application). > > This is a bit similar to clock outputs, cfr. commit f491276a51685987 > > ("clk: vc5: Allow Versaclock driver to support multiple instances"), but > > in the clock case, the name of the clock output is dictated by the > > driver, not by DT. > > Yeah actually the collisions we have seen in GPIO is the same > type, where we assign the names in gc->names and not in the > device tree (or ACPI). > > But I think it is good to establish this habit already so we don't > end up depending on having to support flat namespaces with I think you meant non-flat here? > several lines on the same chip named the same at least. Right, enforcing per-chip-unique names seems perfectly reasonable. The only "use case" of non-unique names that comes to mind would be to provide some kind of grouping like "input"/"output" but then the names can still be made unique by adding an index (e.g. "input0"). Johan