Hi Alexandre,
On Wed, Feb 15, 2023 at 05:51:20PM +0100, Johan Hovold wrote:
> On Sat, Feb 11, 2023 at 05:44:39PM +0100, Alexandre Belloni wrote:
> > On 11/02/2023 09:22:54+0100, Johan Hovold wrote:
> > > On Fri, Feb 10, 2023 at 11:48:08PM +0100, Alexandre Belloni wrote:
> > > > On 02/02/2023 16:54:42+0100, Johan Hovold wrote:
> > > > > On many Qualcomm platforms the PMIC RTC control and time registers are
> > > > > read-only so that the RTC time can not be updated. Instead an offset
> > > > > needs be stored in some machine-specific non-volatile memory, which a
> > > > > driver can take into account.
> > > > >
> > > > > Add an 'offset' nvmem cell which can be used to store a 32-bit offset
> > > > > from the Unix epoch so that the RTC time can be updated on such
> > > > > platforms.
> > > > >
> > > > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> > > > > Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx>
>
> > > > The patch doesn't apply because this part of the context is not
> > > > upstream. Can you rebase?
> > >
> > > Ah, sorry about that. That's because of commit 51b3802e7960
> > > ("dt-bindings: rtc: qcom-pm8xxx: allow 'wakeup-source' property") which
> > > is now in Linus's tree (and your rtc-fixes branch).
> > >
> > > Do you still want me to rebase or do you prefer to handle the conflict
> > > some other way?
> >
> > Ah yes, my bad, I'll merge rtc-fixes in rtc-next before applying
>
> Sorry about reminding so soon, but with the merge window approaching
> fast, will you be able to get this merged for 6.3?
Looks like these last two patches adding support for the nvmem offset
has not been applied yet. Still hoping you can get them merged for 6.3
even if this one does not apply cleanly unless you first merge your
rtc-fixes branch.
Johan
