RFC: i3c: scanning for i2c client devices on the network

[Boris Staletic]

> Hello,
> 
> We have an I3C bus where the user may ultimately attach an I2C slave with an arbitrary address, with the idea
of using i2c-utils to communicate with the I2C slave from userland.
> 
> With the current kernel, I2C slaves need to be known statically and thus i2cdetect fails to detect any slaves.
> All communication attempts get rejected early, because i3c_master_find_i2c_dev_by_addr returns NULL and then i3c_master_i2c_adapter_xfer exits with ENOENT.
> I3c_master_find_i2c_dev_by_addr returns NULL because bus->devs.i2c ends up being empty.
> 
> Since the I2C drivers have i2c_detect and i3c_master_controller has its own i2c_adater, I looked into what needs to be done for networks
with I3C masters to use the existing i2c_detect mechanism. That lead me to the following list of changes:
> 
> - i3c_master_controllr's i2c_adapter needs to have its class member set.
> - In i2c_detect_address, temp_client->dev needs to be populated and registered before the call to i2c_default_probe.
>   - Otherwise the attempt to probe gets rejected early, for the same reason described above (i3c_master_find_i2c_dev_by_addr returning NULL).
> 
> That much was enough to get i2c_detect to work with an I3C master.
> To complete the use case I also needed a registered i2c_driver that implements a simple i2c_driver.detect function.
> In my test, the detect function simply checked whether i2c_smbus_read_byte_data(client, 0) returns a non-error value.
> 
> Could anyone comment whether this is the right approach for implementing I2C slave detection with an I3C master?
> The most iffy part of this approach is the need for such a dummy driver, just so the I3C master knows that "something exists".
> I'd welcome any sort of feedback.
> 
> Thanks,
> Boris Staletic

Hello,

I just wanted to bump this thread, as any sort of feedback would be greatly appreciated.

Thanks in advance,
Boris Staletic