Re: [PATCH] m25p80: Add the is25wp256 SFPD table

[Michael Walle <michael@walle.cc>]

Am 2023-01-02 19:49, schrieb Guenter Roeck:
> On Mon, Jan 02, 2023 at 06:42:03PM +0100, Michael Walle wrote:
>> Am 2023-01-02 17:23, schrieb Guenter Roeck:
>> > On Mon, Jan 02, 2023 at 04:43:49PM +0100, Michael Walle wrote:
>> > > Am 2023-01-02 14:53, schrieb Cédric Le Goater:
>> > > > On 12/27/22 07:31, Tudor Ambarus wrote:
>> > > > >
>> > > > >
>> > > > > On 25.12.2022 14:18, Ben Dooks wrote:
>> > > > > > On Wed, Dec 21, 2022 at 06:36:02PM +0100, Cédric Le Goater wrote:
>> > > > > > > On 12/21/22 13:22, Guenter Roeck wrote:
>> > > > > > > > Generated from hardware using the following command and
>> > > > > > > > then padding
>> > > > > > > > with 0xff to fill out a power-of-2:
>> > > > > > > >     xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
>> > > > > > > >
>> > > > > > > > Cc: Michael Walle <michael@walle.cc>
>> > > > > > > > Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
>> > > > > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> > > > > > >
>> > > > > > > Reviewed-by: Cédric Le Goater <clg@kaod.org>
>> > > > > >
>> > > > > > If SFDP is a standard, couldn't we have an function to generate
>> > > > > > it from
>> > > > > > the flash parameters?
>> > > > > >
>> > > > >
>> > > > > No, it's not practical as you have to specify all the flash parameters
>> > > > > at flash declaration.
>> > > >
>> > > > Indeed and the definition of flash models in QEMU is far to cover all
>> > > > the SFDP
>> > > > features. The known_devices array of m25p80 would be huge ! However, we
>> > > > could
>> > > > generate some of the SFDP tables if no raw data is provided. It could be
>> > > > useful
>> > > > for testing drivers.
>> > >
>> > > I don't think adding (incomplete) SFDP tables makes sense for any real
>> > > devices. E.g. sometimes our linux driver will look at specific bits in
>> > > SFDP to figure out what particular flash device is attached. For
>> > > example
>> > > when there are different flashes with the same jedec id.
>> > >
>> > > But since the last released kernel, we support a generic SFDP
>> > > driver, which
>> > > is used when there is no matching driver for the flash's jedec id.
>> > > Theoretically, you can build your own flash device (with a unique
>> > > id) and
>> > > generate the sfdp tables for that one.
>> > >
>> > How about older kernels versions ? Would those still support such
>> > (virtual ?)
>> > flash devices ?
>> 
>> No with older kernels you'd be out of luck. They will just print 
>> "unknown
>> flash
>> id" and skip the device.
> 
> That would mean that qemu versions including this change could no 
> longer
> be used to test flash support on older kernel versions. That would be
> extremely undesirable. I'd rather live with the current code and still 
> be
> able to test older kernels.

Your board wouldn't need to use it. I don't think that emulating a real
spi flash device would go away. But it might still make sense to have
such a flash device, one example already mentioned is for testing
drivers.

-michael