[PATCH linux dev-4.10] drivers/fsi: Break and set pin states on GPIO master remove

[Milton Miller II]

Around 06/21/2017, Andrew Geissler wrote:
>I think we had this same discussion last time Chris put this on the
>mailing list for 4.7 :)   I think we can do better here but we also
>(as usual) have a big time crunch.  Can we agree to put this in for
>now since our main goal is to just get 4.10 merged and of equal (or
>better) function to 4.7?  Chris can create an issue to come up with a
>final solution?  Without this change, cronus via the FSP debug does
>not work, which is a non-starter for picking this release up by IBM
>(and a lot of partners).
>
>I know, in theory, this is easy to fix, but it will require new
>testing, potentially new documentation for our users, and is just
>adding new function when we're mostly looking to just get a stable
>base going.
>
>Andrew
>
>On Thu, Jun 8, 2017 at 5:00 AM, Jeremy Kerr <jk at ozlabs.org> wrote:
>> Hi Alistair & Chris,
>>
>>>> The pins are set here mainly for the benefit of the Cronus debug
>>>> tools.   Its common practice in test and bringup labs to switch
>back and
>>>> forth between BMC and FSP-2 with Cronus to access the host
>processor
>>>> CFAMs over FSI.  Without the remove pin state changes Cronus
>cannot access.
>>>
>>> As far as I know you have to run "systemctl start
>fsi-disable.service"
>>> to switch over to Cronus mode. I think Jeremy's point is that it
>>> should be that service which explicitly sets up the hardware in a
>>> suitable mode rather than relying on side-effects from removing
>the
>>> kernel driver.
>>
>> Yep, spot on.
>>
>> Also, those side-effects might not be how the GPIOs need to
>configured
>> for the next usage of the FSI bus (which could be Cronus, but could
>also
>> be any other tool). So, let those tools handle the init correctly,
>> rather than the kernel making a guess at it.
>>

Actually I think there are well defined "Idle" states and I would expect 
those to be asserted.

I would expect the gpios to be set such that changing the mux does not 
glitch the signals to the chip.

Is this the state that is being set in the patch?

milton

[catching up after vacation]