Re: [PATCH net-next 2/4] net: phy: sfp: Use correct endian for sfp->id.ext.options
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: 2017-11-08 08:56:47
On Tue, Nov 07, 2017 at 07:49:09PM -0800, Florian Fainelli wrote:
quoted hunk ↗ jump to hunk
The extended ID options 16-bit value is big-endian (and actually annotated as such), but we would be accessing it with our CPU endian, which would not allow the correct detection of whether the LOS signal is inverted or not. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- drivers/net/phy/sfp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c index 942288aa9cdb..dfb28b269687 100644 --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c@@ -355,7 +355,7 @@ static void sfp_sm_link_check_los(struct sfp *sfp) * SFP_OPTIONS_LOS_NORMAL are set? For now, we assume * the same as SFP_OPTIONS_LOS_NORMAL set. */ - if (sfp->id.ext.options & SFP_OPTIONS_LOS_INVERTED) + if (be16_to_cpu(sfp->id.ext.options) & SFP_OPTIONS_LOS_INVERTED)
It would be more efficient to convert the constants to BE16 rather than an indeterminant number to CPU endian. The compiler can optimise the constant. Same for the other two hunks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up