[Skiboot] [PATCH RFC] flash: Rework error paths and messages for multiple flash controllers

[Michael Neuling]

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
happening.

> Are you just after multiple
> flash devices, but not multiple system flash devices?

Correct.

> 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
anyway.

Mikey