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  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, 24 Feb 2017 10:51:05 +0100
From:   Alexandre Belloni <>
To:     Hans-Christian Noren Egtvedt <>
Cc:     Boris Brezillon <>,
        HÃ¥vard Skinnemoen <>,
        Andy Shevchenko <>,
        Richard Weinberger <>,
        "open list:MEMORY TECHNOLOGY..." <>,
        Nicolas Ferre <>,
        "" <>,
        Wenyou Yang <>,
        Josh Wu <>,
        David Woodhouse <>,
        Brian Norris <>,
        Marek Vasut <>,
        Cyrille Pitchen <>,
        linux-arm Mailing List <>,
        Rob Herring <>,
        Pawel Moll <>,
        Mark Rutland <>,
        Ian Campbell <>,
        Kumar Gala <>,
        devicetree <>
Subject: Re: [PATCH v2 1/3] mtd: nand: Cleanup/rework the atmel_nand driver

On 24/02/2017 at 10:04:35 +0100, Hans-Christian Noren Egtvedt wrote:
> Around Fri 24 Feb 2017 09:55:09 +0100 or thereabout, Boris Brezillon wrote:
> > On Fri, 24 Feb 2017 09:52:09 +0100
> > Hans-Christian Noren Egtvedt <> wrote:
> >> OK, I will try to prepare it during the weekend.
> >> 
> >> Any reason to wait for 4.11-rc1? AFAIK Linus prefers the larger changes
> >> before he starts tagging rc's.
> >> 
> > 
> > Oh, so you want to queue it for 4.11, that's even better.
> Perhaps I misunderstood you, by after 4.11-rc1 you mean queue it for 4.12?
> I will see what I get around to do in the weekend, it should be pretty
> straightforward, just want to make sure we remove all the bits.

I think the main task is removing arch/avr32 and update MAINTAINERS
(don't forget to add yourself to CREDITS) and Documentation/ anything
else will have to go through the driver maintainers tree.

If you feel like it, you can also prepare patches for the avr32 only
drivers. I'll be happy to help with the individual drivers if you can't
find the time to do it. We will definitively take care of the shared
avr32/at91 drivers.

Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering

Powered by blists - more mailing lists