linux-kernel - Re: [PATCHv3 1/3] gpio: add a driver for the Synopsys DesignWare APB GPIO block

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Jan 2012 14:54:39 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jamie Iles <jamie@...ieiles.com>
Cc:	linux-kernel@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	linus.walleij@...ricsson.com
Subject: Re: [PATCHv3 1/3] gpio: add a driver for the Synopsys DesignWare APB
 GPIO block

On Mon, Jan 02, 2012 at 01:51:45PM +0000, Jamie Iles wrote:
> On Mon, Jan 02, 2012 at 01:25:00PM +0000, Mark Brown wrote:

> > > v2:	- use Rob Herring's irqdomain in generic irq chip patches
> > > 	- use reg property to indicate bank index
> > > 	- support irqs on both edges based on LinusW's u300 driver

> > Put stuff like this after the ---, it shouldn't end up in git history.

> Grant (and others I believe) have asked to have it above the separator 
> in the past to ensure that it does end up in the history.  This helps 
> make it clear what version got applied and it's a lot easier for patch 
> authors to manage rather than keeping it out of band.

You end up with content-free junk in the changelogs like "v2: rewrite
with new API" (I've actually had that...) which just isn't instructive
to anyone reading the logs later; if there were some way of going from
the changelog back to the actual code that'd be one thing but then
there's a reason why we don't carry the out of tree revision control
history.

Note that patch changelogs are one of the specific examples given in
SubmittingPatches for inclusion after the ---.

Personally I'm not convinced carrying any out of tree change history
except the delta from the last version submitted is useful as the actual
code changes aren't readily available and the fact that there were
earlier versions with bugs or whatever isn't terribly instructive.  The
delta from the last version is useful for helping to focus review but
the rest of it gets very noisy.  If the history is really useful
probably merging an actual branch with is much more helpful, if it's
getting troublesome to manage it and that's not suitable then I'd just
drop it.

> Something like this?

Yes, exactly thanks.
--
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/