* RE: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
From: T, Harini @ 2026-01-29 9:36 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-0-d4edb966b499@vaisala.com>
[Public]
The patch series looks fine to me.
Thanks,
Harini T
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 22, 2026 7:24 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>; T, Harini
> <Harini.T@amd.com>
> Subject: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values are now
> updated to match with expected.
>
> The RTC calibration value operates with full ticks, and fractional ticks which
> are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks and value
> matches the external oscillator in Hz. Through that, the maximum and
> minimum offset values can be calculated dynamically, as they depend on the
> input frequency used.
>
> For docs on the calibration register, see https://docs.amd.com/r/en-
> US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
>
> Due to rounding errors (different number of fract ticks), offset readback will
> differ slightly depending on if the offset is negative or positive. This is
> however well below the granularity provided by the hardware.
>
> For example
> $ echo 34335 > offset
> $ cat offset
> 34335
> $ echo -34335 > offset
> $ cat offset
> -34326
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> Changes in v4:
> - Do not limit building to zynqmp arch as building on other platforms
> might be needed. Implies dropping commit.
> - No need for RTC_PPB to be 64 bit value, use 32 bit instead
> - Link to v3: https://lore.kernel.org/r/20260119-zynqmp-rtc-updates-v3-0-
> acd902fdeab1@vaisala.com
>
> Changes in v3:
> - Add commit for limiting building of driver to zynqmp arch.
> - Reorder variable declarations in set_offset
> - Link to v2: https://lore.kernel.org/r/20260108-zynqmp-rtc-updates-v2-0-
> 864c161fa83d@vaisala.com
>
> Changes in v2:
> - Add commit introducing check for calibration value overflow
> - Update comments
> - Align data types across set and read
> - Rename fract_tick as fract_data conforming to data sheet
> - Further improve on set offset calculation logic
> - Link to v1: https://lore.kernel.org/r/20251201-zynqmp-rtc-updates-v1-0-
> 33875c1e385b@vaisala.com
>
> ---
> Tomas Melin (5):
> rtc: zynqmp: correct frequency value
> rtc: zynqmp: check calibration max value
> rtc: zynqmp: rework read_offset
> rtc: zynqmp: rework set_offset
> rtc: zynqmp: use dynamic max and min offset ranges
>
> drivers/rtc/rtc-zynqmp.c | 75 ++++++++++++++++++++++++++---------------------
> -
> 1 file changed, 41 insertions(+), 34 deletions(-)
> ---
> base-commit: cd635e33b0113287c94021be53d2a7c61a1614e9
> change-id: 20251201-zynqmp-rtc-updates-d260364cc01b
>
> Best regards,
> --
> Tomas Melin <tomas.melin@vaisala.com>
^ permalink raw reply
* Re: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
From: Michal Simek @ 2026-01-29 10:11 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Harini T
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-0-d4edb966b499@vaisala.com>
On 1/22/26 14:53, Tomas Melin wrote:
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values
> are now updated to match with expected.
>
> The RTC calibration value operates with full ticks,
> and fractional ticks which are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks
> and value matches the external oscillator in Hz. Through that,
> the maximum and minimum offset values can be calculated dynamically,
> as they depend on the input frequency used.
>
> For docs on the calibration register, see
> https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
>
> Due to rounding errors (different number of fract ticks),
> offset readback will differ slightly depending on
> if the offset is negative or positive. This is however well below the granularity
> provided by the hardware.
>
> For example
> $ echo 34335 > offset
> $ cat offset
> 34335
> $ echo -34335 > offset
> $ cat offset
> -34326
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> Changes in v4:
> - Do not limit building to zynqmp arch as building on other platforms
> might be needed. Implies dropping commit.
> - No need for RTC_PPB to be 64 bit value, use 32 bit instead
> - Link to v3: https://lore.kernel.org/r/20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com
>
> Changes in v3:
> - Add commit for limiting building of driver to zynqmp arch.
> - Reorder variable declarations in set_offset
> - Link to v2: https://lore.kernel.org/r/20260108-zynqmp-rtc-updates-v2-0-864c161fa83d@vaisala.com
>
> Changes in v2:
> - Add commit introducing check for calibration value overflow
> - Update comments
> - Align data types across set and read
> - Rename fract_tick as fract_data conforming to data sheet
> - Further improve on set offset calculation logic
> - Link to v1: https://lore.kernel.org/r/20251201-zynqmp-rtc-updates-v1-0-33875c1e385b@vaisala.com
>
> ---
> Tomas Melin (5):
> rtc: zynqmp: correct frequency value
> rtc: zynqmp: check calibration max value
> rtc: zynqmp: rework read_offset
> rtc: zynqmp: rework set_offset
> rtc: zynqmp: use dynamic max and min offset ranges
>
> drivers/rtc/rtc-zynqmp.c | 75 ++++++++++++++++++++++++++----------------------
> 1 file changed, 41 insertions(+), 34 deletions(-)
> ---
> base-commit: cd635e33b0113287c94021be53d2a7c61a1614e9
> change-id: 20251201-zynqmp-rtc-updates-d260364cc01b
>
> Best regards,
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 3/3] rtc: optee: simplify OP-TEE context match
From: Alexandre Belloni @ 2026-01-29 16:05 UTC (permalink / raw)
To: rouven.czerwinski
Cc: Jens Wiklander, Sumit Garg, Olivia Mackall, Herbert Xu,
Clément Léger, op-tee, linux-kernel, linux-crypto,
linux-rtc
In-Reply-To: <20260126-optee-simplify-context-match-v1-3-d4104e526cb6@linaro.org>
On 26/01/2026 11:11:26+0100, Rouven Czerwinski via B4 Relay wrote:
> From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
>
> Simplify the TEE implementor ID match by returning the boolean
> expression directly instead of going through an if/else.
>
> Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> ---
> drivers/rtc/rtc-optee.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
> index 184c6d142801..2f18be3de684 100644
> --- a/drivers/rtc/rtc-optee.c
> +++ b/drivers/rtc/rtc-optee.c
> @@ -541,10 +541,7 @@ static int optee_rtc_read_info(struct device *dev, struct rtc_device *rtc,
>
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> {
> - if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> - return 1;
> - else
> - return 0;
> + return (ver->impl_id == TEE_IMPL_ID_OPTEE);
I guess the correct way to do this would be:
return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);
But is this change actually generating better code?
Before:
static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
{
if (ver->impl_id == TEE_IMPL_ID_OPTEE)
0: e5900000 ldr r0, [r0]
return 1;
else
return 0;
}
4: e2400001 sub r0, r0, #1
8: e16f0f10 clz r0, r0
c: e1a002a0 lsr r0, r0, #5
10: e12fff1e bx lr
After:
static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
{
return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);
0: e5900000 ldr r0, [r0]
}
4: e2400001 sub r0, r0, #1
8: e16f0f10 clz r0, r0
c: e1a002a0 lsr r0, r0, #5
10: e12fff1e bx lr
I'm in favor of keeping the current version.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Thomas Bogendoerfer @ 2026-01-30 14:37 UTC (permalink / raw)
To: Brian Masney
Cc: Claudiu Beznea, linux-mips, linux-kernel, Michael Turquette,
Stephen Boyd, linux-clk, Thomas Gleixner, Adrian Hunter,
Ulf Hansson, linux-mmc, Linus Walleij, linux-gpio,
Alexandre Belloni, linux-rtc, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Guenter Roeck, Wim Van Sebroeck, linux-watchdog
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>
On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> There are currently some pic32 MIPS drivers that are in tree, and are
> only configured to be compiled on the MIPS pic32 platform. There's a
> risk of breaking some of these drivers when migrating drivers away from
> legacy APIs. It happened to me with a pic32 clk driver.
>
> Let's go ahead and move the pic32.h from the asm to the platform_data
> include directory in the tree. This will make it easier, and cleaner to
> enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> updating some includes, which I do at the beginning of this series.
>
> This series was compile tested on a centos-stream-10 arm64 host in two
> different configurations:
>
> - native arm64 build with COMPILE_TEST (via make allmodconfig)
> - MIPS cross compile on arm64 with:
> ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
>
> Note that there is a separate MIPS compile error in linux-next, and I
> reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
>
> I included a patch at the end that shows enabling COMPILE_TEST for a
> pic32 clk driver.
>
> Merge Strategy
> ==============
> - Patches 1-15 can go through the MIPS tree.
> - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> tree after the next merge window. There is a separate patch set that
> fixes a compiler error I unintentionally introduced via the clk tree.
> https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> Changes in v2:
> - Fix native MIPS build by updating include files
> - Link to v1: https://lore.kernel.org/r/20260109-mips-pic32-header-move-v1-0-99859c55783d@redhat.com
>
> ---
> Brian Masney (16):
> MIPS: pic32: include linux/io.h header on several files
> MIPS: pic32: include linux/types.h on pic32.h
> MIPS: pic32: drop unused include linux/io.h from pic32.h
> MIPS: copy pic32.h header file from asm/mach-pic32/ to include/platform-data/
> MAINTAINERS: add include/linux/platform_data/pic32.h to MIPS entry
> MIPS: update include to use pic32.h from platform_data
> clk: microchip: core: update include to use pic32.h from platform_data
> irqchip/irq-pic32-evic: update include to use pic32.h from platform_data
> mmc: sdhci-pic32: update include to use pic32.h from platform_data
> pinctrl: pic32: update include to use pic32.h from platform_data
> rtc: pic32: update include to use pic32.h from platform_data
> serial: pic32_uart: update include to use pic32.h from platform_data
> watchdog: pic32-dmt: update include to use pic32.h from platform_data
> watchdog: pic32-wdt: update include to use pic32.h from platform_data
> MIPS: drop unused pic32.h header
> clk: microchip: core: allow driver to be compiled with COMPILE_TEST
>
> MAINTAINERS | 1 +
> arch/mips/pic32/common/reset.c | 3 ++-
> arch/mips/pic32/pic32mzda/config.c | 3 +--
> arch/mips/pic32/pic32mzda/early_clk.c | 3 ++-
> arch/mips/pic32/pic32mzda/early_console.c | 3 ++-
> drivers/clk/microchip/Kconfig | 2 +-
> drivers/clk/microchip/clk-core.c | 6 +++++-
> drivers/irqchip/irq-pic32-evic.c | 2 +-
> drivers/mmc/host/sdhci-pic32.c | 2 +-
> drivers/pinctrl/pinctrl-pic32.c | 3 +--
> drivers/rtc/rtc-pic32.c | 3 +--
> drivers/tty/serial/pic32_uart.c | 3 +--
> drivers/watchdog/pic32-dmt.c | 3 +--
> drivers/watchdog/pic32-wdt.c | 3 +--
> .../mach-pic32 => include/linux/platform_data}/pic32.h | 17 ++++++++++-------
> 15 files changed, 31 insertions(+), 26 deletions(-)
> ---
> base-commit: f417b7ffcbef7d76b0d8860518f50dae0e7e5eda
> change-id: 20260109-mips-pic32-header-move-6ac9965aa70a
series applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 3/3] rtc: optee: simplify OP-TEE context match
From: Rouven Czerwinski @ 2026-01-30 15:03 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Jens Wiklander, Sumit Garg, Olivia Mackall, Herbert Xu,
Clément Léger, op-tee, linux-kernel, linux-crypto,
linux-rtc
In-Reply-To: <202601291605277bc279f4@mail.local>
Hi Alexandre,
On Thu, 2026-01-29 at 17:05 +0100, Alexandre Belloni wrote:
> On 26/01/2026 11:11:26+0100, Rouven Czerwinski via B4 Relay wrote:
> > From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> >
> > Simplify the TEE implementor ID match by returning the boolean
> > expression directly instead of going through an if/else.
> >
> > Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> > ---
> > drivers/rtc/rtc-optee.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
> > index 184c6d142801..2f18be3de684 100644
> > --- a/drivers/rtc/rtc-optee.c
> > +++ b/drivers/rtc/rtc-optee.c
> > @@ -541,10 +541,7 @@ static int optee_rtc_read_info(struct device
> > *dev, struct rtc_device *rtc,
> >
> > static int optee_ctx_match(struct tee_ioctl_version_data *ver,
> > const void *data)
> > {
> > - if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> > - return 1;
> > - else
> > - return 0;
> > + return (ver->impl_id == TEE_IMPL_ID_OPTEE);
>
> I guess the correct way to do this would be:
>
> return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);
Could you explain why? If I read the standard correctly, an equality
operation always produces either 1 or 0, so there should be no need for
!! here like there is for bit flag comparisons, i.e. !!(flag &
SOME_FLAG_SET) to normalize to 1 or 0. Wondering if I am missing
something.
> But is this change actually generating better code?
>
> Before:
>
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const
> void *data)
> {
> if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> 0: e5900000 ldr r0, [r0]
> return 1;
> else
> return 0;
> }
> 4: e2400001 sub r0, r0, #1
> 8: e16f0f10 clz r0, r0
> c: e1a002a0 lsr r0, r0, #5
> 10: e12fff1e bx lr
>
> After:
>
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const
> void *data)
> {
> return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);
> 0: e5900000 ldr r0, [r0]
> }
> 4: e2400001 sub r0, r0, #1
> 8: e16f0f10 clz r0, r0
> c: e1a002a0 lsr r0, r0, #5
> 10: e12fff1e bx lr
>
> I'm in favor of keeping the current version.
I like the short version better, but I am also not very attached to
getting this in at all, I'll let the maintainers decide.
Thanks and best regards,
Rouven
^ permalink raw reply
* Re: (subset) [PATCH v1 06/10] dt-bindings: rtc: cpcap-rtc: convert to schema
From: Alexandre Belloni @ 2026-01-30 22:59 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, Svyatoslav Ryhel
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-7-clamor95@gmail.com>
On Sun, 25 Jan 2026 15:42:58 +0200, Svyatoslav Ryhel wrote:
> Convert RTC devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
>
>
Applied, thanks!
[06/10] dt-bindings: rtc: cpcap-rtc: convert to schema
https://git.kernel.org/abelloni/c/96a77ec577d4
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
From: Alexandre Belloni @ 2026-01-30 22:59 UTC (permalink / raw)
To: Michal Simek, Tomas Melin
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Harini T
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-0-d4edb966b499@vaisala.com>
On Thu, 22 Jan 2026 13:53:44 +0000, Tomas Melin wrote:
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values
> are now updated to match with expected.
>
> The RTC calibration value operates with full ticks,
> and fractional ticks which are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks
> and value matches the external oscillator in Hz. Through that,
> the maximum and minimum offset values can be calculated dynamically,
> as they depend on the input frequency used.
>
> [...]
Applied, thanks!
[1/5] rtc: zynqmp: correct frequency value
https://git.kernel.org/abelloni/c/2724fb4d429c
[2/5] rtc: zynqmp: check calibration max value
https://git.kernel.org/abelloni/c/83b9e5eb0437
[3/5] rtc: zynqmp: rework read_offset
https://git.kernel.org/abelloni/c/0f9989443fae
[4/5] rtc: zynqmp: rework set_offset
https://git.kernel.org/abelloni/c/9f5af70268d6
[5/5] rtc: zynqmp: use dynamic max and min offset ranges
https://git.kernel.org/abelloni/c/2254383176fc
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH 3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
From: Alexandre Belloni @ 2026-01-30 23:15 UTC (permalink / raw)
To: claudiu.beznea.uj, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
Ovidiu Panait
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-4-ovidiu.panait.rb@renesas.com>
On Sun, 25 Jan 2026 19:27:03 +0000, Ovidiu Panait wrote:
> The Renesas RZ/V2N (r9a09g056) RTC is identical to the RZ/V2H
> (r9a09g057) variant. Add the compatible string for RZ/V2N and
> extend the existing RZ/V2H reset configuration to cover both
> variants.
>
>
Applied, thanks!
[3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
https://git.kernel.org/abelloni/c/f3ac75cfacc6
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 0/3] RTC: Add Loongson-2K0300 support
From: Alexandre Belloni @ 2026-01-30 23:16 UTC (permalink / raw)
To: Binbin Zhou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rtc, Huacai Chen, Binbin Zhou
Cc: Xiaochuang Mao, Huacai Chen, Xuerui Wang, loongarch, devicetree,
linux-mips, Keguang Zhang
In-Reply-To: <cover.1768616276.git.zhoubinbin@loongson.cn>
On Sat, 17 Jan 2026 10:26:47 +0800, Binbin Zhou wrote:
> This patch set introduces the Loongson-2K0300 RTC, which has a similar
> hardware design to the Loongson-1B, but without the alarm feature.
>
> Thanks.
> Binbin
>
> ==========
> V3:
> - Add Reviewed-by tag from Huacai, thanks.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
https://git.kernel.org/abelloni/c/da9934a6583a
[2/3] dt-bindings: rtc: loongson: Document Loongson-2K0300 compatible
https://git.kernel.org/abelloni/c/5d4899d4859f
[3/3] rtc: loongson: Add Loongson-2K0300 support
https://git.kernel.org/abelloni/c/770a54accf80
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 3/4] rtc: ds1307: Add Driver for Epson RX8901CE
From: Alexandre Belloni @ 2026-01-31 0:03 UTC (permalink / raw)
To: Fredrik M Olsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20251219-ds1307-rx8901-add-v1-3-b13f346ebe93@axis.com>
Hello,
On 19/12/2025 13:10:37+0100, Fredrik M Olsson wrote:
> #define MCP794XX_REG_CONTROL 0x07
> # define MCP794XX_BIT_ALM0_EN 0x10
> # define MCP794XX_BIT_ALM1_EN 0x20
> @@ -226,6 +233,19 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
> dev_warn_once(dev, "oscillator failed, set time!\n");
> return -EINVAL;
> }
> + } else if (ds1307->type == rx_8901) {
> + unsigned int regflag;
> +
> + ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
> + if (ret) {
> + dev_err(dev, "%s error %d\n", "read", ret);
The multiple dev_err you are adding should be dev_dbg as there is no
other actions for the user than to restart the operation when it fails
so there is not actual value apart when debugging.
> + return ret;
> + }
> +
> + if (regflag & RX8901_REG_INTF_VLF) {
> + dev_warn_once(dev, "oscillator failed, set time!\n");
> + return -EINVAL;
> + }
> }
>
> /* read the RTC date and time registers all at once */
> @@ -307,7 +327,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
> tmp = regs[DS1307_REG_HOUR] & 0x3f;
> t->tm_hour = bcd2bin(tmp);
> /* rx8130 is bit position, not BCD */
> - if (ds1307->type == rx_8130)
> + if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
> t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f) - 1;
> else
> t->tm_wday = bcd2bin(regs[DS1307_REG_WDAY] & 0x07) - 1;
> @@ -358,7 +378,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
> regs[DS1307_REG_MIN] = bin2bcd(t->tm_min);
> regs[DS1307_REG_HOUR] = bin2bcd(t->tm_hour);
> /* rx8130 is bit position, not BCD */
> - if (ds1307->type == rx_8130)
> + if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
> regs[DS1307_REG_WDAY] = 1 << t->tm_wday;
> else
> regs[DS1307_REG_WDAY] = bin2bcd(t->tm_wday + 1);
> @@ -422,6 +442,17 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
> dev_err(dev, "%s error %d\n", "write", result);
> return result;
> }
> + } else if (ds1307->type == rx_8901) {
> + /*
> + * clear Voltage Loss Flag as data is available now (writing 1
> + * to the other bits in the INTF register has no effect)
> + */
> + result = regmap_write(ds1307->regmap, RX8901_REG_INTF,
> + 0xff ^ RX8901_REG_INTF_VLF);
> + if (result) {
> + dev_err(dev, "%s error %d\n", "write", result);
> + return result;
> + }
> }
>
> return 0;
> @@ -568,6 +599,17 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
> return setup;
> }
>
> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
> +{
> + /* make sure that the backup battery is enabled */
> + u8 setup = RX8901_REG_PWSW_CFG_INIEN;
You can't do this as this will cause issues in the future for people
wanting to keep this bit disabled (the main reason being that you don't
want to draw power from the battery while your device sits on a shelf).
You have to handle the RTC_PARAM_BACKUP_SWITCH_MODE parameter and then
switch it from userspace.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 4/4] rtc: ds1307: Add support for reading RX8901CE battery VL status
From: Alexandre Belloni @ 2026-01-31 0:05 UTC (permalink / raw)
To: Fredrik M Olsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20251219-ds1307-rx8901-add-v1-4-b13f346ebe93@axis.com>
On 19/12/2025 13:10:38+0100, Fredrik M Olsson wrote:
> Adds support for:
> - Reading the battery voltage low status using the RTC_VL_READ ioctl,
> which also reports invalid time information if the VLF flag is set.
>
> Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
> ---
> drivers/rtc/rtc-ds1307.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index 99d95e520108..ca062ed0c867 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -133,8 +133,11 @@ enum ds_type {
> #define RX8901_REG_INTF 0x0e
> #define RX8901_REG_INTF_VLF BIT(1)
> #define RX8901_REG_PWSW_CFG 0x37
> +#define RX8901_REG_PWSW_CFG_VBATLDETEN BIT(4)
> #define RX8901_REG_PWSW_CFG_INIEN BIT(6)
> #define RX8901_REG_PWSW_CFG_CHGEN BIT(7)
> +#define RX8901_REG_BUF_INTF 0x46
> +#define RX8901_REG_BUF_INTF_VBATLF BIT(3)
>
> #define MCP794XX_REG_CONTROL 0x07
> # define MCP794XX_BIT_ALM0_EN 0x10
> @@ -458,6 +461,39 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
> return 0;
> }
>
> +#ifdef CONFIG_RTC_INTF_DEV
> +static int rx8901_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)
> +{
> + struct ds1307 *ds1307 = dev_get_drvdata(dev);
> + unsigned int regflag, tmp = 0;
> + int ret = 0;
> +
> + switch (cmd) {
> + case RTC_VL_READ:
> + ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
> + if (ret)
> + return ret;
> +
> + if (regflag & RX8901_REG_INTF_VLF)
> + tmp |= RTC_VL_DATA_INVALID;
> +
> + ret = regmap_read(ds1307->regmap, RX8901_REG_BUF_INTF, ®flag);
> + if (ret)
> + return ret;
> +
> + if (regflag & RX8901_REG_BUF_INTF_VBATLF)
> + tmp |= RTC_VL_BACKUP_LOW;
> +
> + return put_user(tmp, (unsigned int __user *)arg);
> + default:
> + return -ENOIOCTLCMD;
> + }
> + return ret;
> +}
> +#else
> +#define rx8901_ioctl NULL
> +#endif
> +
> static int ds1337_read_alarm(struct device *dev, struct rtc_wkalrm *t)
> {
> struct ds1307 *ds1307 = dev_get_drvdata(dev);
> @@ -599,10 +635,13 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
> return setup;
> }
>
> -static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms __always_unused, bool diode)
> {
> - /* make sure that the backup battery is enabled */
> - u8 setup = RX8901_REG_PWSW_CFG_INIEN;
> + /*
> + * make sure that the backup battery is enabled and that battery
> + * voltage detection is performed
> + */
> + u8 setup = RX8901_REG_PWSW_CFG_INIEN | RX8901_REG_PWSW_CFG_VBATLDETEN;
>
> if (diode)
> setup |= RX8901_REG_PWSW_CFG_CHGEN;
> @@ -1005,6 +1044,7 @@ static const struct rtc_class_ops rx8130_rtc_ops = {
> static const struct rtc_class_ops rx8901_rtc_ops = {
> .read_time = ds1307_get_time,
> .set_time = ds1307_set_time,
> + .ioctl = rx8901_ioctl,
> };
>
This seems to be an unrelated changed that hasn't been squashed in the
proper patch.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: David Lechner @ 2026-01-31 19:46 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-2-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> from TXT to YAML format. Main functionality preserved and added compatible
> for CPCAP regulator set found in the Mot board.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> .../regulator/motorola,cpcap-regulator.yaml | 51 +++++++++++++++++++
> 2 files changed, 51 insertions(+), 35 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> deleted file mode 100644
> index 36f5e2f5cc0f..000000000000
> --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -Motorola CPCAP PMIC voltage regulators
> -------------------------------------
> -
> -Requires node properties:
> -- "compatible" value one of:
> - "motorola,cpcap-regulator"
> - "motorola,mapphone-cpcap-regulator"
> - "motorola,xoom-cpcap-regulator"
> -
> -Required regulator properties:
> -- "regulator-name"
> -- "regulator-enable-ramp-delay"
> -- "regulator-min-microvolt"
> -- "regulator-max-microvolt"
> -
> -Optional regulator properties:
> -- "regulator-boot-on"
> -
> -See Documentation/devicetree/bindings/regulator/regulator.txt
> -for more details about the regulator properties.
> -
> -Example:
> -
> -cpcap_regulator: regulator {
> - compatible = "motorola,cpcap-regulator";
> -
> - cpcap_regulators: regulators {
> - sw5: SW5 {
Old example is missing the required regulator-names property.
> - regulator-min-microvolt = <5050000>;
> - regulator-max-microvolt = <5050000>;
> - regulator-enable-ramp-delay = <50000>;
> - regulator-boot-on;
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> new file mode 100644
> index 000000000000..b73d32a86904
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC regulators
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> + regulator controller is represented as a sub-node of the PMIC node
> + on the device tree.
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap-regulator
> + - motorola,mapphone-cpcap-regulator
> + - motorola,mot-cpcap-regulator
> + - motorola,xoom-cpcap-regulator
> +
> + regulators:
> + type: object
> +
> + patternProperties:
> + "$[A-Z0-9]+^":
Why not put the valid names here? Or does the node name not actually matter?
(in which case lower case could be allowed too.)
"^(SW1|SW2|...)$":
And $,^ are swapped.
> + $ref: /schemas/regulator/regulator.yaml#
> + type: object
> + description:
> + Valid regulator names are SW1, SW2, SW3, SW4, SW5, VCAM, VCSI,
> + VDAC, VDIG, VFUSE, VHVIO, VSDIO, VPLL, VRF1, VRF2, VRFREF, VWLAN1,
> + VWLAN2, VSIM, VSIMCARD, VVIB, VUSB, VAUDIO
> +
If these apply to the regulator-name property, it can be written instead as:
properties:
regulator-name:
enum:
- SW1
- SW2
...
Not sure if it is strictly needed, but this would document the optional
property:
regulator-boot-on: true
> + required:
> + - regulator-name
> + - regulator-enable-ramp-delay
> + - regulator-min-microvolt
> + - regulator-max-microvolt
> +
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
Example should go here.
> +...
^ permalink raw reply
* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: David Lechner @ 2026-01-31 19:48 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-4-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Add compatible for ADC used in Mot board. Separate compatible is required
> since ADC in the Mot board uses a unique set of configurations.
>
Logically, it makes more sense to readers to put the DT binding patch
before the driver change in the series.
^ permalink raw reply
* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: David Lechner @ 2026-01-31 19:50 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <92858c73-1e11-4283-8ab6-1188e8bae0df@baylibre.com>
On 1/31/26 1:48 PM, David Lechner wrote:
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
>> Add compatible for ADC used in Mot board. Separate compatible is required
>> since ADC in the Mot board uses a unique set of configurations.
>>
> Logically, it makes more sense to readers to put the DT binding patch
> before the driver change in the series.
OK, I didn't read carefully enough that there are multiple devices
in this series. So you already did what I suggested. :-)
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: David Lechner @ 2026-01-31 19:55 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <d7938728-fded-4d5e-b23d-a8346e3fab46@baylibre.com>
On 1/31/26 1:46 PM, David Lechner wrote:
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
>> from TXT to YAML format. Main functionality preserved and added compatible
>> for CPCAP regulator set found in the Mot board.
>>
...
>> +properties:
>> + compatible:
>> + enum:
>> + - motorola,cpcap-regulator
>> + - motorola,mapphone-cpcap-regulator
>> + - motorola,mot-cpcap-regulator
This is what caused me to get confused on the order of the later patches.
motorola,mot-cpcap-regulator is a new compatible, so would be better as
a separate patch.
^ permalink raw reply
* Re: [PATCH v1 05/10] dt-bindings: leds: leds-cpcap: convert to schema
From: David Lechner @ 2026-01-31 19:59 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-6-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert leds devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/leds/leds-cpcap.txt | 29 -------------
> .../bindings/leds/motorola,cpcap-leds.yaml | 42 +++++++++++++++++++
> 2 files changed, 42 insertions(+), 29 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
> create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> deleted file mode 100644
> index ebf7cdc7f70c..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Motorola CPCAP PMIC LEDs
> -------------------------
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -Requires node properties:
> -- compatible: should be one of
> - * "motorola,cpcap-led-mdl" (Main Display Lighting)
> - * "motorola,cpcap-led-kl" (Keyboard Lighting)
> - * "motorola,cpcap-led-adl" (Aux Display Lighting)
> - * "motorola,cpcap-led-red" (Red Triode)
> - * "motorola,cpcap-led-green" (Green Triode)
> - * "motorola,cpcap-led-blue" (Blue Triode)
> - * "motorola,cpcap-led-cf" (Camera Flash)
> - * "motorola,cpcap-led-bt" (Bluetooth)
> - * "motorola,cpcap-led-cp" (Camera Privacy LED)
> -- label: see Documentation/devicetree/bindings/leds/common.txt
> -- vdd-supply: A phandle to the regulator powering the LED
> -
> -Example:
> -
> -&cpcap {
> - cpcap_led_red: red-led {
> - compatible = "motorola,cpcap-led-red";
> - label = "cpcap:red";
> - vdd-supply = <&sw5>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> new file mode 100644
> index 000000000000..8dfc98a1ef99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC leds
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. Leds are
s/Leds/LEDs/
> + represented as sub-nodes of the PMIC node on the device tree.
> +
> +allOf:
> + - $ref: /schemas/leds/common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap-led-adl # Display Lighting
> + - motorola,cpcap-led-blue # Blue Triode
> + - motorola,cpcap-led-bt # Bluetooth
> + - motorola,cpcap-led-cf # Camera Flash
> + - motorola,cpcap-led-cp # Camera Privacy LED
> + - motorola,cpcap-led-green # Green Triode
> + - motorola,cpcap-led-kl # Keyboard Lighting
> + - motorola,cpcap-led-mdl # Main Display Lighting
> + - motorola,cpcap-led-red # Red Triode
> +
> + vdd-supply: true
> +
> +required:
> + - compatible
> + - label
> + - vdd-supply
> +
> +unevaluatedProperties: false
> +
Should keep the example here.
> +...
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: David Lechner @ 2026-01-31 20:02 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-8-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert power button devicetree bindings for the Motorola CPCAP MFD from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> 2 files changed, 32 insertions(+), 20 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> deleted file mode 100644
> index 0dd0076daf71..000000000000
> --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -Motorola CPCAP on key
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -This module provides a simple power button event via an Interrupt.
> -
> -Required properties:
> -- compatible: should be one of the following
> - - "motorola,cpcap-pwrbutton"
> -- interrupts: irq specifier for CPCAP's ON IRQ
> -
> -Example:
> -
> -&cpcap {
> - cpcap_pwrbutton: pwrbutton {
> - compatible = "motorola,cpcap-pwrbutton";
> - interrupts = <23 IRQ_TYPE_NONE>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> new file mode 100644
> index 000000000000..643f6b2b1f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC power key
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> + power key is represented as a sub-node of the PMIC node on the device
> + tree.
> +
> +properties:
> + compatible:
> + const: motorola,cpcap-pwrbutton
> +
> + interrupts:
> + minItems: 1
Should this be maxItems: 1?
> + description: CPCAP's ON interrupt
Or I suppose:
items:
- description: ...
> +
> +required:
> + - compatible
> + - interrupts
> +
> +additionalProperties: false
> +
example: ...
> +...
^ permalink raw reply
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: David Lechner @ 2026-01-31 20:07 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-9-clamor95@gmail.com>
On 1/25/26 7:43 AM, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> Audio codec bindings adjusted with common ports node for port@0 and
> port@1. Added compatible for Mot board CPCAP. Other bindings remain the
> same.
>
...
> +examples:
Ah, I guess this covers all of the missing examples. The other commit
messages should say that was the plan so we know why the examples were
omitted in the other patches.
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:01 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <d7938728-fded-4d5e-b23d-a8346e3fab46@baylibre.com>
сб, 31 січ. 2026 р. о 21:46 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> > from TXT to YAML format. Main functionality preserved and added compatible
> > for CPCAP regulator set found in the Mot board.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> > .../regulator/motorola,cpcap-regulator.yaml | 51 +++++++++++++++++++
> > 2 files changed, 51 insertions(+), 35 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > deleted file mode 100644
> > index 36f5e2f5cc0f..000000000000
> > --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > +++ /dev/null
> > @@ -1,35 +0,0 @@
> > -Motorola CPCAP PMIC voltage regulators
> > -------------------------------------
> > -
> > -Requires node properties:
> > -- "compatible" value one of:
> > - "motorola,cpcap-regulator"
> > - "motorola,mapphone-cpcap-regulator"
> > - "motorola,xoom-cpcap-regulator"
> > -
> > -Required regulator properties:
> > -- "regulator-name"
> > -- "regulator-enable-ramp-delay"
> > -- "regulator-min-microvolt"
> > -- "regulator-max-microvolt"
> > -
> > -Optional regulator properties:
> > -- "regulator-boot-on"
> > -
> > -See Documentation/devicetree/bindings/regulator/regulator.txt
> > -for more details about the regulator properties.
> > -
> > -Example:
> > -
> > -cpcap_regulator: regulator {
> > - compatible = "motorola,cpcap-regulator";
> > -
> > - cpcap_regulators: regulators {
> > - sw5: SW5 {
>
> Old example is missing the required regulator-names property.
>
> > - regulator-min-microvolt = <5050000>;
> > - regulator-max-microvolt = <5050000>;
> > - regulator-enable-ramp-delay = <50000>;
> > - regulator-boot-on;
> > - };
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > new file mode 100644
> > index 000000000000..b73d32a86904
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola CPCAP PMIC regulators
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + This module is part of the Motorola CPCAP MFD device. For more details
> > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > + regulator controller is represented as a sub-node of the PMIC node
> > + on the device tree.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - motorola,cpcap-regulator
> > + - motorola,mapphone-cpcap-regulator
> > + - motorola,mot-cpcap-regulator
> > + - motorola,xoom-cpcap-regulator
> > +
> > + regulators:
> > + type: object
> > +
> > + patternProperties:
> > + "$[A-Z0-9]+^":
>
> Why not put the valid names here? Or does the node name not actually matter?
> (in which case lower case could be allowed too.)
>
> "^(SW1|SW2|...)$":
>
> And $,^ are swapped.
>
This is an interesting suggestion, maybe schema maintainers can
suggest how to approach this? Node name and case matters, list of
possible names is in the description.
> > + $ref: /schemas/regulator/regulator.yaml#
> > + type: object
> > + description:
> > + Valid regulator names are SW1, SW2, SW3, SW4, SW5, VCAM, VCSI,
> > + VDAC, VDIG, VFUSE, VHVIO, VSDIO, VPLL, VRF1, VRF2, VRFREF, VWLAN1,
> > + VWLAN2, VSIM, VSIMCARD, VVIB, VUSB, VAUDIO
> > +
>
> If these apply to the regulator-name property, it can be written instead as:
>
Regulator name does not matter, any name is acceptible.
> properties:
> regulator-name:
> enum:
> - SW1
> - SW2
> ...
>
>
> Not sure if it is strictly needed, but this would document the optional
> property:
>
> regulator-boot-on: true
>
this is covered by common regulator schema, along with other possible
regulator properties
> > + required:
> > + - regulator-name
> > + - regulator-enable-ramp-delay
> > + - regulator-min-microvolt
> > + - regulator-max-microvolt
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > +
> > +additionalProperties: false
> > +
>
> Example should go here.
>
> > +...
>
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:01 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <8cedbb9c-9f72-43ae-a23e-705b3feb85fb@baylibre.com>
сб, 31 січ. 2026 р. о 21:55 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/31/26 1:46 PM, David Lechner wrote:
> > On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> >> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> >> from TXT to YAML format. Main functionality preserved and added compatible
> >> for CPCAP regulator set found in the Mot board.
> >>
>
> ...
>
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - motorola,cpcap-regulator
> >> + - motorola,mapphone-cpcap-regulator
> >> + - motorola,mot-cpcap-regulator
>
> This is what caused me to get confused on the order of the later patches.
>
> motorola,mot-cpcap-regulator is a new compatible, so would be better as
> a separate patch.
>
Rob already cleared this up
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:07 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <8bd89524-dfc3-43b0-b0f2-cdb1cd51e1ac@baylibre.com>
сб, 31 січ. 2026 р. о 22:02 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > Convert power button devicetree bindings for the Motorola CPCAP MFD from
> > TXT to YAML format. This patch does not change any functionality; the
> > bindings remain the same.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> > .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> > 2 files changed, 32 insertions(+), 20 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > deleted file mode 100644
> > index 0dd0076daf71..000000000000
> > --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > +++ /dev/null
> > @@ -1,20 +0,0 @@
> > -Motorola CPCAP on key
> > -
> > -This module is part of the CPCAP. For more details about the whole
> > -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> > -
> > -This module provides a simple power button event via an Interrupt.
> > -
> > -Required properties:
> > -- compatible: should be one of the following
> > - - "motorola,cpcap-pwrbutton"
> > -- interrupts: irq specifier for CPCAP's ON IRQ
> > -
> > -Example:
> > -
> > -&cpcap {
> > - cpcap_pwrbutton: pwrbutton {
> > - compatible = "motorola,cpcap-pwrbutton";
> > - interrupts = <23 IRQ_TYPE_NONE>;
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > new file mode 100644
> > index 000000000000..643f6b2b1f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > @@ -0,0 +1,32 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola CPCAP PMIC power key
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + This module is part of the Motorola CPCAP MFD device. For more details
> > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > + power key is represented as a sub-node of the PMIC node on the device
> > + tree.
> > +
> > +properties:
> > + compatible:
> > + const: motorola,cpcap-pwrbutton
> > +
> > + interrupts:
> > + minItems: 1
>
> Should this be maxItems: 1?
>
> > + description: CPCAP's ON interrupt
>
> Or I suppose:
>
> items:
> - description: ...
>
Both options are perfectly fine for me, and I lean towards using
"items: desc" but I would like to hear what schema maintainers would
say, which layout is preferred in this case.
>
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > +
> > +additionalProperties: false
> > +
>
> example: ...
>
> > +...
>
^ permalink raw reply
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:09 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <fca2c04b-fe1c-4685-9c80-b0d7d37ced60@baylibre.com>
сб, 31 січ. 2026 р. о 22:07 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:43 AM, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> > Audio codec bindings adjusted with common ports node for port@0 and
> > port@1. Added compatible for Mot board CPCAP. Other bindings remain the
> > same.
> >
>
> ...
>
> > +examples:
>
> Ah, I guess this covers all of the missing examples. The other commit
> messages should say that was the plan so we know why the examples were
> omitted in the other patches.
>
Subdevices schema state that they are part of MFD and link to the main
MFD schema. MFD device description mandates to have a complete device
example so having examples for each subdevice is redundant.
^ permalink raw reply
* Re: [PATCH 3/4] rtc: ds1307: Add Driver for Epson RX8901CE
From: Fredrik M Olsson @ 2026-02-03 14:23 UTC (permalink / raw)
To: Alexandre Belloni, Fredrik M Olsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20260131000350d1fac76c@mail.local>
On 1/31/26 01:03, Alexandre Belloni wrote:
> [Some people who received this message don't often get email from alexandre.belloni@bootlin.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello,
>
> On 19/12/2025 13:10:37+0100, Fredrik M Olsson wrote:
>> #define MCP794XX_REG_CONTROL 0x07
>> # define MCP794XX_BIT_ALM0_EN 0x10
>> # define MCP794XX_BIT_ALM1_EN 0x20
>> @@ -226,6 +233,19 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
>> dev_warn_once(dev, "oscillator failed, set time!\n");
>> return -EINVAL;
>> }
>> + } else if (ds1307->type == rx_8901) {
>> + unsigned int regflag;
>> +
>> + ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
>> + if (ret) {
>> + dev_err(dev, "%s error %d\n", "read", ret);
>
> The multiple dev_err you are adding should be dev_dbg as there is no
> other actions for the user than to restart the operation when it fails
> so there is not actual value apart when debugging.
>
Okay thanks I will update that for v2.
>> + return ret;
>> + }
>> +
>> + if (regflag & RX8901_REG_INTF_VLF) {
>> + dev_warn_once(dev, "oscillator failed, set time!\n");
>> + return -EINVAL;
>> + }
>> }
>>
>> /* read the RTC date and time registers all at once */
>> @@ -307,7 +327,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
>> tmp = regs[DS1307_REG_HOUR] & 0x3f;
>> t->tm_hour = bcd2bin(tmp);
>> /* rx8130 is bit position, not BCD */
>> - if (ds1307->type == rx_8130)
>> + if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
>> t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f) - 1;
>> else
>> t->tm_wday = bcd2bin(regs[DS1307_REG_WDAY] & 0x07) - 1;
>> @@ -358,7 +378,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>> regs[DS1307_REG_MIN] = bin2bcd(t->tm_min);
>> regs[DS1307_REG_HOUR] = bin2bcd(t->tm_hour);
>> /* rx8130 is bit position, not BCD */
>> - if (ds1307->type == rx_8130)
>> + if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
>> regs[DS1307_REG_WDAY] = 1 << t->tm_wday;
>> else
>> regs[DS1307_REG_WDAY] = bin2bcd(t->tm_wday + 1);
>> @@ -422,6 +442,17 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>> dev_err(dev, "%s error %d\n", "write", result);
>> return result;
>> }
>> + } else if (ds1307->type == rx_8901) {
>> + /*
>> + * clear Voltage Loss Flag as data is available now (writing 1
>> + * to the other bits in the INTF register has no effect)
>> + */
>> + result = regmap_write(ds1307->regmap, RX8901_REG_INTF,
>> + 0xff ^ RX8901_REG_INTF_VLF);
>> + if (result) {
>> + dev_err(dev, "%s error %d\n", "write", result);
>> + return result;
>> + }
>> }
>>
>> return 0;
>> @@ -568,6 +599,17 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
>> return setup;
>> }
>>
>> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
>> +{
>> + /* make sure that the backup battery is enabled */
>> + u8 setup = RX8901_REG_PWSW_CFG_INIEN;
>
> You can't do this as this will cause issues in the future for people
> wanting to keep this bit disabled (the main reason being that you don't
> want to draw power from the battery while your device sits on a shelf).
> You have to handle the RTC_PARAM_BACKUP_SWITCH_MODE parameter and then
> switch it from userspace.
Here my intention was to do something similar to what was done before
for the rx8130 device [1], which as I understand it require similar
setup initialization as the rx8901 device does. Is using the
RTC_PARAM_BACKUP_SWITCH_MODE the new way of performing this initialization?
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
[1] 0026f1604c9b (rtc: ds1307: enable rx8130's backup battery, make it
chargeable optionally)
--
/Fredrik
^ permalink raw reply
* Re: [PATCH 4/4] rtc: ds1307: Add support for reading RX8901CE battery VL status
From: Fredrik M Olsson @ 2026-02-03 14:26 UTC (permalink / raw)
To: Alexandre Belloni, Fredrik M Olsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20260131000549071abafa@mail.local>
On 1/31/26 01:05, Alexandre Belloni wrote:
> [Some people who received this message don't often get email from alexandre.belloni@bootlin.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On 19/12/2025 13:10:38+0100, Fredrik M Olsson wrote:
>> Adds support for:
>> - Reading the battery voltage low status using the RTC_VL_READ ioctl,
>> which also reports invalid time information if the VLF flag is set.
>>
>> Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
>> ---
>> drivers/rtc/rtc-ds1307.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
>> index 99d95e520108..ca062ed0c867 100644
>> --- a/drivers/rtc/rtc-ds1307.c
>> +++ b/drivers/rtc/rtc-ds1307.c
>> @@ -133,8 +133,11 @@ enum ds_type {
>> #define RX8901_REG_INTF 0x0e
>> #define RX8901_REG_INTF_VLF BIT(1)
>> #define RX8901_REG_PWSW_CFG 0x37
>> +#define RX8901_REG_PWSW_CFG_VBATLDETEN BIT(4)
>> #define RX8901_REG_PWSW_CFG_INIEN BIT(6)
>> #define RX8901_REG_PWSW_CFG_CHGEN BIT(7)
>> +#define RX8901_REG_BUF_INTF 0x46
>> +#define RX8901_REG_BUF_INTF_VBATLF BIT(3)
>>
>> #define MCP794XX_REG_CONTROL 0x07
>> # define MCP794XX_BIT_ALM0_EN 0x10
>> @@ -458,6 +461,39 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_RTC_INTF_DEV
>> +static int rx8901_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)
>> +{
>> + struct ds1307 *ds1307 = dev_get_drvdata(dev);
>> + unsigned int regflag, tmp = 0;
>> + int ret = 0;
>> +
>> + switch (cmd) {
>> + case RTC_VL_READ:
>> + ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
>> + if (ret)
>> + return ret;
>> +
>> + if (regflag & RX8901_REG_INTF_VLF)
>> + tmp |= RTC_VL_DATA_INVALID;
>> +
>> + ret = regmap_read(ds1307->regmap, RX8901_REG_BUF_INTF, ®flag);
>> + if (ret)
>> + return ret;
>> +
>> + if (regflag & RX8901_REG_BUF_INTF_VBATLF)
>> + tmp |= RTC_VL_BACKUP_LOW;
>> +
>> + return put_user(tmp, (unsigned int __user *)arg);
>> + default:
>> + return -ENOIOCTLCMD;
>> + }
>> + return ret;
>> +}
>> +#else
>> +#define rx8901_ioctl NULL
>> +#endif
>> +
>> static int ds1337_read_alarm(struct device *dev, struct rtc_wkalrm *t)
>> {
>> struct ds1307 *ds1307 = dev_get_drvdata(dev);
>> @@ -599,10 +635,13 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
>> return setup;
>> }
>>
>> -static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
>> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms __always_unused, bool diode)
>> {
>> - /* make sure that the backup battery is enabled */
>> - u8 setup = RX8901_REG_PWSW_CFG_INIEN;
>> + /*
>> + * make sure that the backup battery is enabled and that battery
>> + * voltage detection is performed
>> + */
>> + u8 setup = RX8901_REG_PWSW_CFG_INIEN | RX8901_REG_PWSW_CFG_VBATLDETEN;
>>
>> if (diode)
>> setup |= RX8901_REG_PWSW_CFG_CHGEN;
>> @@ -1005,6 +1044,7 @@ static const struct rtc_class_ops rx8130_rtc_ops = {
>> static const struct rtc_class_ops rx8901_rtc_ops = {
>> .read_time = ds1307_get_time,
>> .set_time = ds1307_set_time,
>> + .ioctl = rx8901_ioctl,
>> };
>>
>
> This seems to be an unrelated changed that hasn't been squashed in the
> proper patch.
>
Okay I will squash this change into patch 3 for v2.
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
/Fredrik
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: Rob Herring @ 2026-02-03 15:01 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <CAPVz0n25ukBJ6=hmmR9nd4MBoPkHaHQ+ZHMXYxghYZdkB28_sg@mail.gmail.com>
On Sun, Feb 01, 2026 at 09:07:07AM +0200, Svyatoslav Ryhel wrote:
> сб, 31 січ. 2026 р. о 22:02 David Lechner <dlechner@baylibre.com> пише:
> >
> > On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > > Convert power button devicetree bindings for the Motorola CPCAP MFD from
> > > TXT to YAML format. This patch does not change any functionality; the
> > > bindings remain the same.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> > > .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> > > 2 files changed, 32 insertions(+), 20 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > deleted file mode 100644
> > > index 0dd0076daf71..000000000000
> > > --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > +++ /dev/null
> > > @@ -1,20 +0,0 @@
> > > -Motorola CPCAP on key
> > > -
> > > -This module is part of the CPCAP. For more details about the whole
> > > -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> > > -
> > > -This module provides a simple power button event via an Interrupt.
> > > -
> > > -Required properties:
> > > -- compatible: should be one of the following
> > > - - "motorola,cpcap-pwrbutton"
> > > -- interrupts: irq specifier for CPCAP's ON IRQ
> > > -
> > > -Example:
> > > -
> > > -&cpcap {
> > > - cpcap_pwrbutton: pwrbutton {
> > > - compatible = "motorola,cpcap-pwrbutton";
> > > - interrupts = <23 IRQ_TYPE_NONE>;
> > > - };
> > > -};
> > > diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > new file mode 100644
> > > index 000000000000..643f6b2b1f13
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > @@ -0,0 +1,32 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Motorola CPCAP PMIC power key
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description:
> > > + This module is part of the Motorola CPCAP MFD device. For more details
> > > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > > + power key is represented as a sub-node of the PMIC node on the device
> > > + tree.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: motorola,cpcap-pwrbutton
> > > +
> > > + interrupts:
> > > + minItems: 1
> >
> > Should this be maxItems: 1?
> >
> > > + description: CPCAP's ON interrupt
> >
> > Or I suppose:
> >
> > items:
> > - description: ...
> >
>
> Both options are perfectly fine for me, and I lean towards using
> "items: desc" but I would like to hear what schema maintainers would
> say, which layout is preferred in this case.
Either is fine. 'description' is fine if you have something specific
about the interrupt to say. Saying what the interrupt is for is
specific. So 'description' is good in this case.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox