From: Jakub Kicinski <kuba@kernel.org>
To: Min-Hua Chen <minhuadotchen@gmail.com>
Cc: alexandre.torgue@foss.st.com, davem@davemloft.net,
edumazet@google.com, joabreu@synopsys.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
pabeni@redhat.com, peppe.cavallaro@st.com,
simon.horman@corigine.com
Subject: Re: [PATCH v3] net: stmmac: compare p->des0 and p->des1 with __le32 type values
Date: Fri, 19 May 2023 21:04:39 -0700 [thread overview]
Message-ID: <20230519210439.4a3bb326@kernel.org> (raw)
In-Reply-To: <20230520015527.215952-1-minhuadotchen@gmail.com>
On Sat, 20 May 2023 09:55:27 +0800 Min-Hua Chen wrote:
> >Can you try to fix the sparse tool instead? I believe it already
> >ignores such errors for the constant of 0, maybe it can be taught
> >to ignore all "isomorphic" values?
> >
>
> I downloaded the source code of sparse and I'm afraid that I cannot make
> 0xFFFFFFFF ignored easily. I've tried ~0 instead of 0xFFFFFF,
> but it did not work with current sparse.
>
> 0 is a special case mentioned in [1].
>
> """
> One small note: the constant integer “0” is special.
> You can use a constant zero as a bitwise integer type without
> sparse ever complaining. This is because “bitwise” (as the name
> implies) was designed for making sure that bitwise types don’t
> get mixed up (little-endian vs big-endian vs cpu-endian vs whatever),
> and there the constant “0” really _is_ special.
> """
>
> For 0xFFFFFFFF, it may look like a false alarm, but we can silence the
> sparse warning by taking a fix like mine and people can keep working on
> other sparse warnings easier.
We can make working with sparse easier by making sure it doesn't
generate false positive warnings :\
> (There are around 7000 sparse warning in ARCH=arm64 defconfig build and
> sometimes it is hard to remember all the false alarm cases)
>
> Could you consider taking this patch, please?
No. We don't take patches to address false positive static
checker warnings.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Min-Hua Chen <minhuadotchen@gmail.com>
Cc: alexandre.torgue@foss.st.com, davem@davemloft.net,
edumazet@google.com, joabreu@synopsys.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
pabeni@redhat.com, peppe.cavallaro@st.com,
simon.horman@corigine.com
Subject: Re: [PATCH v3] net: stmmac: compare p->des0 and p->des1 with __le32 type values
Date: Fri, 19 May 2023 21:04:39 -0700 [thread overview]
Message-ID: <20230519210439.4a3bb326@kernel.org> (raw)
In-Reply-To: <20230520015527.215952-1-minhuadotchen@gmail.com>
On Sat, 20 May 2023 09:55:27 +0800 Min-Hua Chen wrote:
> >Can you try to fix the sparse tool instead? I believe it already
> >ignores such errors for the constant of 0, maybe it can be taught
> >to ignore all "isomorphic" values?
> >
>
> I downloaded the source code of sparse and I'm afraid that I cannot make
> 0xFFFFFFFF ignored easily. I've tried ~0 instead of 0xFFFFFF,
> but it did not work with current sparse.
>
> 0 is a special case mentioned in [1].
>
> """
> One small note: the constant integer “0” is special.
> You can use a constant zero as a bitwise integer type without
> sparse ever complaining. This is because “bitwise” (as the name
> implies) was designed for making sure that bitwise types don’t
> get mixed up (little-endian vs big-endian vs cpu-endian vs whatever),
> and there the constant “0” really _is_ special.
> """
>
> For 0xFFFFFFFF, it may look like a false alarm, but we can silence the
> sparse warning by taking a fix like mine and people can keep working on
> other sparse warnings easier.
We can make working with sparse easier by making sure it doesn't
generate false positive warnings :\
> (There are around 7000 sparse warning in ARCH=arm64 defconfig build and
> sometimes it is hard to remember all the false alarm cases)
>
> Could you consider taking this patch, please?
No. We don't take patches to address false positive static
checker warnings.
next prev parent reply other threads:[~2023-05-20 4:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-19 11:50 [PATCH v3] net: stmmac: compare p->des0 and p->des1 with __le32 type values Min-Hua Chen
2023-05-19 11:50 ` Min-Hua Chen
2023-05-19 13:17 ` Simon Horman
2023-05-19 13:17 ` Simon Horman
2023-05-19 22:27 ` Jakub Kicinski
2023-05-19 22:27 ` Jakub Kicinski
2023-05-20 1:55 ` Min-Hua Chen
2023-05-20 1:55 ` Min-Hua Chen
2023-05-20 4:04 ` Jakub Kicinski [this message]
2023-05-20 4:04 ` Jakub Kicinski
2023-05-20 7:34 ` Min-Hua Chen
2023-05-20 7:34 ` Min-Hua Chen
2023-05-22 14:09 ` Edward Cree
2023-05-22 14:09 ` Edward Cree
2023-05-22 15:36 ` Min-Hua Chen
2023-05-22 15:36 ` Min-Hua Chen
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=20230519210439.4a3bb326@kernel.org \
--to=kuba@kernel.org \
--cc=alexandre.torgue@foss.st.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=minhuadotchen@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=simon.horman@corigine.com \
/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.