From: Elia Geretto <elia.f.geretto@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Staging: pi433: fix some warnings detected using sparse
Date: Sat, 29 Jul 2017 10:30:55 +0200 [thread overview]
Message-ID: <1501317055.20021.2.camel@gmail.com> (raw)
In-Reply-To: <20170728141707.sdp7yy236247olad@mwanda>
On Fri, 2017-07-28 at 17:17 +0300, Dan Carpenter wrote:
> On Fri, Jul 28, 2017 at 02:56:26PM +0200, Elia Geretto wrote:
> > This patch corrects some visibility issues regarding some functions
> > and
> > solves a warning related to a non-matching union. After this patch,
> > sparse produces only one other warning regarding a bitwise
> > operator;
> > however, this behaviour seems to be intended.
>
> I can't understand this changelog at all.... :/ What are we fixing
> exactly? It seems like we're fixing something about bitwise
> operators... I guess let me check the Sparse warnings... Here they
> are
> from the latest linux-next:
>
> drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:211:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:211:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:268:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:268:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:317:1: warning: symbol
> 'pi433_receive' was not declared. Should it be static?
> drivers/staging/pi433/pi433_if.c:467:1: warning: symbol
> 'pi433_tx_thread' was not declared. Should it be static?
> drivers/staging/pi433/pi433_if.c:1155:36: error: incompatible types
> for operation (<)
> drivers/staging/pi433/pi433_if.c:1155:36: left side has type
> struct task_struct *tx_task_struct
> drivers/staging/pi433/pi433_if.c:1155:36: right side has type int
> drivers/staging/pi433/rf69.c:206:17: warning: dubious: x & !y
> drivers/staging/pi433/rf69.c:436:5: warning: symbol
> 'rf69_set_bandwidth_intern' was not declared. Should it be static?
>
> Each type of fix should be sent as a separate fix with a better
> changelog. People have already done the "static" fixes and IS_ERR()
> fixes, so don't worry about those. But I don't think anyway has
> fixed
> the enum issues so resend that. Also the bitwise thing is a real
> bug,
> but there is already a fix for that, it just hasn't been merged yet.
>
> >
> > Signed-off-by: Elia Geretto <elia.f.geretto@gmail.com>
> > ---
> > drivers/staging/pi433/pi433_if.c | 17 +++++++++++------
> > drivers/staging/pi433/rf69.c | 4 +++-
> > 2 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/staging/pi433/pi433_if.c
> > b/drivers/staging/pi433/pi433_if.c
> > index d9328ce5ec1d..f8219a53ce60 100644
> > --- a/drivers/staging/pi433/pi433_if.c
> > +++ b/drivers/staging/pi433/pi433_if.c
> > @@ -208,7 +208,10 @@ rf69_set_rx_cfg(struct pi433_device *dev,
> > struct pi433_rx_cfg *rx_cfg)
> > {
> > SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
> > always));
> > }
> > - SET_CHECKED(rf69_set_packet_format (dev->spi, rx_cfg-
> > >enable_length_byte));
> > + if (rx_cfg->enable_length_byte == optionOn)
> > + SET_CHECKED(rf69_set_packet_format(dev->spi,
> > packetLengthVar));
> > + else
> > + SET_CHECKED(rf69_set_packet_format(dev->spi,
> > packetLengthFix));
>
> The SET_CHECKED() macro is total garbage. It has a hidden return and
> it calls the rf69_set_packet_format() twice on error it expands to:
>
> if (rf69_set_packet_format(dev->spi, rx_cfg-
> >enable_length_byte)) < 0)
> return rf69_set_packet_format(dev->spi, rx_cfg-
> >enable_length_byte);
>
> Mega turbo barf! Kill it with fire!
>
> regards,
> dan carpenter
>
I will resend a separate patch containing the enum work; I apologize
for the unclear changelog, I am still trying to understand how much in
detail I should go. Next time I will be more precise.
Regards,
Elia Geretto
next prev parent reply other threads:[~2017-07-29 8:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 12:56 [PATCH] Staging: pi433: fix some warnings detected using sparse Elia Geretto
2017-07-28 14:17 ` Dan Carpenter
2017-07-29 8:30 ` Elia Geretto [this message]
2017-07-29 13:36 ` kbuild test robot
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=1501317055.20021.2.camel@gmail.com \
--to=elia.f.geretto@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@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.