From: Simon Horman <horms@kernel.org>
To: "Karumanchi, Vineeth" <vineeth.karumanchi@amd.com>
Cc: nicolas.ferre@microchip.com, claudiu.beznea@tuxon.dev,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux@armlinux.org.uk, vadim.fedorenko@linux.dev, andrew@lunn.ch,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, git@amd.com
Subject: Re: [PATCH net-next v6 3/4] net: macb: Add ARP support to WOL
Date: Thu, 20 Jun 2024 17:41:43 +0100 [thread overview]
Message-ID: <20240620164143.GL959333@kernel.org> (raw)
In-Reply-To: <616a10c5-9c72-4221-a181-6251e808b9b8@amd.com>
Hi Vineeth,
On Thu, Jun 20, 2024 at 09:29:01PM +0530, Karumanchi, Vineeth wrote:
> Hi Simon,
>
> On 6/18/2024 4:26 PM, Simon Horman wrote:
> > On Mon, Jun 17, 2024 at 12:34:12PM +0530, Vineeth Karumanchi wrote:
...
> > > @@ -5290,6 +5289,14 @@ static int __maybe_unused macb_suspend(struct device *dev)
> > > macb_writel(bp, TSR, -1);
> > > macb_writel(bp, RSR, -1);
> > > + tmp = (bp->wolopts & WAKE_MAGIC) ? MACB_BIT(MAG) : 0;
> > > + if (bp->wolopts & WAKE_ARP) {
> > > + tmp |= MACB_BIT(ARP);
> > > + /* write IP address into register */
> > > + tmp |= MACB_BFEXT(IP,
> > > + (__force u32)(cpu_to_be32p((uint32_t *)&ifa->ifa_local)));
> >
> > Hi Vineeth and Harini,
> >
> > I guess I must be reading this wrong, beause I am confused
> > by the intent of the endeness handling above.
> >
> > * ifa->ifa_local is a 32-bit big-endian value
> >
> > * It's address is cast to a 32-bit host-endian pointer
> >
> > nit: I think u32 would be preferable to uint32_t; this is kernel code.
> >
> > * The value at this address is then converted to a host byte order value.
> >
> > nit: Why is cpu_to_be32p() used here instead of the more commonly used
> > cpu_to_be32() ?
> >
> > More importantly, why is a host byte order value being converted from
> > big-endian to host byte order?
> >
> > * The value returned by cpu_to_be32p, which is big-endian, because
> > that is what that function does, is then cast to host-byte order.
> >
> >
> > So overall we have:
> >
> > 1. Cast from big endian to host byte order
> > 2. Conversion from host byte order to big endian
> > (a bytes-swap on litte endian hosts; no-op on big endian hosts)
> > 3. Cast from big endian to host byte oder
> >
> > All three of these steps seem to warrant explanation.
> > And the combination is confusing to say the least.
> >
>
> tmp |= MACB_BFEXT(IP, be32_to_cpu(ifa->ifa_local));
>
> The above snippet will address above points.
> Consider the ip address is : 11.11.70.78
>
> 1. ifa->ifa_local : returns be32 -> 0x4E460b0b
> 2. be32_to_cpu(ifa->ifa_local) : converts be32 to host byte order u32:
> 0x0b0b464e
>
> There are no sparse errors as well.
> I will make the change, please let me know your suggestions/thoughts.
Thanks for your response, your proposal looks good to me.
next prev parent reply other threads:[~2024-06-20 16:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 7:04 [PATCH net-next v6 0/4] net: macb: WOL enhancements Vineeth Karumanchi
2024-06-17 7:04 ` [PATCH net-next v6 1/4] net: macb: queue tie-off or disable during WOL suspend Vineeth Karumanchi
2024-06-17 7:04 ` [PATCH net-next v6 2/4] net: macb: Enable queue disable Vineeth Karumanchi
2024-06-17 7:04 ` [PATCH net-next v6 3/4] net: macb: Add ARP support to WOL Vineeth Karumanchi
2024-06-18 10:56 ` Simon Horman
2024-06-20 15:59 ` Karumanchi, Vineeth
2024-06-20 16:41 ` Simon Horman [this message]
2024-06-17 7:04 ` [PATCH net-next v6 4/4] dt-bindings: net: cdns,macb: Deprecate magic-packet property Vineeth Karumanchi
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=20240620164143.GL959333@kernel.org \
--to=horms@kernel.org \
--cc=andrew@lunn.ch \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=git@amd.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=vadim.fedorenko@linux.dev \
--cc=vineeth.karumanchi@amd.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.