From: Wolfram Sang <wsa@kernel.org>
To: "Martin Povišer" <povik+lin@cutebit.org>
Cc: Sven Peter <sven@svenpeter.dev>, Hector Martin <marcan@marcan.st>,
linux-kernel@vger.kernel.org, Olof Johansson <olof@lixom.net>,
Paul Mackerras <paulus@samba.org>,
linux-arm-kernel@lists.infradead.org,
Jean Delvare <khali@linux-fr.org>, Janne Grunau <j@jannau.net>,
linuxppc-dev@lists.ozlabs.org,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c: pasemi: Wait for write xfers to finish
Date: Fri, 15 Apr 2022 23:12:28 +0200 [thread overview]
Message-ID: <YlnfvJDyluEDfu39@shikoro> (raw)
In-Reply-To: <20220329183817.21656-1-povik+lin@cutebit.org>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Tue, Mar 29, 2022 at 08:38:17PM +0200, Martin Povišer wrote:
> Wait for completion of write transfers before returning from the driver.
> At first sight it may seem advantageous to leave write transfers queued
> for the controller to carry out on its own time, but there's a couple of
> issues with it:
>
> * Driver doesn't check for FIFO space.
>
> * The queued writes can complete while the driver is in its I2C read
> transfer path which means it will get confused by the raising of
> XEN (the 'transaction ended' signal). This can cause a spurious
> ENODATA error due to premature reading of the MRXFIFO register.
>
> Adding the wait fixes some unreliability issues with the driver. There's
> some efficiency cost to it (especially with pasemi_smb_waitready doing
> its polling), but that will be alleviated once the driver receives
> interrupt support.
>
> Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver")
> Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2022-04-15 21:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 18:38 [PATCH] i2c: pasemi: Wait for write xfers to finish Martin Povišer
2022-03-29 19:58 ` Sven Peter
2022-04-15 21:12 ` Wolfram Sang [this message]
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=YlnfvJDyluEDfu39@shikoro \
--to=wsa@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=j@jannau.net \
--cc=khali@linux-fr.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=marcan@marcan.st \
--cc=olof@lixom.net \
--cc=paulus@samba.org \
--cc=povik+lin@cutebit.org \
--cc=sven@svenpeter.dev \
/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;
as well as URLs for NNTP newsgroup(s).