From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa@kernel.org>
Cc: Linux I2C <linux-i2c@vger.kernel.org>,
David Jedynak <sileasresearch@gmail.com>
Subject: Re: [PATCH] i2cset: Fix short writes with mask
Date: Tue, 8 Sep 2020 17:19:08 +0200 [thread overview]
Message-ID: <20200908171908.65690731@endymion> (raw)
In-Reply-To: <20200908065111.GA5936@ninjato>
On Tue, 8 Sep 2020 08:51:11 +0200, Wolfram Sang wrote:
> On Thu, Sep 03, 2020 at 11:00:54AM +0200, Jean Delvare wrote:
> > Short writes used "daddress" for the value, but the masking code did
> > not expect that, and instead applied the mask to a variable that was
> > never used.
> >
> > So change short writes to use "value" for the value, as all other
> > commands do. Adjust all code paths accordingly.
> >
> > Reported by David Jedynak.
> >
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Passed my test as well. One question:
Thank you very much for testing! I'll commit that now.
> > @@ -140,7 +140,7 @@ static int confirm(const char *filename,
> > } else
> > fprintf(stderr, "data 0x%02x%s, mode %s.\n", value,
> > vmask ? " (masked)" : "",
> > - size == I2C_SMBUS_BYTE_DATA ? "byte" : "word");
> > + size == I2C_SMBUS_WORD_DATA ? "word" : "byte");
>
> Does this really change something or is it a refactoring leftover?
It does change something. Before the changes, size could only have two
values here, I2C_SMBUS_BYTE_DATA and I2C_SMBUS_WORD_DATA, so the result
would indeed be the same. But after the changes, size can also have
value I2C_SMBUS_BYTE, for which we want to display "mode byte", not
"mode word". Which is why we test explicitly for I2C_SMBUS_WORD_DATA,
else default to "byte", rather than the other way around.
Note that this also aligns nicely with the rest of the code in this
file, which does the same in various places.
Funny story, while I only posted this last week, I wrote the fix
several months ago, so last week I actually got to review my own code
with fresh eyes, and when I stumbled upon that specific change, first
thing that came to my mind was "this is a useless change, why did I do
that ?" Then I scrolled up, checked the other changes in that function,
noticed the removed "else" and said OK, I'm not that stupid after all
;-)
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2020-09-08 15:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 9:00 [PATCH] i2cset: Fix short writes with mask Jean Delvare
2020-09-08 6:51 ` Wolfram Sang
2020-09-08 15:19 ` Jean Delvare [this message]
2020-09-08 15:40 ` Wolfram Sang
2020-09-08 21:08 ` Jean Delvare
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=20200908171908.65690731@endymion \
--to=jdelvare@suse.de \
--cc=linux-i2c@vger.kernel.org \
--cc=sileasresearch@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;
as well as URLs for NNTP newsgroup(s).