i3c: scanning for i2c client devices on the network
Frank Li
Frank.li at nxp.com
Tue Sep 16 10:08:44 PDT 2025
On Wed, Sep 10, 2025 at 02:01:33PM +0000, Boris Staletic wrote:
> 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?
Generally, it is the same as I2C. just send out address, and check if target
ACK/NACK this address.
Address 7E, REPEAT START, scan's address. ACK/NACK STOP.
Check ACK/NACK. But you don't know if it is i3c device or i2c device by this
way.
send 7E to avoid IBI during you send out address.
Fank
> 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
> --
> linux-i3c mailing list
> linux-i3c at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-i3c
More information about the linux-i3c
mailing list