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]
Date:   Sat, 16 Jul 2022 11:38:50 +0200
From:   Michal Suchánek <msuchanek@...e.de>
To:     Michael Walle <michael@...le.cc>
Cc:     Pratyush Yadav <p.yadav@...com>, 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>,
        Samuel Holland <samuel@...lland.org>,
        Tudor Ambarus <tudor.ambarus@...rochip.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 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?

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.

Thanks

Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ