linux-kernel - Re: [PATCH 0/3] removing of some unused/unsupported dts entries

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: <20141213143328.GA967@titan.lakedaemon.net>
Date:	Sat, 13 Dec 2014 09:33:28 -0500
From:	Jason Cooper <jason@...edaemon.net>
To:	Marc Zyngier <marc.zyngier@....com>
Cc:	Silvio Fricke <silvio.fricke@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] removing of some unused/unsupported dts entries

Silvio, Marc,

On Sat, Dec 13, 2014 at 09:21:23AM +0000, Marc Zyngier wrote:
> On Sat, Dec 13 2014 at  1:46:45 am GMT, Silvio Fricke <silvio.fricke@...il.com> wrote:
> 
> Hi Silvio,
> 
> > I have found some dts entries which are not evaluated by the drivers. This
> > patch remove this entries from the dts files.
> > Jason has mentioned I should CC: Thomas, Marc and him self to this
> > mails.
> 
> As far as I can tell, this looks correct. A few key things though:
> 
> - Please write decent commit logs. Indicate *why* you think these
>   properties can be removed (hint: not finding corresponding in the
>   drivers is not enough a reason, the binding itself matters).

Right.  The real issue is the state of these properties within the
binding documentation.  Linux isn't the only consumer of these dts
files (*BSD, barebox, etc), so us not using them doesn't necessarily
mean the property should be removed.

The most important lesson (recently learned ;-) ) is to make sure all
properties are accurately describing the *hardware*.  Not Linux's
implementation of talking to the hardware.  That'll go a long way if the
changelog discusses how property X is an implementation detail vice a
hardware characteristic or feature.

> - Cc the relevant platform maintainers. You're changing things that they
>   care about, basic courtesy is to keep them in the loop.

True.  In Silvio's defense, I just told him to Cc us to get the ball
rolling.  (I tend to dislike long discussions on chat mediums, I'd much
rather they be in email.  So I was definitely too succinct).

For the record, you can use ./scripts/get_maintainer.pl on your patches
to make sure you get most of the right people.  In this case, that'll
include the DT maintainers.  You may want to run a get_maintainer.pl -f
arch/arm/mach-$ARCH for each of the dts file you touch.  Those
maintainers usually wrangle the patches for their dts files.
Unfortunately, not all of them have updated MAINTAINERS
(<cough>mvebu<cough>) to include the dts file patterns.

thx,

Jason.
--
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/