[Skiboot] [PATCH RFC] flash: Rework error paths and messages for multiple flash controllers
mikey at neuling.org
Wed Jul 6 08:44:48 AEST 2016
On Tue, 2016-07-05 at 22:01 +0800, Jeremy Kerr wrote:
> Hi Mikey,
> > The current flash code was written with only one flash chip, which is
> > a system_flash (ie. the PNOR image), in mind.
> Kinda. There's scope for more than one flash chip, but only one of them
> as the "system" flash.
That might be the intention but the error paths don't really deal with it
that well. Hence this patch..
> > We assume everything can be a system flash, so I've removed the
> > is_system_flash parameter from flash_register(). We'll use the first
> > system flash we find and warn if we find another since discovery order
> > is not a guaranteed API.
> Being the system flash means that that device is used:
> - for NVRAM
> - for the "resource" API (currently BOOTKERNEL and CAPI uCode)
> - as the mtd device that HBRT will use
> so I don't think we really want multiples of those.
> Is there a good reason for changing that?
No. I don't want multiple system flash. We just need to deal with it
> Are you just after multiple
> flash devices, but not multiple system flash devices?
> In that case, I'd say that the platform code should set is_system_flash
> appropriately (ie, true for the first discovered one, false otherwise).
> This way, the platform defines the flash device configuration, rather
> than having the core flash support making assumptions about it.
The problem is the platform code doesn't know. When I put a mambo disk in,
I don't want the mambo code to have to probe if it's formatted for a system
flash or not. I just want to add them and have it discovered.
This path removes the is_system_flash parameter and the generic flash code
adds the first system flash it finds is formatted correctly as a system
flash. If it finds more than one, it flags that as an unsupported
configuration (since probe order may change in future) but continues
More information about the Skiboot