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:   Thu, 1 Aug 2019 09:33:23 +0200
From:   Arnd Bergmann <>
To:     Russell King - ARM Linux admin <>
Cc:, Linux ARM <>,
        Vladimir Zapolskiy <>,
        Sylvain Lemieux <>,
        Gregory Clement <>,
        Linus Walleij <>,
        Jason Cooper <>,
        Andrew Lunn <>,
        Sebastian Hesselbarth <>,
        "David S. Miller" <>,
        Greg Kroah-Hartman <>,
        Alan Stern <>,
        Guenter Roeck <>,
        "open list:GPIO SUBSYSTEM" <>,
        Networking <>,, USB list <>,
Subject: Re: [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform

On Thu, Aug 1, 2019 at 12:53 AM Russell King - ARM Linux admin
<> wrote:
> On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> > For dove, the patches are basically what I had proposed back in
> > 2015 when all other ARMv6/ARMv7 machines became part of a single
> > kernel build. I don't know what the state is mach-dove support is,
> > compared to the DT based support in mach-mvebu for the same
> > hardware. If they are functionally the same, we could also just
> > remove mach-dove rather than applying my patches.
> Well, the good news is that I'm down to a small board support file
> for the Dove Cubox now - but the bad news is, that there's still a
> board support file necessary to support everything the Dove SoC has
> to offer.
> Even for a DT based Dove Cubox, I'm still using mach-dove, but it
> may be possible to drop most of mach-dove now.  Without spending a
> lot of time digging through it, it's impossible to really know.

Ok, so we won't remove it then, but I'd like to merge my patches to
at least get away from the special case of requiring a separate kernel
image for it.

Can you try if applying patches 12 and 14 from my series causes
problems for you? (it may be easier to apply the entire set
or pull from [1] to avoid rebase conflicts).


[1] mach-cleanup-5.4

Powered by blists - more mailing lists