[PATCH linux dev-4.10] ARM: dts: aspeed: gpio controller register range

[Joel Stanley]

On Sat, Dec 9, 2017 at 3:40 AM, Patrick Venture <venture at google.com> wrote:

>
> Thanks,
> Patrick
>
> On Thu, Dec 7, 2017 at 10:30 PM, Joel Stanley <joel at jms.id.au> wrote:
>> On Fri, Dec 1, 2017 at 2:05 AM, Patrick Venture <venture at google.com> wrote:
>>> On Wed, Nov 29, 2017 at 7:53 PM, Joel Stanley <joel at jms.id.au> wrote:
>>> I'd actually appreciate hearing some thoughts at this point on which
>>> way to go, since merging the serial handling into the main driver will
>>> require re-working a few things -- I'd rather take the extra time to
>>> handle that merge if it's going to head in that direction anyway.
>>>
>>> I have read through the gpio-aspeed driver before, as it was a bit
>>> useful as a guide, and I could see it getting a bit cluttered with
>>> also handling the serial gpios.
>>
>> It sounds like a call that could go either way. If you think it would
>> be easier to maintain two separate drivers then we can go that
>> direction.
>>
>> I'd suggest discussing it upstream.
>>
>> The best way to discuss it would be in the form of a patch. Even if
>> it's not complete, post it as a RFC.
>
> Thanks for the feedback.  I'm still working on getting a few kinks
> worked out in the driver, for instance, verifying that waiting on the
> rising edge for the J1 gpio (on the ast2400) is required for stable
> writing -- which has been true.  We were actually seeing the serial
> gpios wedge to a specific value on the quanta-q71l board, but having
> it wait on that prevents this case... so more work is going into
> verifying behaviors and caveats.  I'm without a motherboard that has
> serial gpios and the ast2500 for testing...

This is a good example of where sending a RFC is the right thing to do
- it doesn't matter that the code isn't functioning, but it will allow
review of the structure.

I encourage you to send it out as you have it now.

Cheers,

Joel