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

[Patrick Venture]

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

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:
>>> On Thu, Nov 30, 2017 at 5:03 AM, Patrick Venture <venture at google.com> wrote:
>>>> Can I get a status on this patch?  The device datasheet has 4K
>>>> reserved for the range, but only the first 512 are registers
>>>> controlled by this driver.  The rest will be handled by a separate
>>>> driver.  Or at least that's how it's planned.
>>>
>>> +cc the people who have worked on this.
>>>
>>> I think that's okay, but lets see what the others have to say.
>>>
>>> Do you have a driver for the rest of the GPIOs you can submit? I'd
>>> like to see  that code so we can decide if there is good reason to
>>> make that completely separate, and not part of the existing driver.
>>>
>>> This work is best done upstream, as you will need to make the same
>>> arguments there.
>>
>> I should have a driver ready sometime late next week that I'll be
>> sending upstream first.  I still need to finish up a few loose ends on
>> it.  It wouldn't be unreasonable to have them in the same driver,
>> you'd just end up with two groups of gpios that are handled
>> differently, and extra soft-irqs.  That said, if you have two large
>> groups of things that need to be treated differently, then that's
>> somewhat of an argument for having them separate. :)
>>
>> 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.
>
> Cheers,
>
> Joel