linux-kernel - Re: [PATCH] of: match the compatible in the order set by the dts file

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]

Date:	Sun, 21 Jul 2013 08:35:34 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Grant Likely <grant.likely@...aro.org>
Cc:	Huang Shijie <b32955@...escale.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	rob.herring@...xeda.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] of: match the compatible in the order set by the dts file

On Sat, Jul 20, 2013 at 06:44:39AM +0100, Grant Likely wrote:
> On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie <b32955@...escale.com> wrote:
> > 于 2013年07月09日 15:51, Sascha Hauer 写道:
> > > On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> > >> 于 2013年07月09日 15:05, Sascha Hauer 写道:
> > >>> Why don't you set the matching order in the driver the way you want it
> > >>> to be, i.e.:
> > >>>
> > >>> 	{ .compatible = "fsl,imx6q-uart", ... },
> > >>> 	{ .compatible = "fsl,imx21-uart", ... },
> > >>> 	{ .compatible = "fsl,imx1-uart", ... },
> > >>>
> > >> yes. i can set it like this.
> > >>
> > >> but this method looks like a ugly workaround.
> > > If a driver has different ways of supporting a single device, then
> > > putting the preferred or most feature rich on top doesn't look very ugly
> > > to me.
> > this method makes it much _coupled_ between the driver and the dts file.
> > 
> > IMHO, it's an unnecessary _burden_ to the driver programmer:
> >     he should puts the most feature compatible on the top.
> > 
> > it's much graceful if we let the driver programmer be transparent about 
> > this.
> 
> Absolutely true. Applied, thanks.

I don't think this will work. The patch looks very similar to one that I
posted about a year ago (commit 107a84e "of: match by compatible
property first"). The problem it was trying to address was exactly the
same. However the patch caused regressions on SPARC and had to be
reverted in commit bc51b0c "Revert "of: match by compatible property
first"".

The revert commit quotes Rob having a fix for this, and I remember that
I pinged him about it occasionally, but I suspect that those must have
fallen through the cracks.

Grant, before applying this patch we should make sure that it doesn't
cause a regression again, so perhaps asking Meelis Roos (mentioned in
the revert commit) to test would be good. I have a strong feeling that
this patch will break in the same way than mine did a year ago, because
it looks too similar and doesn't handle the compatible & name
combination that Rob mentioned.

Thierry

Content of type "application/pgp-signature" skipped