lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 18 Nov 2013 12:35:35 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Magnus Damm <magnus.damm@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Simon Horman <horms@...ge.net.au>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH] gpio: Renesas RZ GPIO driver

On Monday 18 November 2013, Linus Walleij wrote:
> On Wed, Nov 13, 2013 at 7:19 AM, Magnus Damm <magnus.damm@...il.com> wrote:
> > On Wed, Nov 13, 2013 at 4:59 AM, Linus Walleij <linus.walleij@...aro.org> wrote:
> >> On Thu, Nov 7, 2013 at 12:47 AM, Magnus Damm <magnus.damm@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ