[PATCH] drm/bridge: ti-sn65dsi86: Fix multiple instances

[Dmitry Baryshkov]

On Tue, Oct 22, 2024 at 07:37:01AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Oct 22, 2024 at 12:12 AM Geert Uytterhoeven
> <geert at linux-m68k.org> wrote:
> >
> > > > > > > However, using i2c_client->adapter->nr instead of ida_alloc()
> > > > > > > in the TI driver does sound like a good idea to me...
> > > > > >
> > > > > > Great!
> > > >
> > > > > With the I2C adapter numbers, that becomes:
> > > > >
> > > > >     /sys/bus/auxiliary/devices
> > > > >     ├── ti_sn65dsi86.gpio.1
> > > > >     ├── ti_sn65dsi86.pwm.1
> > > > >     ├── ti_sn65dsi86.aux.1
> > > > >     ├── ti_sn65dsi86.bridge.1
> > > > >     ├── ti_sn65dsi86.gpio.4
> > > > >     ├── ti_sn65dsi86.pwm.4
> > > > >     ├── ti_sn65dsi86.aux.4
> > > > >     └── ti_sn65dsi86.bridge.4
> > > > >
> > > > > > adapter->nr instead like other aux subsystems already do.
> > > >
> > > > Unfortunately the devil is in the details, as usual: there can be
> > > > multiple instances of the sn65dsi86 bridge on a single I2C bus,
> > > > so adapter->nr is not guaranteed to generate a unique name.
> > >
> > > In the case of sn65dsi86 I think we'd actually be OK. The TI bridge
> > > chip is always at bus address 0x2d so you can't have more than one on
> > > the same bus. Unless you added something funky atop it (like a mux of
> > > some sort) you might be OK.
> >
> > It's 0x2c on mine ;-)
> >
> >     8.5.1 Local I2C Interface Overview
> >     The 7-bit device address for SN65DSI86 is factory preset to 010110X
> >     with the least significant bit being determined by the ADDR control
> >     input.
> 
> Doh! I missed that in my search of the doc. I guess because they
> decided to specify the address in binary in that part so my searching
> for both the 7-bit and 8-bit I2C address didn't trigger. Oh well.
> 
> 
> > > > Changing the auxiliary bus to use the parent's name instead of the
> > > > module name, as suggested by Laurent, would fix that.
> > >
> > > Right. On my system dev_name() of the sn65dsi86 device is "2-002d". If
> > > we had a second on i2c bus 4, we'd have:
> > >
> > >     /sys/bus/auxiliary/devices
> > >     ├── 2-002d.gpio.0
> > >     ├── 2-002d.pwm.0
> > >     ├── 2-002d.aux.0
> > >     ├── 2-002d.bridge.0
> > >     ├── 4-002d.gpio.0
> > >     ├── 4-002d.pwm.0
> > >     ├── 4-002d.aux.0
> > >     └── 4-002d.bridge.0
> > >
> > > ...and I think that's guaranteed to be unique because all the i2c
> > > devices are flat in "/sys/bus/i2c/devices".
> >
> > Correct.
> 
> So given everything, using the dev_name() of the "parent" sounds
> pretty good and seems like it addresses everyone's concerns. Was there
> a part of the conversation where someone pointed out problems with it
> that I missed? Is the next step to post a patch implementing that?
> It'll change sysfs paths and dev names for everyone using AUX bus, but
> presumably that's OK?

It also requires changing in the way the auxiliary_match_id() works.
Currently matching is done using modname + ID.

So, maybe using MODNAME.NAME.parent-name.ID is better (e.g.
ti_sn65dsi86.gpio.2-002d.1). It will still require changes to the
match_id function, but they won't be that intrusive (one just has to
skip two parts of the name instead of skipping just one).

-- 
With best wishes
Dmitry