Skip to content
  • Russell King's avatar
    net: smc91x: fix SMC accesses · 2fb04fdf
    Russell King authored
    Commit b70661c7 ("net: smc91x: use run-time configuration on all ARM
    machines") broke some ARM platforms through several mistakes.  Firstly,
    the access size must correspond to the following rule:
    
    (a) at least one of 16-bit or 8-bit access size must be supported
    (b) 32-bit accesses are optional, and may be enabled in addition to
        the above.
    
    Secondly, it provides no emulation of 16-bit accesses, instead blindly
    making 16-bit accesses even when the platform specifies that only 8-bit
    is supported.
    
    Reorganise smc91x.h so we can make use of the existing 16-bit access
    emulation already provided - if 16-bit accesses are supported, use
    16-bit accesses directly, otherwise if 8-bit accesses are supported,
    use the provided 16-bit access emulation.  If neither, BUG().  This
    exactly reflects the driver behaviour prior to the commit being fixed.
    
    Since the conversion incorrectly cut down the available access sizes on
    several platforms, we also need to go through every platform and fix up
    the overly-restrictive access size: Arnd assumed that if a platform can
    perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
    size needed to be specified - not so, all available access sizes must
    be specified.
    
    This likely fixes some performance regressions in doing this: if a
    platform does not support 8-bit accesses, 8-bit accesses have been
    emulated by performing a 16-bit read-modify-write access.
    
    Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
    accesses, which was broken by the original commit.
    
    Fixes: b70661c7
    
     ("net: smc91x: use run-time configuration on all ARM machines")
    Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
    Tested-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    2fb04fdf