From: Heiner Kallweit <hkallweit1@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Wolfram Sang <wsa@kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Krzysztof Piotr Oledzki <ole@ans.pl>
Subject: Re: [PATCH v2] i2c: core: Lock address during client device instantiation
Date: Fri, 16 Aug 2024 08:12:47 +0200 [thread overview]
Message-ID: <7260d24e-30c5-49ff-bc27-2c68bc2d6113@gmail.com> (raw)
In-Reply-To: <Zr6LAJPqabEMMy17@google.com>
On 16.08.2024 01:10, Dmitry Torokhov wrote:
> Hi Heiner,
>
> On Thu, Aug 15, 2024 at 09:44:50PM +0200, Heiner Kallweit wrote:
>>
>> +/*
>> + * Serialize device instantiation in case it can be instantiated explicitly
>> + * and by auto-detection
>> + */
>> +static int i2c_lock_addr(struct i2c_adapter *adap, unsigned short addr,
>> + unsigned short flags)
>> +{
>> + if (!(flags & I2C_CLIENT_TEN) &&
>> + test_and_set_bit(addr, adap->addrs_in_instantiation))
>> + return -EBUSY;
>
> Why don't you add a list of client devices to the adapter structure
> instead of using bitmap? Then you could handle cases with 10 bit
> addresses as well.
>
I think this question in the same as asked by Wolfram: whether a linked list
would be better suited. It would require more complexity to deal with it than
the bitmap. And we could use the bitmap also with 10bit addresses, then the
bitmap would have 128 bytes. It's an acceptable tradeoff to exclude (very rare)
10 bit addresses from the check.
> I know that there is already a list of children in the driver core, but
> it is populated too late for what we need.
>
> Thanks.
>
next prev parent reply other threads:[~2024-08-16 6:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 19:44 [PATCH v2] i2c: core: Lock address during client device instantiation Heiner Kallweit
2024-08-15 23:10 ` Dmitry Torokhov
2024-08-16 6:12 ` Heiner Kallweit [this message]
2024-08-26 13:20 ` Wolfram Sang
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=7260d24e-30c5-49ff-bc27-2c68bc2d6113@gmail.com \
--to=hkallweit1@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=ole@ans.pl \
--cc=wsa@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox