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

[Andrew Jeffery]

On Mon, 2017-07-31 at 10:36 +0800, Jeremy Kerr wrote:
> Hi Chris,
> 
> > 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?
> 
> Yes, any state change from blocked to unblocked would need to reinit the
> GPIOs, and potentially initiate a scan.
> 
> So, if we're initialised in blocked mode, the fsi master gpio driver
> would still claim the GPIOs (but not change any of their states),
> register with the FSI core, etc, but couldn't start any operations that
> require GPIO activity.

On this note, we should probably configure reset tolerance for the FSI
GPIOs on the Aspeed SoC to avoid glitching them in any way during a SoC
reset.

> 
> > 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.
> 
> OK, I'm confused - are we able to access *some* parts of the FSI bus
> (ie, the SISC register in the CFAM) while the host is booting?
> 
> But as you say, this might race. It would seem simpler to use the BMC's
> knowledge of when the host is booting to decide when the BMC is able to
> access the bus.
> 
> Cheers,
> 
> 
> Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170731/bbc73e05/attachment.sig>