[PATCH linux dev-4.10] drivers/fsi: Remove scan from master registration

[Jeremy Kerr]

Hi Eddie & Patrick,

> On Fri, Jul 28, 2017 at 09:57:23AM -0500, Eddie James wrote:
>> 2) FSI operations while the host is booting can cause FSI failures. 
>> Since we don't know the state of the host while booting the BMC, it's 
>> generally not safe to do FSI ops as we may disrupt the host.
> 
> From my perspective this is especially bad because it would only surface
> in specific timing conditions.  The FSI bus is, by the system
> architecture, under the control of the Host for a period during the
> boot.

OK, so this sounds like a good reason to add some form of arbitration,
but this patch isn't sufficient to handle that - we still have GPIO
initialisation on (FSI master) driver probe, and there's other
facilities that would cause the BMC to access the bus, potentially in
conflict with the host master.

So, I'd suggest this instead:

 - add a 'blocked' state to the fsi master driver, which prevents
   *all* accesses to the GPIOs, including during init; all master
   reads/writes would return -EBUSY.

 - add a boolean device tree property to indicate that a master should
   be initialised in blocked state (preventing GPIO changes during
   probe)

   It would make sense for this property to be associated with the
   'fsi-master' compatible value, as it'd potentially apply to all
   master implementations, not just GPIO-based ones.

 - add a sysfs file to control blocked state, which would be updated
   when the host acquires/releases control of the bus.

We may want to rethink the 'external mode' implementation to work with
this too.

Regards,


Jeremy