From: Wolfram Sang <wsa@the-dreams.de>
To: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: alexandre.torgue@st.com, linux-kernel@vger.kernel.org,
pierre-yves.mordret@st.com, alain.volmat@st.com,
linux-i2c@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] i2c: i2c-stm32f7: fix a race in slave mode with arbitration loss irq
Date: Mon, 21 Oct 2019 15:59:10 +0200 [thread overview]
Message-ID: <20191021135910.GA26782@ninjato> (raw)
In-Reply-To: <1569919869-3218-1-git-send-email-fabrice.gasnier@st.com>
[-- Attachment #1.1: Type: text/plain, Size: 1329 bytes --]
On Tue, Oct 01, 2019 at 10:51:09AM +0200, Fabrice Gasnier wrote:
> When in slave mode, an arbitration loss (ARLO) may be detected before the
> slave had a chance to detect the stop condition (STOPF in ISR).
> This is seen when two master + slave adapters switch their roles. It
> provokes the i2c bus to be stuck, busy as SCL line is stretched.
> - the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but
> don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag
> remains set until next master xfer (e.g. when STOPIE irq get unmasked).
> In this case, completion is generated too early: immediately upon new
> transfer request (then it doesn't send all data).
> - Some data get stuck in TXDR register. As a consequence, the controller
> stretches the SCL line: the bus gets busy until a future master transfer
> triggers the bus busy / recovery mechanism (this can take time... and
> may never happen at all)
>
> So choice is to let the STOPF being detected by the slave isr handler,
> to properly handle this stop condition. E.g. don't mask IRQs in error
> handler, when the slave is running.
>
> Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support")
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Applied to for-current, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: pierre-yves.mordret@st.com, alain.volmat@st.com,
alexandre.torgue@st.com, linux-i2c@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c: i2c-stm32f7: fix a race in slave mode with arbitration loss irq
Date: Mon, 21 Oct 2019 15:59:10 +0200 [thread overview]
Message-ID: <20191021135910.GA26782@ninjato> (raw)
In-Reply-To: <1569919869-3218-1-git-send-email-fabrice.gasnier@st.com>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
On Tue, Oct 01, 2019 at 10:51:09AM +0200, Fabrice Gasnier wrote:
> When in slave mode, an arbitration loss (ARLO) may be detected before the
> slave had a chance to detect the stop condition (STOPF in ISR).
> This is seen when two master + slave adapters switch their roles. It
> provokes the i2c bus to be stuck, busy as SCL line is stretched.
> - the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but
> don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag
> remains set until next master xfer (e.g. when STOPIE irq get unmasked).
> In this case, completion is generated too early: immediately upon new
> transfer request (then it doesn't send all data).
> - Some data get stuck in TXDR register. As a consequence, the controller
> stretches the SCL line: the bus gets busy until a future master transfer
> triggers the bus busy / recovery mechanism (this can take time... and
> may never happen at all)
>
> So choice is to let the STOPF being detected by the slave isr handler,
> to properly handle this stop condition. E.g. don't mask IRQs in error
> handler, when the slave is running.
>
> Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support")
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-10-21 13:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 8:51 [PATCH] i2c: i2c-stm32f7: fix a race in slave mode with arbitration loss irq Fabrice Gasnier
2019-10-01 8:51 ` Fabrice Gasnier
2019-10-01 8:51 ` Fabrice Gasnier
2019-10-01 12:21 ` Pierre Yves MORDRET
2019-10-01 12:21 ` Pierre Yves MORDRET
2019-10-01 12:21 ` Pierre Yves MORDRET
2019-10-15 12:21 ` Fabrice Gasnier
2019-10-15 12:21 ` Fabrice Gasnier
2019-10-15 12:21 ` Fabrice Gasnier
2019-10-21 13:59 ` Wolfram Sang [this message]
2019-10-21 13:59 ` 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=20191021135910.GA26782@ninjato \
--to=wsa@the-dreams.de \
--cc=alain.volmat@st.com \
--cc=alexandre.torgue@st.com \
--cc=fabrice.gasnier@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=pierre-yves.mordret@st.com \
/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.