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!
