linux-kernel - Re: [PATCH v3 1/5] arch: riscv: add support for building DTB files from DT source data

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 8 Jun 2019 22:50:14 -0700 (PDT)
From:   Paul Walmsley <paul.walmsley@...ive.com>
To:     Palmer Dabbelt <palmer@...ive.com>
cc:     lollivier@...libre.com, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org, paul@...an.com,
        aou@...s.berkeley.edu
Subject: Re: [PATCH v3 1/5] arch: riscv: add support for building DTB files
 from DT source data

On Sat, 8 Jun 2019, Palmer Dabbelt wrote:

> On Thu, 06 Jun 2019 22:12:05 PDT (-0700), Paul Walmsley wrote:
> > On Tue, 4 Jun 2019, Loys Ollivier wrote:
> > 
> > > Always build it ?
> > > Any particular reason to drop ARCH_SIFIVE ?
> > 
> > Palmer had some reservations about it, so I dropped it for now.  But then
> > as I was thinking about it, I remembered that I also had some reservations
> > about it, years ago: that everyone should use CONFIG_SOC_* for this,
> > rather than CONFIG_ARCH.  CONFIG_ARCH_* seems better reserved for
> > CPU architectures.
> 
> The SOC stuff will, of course, be vendor specific.  In this idealized world
> SiFive's SOC support has nothing to do with RISC-V, but of course all of
> SiFive's SOCs are RISC-V based so the separation is a bit of pedantry.  That
> said, in this case I think getting the name right does make it slightly easier
> to espouse this "one kernel can run on all RISC-V systems" philosophy.
> Balancing the SiFive and RISC-V stuff can be a bit tricky, which is why I am
> sometimes a bit pedantic about these sorts of things.

Once there are SoC variants that have different CPU cores, but with the 
remaining chip integration the same, I think it would make sense to move 
the CONFIG_SOC_ stuff out from ARM, RISC-V, etc., into something that's 
not CPU architecture-specific.  But for the time being, that seems 
premature.  Might as well have it be driven by an actual use-case.


- Paul