| 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
| ||
|
Message-ID: <CAEbi=3dWeYzGMf2ip9n=7aexojTsX5_nHpAfgL_WpD7qu0HLyg@mail.gmail.com>
Date: Tue, 23 Jan 2018 00:00:34 +0800
From: Greentime Hu <green.hu@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Greentime <greentime@...estech.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Marc Zyngier <marc.zyngier@....com>,
Rob Herring <robh+dt@...nel.org>,
Networking <netdev@...r.kernel.org>,
Vincent Chen <deanbo422@...il.com>,
DTML <devicetree@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
David Howells <dhowells@...hat.com>,
Will Deacon <will.deacon@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-serial@...r.kernel.org,
Geert Uytterhoeven <geert.uytterhoeven@...il.com>,
Linus Walleij <linus.walleij@...aro.org>,
Mark Rutland <mark.rutland@....com>, Greg KH <greg@...ah.com>,
Guo Ren <ren_guo@...ky.com>,
Randy Dunlap <rdunlap@...radead.org>,
David Miller <davem@...emloft.net>,
Jonas Bonn <jonas@...thpole.se>,
Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
Stafford Horne <shorne@...il.com>,
Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v6 29/36] nds32: Build infrastructure
Hi, Arnd:
2018-01-22 23:38 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
> On Mon, Jan 22, 2018 at 4:20 PM, Greentime Hu <green.hu@...il.com> wrote:
> BE
>>>
>>> I think it's better to drop GENERIC_IRQ_PROBE here, no modern driver
>>> should rely on that.
>>
>> I will drop it.
>>
>>>> +choice
>>>> + prompt "CPU type"
>>>> + default CPU_V3
>>>> +config CPU_N15
>>>> + bool "AndesCore N15"
>>>> +config CPU_N13
>>>> + bool "AndesCore N13"
>>>> + select CPU_CACHE_ALIASING if ANDES_PAGE_SIZE_4KB
>>>> +config CPU_N10
>>>> + bool "AndesCore N10"
>>>> + select CPU_CACHE_ALIASING
>>>> +config CPU_D15
>>>> + bool "AndesCore D15"
>>>> +config CPU_D10
>>>> + bool "AndesCore D10"
>>>> + select CPU_CACHE_ALIASING
>>>> +config CPU_V3
>>>> + bool "AndesCore v3 compatible"
>>>> + select ANDES_PAGE_SIZE_8KB
>>>> +endchoice
>>>
>>> I forget what we discussed here earlier, but at the very least, there should be
>>> some help text here to explain what the implications are. I assume that you
>>> generally want to be able to build one kernel to run on all of the above, right?
>>>
>>> Will selecting 'CPU_V3' result in a kernel binary that can run on all of them?
>>> If so, please explain it here as that is not obvious.
>>>
>>> For the other CPU types, can you list the what backwards-compatiblity
>>> you get? E.g. will a kernel built for N13 run on any of N15, D15 or N10?
>>>
>> Yes, we would like to build a kernel with CPU_V3 to run on all of the above.
>>
>> Not sure if these help texts clear enough?
>>
>> choice
>> prompt "CPU type"
>> default CPU_V3
>> help
>> The data cache of N15/D15 is implemented as PIPT and it will
>> not cause the
>> cache aliasing issue. The rest cpus(N13, N10 and D10) are
>> implemented as
>> VIPT data cache. It may cause the cache aliasing issue if
>> its cache way
>> size is larger than page size. You can specify the the CPU
>> type direcly or
>> choose CPU_V3 if unsure.
>>
>> A kernel built for N10 is able to run on N15, D15, N13, N10 or D10.
>> A kernel built for N15 is able to run on N15 or D15.
>> A kernel built for D10 is able to run on D10 or D15.
>> A kernel built for D15 is able to run on D15.
>> A kernel built for N13 with CPU_CACHE_ALIASING is able to
>> run on N15, D15, N13, N10 or D10
>> A kernel built for N13 without CPU_CACHE_ALIASING is able to
>> run on N15, N13 or D15
>>
>> config CPU_N15
>> bool "AndesCore N15"
>> config CPU_N13
>> bool "AndesCore N13"
>> select CPU_CACHE_ALIASING if ANDES_PAGE_SIZE_4KB
>> config CPU_N10
>> bool "AndesCore N10"
>> select CPU_CACHE_ALIASING
>> config CPU_D15
>> bool "AndesCore D15"
>> config CPU_D10
>> bool "AndesCore D10"
>> select CPU_CACHE_ALIASING
>> config CPU_V3
>> bool "AndesCore v3 compatible"
>> select CPU_CACHE_ALIASING
>> endchoice
>
> I would drop the description about CPU_CACHE_ALIASING in the list
> of compatibilities text and simply say 'A kernel built for N13 is able to run
> on N15, N13 or D15', it's more logical that way, and it gives you the freedom
> to later change the rules about whether it can or cannot run.
>
> Maybe also change the initial prompt from "CPU type" to "minimum CPU type".
>
Thank you for your suggestion.
I will update it like this.
choice
prompt "minimum CPU type"
default CPU_V3
help
The data cache of N15/D15 is implemented as PIPT and it will not cause
the cache aliasing issue. The rest cpus(N13, N10 and D10) are
implemented as VIPT data cache. It may cause the cache aliasing issue
if its cache way size is larger than page size. You can specify the
CPU type direcly or choose CPU_V3 if unsure.
A kernel built for N10 is able to run on N15, D15, N13, N10 or D10.
A kernel built for N15 is able to run on N15 or D15.
A kernel built for D10 is able to run on D10 or D15.
A kernel built for D15 is able to run on D15.
A kernel built for N13 is able to run on N15, N13 or D15.
config CPU_N15
bool "AndesCore N15"
config CPU_N13
bool "AndesCore N13"
select CPU_CACHE_ALIASING if ANDES_PAGE_SIZE_4KB
config CPU_N10
bool "AndesCore N10"
select CPU_CACHE_ALIASING
config CPU_D15
bool "AndesCore D15"
config CPU_D10
bool "AndesCore D10"
select CPU_CACHE_ALIASING
config CPU_V3
bool "AndesCore v3 compatible"
select CPU_CACHE_ALIASING
endchoice
Powered by blists - more mailing lists