linux-kernel - Re: [PATCH] ARM: shmobile: rcar-gen2: fix non-SMP build

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:   Fri, 6 Oct 2017 11:39:21 +0200
From:   Simon Horman <horms@...ge.net.au>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Magnus Damm <magnus.damm@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: shmobile: rcar-gen2: fix non-SMP build

On Fri, Oct 06, 2017 at 11:28:56AM +0200, Simon Horman wrote:
> On Thu, Oct 05, 2017 at 10:29:47PM +0200, Arnd Bergmann wrote:
> > On Thu, Oct 5, 2017 at 2:25 PM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Thu, Oct 5, 2017 at 2:09 PM, Arnd Bergmann <arnd@...db.de> wrote:
> > >>  arch/arm/mach-shmobile/headsmp-apmu.S | 2 ++
> > >>  1 file changed, 2 insertions(+)
> > >>
> > >> diff --git a/arch/arm/mach-shmobile/headsmp-apmu.S b/arch/arm/mach-shmobile/headsmp-apmu.S
> > >> index db4743d2bf91..5672b5849401 100644
> > >> --- a/arch/arm/mach-shmobile/headsmp-apmu.S
> > >> +++ b/arch/arm/mach-shmobile/headsmp-apmu.S
> > >
> > > As this hasn't been pulled into arm-soc yet (pull request sent though),
> > > perhaps Simon should squash this fix into the original commit?
> > > Should we rename headsmp-apmu.S to head-apmu.S?
> > 
> > I'm fine with it either way, just do whatever works best for you here.
> 
> My preference is to send a second pull request with this patch on top of the
> previous pull request. Arnd does that work for you?

In the mean time I pushed the patch to the next branch of the renesas
tree so it should appear in linux-next in the not to distant future.