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.

> 
> If using the Goldfish code really is what we all want to do (see
> below), 
> then the kernel patch that should go in right away -- which also has
> no 
> dependence on what QEMU does -- would be the first patch of this
> series:
> 
> https://lore.kernel.org/linux-riscv/20190925063706.56175-2-anup.pa...@wdc.com/

Ok, so it looks like this patch will be a 5.5 patch not a 5.4 patch. It
looks like that can't be helped. I just don't want the defconfig change
waiting on QEMU as I think that just slows everything down.

> 
> And that should go in via whoever is maintaining the Goldfish driver,
> not 
> the RISC-V tree.  (It looks like drivers/platform/goldfish is
> completely 
> unmaintained - a red flag! - so probably someone needs to persuade
> Greg or 
> Andrew to take it.)
> 
> Incidentally, just looking at drivers/platform/goldfish, that driver
> seems 
> to be some sort of Google-specific RPC driver.  Are you all really
> sure 
> you want to enable that just for an RTC?  Seems like overkill - there
> are 
> much simpler RTCs out there.

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.

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

Alistair

> 
> 
> - Paul
> 
> _______________________________________________
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Reply via email to