mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Alex Elder <elder@ieee.org>,
	greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
	outreachy@lists.linux.dev, johan@kernel.org, elder@kernel.org,
	gregkh@linuxfoundation.org, vaibhav.sr@gmail.com,
	mgreer@animalcreek.com, vireshk@kernel.org, rmfrfs@gmail.com,
	dtwlin@gmail.com, pure.logic@nexus-software.ie,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: greybus: Replace format specifiers
Date: Fri, 23 Oct 2026 22:54:42 +0530	[thread overview]
Message-ID: <atuYWuWeqvEG6j4B@user> (raw)
In-Reply-To: <77adf02-43a9-7621-a94-9da41f8c5a56@inria.fr>

On Thu, Oct 22, 2026 at 09:30:26AM -0400, Julia Lawall wrote:
> 
> 
> On Thu, 22 Oct 2026, Alex Elder wrote:
> 
> > On 10/21/26 11:34 AM, pavankumaryalagada@gmail.com wrote:
> > > From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
> > >
> > > Unsigned variables are printed using %d.
> > > Replace them with %u to match their types.
> > >
> > > Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
> >
> > I have reviewed every one of these and they look good.  Quite a few
> > of them--because the size of the value being formatted is less than
> > 32 bits--would print correctly no matter what their value.  But I
> > think it at least does no harm to convert the format specifier to
> > unsigned in all of these cases.
> 
> I was suprised the compiler doesn't complain about this.  It seems to
> complain a lot about type-related format specifiers.  Yalagada maybe it
> could be worth adding something clearly invalid in one of the argument
> lists to see if the code is actually getting compiled, or if you need to
> set some config option to make that happen.

The files compiled sucessfully with the normal build settings. I also
enabled -Wformat-signedness to check for format mismatchse, as this check
is not enabled by default. It revealed a few more issues, which i'll look
into as well.

Pavan

> 
> julia
> 
> >
> > I have highlighted below an existing bug that should be fixed.  It
> > gives an example of something to look for when you do this sort of
> > activity.  Please arrange to get that bug fixed.
> >
> > I also pointed out one other observation for you to think about.
> >
> > Thanks for sending this.  I didn't check to find any other instances
> > you might have missed, but you seem to have found quite a few.
> >
> > Reviewed-by: Alex Elder <elder@riscstar.com>
> >
> > > ---
> > >   drivers/staging/greybus/audio_codec.c    | 20 ++++++++--------
> > >   drivers/staging/greybus/audio_topology.c | 30 ++++++++++++------------
> > >   drivers/staging/greybus/bootrom.c        |  2 +-
> > >   drivers/staging/greybus/fw-download.c    |  2 +-
> > >   drivers/staging/greybus/fw-management.c  |  2 +-
> > >   drivers/staging/greybus/gpio.c           |  2 +-
> > >   drivers/staging/greybus/light.c          |  2 +-
> > >   drivers/staging/greybus/log.c            |  4 ++--
> > >   drivers/staging/greybus/loopback.c       |  4 ++--
> > >   drivers/staging/greybus/power_supply.c   |  2 +-
> > >   drivers/staging/greybus/raw.c            |  2 +-
> > >   drivers/staging/greybus/sdio.c           |  4 ++--
> > >   drivers/staging/greybus/spilib.c         |  2 +-
> > >   drivers/staging/greybus/uart.c           |  4 ++--
> > >   14 files changed, 41 insertions(+), 41 deletions(-)
> > >
> >
> > . . .
> >
> > > diff --git a/drivers/staging/greybus/bootrom.c
> > > b/drivers/staging/greybus/bootrom.c
> > > index 83921d90c322..fb1fbd3f7b99 100644
> > > --- a/drivers/staging/greybus/bootrom.c
> > > +++ b/drivers/staging/greybus/bootrom.c
> > > @@ -222,7 +222,7 @@ static int gb_bootrom_firmware_size_request(struct
> > > gb_operation *op)
> > >   	size_response = op->response->payload;
> > >   	size_response->size = cpu_to_le32(bootrom->fw->size);
> > >   -	dev_dbg(dev, "%s: firmware size %d bytes\n",
> > > +	dev_dbg(dev, "%s: firmware size %u bytes\n",
> > >   		__func__, size_response->size);
> >
> > This line actually contains an error (and it was there before).
> >
> > The type of gb_bootrom_firmware_size_response->size is __le32.
> > So the value being formatted needs to be converted into CPU
> > byte order before being used.  That could be done this way:
> > 	le32_to_cpu(size_response->size)
> > or just use this, which is known from a few lines above to
> > have the proper value and byte order:
> > 	bootrom->fw->size
> >
> > Please add this to your list of things to fix, and submit it
> > as a separate patch.  This would be a bug fix, which would
> > also give you a little bit of a new experience.
> >
> > >     unlock:
> >
> > . . .
> >
> > > diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c
> > > index 4f1b3f4db404..2314496a858a 100644
> > > --- a/drivers/staging/greybus/raw.c
> > > +++ b/drivers/staging/greybus/raw.c
> > > @@ -112,7 +112,7 @@ static int gb_raw_request_handler(struct gb_operation
> > > *op)
> > >   	receive = op->request->payload;
> > >   	len = le32_to_cpu(receive->len);
> > >   	if (len != (int)(op->request->payload_size - sizeof(__le32))) {
> > > -		dev_err(dev, "raw receive request wrong size %d vs %d\n", len,
> > > +		dev_err(dev, "raw receive request wrong size %u vs %d\n", len,
> > >   			(int)(op->request->payload_size - sizeof(__le32)));
> >
> > The above size calculation was done somewhere else without the
> > (int) cast, and the format specifier was %zu in that case.
> > I don't think this needs to be changed necessarily, but it's
> > something inconsistent across the Greybus code.  Consistency
> > helps readability and maintainability.
> >  >   		return -EINVAL;
> > >   	}
> >
> > . . .
> >
> >

  reply	other threads:[~2026-10-23 17:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 16:34 pavankumaryalagada
2026-10-22 13:16 ` Alex Elder
2026-10-22 13:30   ` Julia Lawall
2026-10-23 17:24     ` Yalagada Pavan Kumar [this message]
2026-10-22 13:35   ` Julia Lawall
2026-10-22 13:41     ` Alex Elder
2026-10-22 13:45       ` Julia Lawall
2026-10-22 13:52         ` Johan Hovold
2026-10-23  2:30           ` Bryan O'Donoghue

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=atuYWuWeqvEG6j4B@user \
    --to=pavankumaryalagada@gmail.com \
    --cc=dtwlin@gmail.com \
    --cc=elder@ieee.org \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=julia.lawall@inria.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mgreer@animalcreek.com \
    --cc=outreachy@lists.linux.dev \
    --cc=pure.logic@nexus-software.ie \
    --cc=rmfrfs@gmail.com \
    --cc=vaibhav.sr@gmail.com \
    --cc=vireshk@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

all inboxes | Powered by JetHome®