Currently, M25P80 uses an object property to differentiate between flash parts.
Changed this over to use QOM sub-classes - the actual names of the different parts
are used to create a set of dynamic classes which passes the part info as class
data. The object no longer needs to search the known_devices table for itself,
instead it just gets its info from its own class.
Kept the intermediate class definition private to m25p80.c for the moment, as
the expectation is parts will only be added as new entries in the table. We can
factor out the TYPE_M25P80 abstraction into a header on a demand basis.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-id: e24e156d-ff96-4901-997a-e31178b08bee@VA3EHSMHS021.ehs.local
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Atmel, SST and Intel/Numonyx serial flash tend to power up
with the software protection bits set.
And thus the new m25p80.c in linux kernel would always tries
to use WREN(0x06) + WRSR(0x01) to turn-off the protection.
The WEL(0x02) of status register is supposed to be cleared after
WRSR(0x01). There are also some drivers (i.e mine for RTOSes)
would check the WEL(0x02) in status register to make sure the
protection is correctly turned off.
Signed-off-by: Kuo-Jung Su <dantesu@faraday-tech.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Default to moving back to the IDLE state after the COLLECTING_DATA
state. For a well behaved guest this patch has no consequence, but
A bad guest could crash QEMU by using one of the erase commands
followed by a longer than 5 byte argument (undefined behaviour).
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Added the Quad mode read and write commands. Data remains serialized on a
single wire, i.e. the quad mode instructions just behave the same as single
mode, with the expection of modelling the varying number of dummy/mode bytes
between the address bytes and the first data word.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
