Re: [PATCH net-next] net: phy: mdio-bcm-unimac: Cast denominator to unsigned long to avoid overflow

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Mar 12, 2024 at 12:23:20PM -0700, Doug Berger wrote:
> On 3/12/2024 10:23 AM, Florian Fainelli wrote:
> > On 3/12/24 10:18, Russell King (Oracle) wrote:
> > > On Tue, Mar 12, 2024 at 07:53:58PM +0300, Daniil Dulov wrote:
> > > > The expression priv->clk_freq * 2 can lead to overflow that will cause
> > > > a division by zero. So, let's cast it to unsigned long to avoid it.
> > > 
> > > How does casting this help? "unsigned long" can still be 32-bit.
> > > Maybe unimac_mdio_probe() should be validating the value it read from
> > > DT won't overflow? I suspect that a value of 2.1GHz is way too large
> > > for this property in any case.
> > > 
> > > https://en.wikipedia.org/wiki/Management_Data_Input/Output#Electrical_specification
> > > 
> > > (note, this driver is clause-22 only.)
> > > 
> > 
> > Had commented on the previous version (not sure why this was not
> > prefixed with v2) that the maximum clock frequency for this clock is
> > 250MHz, the driver could check that to prevent for an overflow, most
> > certainly.
> 
> Could also use:
> -	div = (rate / (2 * priv->clk_freq)) - 1;
> +	div = ((rate / priv->clk_freq) >> 1) - 1;
> which is mathematically equivalent without the risk of overflow.

What's the point when the maximum clock frequency that the driver should
allow fits within u32, nay u28?

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