[PATCH linux] ARM: dts: aspeed: zaius: Enable NC-SI mux

[Xo Wang]

On Tue, Mar 7, 2017 at 1:32 PM, Rick Altherr <raltherr at google.com> wrote:
> +maxim
>
> Sounds like U-Boot needs to do some work here.  I'm unclear if the hog
> is necessary once U-Boot does the right thing.
>
> On Tue, Mar 7, 2017 at 1:31 PM, Xo Wang <xow at google.com> wrote:
>> On Tue, Mar 7, 2017 at 1:21 PM, Rick Altherr <raltherr at google.com> wrote:
>>> I don't believe it currently does.  I'm concerned with whether U-Boot
>>> or Linux is expected to configure the NC-SI muxes.
>>>
>>> On Tue, Mar 7, 2017 at 1:19 PM, Xo Wang <xow at google.com> wrote:
>>>> On Tue, Mar 7, 2017 at 1:13 PM, Rick Altherr <raltherr at google.com> wrote:
>>>>> Why is Linux doing this instead of U-Boot?
>>>>>
>>>>
>>>> Does our U-Boot understand Aspeed GPIO in the device tree? If it does,
>>>> then it makes more sense for U-Boot to consume and set these pin
>>>> assignments.
>>>>
>>>> xo
>>
>> I would think U-Boot is expected to, since that provides the option of
>> netbooting from the NC-SI adapter in U-Boot.
>>
>> In addition, the Linux ftgmac100 driver can't yet handle the NC-SI mux
>> changing dynamically (https://github.com/openbmc/openbmc/issues/979).
>> So for now the mux must be enabled and selected prior to that driver
>> probing. This is the only reason why this assignment exists as a Linux
>> gpio-hog: it is set prior to any other driver being probed.
>>
>> xo

The hog would be no longer necessary once U-Boot sets it. In fact,
eliminating it is desirable because it opens up the possibility of
changing the mux selection at runtime (gpio-hogs are write-once as far
as I understand and preclude sysfs export for the GPIOs they occupy).

xo