From: Michael Walle <michael@walle.cc>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: linux-sunxi@lists.linux.dev, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Chen-Yu Tsai <wens@csie.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
Pratyush Yadav <p.yadav@ti.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: When a flash memory is missing do not report an error
Date: Thu, 14 Jul 2022 23:51:56 +0200 [thread overview]
Message-ID: <33abf7b84860049c4a22605578303ff2@walle.cc> (raw)
In-Reply-To: <20220714205529.GE17705@kitsune.suse.cz>
Am 2022-07-14 22:55, schrieb Michal Suchánek:
> On Thu, Jul 14, 2022 at 09:41:48PM +0200, Michael Walle wrote:
>> Hi,
>>
>> Am 2022-07-14 21:19, schrieb Michal Suchanek:
>> > It is normal that devices are designed with multiple types of storage,
>> > and only some types of storage are present.
>> >
>> > The kernel can handle this situation gracefully for many types of
>> > storage devices such as mmc or ata but it reports and error when spi
>> > flash is not present.
>> >
>> > Only print a notice that the storage device is missing when no response
>> > to the identify command is received.
>> >
>> > Consider reply buffers with all bits set to the same value no response.
>>
>> I'm not sure you can compare SPI with ATA and MMC. I'm just speaking
>> of
>> DT now, but there, for ATA and MMC you just describe the controller
>> and
>> it will auto-detect the connected storage. Whereas with SPI you
>> describe
>
> Why does mmc assume storage and SDIO must be descibed? Why the special
> casing?
I can't follow you here. My SDIO wireless card just works in an SD
slot and doesn't have to be described.
>> both the controller and the flash. So I'd argue that your hardware
>> description is wrong if it describes a flash which is not present.
>
> At any rate the situation is the same - the storage may be present
> sometimes. I don't think assuming some kind of device by defualt is a
> sound practice.
Where is the assumption when the DT tells you there is a flash
on a specific chip select but actually there it isn't. Shouldn't
the DT then be fixed?
Maybe I don't understand your problem. What are you trying to
solve? I mean this just demotes an error to an info message.
> 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? Or load an overlay if it is there?
-michael
next prev parent reply other threads:[~2022-07-14 21:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 19:19 [PATCH 1/2] mtd: spi-nor: When a flash memory is missing do not report an error Michal Suchanek
2022-07-14 19:19 ` [PATCH resend 2/2] ARM: dts: sunxi: Enable optional SPI flash on Orange Pi Zero board Michal Suchanek
2022-07-14 19:41 ` [PATCH 1/2] mtd: spi-nor: When a flash memory is missing do not report an error Michael Walle
2022-07-14 20:55 ` Michal Suchánek
2022-07-14 21:51 ` Michael Walle [this message]
2022-07-14 22:07 ` Michal Suchánek
2022-07-15 9:20 ` Pratyush Yadav
2022-07-16 8:20 ` Michal Suchánek
2022-07-16 9:30 ` Michael Walle
2022-07-16 9:38 ` Michal Suchánek
2022-07-16 9:44 ` Michael Walle
2022-07-24 15:59 ` Michal Suchánek
2022-07-15 12:20 ` Andre Przywara
2022-07-16 2:28 ` Samuel Holland
2022-07-16 10:58 ` Andre Przywara
2022-07-24 18:28 ` Michal Suchánek
2022-07-16 7:54 ` Michal Suchánek
2022-07-16 10:49 ` Andre Przywara
2022-07-15 0:43 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33abf7b84860049c4a22605578303ff2@walle.cc \
--to=michael@walle.cc \
--cc=devicetree@vger.kernel.org \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=miquel.raynal@bootlin.com \
--cc=msuchanek@suse.de \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=tudor.ambarus@microchip.com \
--cc=vigneshr@ti.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).