linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: Pratyush Yadav <p.yadav@ti.com>,
	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>,
	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: Sat, 16 Jul 2022 11:44:48 +0200	[thread overview]
Message-ID: <50ec7bf33d8eca5eb68a079f7bcc12b7@walle.cc> (raw)
In-Reply-To: <20220716093850.GL17705@kitsune.suse.cz>

Am 2022-07-16 11:38, schrieb Michal Suchánek:
> On Sat, Jul 16, 2022 at 11:30:12AM +0200, Michael Walle wrote:
>> Am 2022-07-16 10:20, schrieb Michal Suchánek:
>> 
>> > > So if DT says there isn't a flash on a specific CS when there is, then
>> > > DT should be fixed to describe the flash, and then we can probe it.
>> > > You
>> > > both seem to be saying the same thing here, and I agree.
>> >
>> > The disagreement is about the situation when there is sometimes a flash
>> > chip.
>> 
>> No. The disagreement is what should happen if the DT says there is
>> a device but there isn't. Which right now is an error and it should
>> stay that way. Your hardware description says there is a flash
>> but it cannot be probed, so it is an error. What about a board
>> which has an actual error and the flash isn't responding? You
>> trade one use case for another.
> 
> And what if you have a SATA controller with a bad cable?
> 
> Or a bad connection to a mmc card?

Again. You don't tell the kernel via the DT that there is an
MMC card nor that there is a SATA SDD. In contrast to SPI-NOR..


> Then the kernel also does not say there is an error and simply does not
> see the device.
> 
> This is normal. Not all devices that can potentially exist do exist. It
> is up to the user to decide if it's an error that the device is 
> missing.
> 
>> Also I've looked at the PHY subsystem and there, if a PHY is described
>> in the DT but isn't there, the following error will be printed:
>>   dev_err(&mdio->dev, "MDIO device at address %d is missing.\n", 
>> addr);
>> 
>> And that is for a bus which can even be automatically be
>> probed/detected.
> 
> If there is no use case for having a card with unpopulated PHY then it
> makes sense.
> 
> Here we do have a use case so the comparison is moot.

And what use case is that? You are just demoting an error
to an info. Apparently you just want to see that error
go away, there is no change in functionality.

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2022-07-16  9:46 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
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 [this message]
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=50ec7bf33d8eca5eb68a079f7bcc12b7@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).