linux-kernel - Re: linux-next: Tree for Oct 24

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: <20131025132422.GC12932@sirena.org.uk>
Date:	Fri, 25 Oct 2013 14:24:22 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Olof Johansson <olof@...om.net>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Guenter Roeck <linux@...ck-us.net>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for Oct 24

On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding

> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> > boards on ARM I think. Must have forgotten to update the summary email.
> > I'll see if I can come up with a patch to fix the GPIO related build
> > failures, or at least report it to LinusW or Alexandre.

> Hmm.

> Please don't apply fixes like these directly to your tree, keep the
> broken parts (or drop the tree that introduced it). It makes the
> process of getting the fixes in where they really have to go much more
> error prone, since there's no way to track whether they have landed in
> the right place yet or not.

The rule I was applying (which I think is the same as Stephen applies)
is that I'd fix anything that was definitely the result of a merge issue
(like the build failure in misc due to a sysfs API change in the sysfs
tree) but not anything that was just plain broken in the tree in
isolation.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)