• Mark Brown's avatar
    spi: Revert modalias changes · 96c8395e
    Mark Brown authored
    During the v5.13 cycle we updated the SPI subsystem to generate OF style
    modaliases for SPI devices, replacing the old Linux style modalises we
    used to generate based on spi_device_id which are the DT style name with
    the vendor removed.  Unfortunately this means that we start only
    reporting OF style modalises and not the old ones and there is nothing
    that ensures that drivers list every possible OF compatible string in
    their OF ID table.  The result is that there are systems which have been
    relying on loading modules based on the old style that are now broken,
    as found by Russell King with spi-nor on Macchiatobin.
    
    spi-nor is a particularly problematic case for this, it only lists a
    single generic DT compatible jedec,spi-nor in the driver but supports a
    huge raft of device specific compatibles, with a large set of part
    numbers many of which are offered by multiple vendors.  Russell's
    searches of upstream device trees has turned up examples with vendor
    names written in non-standard ways too.  To make matters worse up until
    8ff16cf7 ("Documentation: devicetree: m25p80: add "nor-jedec"
    binding") the generic compatible was not part of the binding so there
    are device trees out there written to that binding version which don't
    list it all.  The sheer number of parts supported together with our
    previous approach of ignoring the vendor ID makes robustly fixing this
    by adding compatibles to the spi-nor driver seem problematic, the
    current DT binding document does not list all the parts supported by the
    driver at the minute (further patches will fix this).
    
    I've also investigated supporting both formats of modalias
    simultaneously but that doesn't seem possible, especially without
    breaking our userspace ABI which is obviously not viable.
    
    Instead revert the relevant changes for now:
    
    e09f2ab8 ("spi: update modalias_show after of_device_uevent_modalias support")
    3ce6c9e2 ("spi: add of_device_uevent_modalias support")
    
    This will unfortunately mean that any system which had started having
    modules autoload based on the OF compatibles for drivers that list
    things there but not in the spi_device_ids will now not have those
    modules load which is itself a regression.  Since it affects a narrower
    time window and the particularly problematic spi-nor driver may be
    critical to system boot on smaller systems this seems the best of a
    series of bad options.  I will start an audit of SPI drivers to identify
    and fix cases where things won't autoload using spi_device_id, this is
    not great but seems to be the best way forward that anyone has been able
    to identify.
    
    Thanks to Russell for both his report and the additional diagnostic and
    analysis work he has done here, the detailed research above was his
    work.
    
    Fixes: e09f2ab8 ("spi: update modalias_show after of_device_uevent_modalias support")
    Fixes: 3ce6c9e2 ("spi: add of_device_uevent_modalias support")
    Reported-by: default avatarRussell King (Oracle) <linux@armlinux.org.uk>
    Suggested-by: default avatarRussell King (Oracle) <linux@armlinux.org.uk>
    Signed-off-by: default avatarMark Brown <broonie@kernel.org>
    Tested-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Cc: Andreas Schwab <schwab@suse.de>
    Cc: Marco Felsch <m.felsch@pengutronix.de>
    96c8395e
spi.c 115 KB