Re: [bug report] sfp: add SFP module support

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

On Mon, Jul 18, 2022 at 04:00:55PM +0300, Dan Carpenter wrote:
> Hi Russell,
> 
> The patch 73970055450e: "sfp: add SFP module support" from Jul 25,
> 2017, leads to the following Smatch static checker warnings:
> 
> drivers/net/phy/sfp.c:474 sfp_soft_get_state() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1710 sfp_sm_mod_hpower() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1728 sfp_sm_mod_hpower() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1781 sfp_cotsworks_fixup_check() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1794 sfp_cotsworks_fixup_check() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1827 sfp_sm_mod_probe() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1854 sfp_sm_mod_probe() warn: passing zero to 'ERR_PTR'
> drivers/net/phy/sfp.c:1903 sfp_sm_mod_probe() warn: passing zero to 'ERR_PTR'
> 
> drivers/net/phy/sfp.c
>     1767 static int sfp_cotsworks_fixup_check(struct sfp *sfp, struct sfp_eeprom_id *id)

It seems this report is itself buggy. Commit 73970055450e does not
contain this function. The correct commit that introduced the underlying
problem was:

b18432c5a49c ("net: phy: sfp: Cotsworks SFF module EEPROM fixup")

But the commit which would have triggered the "passing zero to ERR_PTR"
would have been:

9ae1ef4b1634 ("net: sfp: use %pe for printing errors")

Nevertheless, thanks for spotting the error!

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