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

[Joel Stanley]

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