Re: [PATCH 2/2] rtc: mt6397: expose the spare bytes of the alarm registers as nvmem

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

On 9/18/26 06:57, Ryan Brue wrote:
> Each alarm field lives in the low bits of its register and the driver
> masks its writes accordingly, so the high byte of four of them is storage
> the RTC never touches. MediaTek names these RTC_NEW_SPARE0 to
> RTC_NEW_SPARE3 and gives the first to a fuel gauge, which is how its PMIC
> battery drivers carry a state of charge over a reboot.
> 
> Offer all four as a battery-backed nvmem provider, so that a consumer does
> not have to reach into this block behind the driver's back. Doing it here
> is what makes it safe: a write lands under the same lock the alarm paths
> take, so it can neither be lost inside mtk_rtc_set_alarm()'s
> read-modify-write nor fire the write trigger in the middle of one.
> 
> The nvmem core does not range check a cell against the provider size, so
> the callbacks check the offset themselves.
> 
> Tested on an MT6397; MediaTek's spare map for mt6323 matches, and the
> alarm field masks are common to every compatible this driver binds.
> 
> Assisted-by: LLM
> Signed-off-by: Ryan Brue <ryanbrue.dev@gmail.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>