Re: [PATCH] gpio: Renesas RZ GPIO driver

[Arnd Bergmann]

On Monday 18 November 2013, Linus Walleij wrote:
> On Wed, Nov 13, 2013 at 7:19 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> > On Wed, Nov 13, 2013 at 4:59 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> >> On Thu, Nov 7, 2013 at 12:47 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> >>
> >> Is it so that arch/sh is more soft on this for example...?
> >> Can some arch maintainer like SH/Paul ACK this approach?
> >>
> >> Read: SH is not moving to device tree...?
> >
> > From what I can tell this GPIO block is not used with SH, so I don't
> > think SH is related, but regarding DT on SH, do you know when it was
> > decided that other architectures also were supposed to move DT?
> 
> I don't think these is any such decision, I'm just asking. I know
> that we only want to see DT on new archs and old hairy board code
> should be ridded using DT ... So I just want to know what the
> situation is like wrt Super-H.

I think Paul as the arch/sh maintainer has made it very clear in the
past that he is not interested in converting the architecture.

IMHO that makes sense because the current code is working well and
there won't be new SoCs that need to get added to it. While there is
a set of drivers that are shared with arm/shmobile, that set is known
and we can handle each driver individually. In some cases we actually
end up having two completely different drivers for the same peripheral
(e.g. some interrupt controllers), something we normally try very
hard to avoid but that seems appropriate here. Let's just not make it
a common theme for other drivers that are not in this situation.

One thing that makes arch/sh and traditionally mach-shmobile different
from everything else is a very sophisticated way for describing
platforms in an abstract way using C data structures. It's not
necessarily bad, but it's inconsistent with other drivers we have
on ARM, and it's to a large degree incompatible to how we use DT
to describe the same hardware.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/