Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Wed, 13 Dec 2023 16:34:50 +0000
From:   "Russell King (Oracle)" <linux@armlinux.org.uk>
To:     Christian Marangi <ansuelsmth@gmail.com>
Cc:     Florian Fainelli <florian.fainelli@broadcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@broadcom.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        David Epping <david.epping@missinglinkelectronics.com>,
        Harini Katakam <harini.katakam@amd.com>,
        Simon Horman <horms@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH v6 1/3] net: phy: extend PHY package API to
 support multiple global address
Message-ID: <ZXndKlCTq12jf53y@shell.armlinux.org.uk>
References: <20231213105730.1731-1-ansuelsmth@gmail.com>
 <ZXnRlERUGhwxKJxi@shell.armlinux.org.uk>
 <6579d2cc.050a0220.e6ea.d8cf@mx.google.com>
 <ZXnX6GuooQQwu8Bs@shell.armlinux.org.uk>
 <6579dab5.050a0220.8552a.d827@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6579dab5.050a0220.8552a.d827@mx.google.com>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>
Precedence: bulk

On Wed, Dec 13, 2023 at 05:24:18PM +0100, Christian Marangi wrote:
> On Wed, Dec 13, 2023 at 04:12:24PM +0000, Russell King (Oracle) wrote:
> > On Wed, Dec 13, 2023 at 04:50:33PM +0100, Christian Marangi wrote:
> > > On Wed, Dec 13, 2023 at 03:45:24PM +0000, Russell King (Oracle) wrote:
> > > > On Wed, Dec 13, 2023 at 11:57:28AM +0100, Christian Marangi wrote:
> > > > > -static inline int phy_package_read(struct phy_device *phydev, u32 regnum)
> > > > > +static inline int phy_package_read(struct phy_device *phydev,
> > > > > +				   unsigned int addr_offset, u32 regnum)
> > > > >  {
> > > > >  	struct phy_package_shared *shared = phydev->shared;
> > > > > +	int addr = shared->base_addr + addr_offset;
> > > > >  
> > > > > -	if (!shared)
> > > > > +	if (addr >= PHY_MAX_ADDR)
> > > > >  		return -EIO;
> > > > 
> > > > If we're going to check the address, I think we should check it
> > > > properly, which means also checking whether it's become negative.
> > > > 
> > > > Alternatively, we could consider making "addr" and "base_addr"
> > > > unsigned types, since they should never be negative. However,
> > > > that probably should be done as a separate patch before this one.
> > > >
> > > 
> > > Maybe I'm confused but isn't already like that?
> > > On phy_package_join base_addr is already checked if it's negative (and
> > > rejected)
> > > 
> > > addr_offset is unsigned so it can't be negative.
> > 
> > True, but with base_addr being an int, addr_offset being unsigned int,
> > and addr being an int, if addr_offset is a very large number,
> > 2-complement arithmetic will have the effect of treating it as a
> > negative number.
> > 
> > So, base_addr=0, addr_offset=~0 results in addr being -1.
> > 
> > If "addr" were unsigned int, and as we've already established,
> > "base_addr" can't be less than zero because of the checks already done
> > (thus it can also be unsigned int) then we'll end up with the checks
> > you're adding automatically doing the right thing, because...
> > 
> > base_addr=0, addr_offset=~0 results in addr being ~0 (a large
> > positive unsigned number).
> > 
> 
> Oh ok... now it makes sense. So I guess I should change "addr" to
> unsigned.
> 
> Considering I'm changing addr in phy_package_shared to base_addr would
> it be ok to change that also to unsigned (doesn't make sense to have
> that int) in this patch? Or should I create first a small patch before
> this to change addr type?

What I said when I mooted the use of unsigned was:

"Alternatively, we could consider making "addr" and "base_addr"
 unsigned types, since they should never be negative. However,
 that probably should be done as a separate patch before this
 one."

so my thoughts are that it should be a separate small patch - it's a
single logical change.

Thanks.

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