drivers/net/pse-pd/tps23881.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Fix incorrect boolean evaluation when checking bitmask values.
The existing code directly assigned the result of bitwise operations
to boolean variables. In the case of 4-pair PoE, this led to incorrect
enabled and delivering status values.
This has been corrected by explicitly converting the bitmask results
to boolean using the !! operator, ensuring proper evaluation.
Fixes: 20e6d190ffe1 ("net: pse-pd: Add TI TPS23881 PSE controller driver")
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Change in v2:
- Update commit message to describe the issue.
drivers/net/pse-pd/tps23881.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/pse-pd/tps23881.c b/drivers/net/pse-pd/tps23881.c
index 5c4e88be46ee..1a57c55f8577 100644
--- a/drivers/net/pse-pd/tps23881.c
+++ b/drivers/net/pse-pd/tps23881.c
@@ -139,9 +139,9 @@ static int tps23881_pi_is_enabled(struct pse_controller_dev *pcdev, int id)
chan = priv->port[id].chan[0];
if (chan < 4)
- enabled = ret & BIT(chan);
+ enabled = !!(ret & BIT(chan));
else
- enabled = ret & BIT(chan + 4);
+ enabled = !!(ret & BIT(chan + 4));
if (priv->port[id].is_4p) {
chan = priv->port[id].chan[1];
@@ -172,11 +172,11 @@ static int tps23881_ethtool_get_status(struct pse_controller_dev *pcdev,
chan = priv->port[id].chan[0];
if (chan < 4) {
- enabled = ret & BIT(chan);
- delivering = ret & BIT(chan + 4);
+ enabled = !!(ret & BIT(chan));
+ delivering = !!(ret & BIT(chan + 4));
} else {
- enabled = ret & BIT(chan + 4);
- delivering = ret & BIT(chan + 8);
+ enabled = !!(ret & BIT(chan + 4));
+ delivering = !!(ret & BIT(chan + 8));
}
if (priv->port[id].is_4p) {
--
2.34.1On Wed, 2 Oct 2024 12:23:40 +0200 Kory Maincent wrote: > In the case of 4-pair PoE, this led to incorrect enabled and > delivering status values. Could you elaborate? The patch looks like a noop I must be missing some key aspect..
On Wed, 2 Oct 2024 05:24:31 -0700 Jakub Kicinski wrote: > On Wed, 2 Oct 2024 12:23:40 +0200 Kory Maincent wrote: > > In the case of 4-pair PoE, this led to incorrect enabled and > > delivering status values. > > Could you elaborate? The patch looks like a noop I must be missing some > key aspect.. Reading the discussion on v1 it seems you're doing this to be safe, because there was a problem with x &= val & MASK; elsewhere. If that's the case, please resend to net-next and make it clear it's not a fix.
On Wed, 2 Oct 2024 05:27:32 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > On Wed, 2 Oct 2024 05:24:31 -0700 Jakub Kicinski wrote: > > On Wed, 2 Oct 2024 12:23:40 +0200 Kory Maincent wrote: > > > In the case of 4-pair PoE, this led to incorrect enabled and > > > delivering status values. > > > > Could you elaborate? The patch looks like a noop I must be missing some > > key aspect.. > > Reading the discussion on v1 it seems you're doing this to be safe, > because there was a problem with x &= val & MASK; elsewhere. > If that's the case, please resend to net-next and make it clear it's > not a fix. Indeed it fixes this issue. Why do you prefer to have it on net-next instead of a net? We agreed with Oleksij that it's where it should land. Do we have missed something? Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On Wed, 2 Oct 2024 14:53:02 +0200 Kory Maincent wrote:
> On Wed, 2 Oct 2024 05:27:32 -0700
> Jakub Kicinski <kuba@kernel.org> wrote:
>
> > On Wed, 2 Oct 2024 05:24:31 -0700 Jakub Kicinski wrote:
> > > On Wed, 2 Oct 2024 12:23:40 +0200 Kory Maincent wrote:
> > > > In the case of 4-pair PoE, this led to incorrect enabled and
> > > > delivering status values.
> > >
> > > Could you elaborate? The patch looks like a noop I must be missing some
> > > key aspect..
> >
> > Reading the discussion on v1 it seems you're doing this to be safe,
> > because there was a problem with x &= val & MASK; elsewhere.
> > If that's the case, please resend to net-next and make it clear it's
> > not a fix.
>
> Indeed it fixes this issue.
Is "this" here the &= issue or the sentence from the commit message?
> Why do you prefer to have it on net-next instead of a net? We agreed with
> Oleksij that it's where it should land. Do we have missed something?
The patch is a noop, AFAICT. Are you saying it changes how the code
behaves?
The patch only coverts cases which are
ena = val & MASK;
the automatic type conversion will turn this into:
ena = bool(val & MASK);
which is the same as:
ena = !!(val & MASK);
The problem you were seeing earlier was that:
ena &= val & MASK;
will be converted to:
ena = ena & (val & MASK);
and that is:
ena = bool(int(ena) & (val & MASK));
^^^
IOW ena gets promoted to int for the & operation.
This problem does not occur with simple assignment.
On Wed, 2 Oct 2024 07:31:56 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > On Wed, 2 Oct 2024 14:53:02 +0200 Kory Maincent wrote: > > On Wed, 2 Oct 2024 05:27:32 -0700 > > Jakub Kicinski <kuba@kernel.org> wrote: > > > > > On Wed, 2 Oct 2024 05:24:31 -0700 Jakub Kicinski wrote: > [...] > [...] > [...] > > > > > > Reading the discussion on v1 it seems you're doing this to be safe, > > > because there was a problem with x &= val & MASK; elsewhere. > > > If that's the case, please resend to net-next and make it clear it's > > > not a fix. > > > > Indeed it fixes this issue. > > Is "this" here the &= issue or the sentence from the commit message? > > > Why do you prefer to have it on net-next instead of a net? We agreed with > > Oleksij that it's where it should land. Do we have missed something? > > The patch is a noop, AFAICT. Are you saying it changes how the code > behaves? > > The patch only coverts cases which are > > ena = val & MASK; > > the automatic type conversion will turn this into: > > ena = bool(val & MASK); > which is the same as: > ena = !!(val & MASK); > > The problem you were seeing earlier was that: > > ena &= val & MASK; > > will be converted to: > > ena = ena & (val & MASK); > > and that is: > > ena = bool(int(ena) & (val & MASK)); > ^^^ > > IOW ena gets promoted to int for the & operation. > This problem does not occur with simple assignment. Indeed you are totally right! It is a noop! Thanks! Should I drop it? Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On Wed, 2 Oct 2024 17:00:47 +0200 Kory Maincent wrote: > Should I drop it? Your call, if you want to change things for consistency that's fine. But you'd need to repost against net-next and without the Fixes tag.
© 2016 - 2024 Red Hat, Inc.