[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240723175027.081423a1@fedora.home>
Date: Tue, 23 Jul 2024 17:50:27 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Simon Horman <horms@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose
Abreu <joabreu@...opsys.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>,
netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net] net: stmmac: Correct byte order of perfect_match
Hello Simon,
On Tue, 23 Jul 2024 14:29:27 +0100
Simon Horman <horms@...nel.org> wrote:
> The perfect_match parameter of the update_vlan_hash operation is __le16,
> and is correctly converted from host byte-order in the lone caller,
> stmmac_vlan_update().
>
> However, the implementations of this caller, dwxgmac2_update_vlan_hash()
> and dwxgmac2_update_vlan_hash(), both treat this parameter as host byte
> order, using the following pattern:
>
> u32 value = ...
> ...
> writel(value | perfect_match, ...);
>
> This is not correct because both:
> 1) value is host byte order; and
> 2) writel expects a host byte order value as it's first argument
>
> I believe that this will break on big endian systems. And I expect it
> has gone unnoticed by only being exercised on little endian systems.
>
> The approach taken by this patch is to update the callback, and it's
> caller to simply use a host byte order value.
>
> Flagged by Sparse.
> Compile tested only.
>
> Fixes: c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available")
> Signed-off-by: Simon Horman <horms@...nel.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
Thanks,
Maxime
Powered by blists - more mailing lists