Re: REGRESSION: "spi: add of_device_uevent_modalias support" and following "fix" breaks Macchiatobin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 20, 2021 at 11:20:29AM +0100, Russell King (Oracle) wrote:

> spi-flash@0 {
>         compatible = "st,w25q32";

> which is entirely legal according to the binding documentation in
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml.

Are you sure?  Looking at the binding document it appears that the
fallback to jedec,spi-nor is mandatory in all cases - it's either one of
the two items: cases both of which are lists with jedec,spi-nor in them
or just the plain jedec,spi-nor fallback.  It kind of doesn't matter
given that we weren't enforcing it in the past but still.

> MODALIAS=of:Nspi-flashT(null)Cst,w25q32

> However, the spi-nor module only supports these "of" modaliases:

> alias:          of:N*T*Cjedec,spi-norC*
> alias:          of:N*T*Cjedec,spi-nor

> but supports _way_ more "spi" modaliases, including "spi:w25q32".

> Therefore, this change breaks module autoloading.

Ugh, right.  This sort of stuff is why I really dislike not listing all
the compatibles in driver like some of the SoC vendors seem allergic to,
I keep having to fight for that.  

> Hence there are two commits that may need to be reverted:

> e09f2ab8eecc ("spi: update modalias_show after of_device_uevent_modalias support")
> 3ce6c9e2617e ("spi: add of_device_uevent_modalias support")

This then causes issues for anything trying to bind based with DT
aliases AIUI so it's just pushing the problems around to different
devices.  I think ideally we should be including the fallback compat IDs
that could also be matched along with the OF aliases.

> Alternatively, we need to add _all_ the flash types that the spi-nor
> driver supports to the DT table, which sounds like a recipe for
> disaster waiting to happen as it means maintaining two large tables of
> flash devices, one for the SPI aliases with the flash information and
> one for the DT aliases.

That doesn't seem particularly hard TBH, and if we're going to be
listing any compatibles we really ought to be including them all rather
than just a random one.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux