linux-kernel - Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

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] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.02.1209162137270.28681@xanadu.home>
Date:	Sun, 16 Sep 2012 21:55:31 -0400 (EDT)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Jason Cooper <jason@...edaemon.net>
Cc:	Andrew Lunn <andrew@...n.ch>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Lior Amsalem <alior@...vell.com>,
	Russell King <linux@....linux.org.uk>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

On Sun, 16 Sep 2012, Jason Cooper wrote:

> On Sun, Sep 16, 2012 at 09:46:52AM +0200, Andrew Lunn wrote:
> > > +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> > > @@ -0,0 +1,279 @@
> > > +* Marvell Kirkwood SoC pinctrl driver for mpp
> > > +
> > > +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
> > > +part and usage.
> > > +
> > > +Required properties:
> > > +- compatible: "marvell,88f6180-pinctrl",
> > > +              "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
> > > +              "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
> > > +
> > > +This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628
> > 
> > Hi Sebastian 
> > 
> > The current MPP code determines for itself what chip it is running on.
> > It can then check if a pin configuration is valid for the current
> > run time environment.
> > 
> > Here you are suggesting we have to put into the DT what chip we expect
> > to be on.
> > 
> > What is the advantage of this, over getting the information from the
> > device itself?
> 
> The DT should describe the hardware as accurately as possible.  We can't
> always assume Linux will be the only thing the DT is handed off to.
> 
> > If i wanted to mass convert all existing kirkwood DT boards over to
> > use pinctrl, im stuck at the very first step. I've no idea what chip
> > they use, it was not relevant before.
> 
> Let's try to do the DT correctly, and create a migration path for
> kirkwood to work first, then migrate to using the DT fully.

Beware beware.

The DT should of course describe the hardware as accurately as possible.  
That doesn't necessarily mean it should describe the hardware as 
_extensively_ as possible.

And that doesn't mean that all the information found in the DT has to be 
consumed by the kernel either.

Any information that can be *probed* at run time has no benefit being 
stuffed in a DT.  That's true whether it is Linux or another operating 
system.  The more that can be probed at run time the better.


Nicolas
--
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/