All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Staletic <bstaletic@axiado.com>
To: Frank Li <Frank.li@nxp.com>
Cc: "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: Re: i3c: scanning for i2c client devices on the network
Date: Mon, 22 Sep 2025 13:46:58 +0200	[thread overview]
Message-ID: <aNE3MkhlABIHQ-J7@axiado.com> (raw)
In-Reply-To: <aMwT9S92IpIOT_Gq@axiado.com>

On Thu, Sep 18, 2025 at 04:15:17PM +0200, Boris Staletic wrote:
> On Tue, Sep 16, 2025 at 01:08:44PM -0400, Frank Li wrote:
> > 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.
> 
> Are you referring here to i2c_new_scanned_device? If so, that also, in
> my testing, couldn't detect any devices without modificatioins.
> The failure to scan happens because:

Once again, here's a patch of what I have attempted to do, but this has
seen less testing.
I have removed the quotes below the patch for brevity.

-----------------------------------------------------------------------
 drivers/i3c/master.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 2ef898a8fd80..de9dbf6c518e 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -2849,6 +2849,26 @@ int i3c_master_register(struct i3c_master_controller *master,
 			i2c_scl_rate = I3C_BUS_I2C_FM_SCL_MAX_RATE;
 	}

+	unsigned short addr_list[] = { 0x48, 0x49, 0x50, 0x51, 0x52, 0x53, I2C_CLIENT_END };
+	struct i2c_client *temp_client = kzalloc(sizeof(*temp_client), GFP_KERNEL);
+	for(int i = 0; addr_list[i] != I2C_CLIENT_END; i++) {
+		unsigned short one_address[] = { addr_list[i], I2C_CLIENT_END };
+		struct i2c_board_info info;
+		memset(&info, 0, sizeof(info));
+		info.addr = addr_list[i];
+
+		memset(&temp_client->dev, 0, sizeof(info));
+		temp_client->dev.bus = &i2c_bus_type;
+		temp_client->dev.type = &i2c_client_type;
+		temp_client->dev.parent = &temp_client->adapter->dev;
+		dev_set_name(&temp_client->dev, "i2c-temp-client");
+		int err = device_register(&temp_client->dev);
+		if(err)
+			continue;
+		i2c_new_scanned_device(&master->i2c, &info, one_address, NULL);
+		i2c_unregister_device(temp_client);
+	}
+
 	ret = i3c_bus_set_mode(i3cbus, mode, i2c_scl_rate);
 	if (ret)
 		goto err_put_dev;

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  parent reply	other threads:[~2025-09-22 11:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 14:01 i3c: scanning for i2c client devices on the network Boris Staletic
2025-09-16  9:31 ` RFC: " Boris Staletic
2025-09-16 17:08 ` Frank Li
2025-09-18 14:15   ` Boris Staletic
2025-09-22 11:43     ` Boris Staletic
2025-09-23 18:46       ` Mukesh Savaliya
2025-09-24 18:20         ` Frank Li
2025-09-25 15:42           ` Boris Staletic
2025-09-22 11:46     ` Boris Staletic [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-09-10 13:52 Boris Staletic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aNE3MkhlABIHQ-J7@axiado.com \
    --to=bstaletic@axiado.com \
    --cc=Frank.li@nxp.com \
    --cc=linux-i3c@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.