Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 8 Jun 2019 22:50:14 -0700 (PDT)
From:   Paul Walmsley <paul.walmsley@sifive.com>
To:     Palmer Dabbelt <palmer@sifive.com>
cc:     lollivier@baylibre.com, linux-kernel@vger.kernel.org,
        linux-riscv@lists.infradead.org, paul@pwsan.com,
        aou@eecs.berkeley.edu
Subject: Re: [PATCH v3 1/5] arch: riscv: add support for building DTB files
 from DT source data
In-Reply-To: <mhng-802d67ce-9f78-4ebc-9981-a27e5e4e40df@palmer-si-x1e>
Message-ID: <alpine.DEB.2.21.9999.1906082245300.720@viisi.sifive.com>
References: <mhng-802d67ce-9f78-4ebc-9981-a27e5e4e40df@palmer-si-x1e>
User-Agent: Alpine 2.21.9999 (DEB 301 2018-08-15)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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