Re: [PATCH v2 01/21] hw/block: Rename TYPE_PFLASH_CFI02 'width' property as 'device-width'

[Peter Maydell]

On Mon, 9 Jan 2023 at 14:19, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> On 9/1/23 14:33, BALATON Zoltan wrote:
> > On Mon, 9 Jan 2023, Philippe Mathieu-Daudé wrote:
> >> Use the same property name than the TYPE_PFLASH_CFI01 model.
> >
> > Nothing uses it? Can this break command lines and if so do we need
> > deprecation or some compatibility function until everybody changed their
> > usage?
>
> Good point... I missed that :/

That should not be possible, because the cfi02 device
is a sysbus device that must be mapped into memory. There's
no useful way to use it on the QEMU commandline; the only
users are those creating it from C code within QEMU.

That said, the meanings of the cfi01 parameters are:

    /* width here is the overall width of this QEMU device in bytes.
     * The QEMU device may be emulating a number of flash devices
     * wired up in parallel; the width of each individual flash
     * device should be specified via device-width. If the individual
     * devices have a maximum width which is greater than the width
     * they are being used for, this maximum width should be set via
     * max-device-width (which otherwise defaults to device-width).
     * So for instance a 32-bit wide QEMU flash device made from four
     * 16-bit flash devices used in 8-bit wide mode would be configured
     * with width = 4, device-width = 1, max-device-width = 2.
     *
     * If device-width is not specified we default to backwards
     * compatible behaviour which is a bad emulation of two
     * 16 bit devices making up a 32 bit wide QEMU device. This
     * is deprecated for new uses of this device.
     */

cfi02 claims that it does not support flash interleaving
(and unlike cfi01's comment which also claims that, I think
it really means it). So I think the cfi01 'width' parameter is the
same meaning as the cfi01 'width' parameter. It also happens
to be the same as 'device-width', but I don't think we
really need to rename the parameter here.

Happily, unlike cfi01, cfi02 doesn't have any of that
"bad emulation of two 16 bit devices making up a 32 bit
wide device" code :-)

thanks
-- PMM