Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure

[Arnd Bergmann]

On Thu, Sep 6, 2018 at 3:21 PM Boris Brezillon
<boris.brezillon@xxxxxxxxxxx> wrote:
>
> On Thu, 6 Sep 2018 15:14:37 +0200
> Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote:

> > When a master is not in control of the bus, it gets informed of devices
> > present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> > means the secondary master should populate the bus with I3C/I2C devices
> > on such events, but that's not enough, because DEFSLVS/DAA do not
> > provide all device info. Some of them (like read/write/ibi limitations)
> > require extra CCC commands, and, to send those CCC commands, the
> > secondary master must claim the bus. We could add a case where we
> > declare devices as partially discovered until the master acquires
> > ownership of the bus, but that means part of the data returned by
> > i3c_device_get_info() will be inaccurate, which might have an impact on
> > some i3c driver ->probe() functions.
>
> Hm, one possible solution would be to register partially discovered
> devices to the device model and let i3c_device_get_info() claim the bus
> and request missing data when needed. This way, if the driver needs to
> call i3c_device_get_info() in its probe path, it should work just fine.

I guess you could also call i3c_device_get_info() in the common i3c_probe()
function before calling into the driver.

However, either way, we may still have a problem here: if the current master
decides not to hand over master access to us at all, the probe() function
will be blocked indefinitely, and that may stop us from probing other devices
later on, or hang the module loader (depending on what context that
probe() is called from).

Using a timeout here could avoid the hang, but leads to other potential
issues, e.g. how to decide whether to retry the probe later.

       Arnd