linux-kernel - Re: [PATCH v4] hsdk: initial port for HSDK board

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:   Tue, 6 Jun 2017 15:15:10 -0700
From:   Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:     Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        <linux-snps-arc@...ts.infradead.org>
CC:     <linux-kernel@...r.kernel.org>,
        Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v4] hsdk: initial port for HSDK board

On 06/05/2017 12:50 PM, Alexey Brodkin wrote:
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
> 
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
> 
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_0000 intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_0000.
> 
> Signed-off-by: Eugeniy Paltsev <paltsev@...opsys.com>
> Signed-off-by: Alexey Brodkin <abrodkin@...opsys.com>
> Cc: Vineet Gupta <vgupta@...opsys.com>
> Cc: Rob Herring <robh+dt@...nel.org>
> ---
> 
> Changes v3 -> v4:
>   * Removed senseless "ranges" property from "memory" node in .dts
>   * Refined early-boot code:
>      - CREG_PAE should be set only once thus master does that in init_early()
>      - ICCM relocation should be done on each and every core that sports ICCM
>        so we leave it in init_per_cpu(). Even though init_per_cpu() gets called
>        on the master core pretty late still it is way much earlier than that
>        moment when it might affect us - as it only huts us when addresses in
>        0x7z-0x7fff_ffff range are used, i.e. virtual addresses that we don't
>        use during init. This also makes code much cleaner compared to
>        additional check in case of master etc.

So you are assuming that vmalloc machinery would not have kicked in by then i.e. 
by the time of irq_init() i.e. - perhaps that is true. Lets go with what you have 
now....

-Vineet