[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFqH_534v=_LxwVVn51SXmeocggvYQVjzq2GOvFs=mm7A7qhkA@mail.gmail.com>
Date: Fri, 8 Feb 2019 18:15:04 +0100
From: Enric Balletbo Serra <eballetbo@...il.com>
To: Nick Crews <ncrews@...omium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
Benson Leung <bleung@...omium.org>,
Duncan Laurie <dlaurie@...gle.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
dlaurie@...omium.org, Dmitry Torokhov <dmitry.torokhov@...il.com>,
Guenter Roeck <groeck@...omium.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-rtc@...r.kernel.org, Simon Glass <sjg@...omium.org>
Subject: Re: [PATCH v6 4/4] platform/chrome: rtc: Add RTC driver
Hi Nick,
Missatge de Nick Crews <ncrews@...omium.org> del dia dv., 8 de febr.
2019 a les 17:10:
>
> Hi Enric and Alexandre,
>
> On Fri, Feb 8, 2019 at 5:18 AM Enric Balletbo i Serra
> <enric.balletbo@...labora.com> wrote:
> >
> > Hi,
> >
> > On 8/2/19 2:23, Nick Crews wrote:
> > > This Embedded Controller has an internal RTC that is exposed
> > > as a standard RTC class driver with read/write functionality.
> > >
> > > The driver is added to the drivers/rtc/ so that the maintainer of that
> > > directory will be able to comment on this change, as that maintainer is
> > > the expert on this system. In addition, the driver code is called
> > > indirectly after a corresponding device is registered from core.c,
> > > as opposed to core.c registering the driver callbacks directly.
> > >
> > > To test:
> > >> hwclock --show --rtc /dev/rtc1
> > > 2007-12-31 16:01:20.460959-08:00
> > >> hwclock --systohc --rtc /dev/rtc1
> > >> hwclock --show --rtc /dev/rtc1
> > > 2018-11-29 17:08:00.780793-08:00
> > >
> > >> hwclock --show --rtc /dev/rtc1
> > > 2007-12-31 16:01:20.460959-08:00
> > >> hwclock --systohc --rtc /dev/rtc1
> > >> hwclock --show --rtc /dev/rtc1
> > > 2018-11-29 17:08:00.780793-08:00
> > >
> > > Signed-off-by: Duncan Laurie <dlaurie@...gle.com>
> > > Signed-off-by: Nick Crews <ncrews@...omium.org>
> >
> > I think that you missed :)
> >
> > Acked-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
> > Acked-by: Alexandre Belloni <alexandre.belloni@...tlin.com>
> >
>
> Ah, I removed these because this version is a bit different from the
> one that you Acked. Do you normally keep those sign-offs
> even after making changes that you possibly might not like?
>
Well, it's right that you did a small change in the core, so to be
strict maybe you have reason, but I don't see as a big change so I
expected you maintain my tag. Anyway it's not a problem at all, just
that at least I expected the Alexandre ack :)
[snip]
> >
> > Alexandre, this specific patch depends on the patches of the series to apply,
> > and the first patches of the series also conflicts/depends on some patches
> > queued in chrome-platform-5.1 branch [1]. Is it fine with you if I create an
> > immutable branch and all go via your tree? Or what do you think? I am new here
> > and I am not sure how to manage that.
> >
> > Thanks,
> > Enric
>
> Let me know if I can help with this. I based this off what I thought was the
> most current master, SHA 74e96711e3379fc66630f2a1d184947f80cf2c48.
> Was this not the correct commit to base these off of?
>
Yeah, it's fine, just that I queued recently some changes and I have
trivial conflicts in Kconfig and Makefile, nothing that you need to
worry.
[snip]
Powered by blists - more mailing lists