linux-kernel - Re: [PATCH 1/2] mtd: spi-nor: When a flash memory is missing do not report an error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2d4f200c-1ce3-19c6-179f-8d8e0545adfe@sholland.org>
Date:   Fri, 15 Jul 2022 21:28:57 -0500
From:   Samuel Holland <samuel@...lland.org>
To:     Andre Przywara <andre.przywara@....com>,
        Michal Suchánek <msuchanek@...e.de>
Cc:     Michael Walle <michael@...le.cc>, linux-sunxi@...ts.linux.dev,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Pratyush Yadav <p.yadav@...com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: When a flash memory is missing do not
 report an error

On 7/15/22 7:20 AM, Andre Przywara wrote:
>>>> However, when the board is designed for a specific kind of device which
>>>> is not always present, and the kernel can detect the device, it is
>>>> perfectly fine to describe it.
>>>>
>>>> The alternative is to not use the device at all, even when present,
>>>> which is kind of useless.  
>>>
>>> Or let the bootloader update your device tree and disable the device
>>> if it's not there?  
> 
> Yes, this is what I was suggesting already: U-Boot can do the job, because
> a U-Boot build is device specific, and we can take certain risks that the
> generic and single-image kernel wants to avoid.
> In this case we know that there is a SPI flash footprint, and it does no
> harm in trying to check on CS0. So I was thinking about introducing a
> U-Boot Kconfig variable to probe for and potentially disable the SPI flash
> DT node. We would set this variable in defconfigs of boards with optional
> SPI flash.

To support the "does no harm" assertion: the Allwinner Boot ROM will probe for
NOR flash (and possibly SPI NAND) on SPI0 + CS0 if no bootable MMC device is
found. So the board designer must already assume that JEDEC Read ID commands
will be sent over that bus.

>> But then it must be in the device tree?
> 
> However this indeed means that the SPI flash DT node must be in and enabled
> in the DT, because we (try hard to) only use original Linux DT files, and
> DTs must have been reviewed through the kernel ML first. The U-Boot driver
> relies on the DT as well, so the official kernel DT copy would need to come
> with that node enabled. Ideally U-Boot would disable it, if needed, and
> the kernel error message would never appear.

I don't think this works for newer SoCs where the Boot ROM supports both NOR and
SPI NAND. If the board is sold with the flash chip unpopulated, the user could
install either kind of chip. So we cannot statically assume which binding will
be used. We would need to add a node with the right compatible string after
probing for both in the bootloader.

Regards,
Samuel