From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Gregor Riepl <onitake@gmail.com>,
linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Kamal Dasu <kamal.dasu@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Andi Shyti <andi.shyti@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Wolfram Sang <wsa@kernel.org>
Subject: Re: [PATCH] i2c: brcmstb: Add support for atomic transfers
Date: Wed, 11 Oct 2023 13:47:04 +0200 [thread overview]
Message-ID: <b4b91fb3-07b0-41c2-a97c-d1a045924fdc@samsung.com> (raw)
In-Reply-To: <ba3c0972-2ba2-4df7-826e-a7634027b967@gmail.com>
On 11.10.2023 12:23, Gregor Riepl wrote:
> I admit that I don't understand the I²C subsystem very well, but
> doesn't this introduce a potential race condition?
>
> > ...
> > @@ -240,7 +241,7 @@ static int
> brcmstb_i2c_wait_for_completion(struct brcmstb_i2c_dev *dev)
> > ...
>> - if (dev->irq >= 0) {
>> + if (dev->irq >= 0 && !dev->atomic) {
> > ...
> > @@ -287,7 +288,7 @@ static int brcmstb_send_i2c_cmd(struct
> brcmstb_i2c_dev *dev,
> > ...
>> - if (dev->irq >= 0)
>> + if (dev->irq >= 0 && !dev->atomic)
> > ...
> > +static int brcmstb_i2c_xfer_atomic(struct i2c_adapter *adapter,
> > + struct i2c_msg msgs[], int num)
> > ...
>> + dev->atomic = true;
>> + ret = brcmstb_i2c_xfer(adapter, msgs, num);
>> + dev->atomic = false;
>> ...
>
> What happens when one of the if() branches is taken in one thread
> while another thread is just executing the assignment of the atomic
> flag? My expectation would be that the first tread still sees the old
> flag value and happily executes the branch, while
> brcmstb_i2c_xfer_atomic() sets the flag just after and initiates a
> transfer.
>
> I'd expect that access to the flag must be atomic as well, so maybe
> something like
> https://www.kernel.org/doc/html/latest/core-api/wrappers/atomic_t.html
> is needed, or some other synchronization mechanism.
>
> Or is it guaranteed that brcmstb_i2c_wait_for_completion() and
> brcmstb_send_i2c_cmd() can only be called from the same thread as
> brcmstb_i2c_xfer_atomic() ?
Atomic i2c transfers are some kind of a special case.
I guess that i2c core takes care of NOT multiplexing atomic and standard
i2c transfers. No special locking/protection is needed in the bus
drivers. This is at least what I see from commits like 08960b022fb6
("i2c: tegra-bpmp: convert to use new atomic callbacks") or 3d11a12ece85
("i2c: ocores: enable atomic xfers").
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2023-10-11 11:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20231006144123eucas1p111cbbdbd70927ffbd697f7edf6b7ae1c@eucas1p1.samsung.com>
2023-10-06 14:41 ` [PATCH] i2c: brcmstb: Add support for atomic transfers Marek Szyprowski
2023-10-09 20:41 ` Florian Fainelli
2023-10-11 9:57 ` Marek Szyprowski
2023-10-11 15:43 ` Florian Fainelli
2023-10-11 10:23 ` Gregor Riepl
2023-10-11 11:47 ` Marek Szyprowski [this message]
2023-10-11 14:48 ` Wolfram Sang
2023-10-11 13:40 ` Andi Shyti
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=b4b91fb3-07b0-41c2-a97c-d1a045924fdc@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=andi.shyti@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=florian.fainelli@broadcom.com \
--cc=kamal.dasu@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=onitake@gmail.com \
--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