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

[Jeremy Kerr]

Hi Mikey,

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

OK, I'm all for addressing that :)

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

Ah, that makes sense. So you're using the presence of a ffs partition
table to determine which should be the flash device, rather than it
being passed from the platform code.

I'm concerned that this makes the allocation of system flash less
reliable; if we end up with two things that look like they have a FFS
header, then (as you say) we will end up relying on probe order.

This could break systems that have separate working and golden flashes,
or a scenario where a non-system flash looks enough like a FFS device to
get detected as such.

However: we don't currently have any machines that have separate
working/golden PNOR (and it's not likely we'll have that for P9), so
maybe that first point is moot.  Since the FFS header is checksumed,
we're fairly unlikely to mis-detect a FFS partition.

[That leaves the scenario where a secondary flash device is maliciously
written with a FFS partition, potentially bricking a machine, but still,
nothing exists with >1 flash device at present]

So: if this makes bringup easier, I'd say merge it. If we do end up with
multiple-flash-device hardware in future, we can address that at the
time.

Acked-by: Jeremy Kerr <jk at ozlabs.org>

Cheers,


Jeremy