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] [day] [month] [year] [list]
Date:	Thu, 19 Nov 2015 20:36:47 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Nicolas Ferre <nicolas.ferre@...el.com>
Cc:	Olof Johansson <olof@...om.net>, arm@...nel.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>
Subject: Re: [GIT PULL] at91: fixes for 4.4 #1

On Thursday 19 November 2015 18:44:57 Nicolas Ferre wrote:
> Le 19/11/2015 16:22, Arnd Bergmann a écrit :
> > On Tuesday 17 November 2015 12:35:58 Nicolas Ferre wrote:
> >> Arnd, Olof, Kevin,
> >>
> >> This is the first "fixes" pull-request for AT91. I tried to collect little
> >> patches that didn't make it for -rc1.
> >> It can be due to synchronization between trees like the addition of some
> >> sama5d2 Xplained nodes (MFD tree) or the change of the watchdog compatible
> >> string for sama5d4 (watchdog tree).
> >> It can also be due to trivial cleanups that were spotted or submitted late like
> >> the replacement of "wakeup" properties or removal of unneeded defconfig option.
> >> The removal of some dead legacy DT properties or nodes is, in my opinion worth
> >> it as well in order to prevent us from abusive cut'n paste.
> >> NAND and ISI Atmel MAINTAINERS entries are also updated.
> >>
> >> Tell me if it's okay for you.
> > 
> > I'd be happier to get the patches late in the process and then push back
> > myself than to get them as fixes, there was really no reason to wait
> > for the merge window to end with the ones that you already had.
> 
> I thought than having a precise milestone as a base for this
> pull-request would be preferred.

It is, but if you have a branch that introduces or exposes a bug,
then I'd prefer to get a pull request with the bug fixes on top
of the branch that we already have, e.g. the at91/dt branch
(as opposed to next/dt or for-next, which would be wrong).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ