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]

Date:	Fri, 25 Oct 2013 06:33:43 -0700
From:	Olof Johansson <olof@...om.net>
To:	Mark Brown <broonie@...nel.org>
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 6:24 AM, Mark Brown <broonie@...nel.org> wrote:
> 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.

Some of those might still make sense, but as many as possible of them
should be pushed down into the trees where they belong, even if
they're strictly not needed there (as long as they don't break the
standalone tree, of course).


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