linux-kernel - Re: [net-next PATCH] net: phy: aquantia: make mailbox interface4 lsw addr mask more specific

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZV3UIM+YR0U6PO+e@shell.armlinux.org.uk>
Date:   Wed, 22 Nov 2023 10:12:48 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Christian Marangi <ansuelsmth@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Robert Marko <robimarko@...il.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [net-next PATCH] net: phy: aquantia: make mailbox interface4 lsw
 addr mask more specific

On Tue, Nov 21, 2023 at 03:39:18PM -0800, Jakub Kicinski wrote:
> On Wed, 22 Nov 2023 00:32:56 +0100 Christian Marangi wrote:
> > the 2 addr comes from a define
> > 
> > #define DRAM_BASE_ADDR		0x3FFE0000
> > #define IRAM_BASE_ADDR		0x40000000
> > 
> > it wasn't clear to me if on BE these addrs gets saved differently or
> > not. PHY wants the addr in LE.
> > 
> > On testing by removing the cpu_to_le32 the error is correctly removed!
> > 
> > I guess on BE the addr was actually swapped and FIELD_GET was correctly
> > warning (and failing) as data was missing in applying the mask.
> 
> I think so. It's the responsibility of whether underlies 
> phy_write_mmd() to make sure the data is put on the bus in
> correct order (but that's still just within the u16 boundaries,
> splitting a constant into u16 halves is not endian dependent).

MDIO bus accesses via the MDIO bus accessors are expected to produce
the correct value in CPU order no matter what endian the host platform
is. So if the BMCR contains the value 0x1234, then reading and then
printing this register is expected to produce 0x1234 irrespective of
the host CPU architecture.

We do have 32-bit values split across two registers in clause 45 PHYs,
namely the MMD present register pair. Another example is the PHY ID.
In both cases we read the registers and apply the appropriate shift.
See get_phy_c45_ids() and get_phy_c22_id(). Note that these, again,
have to work independent of the CPU architecture.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!