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

[Christopher Bostic]

On 7/30/17 8:40 PM, Jeremy Kerr wrote:
> 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)
Hi Jeremy,

Not sure I follow what the FSI GPIO master probe would do if it can't 
access the GPIO itself, assuming we're in blocked mode. Would this 
require a deferred probe of some kind once access is unblocked?

There is also a control register setting


Also, in the existing FSP-2 implementation there is a bit in the FSI 
slave SISC which indicates if OPB if fence by host.  Which I believe is 
set whenever host boot is using the FSI bus.   Possibly we could use 
that info to determine if any FSI accesses past the CFAM slave engines 
are allowed.   This might be racy though since BMC can't control when 
that bit is set and cleared.



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