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:   Wed, 23 Oct 2019 11:20:43 -0700 (PDT)
From:   Paul Walmsley <paul.walmsley@sifive.com>
To:     Alistair Francis <Alistair.Francis@wdc.com>
cc:     "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        Atish Patra <Atish.Patra@wdc.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "rkir@google.com" <rkir@google.com>,
        Anup Patel <Anup.Patel@wdc.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "hch@infradead.org" <hch@infradead.org>,
        "anup@brainfault.org" <anup@brainfault.org>,
        "palmer@sifive.com" <palmer@sifive.com>,
        "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v2 2/2] RISC-V: defconfig: Enable Goldfish RTC driver
In-Reply-To: <678b7a7a82adb389e34f023d282a7935f41e356a.camel@wdc.com>
Message-ID: <alpine.DEB.2.21.9999.1910231105170.16536@viisi.sifive.com>
References: <20190925063706.56175-3-anup.patel@wdc.com>  <mhng-edb410db-fdd1-46f6-84c3-ae3b843f7e3a@palmer-si-x1c4>  <MN2PR04MB606160F5306A5F3C5D97FB788D900@MN2PR04MB6061.namprd04.prod.outlook.com>  <alpine.DEB.2.21.9999.1910221213490.28831@viisi.sifive.com>
  <17db4a6244d09abf867daf2a6c10de6a5cd58c89.camel@wdc.com>  <alpine.DEB.2.21.9999.1910221751500.25457@viisi.sifive.com> <678b7a7a82adb389e34f023d282a7935f41e356a.camel@wdc.com>
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 Wed, 23 Oct 2019, Alistair Francis wrote:

> On Tue, 2019-10-22 at 18:06 -0700, Paul Walmsley wrote:
> > On Tue, 22 Oct 2019, Alistair Francis wrote:
> > 
> > > I think it makese sense for this to go into Linux first.
> > > 
> > > The QEMU patches are going to be accepted, just some nit picking to 
> > > do first :)
> > > 
> > > After that we have to wait for a PR and then a QEMU release until 
> > > most people will see the change in QEMU. In that time Linux 5.4 will 
> > > be released, if this can make it into 5.4 then everyone using 5.4 
> > > will get the new RTC as soon as they upgrade QEMU (QEMU provides the 
> > > device tree). If this has to wait until QEMU has support then it 
> > > won't be supported for users until even later.
> > > 
> > > Users are generally slow to update kernels (buildroot is still using 
> > > 5.1 by default for example) so the sooner changes like this go in 
> > > the better.
> > 
> > The defconfigs are really just for kernel developers.  We expect users 
> > to define their own Kconfigs for their own needs.
> 
> From experience most people use the defconfig, at least as a starting
> point.

We'll definitely add it to the defconfigs, but I think it makes sense to 
do that once the patches hit the QEMU master branch.  (No need to wait for 
a QEMU release.)

That roughly matches what I understand the Linux kernel's approach is to 
adding hardware support: no point in adding hardware support until it 
looks likely that it will actually exist.  Otherwise it just adds churn 
and maintenance burden.

> I was under the impression that everyone was on board with this going
> in. In QEMU land it doesn't make sense to add it if the kernel isn't
> going to, so we need to be on the same page here.

Whatever RTC gets added into QEMU, we'll take defconfig patches for.  I 
don't care which one it is.  Based on the patches that hit the kernel 
lists, it initially looked like the Goldfish RTC was more complicated than 
it needed to be; but it turned out I just didn't look deeply enough.

> From the other discussions it looks like you are happy with this change
> overall right?

Yes


- Paul