linux-kernel - Re: [PATCH 15/19] csky: Build infrastructure

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180327023927.GA11454@guoren>
Date:   Tue, 27 Mar 2018 10:39:29 +0800
From:   Guo Ren <ren_guo@...ky.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Jason Cooper <jason@...edaemon.net>,
        c-sky_gcc_upstream@...ky.com, gnu-csky@...tor.com,
        thomas.petazzoni@...tlin.com, wbx@...ibc-ng.org
Subject: Re: [PATCH 15/19] csky: Build infrastructure

On Mon, Mar 26, 2018 at 03:00:00PM +0200, Arnd Bergmann wrote:
> Ok, I understand the part about ck610 being incompatible, but I'm
> still not sure about the 8xx ones: Do you mean it's impossible to
> have one kernel that runs across all of them for some other reason,
> or is it something you haven't allowed because you see no use for it?
Sorry, Csky gcc need "-mcpu=ck807" or "-mcpu=ck810" or "-mcpu=ck860" to
determine the back-end policy. So I must seperate them with different vmlinux.

> This is basically the same question as above: For c610, using the fixed
> value is sufficient, because it's incompatible with the others. But if you want
> to run the same kernel on both ck810 and ck860, then it needs some form
> of runtime detection.
Sorry, currently no runtime detection.
But I agree with you that one vmlinux for all cpus is a good design for compat.

> On other architectures, the L1_CACHE_BYTES constant is the maximum
> possible cache line size, and the cache flush function uses the actual size
The same with above, we don't detect cpus on runtime. So we just make it
simple here.

> Ok. Just make sure that the DT always has this information as well,
> so this can be changed in the future when desired, without having to
> make incompatible changes to the devicetree binary files.
Ok

Best Regards
 Guo Ren