From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: "Gabbasov, Andrew" <Andrew_Gabbasov@mentor.com>
Cc: "linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
"Surachari, Bhuvanesh" <Bhuvanesh_Surachari@mentor.com>
Subject: Re: [PATCH v2] i2c: rcar: add SMBus block read support
Date: Fri, 1 Apr 2022 18:29:43 +0200 [thread overview]
Message-ID: <Ykcod/XOYvGfUsga@ninjato> (raw)
In-Reply-To: <0a07902900bc4ecc84bd93a6b85a2e0c@svr-ies-mbx-02.mgc.mentorg.com>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
> > /* If next received data is the _LAST_, go to new phase. */
> > - if (priv->pos + 1 == msg->len) {
> > + if (priv->pos + 1 == msg->len && !recv_len_init) {
>
> If a message contains a single byte after the length byte,
> when we come here after processing the length (in the same function call),
> "pos" is 1, "len" is 2, and we indeed are going to process the last byte.
> However, "recv_len_init" is still "true", and we skip these corresponding
> register writes, which is probably incorrect.
> The flag in this case should be re-set back to "false" after length
> processing and "pos" moving, but I think the variant in my patch
Confirmed. Tests fail with only one extra byte and clearing
'recv_len_init' fixes the issue. I don't think this is the proper
solution, though. I think it will create more readable code if we update
the checks. So people will understand what we are aiming for. The
current code is already implicit enough.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-04-01 16:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 16:06 [PATCH] i2c: rcar: add SMBus block read support Andrew Gabbasov
2021-10-05 13:31 ` Geert Uytterhoeven
2021-10-06 18:11 ` Andrew Gabbasov
2021-10-06 18:23 ` [PATCH v2] " Andrew Gabbasov
2022-02-17 19:44 ` Wolfram Sang
2022-02-18 11:02 ` Gabbasov, Andrew
2022-03-15 10:45 ` Surachari, Bhuvanesh
2022-03-30 11:04 ` Wolfram Sang
2022-04-01 16:27 ` Wolfram Sang
2022-04-01 16:29 ` Wolfram Sang [this message]
2022-03-23 21:52 ` Eugeniu Rosca
2022-03-30 10:58 ` Wolfram Sang
2022-03-30 11:09 ` Wolfram Sang
2022-03-31 16:02 ` Eugeniu Rosca
2022-04-01 16:38 ` Wolfram Sang
2022-04-05 9:30 ` Eugeniu Rosca
2022-04-05 9:43 ` Wolfram Sang
2022-04-06 17:32 ` Eugeniu Rosca
2022-04-06 19:44 ` Wolfram Sang
2021-11-18 10:35 ` [PATCH] " Andrew Gabbasov
2022-01-09 19:20 ` Andrew Gabbasov
2022-01-25 6:45 ` Andrew Gabbasov
2022-02-17 14:40 ` Andrew Gabbasov
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=Ykcod/XOYvGfUsga@ninjato \
--to=wsa+renesas@sang-engineering.com \
--cc=Andrew_Gabbasov@mentor.com \
--cc=Bhuvanesh_Surachari@mentor.com \
--cc=geert+renesas@glider.be \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.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 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.