* 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 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: [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: 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 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 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 4/5] rtc: zynqmp: rework set_offset
From: T, Harini @ 2026-01-29 9:33 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-4-d4edb966b499@vaisala.com>
[Public]
Reviewed-by: Harini T <harini.t@amd.com>
> -----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 4/5] rtc: zynqmp: rework set_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> set_offset was using remainder of do_div as tick_mult which resulted in
> wrong offset. Calibration value also assumed builtin calibration default.
> Update fract_offset to correctly calculate the value for negative offset and
> replace the for loop with division.
>
> Tested-by: Harini T <harini.t@amd.com>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 33 +++++++++++++--------------------
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> c82f4d490fc7ebb5876b820182f5e79a99e496a8..f0f5dc63e254799ed99927c25
> 9c767b30ee877a4 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> - unsigned char fract_tick = 0;
> + int max_tick, tick_mult, fract_offset, fract_part;
> + int freq = xrtcdev->freq;
> unsigned int calibval;
> - short int max_tick;
> - int fract_offset;
> + int fract_data = 0;
>
> + /* Tick to offset multiplier */
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> return -ERANGE;
>
> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> - if (fract_offset < 0) {
> - fract_offset = fract_offset + tick_mult;
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> + fract_data = fract_offset / fract_part;
> + /* Subtract one from max_tick while adding fract_offset */
> + if (fract_offset < 0 && fract_data) {
> max_tick--;
> - }
> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
> - if (fract_offset <=
> - (fract_tick *
> - (tick_mult / RTC_FR_MAX_TICKS)))
> - break;
> - }
> + fract_data += RTC_FR_MAX_TICKS;
> }
> }
>
> /* Zynqmp RTC uses second and fractional tick
> * counters for compensation
> */
> - calibval = max_tick + RTC_CALIB_DEF;
> -
> - if (fract_tick)
> - calibval |= RTC_FR_EN;
> + calibval = max_tick + freq;
>
> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
> + if (fract_data)
> + calibval |= (RTC_FR_EN | (fract_data <<
> + RTC_FR_DATSHIFT));
>
> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>
>
> --
> 2.47.3
^ permalink raw reply
* RE: [PATCH v4 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL
From: Lakshay Piplani @ 2026-01-29 5:43 UTC (permalink / raw)
To: alexandre.belloni@bootlin.com, linux-rtc@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain, Shashank Rebbapragada
In-Reply-To: <20251121121137.3043764-2-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Friday, November 21, 2025 5:42 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org; wim@linux-watchdog.org;
> linux@roeck-us.net; linux-watchdog@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>
> Subject: [PATCH v4 2/5] rtc: pcf85363: support reporting battery switch-over
> via RTC_VL
>
> Add battery switch-over reporting for PCF85263/PCF85363 using the standard
> RTC_VL_* ioctl interface. When the backup supply takes over, the BSF flag is
> exposed to userspace through RTC_VL_READ and can be cleared using
> RTC_VL_CLR.
>
> This allows applications to detect loss of main power without relying on non-
> standard interfaces.
>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V3 -> V4:
> - No changes in v4.
> V2 -> V3:
> - Split into separate patches as suggested:
> - Battery switch-over detection.
> - Timestamp recording for TS pin and battery switch-over events.
> - Offset calibration.
> - Watchdog timer (to be reviewed by watchdog maintainers).
> - Dropped Alarm2 support
> - Switched to rtc_add_group() for sysfs attributes
> V1 -> V2:
> - Watchdog related changes due to removal of vendor specific properties
> from device tree
> * remove vendor DT knobs (enable/timeout/stepsize/repeat)
> * use watchdog_init_timeout (with 10s default)
> * derive clock_sel from final timeout
> * default, repeat=true (repeat mode)
> - Fixed uninitalised warning on 'ret' (reported by kernel test robot)
> - Use dev_dbg instead of dev_info for debug related print messages
> - Minor cleanup and comments.
>
> drivers/rtc/rtc-pcf85363.c | 49 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 47 insertions(+), 2 deletions(-)
>
Hi,
I'm sending a gentle reminder regarding the patches that I submitted in November.
I haven't received any review comments yet, so I'd really appreciate it if you could have a look whenever you have some time.
Best Regards
Lakshay Piplani
^ permalink raw reply
* RE: [PATCH v7 2/2] rtc: Add NXP PCF85053 driver support
From: Lakshay Piplani @ 2026-01-29 5:34 UTC (permalink / raw)
To: alexandre.belloni@bootlin.com, linux-rtc@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain, Shashank Rebbapragada,
Daniel Aguirre, Pankit Garg
In-Reply-To: <20251127120456.1849177-2-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Thursday, November 27, 2025 5:35 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>; Daniel Aguirre <daniel.aguirre@nxp.com>;
> Pankit Garg <pankit.garg@nxp.com>
> Subject: [PATCH v7 2/2] rtc: Add NXP PCF85053 driver support
>
> PCF85053 is i2c based RTC which supports timer and calendar functionality.
>
> Features supported:
> 1. Read/Write time
> 2. Get/Set Alarm
> 3. Wakeup Source
> 4. Generate up to 32768Hz clock output
> 5. Primary/Secondary i2c bus
>
> Signed-off-by: Daniel Aguirre <daniel.aguirre@nxp.com>
> Signed-off-by: Pankit Garg <pankit.garg@nxp.com>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V6 -> V7: - Addressed minor cleanups from review: use
> dev_get_drvdata()/dev_set_drvdata()
> consistently, fix alarm IRQ dev_id handling, and switch to
> devm_device_init_wakeup().
> - Simplified time/alarm programming by forcing 24h + binary mode
> in hardware,
> dropping complex 12h/BCD handling in setters.
> - Documented the 2000–2099 supported year range, explaining how
> the 00–99 year
> register maps to leap-year behavior in the device.
> V5 -> V6: no changes
> V4 -> V5: no changes
> V3 -> V4: - Handle multi-host ownership explicitly using primary/secondary
> bus hadling.
> - Probe no longer changes any CTRL bits unconditionally and do not
> clear ST/AF/OF
> avoiding lost interrupts or silent mode changes.
> - Read/Set time & alarm now respect HF(12/24h) and DM(BCD/BIN)
> converting
> hour fields correctly for all combinations.
> - Minor changes: drop noisy warnings, tidy error paths/comments.
> V2 -> V3: Add MAINTAINERS file changes to this patch
> V1 -> V2: no changes
>
> MAINTAINERS | 7 +
> drivers/rtc/Kconfig | 10 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-pcf85053.c | 717 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 735 insertions(+)
> create mode 100644 drivers/rtc/rtc-pcf85053.c
>
Hi Alexandre,
I'm sending a gentle reminder regarding the patches that I submitted in November.
I haven't received any review comments yet, so I’d really appreciate it if you could have a look whenever you have some time.
Best Regards
Lakshay Piplani
^ permalink raw reply
* Re: (subset) [PATCH v2 12/20] rtc: amlogic-a4: Remove IRQF_ONESHOT
From: Alexandre Belloni @ 2026-01-28 11:28 UTC (permalink / raw)
To: linux-kernel, Sebastian Andrzej Siewior
Cc: Thomas Gleixner, Xianwei Zhao, Yiting Deng, linux-amlogic,
linux-rtc
In-Reply-To: <20260128095540.863589-13-bigeasy@linutronix.de>
On Wed, 28 Jan 2026 10:55:32 +0100, Sebastian Andrzej Siewior wrote:
> Passing IRQF_ONESHOT ensures that the interrupt source is masked until
> the secondary (threaded) handler is done. If only a primary handler is
> used then the flag makes no sense because the interrupt can not fire
> (again) while its handler is running.
> The flag also disallows force-threading of the primary handler and the
> irq-core will warn about this.
>
> [...]
Applied, thanks!
[12/20] rtc: amlogic-a4: Remove IRQF_ONESHOT
https://git.kernel.org/abelloni/c/1932db202c93
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: isl12022: Add missing check for device_property_read_u32_array
From: Markus Elfring @ 2026-01-28 10:16 UTC (permalink / raw)
To: Chen Ni, linux-rtc, Alexandre Belloni; +Cc: LKML
In-Reply-To: <20260128043430.2260970-1-nichen@iscas.ac.cn>
> Add check for the return value of device_property_read_u32_array() and
> log a warning message if it fails in order to catch the error.
* Were any source code analysis tools involved here?
* Did anything hinder to add any tags (like “Fixes” and “Cc”) accordingly?
Regards,
Markus
^ permalink raw reply
* [PATCH v2 12/20] rtc: amlogic-a4: Remove IRQF_ONESHOT
From: Sebastian Andrzej Siewior @ 2026-01-28 9:55 UTC (permalink / raw)
To: linux-kernel
Cc: Thomas Gleixner, Sebastian Andrzej Siewior, Xianwei Zhao,
Yiting Deng, Alexandre Belloni, linux-amlogic, linux-rtc
In-Reply-To: <20260128095540.863589-1-bigeasy@linutronix.de>
Passing IRQF_ONESHOT ensures that the interrupt source is masked until
the secondary (threaded) handler is done. If only a primary handler is
used then the flag makes no sense because the interrupt can not fire
(again) while its handler is running.
The flag also disallows force-threading of the primary handler and the
irq-core will warn about this.
Remove IRQF_ONESHOT from irqflags.
Fixes: c89ac9182ee29 ("rtc: support for the Amlogic on-chip RTC")
Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
Cc: Yiting Deng <yiting.deng@amlogic.com>
Cc: Xianwei Zhao <xianwei.zhao@amlogic.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-amlogic@lists.infradead.org
Cc: linux-rtc@vger.kernel.org
---
drivers/rtc/rtc-amlogic-a4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-amlogic-a4.c b/drivers/rtc/rtc-amlogic-a4.c
index 123fb372fc9fe..50938c35af36a 100644
--- a/drivers/rtc/rtc-amlogic-a4.c
+++ b/drivers/rtc/rtc-amlogic-a4.c
@@ -369,7 +369,7 @@ static int aml_rtc_probe(struct platform_device *pdev)
return PTR_ERR(rtc->rtc_dev);
ret = devm_request_irq(dev, rtc->irq, aml_rtc_handler,
- IRQF_ONESHOT, "aml-rtc alarm", rtc);
+ 0, "aml-rtc alarm", rtc);
if (ret) {
dev_err_probe(dev, ret, "IRQ%d request failed, ret = %d\n",
rtc->irq, ret);
--
2.51.0
^ permalink raw reply related
* [PATCH] rtc: isl12022: Add missing check for device_property_read_u32_array
From: Chen Ni @ 2026-01-28 4:34 UTC (permalink / raw)
To: alexandre.belloni; +Cc: linux-rtc, linux-kernel, Chen Ni
Add check for the return value of device_property_read_u32_array() and
log a warning message if it fails in order to catch the error.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
drivers/rtc/rtc-isl12022.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c
index 5fc52dc64213..6f66ec4a9948 100644
--- a/drivers/rtc/rtc-isl12022.c
+++ b/drivers/rtc/rtc-isl12022.c
@@ -517,8 +517,10 @@ static void isl12022_set_trip_levels(struct device *dev)
int ret, i, j, x[2];
u8 val, mask;
- device_property_read_u32_array(dev, "isil,battery-trip-levels-microvolt",
- levels, 2);
+ ret = device_property_read_u32_array(dev, "isil,battery-trip-levels-microvolt",
+ levels, 2);
+ if (ret)
+ dev_warn(dev, "failed to read battery-trip-levels-microvolt: %d\n", ret);
for (i = 0; i < 2; i++) {
for (j = 0; j < ARRAY_SIZE(trip_levels[i]) - 1; j++) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
From: Conor Dooley @ 2026-01-26 20:30 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, mturquette, sboyd,
prabhakar.mahadev-lad.rj, linux-rtc, linux-renesas-soc,
devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-4-ovidiu.panait.rb@renesas.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
From: kernel test robot @ 2026-01-26 19:41 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: llvm, oe-kbuild-all, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc,
Kaustabh Chakraborty
In-Reply-To: <20260126-s2mu005-pmic-v2-6-78f1a75f547a@disroot.org>
Hi Kaustabh,
kernel test robot noticed the following build errors:
[auto build test ERROR on ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea]
url: https://github.com/intel-lab-lkp/linux/commits/Kaustabh-Chakraborty/dt-bindings-leds-document-Samsung-S2M-series-PMIC-flash-LED-device/20260126-031457
base: ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
patch link: https://lore.kernel.org/r/20260126-s2mu005-pmic-v2-6-78f1a75f547a%40disroot.org
patch subject: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260127/202601270307.Ds4yus7I-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260127/202601270307.Ds4yus7I-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601270307.Ds4yus7I-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/mfd/sec-irq.c:218:7: error: expression is not an integer constant expression
case irqf_regs[0]:
^~~~~~~~~~~~
drivers/mfd/sec-irq.c:218:7: note: initializer of 'irqf_regs' is not a constant expression
drivers/mfd/sec-irq.c:204:21: note: declared here
const unsigned int irqf_regs[] = {
^
drivers/mfd/sec-irq.c:220:7: error: expression is not an integer constant expression
case mask_regs[0]:
^~~~~~~~~~~~
drivers/mfd/sec-irq.c:220:7: note: initializer of 'mask_regs' is not a constant expression
drivers/mfd/sec-irq.c:210:21: note: declared here
const unsigned int mask_regs[] = {
^
2 errors generated.
vim +218 drivers/mfd/sec-irq.c
200
201 static unsigned int s2mu005_irq_get_reg(struct regmap_irq_chip_data *data,
202 unsigned int base, int index)
203 {
204 const unsigned int irqf_regs[] = {
205 S2MU005_REG_CHGR_INT1,
206 S2MU005_REG_FLED_INT1,
207 S2MU005_REG_MUIC_INT1,
208 S2MU005_REG_MUIC_INT2,
209 };
210 const unsigned int mask_regs[] = {
211 S2MU005_REG_CHGR_INT1M,
212 S2MU005_REG_FLED_INT1M,
213 S2MU005_REG_MUIC_INT1M,
214 S2MU005_REG_MUIC_INT2M,
215 };
216
217 switch (base) {
> 218 case irqf_regs[0]:
219 return irqf_regs[index];
220 case mask_regs[0]:
221 return mask_regs[index];
222 }
223
224 return base;
225 }
226
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable RTC
From: Geert Uytterhoeven @ 2026-01-26 15:57 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-6-ovidiu.panait.rb@renesas.com>
On Sun, 25 Jan 2026 at 20:27, Ovidiu Panait
<ovidiu.panait.rb@renesas.com> wrote:
> Enable RTC.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/5] arm64: dts: renesas: r9a09g056: Add RTC node
From: Geert Uytterhoeven @ 2026-01-26 15:56 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-5-ovidiu.panait.rb@renesas.com>
On Sun, 25 Jan 2026 at 20:27, Ovidiu Panait
<ovidiu.panait.rb@renesas.com> wrote:
> Add RTC node to Renesas RZ/V2N ("R9A09G056") SoC DTSI.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
From: Geert Uytterhoeven @ 2026-01-26 15:56 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
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 at 20:27, Ovidiu Panait
<ovidiu.panait.rb@renesas.com> 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.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/5] clk: renesas: r9a09g056: Add clock and reset entries for RTC
From: Geert Uytterhoeven @ 2026-01-26 15:54 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-3-ovidiu.panait.rb@renesas.com>
On Sun, 25 Jan 2026 at 20:27, Ovidiu Panait
<ovidiu.panait.rb@renesas.com> wrote:
> Add module clock and reset entries for the RTC module on the Renesas RZ/V2N
> (R9A09G056) SoC.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/5] clk: renesas: r9a09g056: Fix ordering of module clocks array
From: Geert Uytterhoeven @ 2026-01-26 15:27 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-2-ovidiu.panait.rb@renesas.com>
On Sun, 25 Jan 2026 at 20:27, Ovidiu Panait
<ovidiu.panait.rb@renesas.com> wrote:
> The r9a09g056_mod_clks array is sorted by CPG_CLKON register number and
> bit position. Move the RSPI 0/1/2 module clock entries to their correct
> position to restore the array sort order.
>
> Fixes: 1f76689d1715 ("clk: renesas: r9a09g056: Add entries for RSCIs")
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: Rob Herring @ 2026-01-26 14:37 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, 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: <20260125134302.45958-9-clamor95@gmail.com>
On Sun, Jan 25, 2026 at 03:43:00PM +0200, 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.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/mfd/motorola,cpcap.yaml | 389 ++++++++++++++++++
> .../bindings/mfd/motorola-cpcap.txt | 78 ----
> 2 files changed, 389 insertions(+), 78 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 000000000000..f75f884c7b3e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -0,0 +1,389 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC MFD
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap
> + - st,6556002
> + - motorola,mapphone-cpcap
> + - motorola,mot-cpcap
Adding new compatibles should be a separate patch unless they have
already been in use.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + spi-max-frequency:
> + maximum: 8000000
> +
> + spi-cs-high: true
> +
> + adc:
> + $ref: /schemas/iio/adc/motorola,cpcap-adc.yaml
> +
> + audio-codec:
> + type: object
additionalProperties: false
> +
> + properties:
> + interrupts:
> + items:
> + - description: headset detect interrupt
> + - description: microphone bias 2 detect interrupt
> +
> + interrupt-names:
> + items:
> + - const: hs
> + - const: mb2
> +
> + "#sound-dai-cells":
> + const: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description: The audio-codec provides two DAIs. The first one is
> + connected to the Stereo HiFi DAC and the second one is connected
> + to the Voice DAC.
You need to define each port in the schema.
> +
> + required:
> + - interrupts
> + - interrupt-names
> + - "#sound-dai-cells"
> +
> + battery:
> + $ref: /schemas/power/supply/cpcap-battery.yaml
> +
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml
> +
> + phy:
> + $ref: /schemas/phy/motorola,cpcap-usb-phy.yaml
> +
> + regulator:
> + $ref: /schemas/regulator/motorola,cpcap-regulator.yaml
> +
> + rtc:
> + $ref: /schemas/rtc/motorola,cpcap-rtc.yaml
> +
> +patternProperties:
> + "^led(-[a-z]+)?$":
> + $ref: /schemas/leds/motorola,cpcap-leds.yaml
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/input/linux-event-codes.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpcap: pmic@0 {
> + compatible = "motorola,cpcap";
> + reg = <0>; /* cs0 */
> +
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + spi-max-frequency = <3000000>;
> + spi-cs-high;
> +
> + cpcap_adc: adc {
> + compatible = "motorola,cpcap-adc";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <8 IRQ_TYPE_NONE>;
> + interrupt-names = "adcdone";
> +
> + #io-channel-cells = <1>;
> + };
> +
> + cpcap_audio: audio-codec {
> + interrupt-parent = <&cpcap>;
> + interrupts = <9 IRQ_TYPE_NONE>, <10 IRQ_TYPE_NONE>;
> + interrupt-names = "hs", "mb2";
> +
> + #sound-dai-cells = <1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* HiFi */
> + port@0 {
> + reg = <0>;
> + cpcap_audio_codec0: endpoint {
> + };
> + };
> +
> + /* Voice */
> + port@1 {
> + reg = <1>;
> + cpcap_audio_codec1: endpoint {
> + };
> + };
> + };
> + };
> +
> + cpcap_battery: battery {
> + compatible = "motorola,cpcap-battery";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <6 IRQ_TYPE_NONE>, <5 IRQ_TYPE_NONE>,
> + <3 IRQ_TYPE_NONE>, <20 IRQ_TYPE_NONE>,
> + <54 IRQ_TYPE_NONE>, <57 IRQ_TYPE_NONE>;
> + interrupt-names = "eol", "lowbph", "lowbpl",
> + "chrgcurr1", "battdetb", "cccal";
> +
> + io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
> + <&cpcap_adc 5>, <&cpcap_adc 6>;
> + io-channel-names = "battdetb", "battp",
> + "chg_isense", "batti";
> + power-supplies = <&cpcap_charger>;
> + };
> +
> + cpcap_charger: charger {
> + compatible = "motorola,mapphone-cpcap-charger";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <13 IRQ_TYPE_NONE>, <12 IRQ_TYPE_NONE>,
> + <29 IRQ_TYPE_NONE>, <28 IRQ_TYPE_NONE>,
> + <22 IRQ_TYPE_NONE>, <21 IRQ_TYPE_NONE>,
> + <20 IRQ_TYPE_NONE>, <19 IRQ_TYPE_NONE>,
> + <54 IRQ_TYPE_NONE>;
> + interrupt-names = "chrg_det", "rvrs_chrg", "chrg_se1b",
> + "se0conn", "rvrs_mode", "chrgcurr2",
> + "chrgcurr1", "vbusvld", "battdetb";
> +
> + mode-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>,
> + <&gpio3 23 GPIO_ACTIVE_LOW>;
> +
> + io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
> + <&cpcap_adc 2>, <&cpcap_adc 5>,
> + <&cpcap_adc 6>;
> + io-channel-names = "battdetb", "battp",
> + "vbus", "chg_isense",
> + "batti";
> + };
> +
> + key-power {
> + compatible = "motorola,cpcap-pwrbutton";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <23 IRQ_TYPE_NONE>;
> + };
> +
> + led-red {
> + compatible = "motorola,cpcap-led-red";
> + vdd-supply = <&vdd_led>;
> + label = "status-led::red";
> + };
> +
> + led-green {
> + compatible = "motorola,cpcap-led-green";
> + vdd-supply = <&vdd_led>;
> + label = "status-led::green";
> + };
> +
> + led-blue {
> + compatible = "motorola,cpcap-led-blue";
> + vdd-supply = <&vdd_led>;
> + label = "status-led::blue";
> + };
> +
> + cpcap_usb2_phy: phy {
> + compatible = "motorola,mapphone-cpcap-usb-phy";
> +
> + pinctrl-0 = <&usb_gpio_mux_sel1>, <&usb_gpio_mux_sel2>;
> + pinctrl-1 = <&usb_ulpi_pins>;
> + pinctrl-2 = <&usb_utmi_pins>;
> + pinctrl-3 = <&uart3_pins>;
> + pinctrl-names = "default", "ulpi", "utmi", "uart";
> + #phy-cells = <0>;
> +
> + interrupts-extended =
> + <&cpcap 15 IRQ_TYPE_NONE>, <&cpcap 14 IRQ_TYPE_NONE>,
> + <&cpcap 28 IRQ_TYPE_NONE>, <&cpcap 19 IRQ_TYPE_NONE>,
> + <&cpcap 18 IRQ_TYPE_NONE>, <&cpcap 17 IRQ_TYPE_NONE>,
> + <&cpcap 16 IRQ_TYPE_NONE>, <&cpcap 49 IRQ_TYPE_NONE>,
> + <&cpcap 48 IRQ_TYPE_NONE>;
> + interrupt-names = "id_ground", "id_float", "se0conn",
> + "vbusvld", "sessvld", "sessend",
> + "se1", "dm", "dp";
> +
> + mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,
> + <&gpio1 0 GPIO_ACTIVE_HIGH>;
> +
> + io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
> + io-channel-names = "vbus", "id";
> +
> + vusb-supply = <&avdd_usb>;
> + };
> +
> + regulator {
> + compatible = "motorola,cpcap-regulator";
> +
> + regulators {
> + vdd_cpu: SW1 {
> + regulator-name = "vdd_cpu";
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1125000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_core: SW2 {
> + regulator-name = "vdd_core";
> + regulator-min-microvolt = <950000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_1v8_vio: SW3 {
> + regulator-name = "vdd_1v8_vio";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_aon: SW4 {
> + regulator-name = "vdd_aon";
> + regulator-min-microvolt = <950000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_led: SW5 {
> + regulator-name = "vdd_led";
> + regulator-min-microvolt = <5050000>;
> + regulator-max-microvolt = <5050000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-boot-on;
> + };
> +
> + vdd_hvio: VHVIO {
> + regulator-name = "vdd_hvio";
> + regulator-min-microvolt = <2775000>;
> + regulator-max-microvolt = <2775000>;
> + regulator-enable-ramp-delay = <1000>;
> + };
> +
> + vcore_emmc: VSDIO {
> + regulator-name = "vcore_emmc";
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + avdd_dsi_csi: VCSI {
> + regulator-name = "avdd_dsi_csi";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-boot-on;
> + };
> +
> + avdd_3v3_periph: VWLAN2 {
> + regulator-name = "avdd_3v3_periph";
> + regulator-min-microvolt = <2775000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-boot-on;
> + };
> +
> + vddio_usd: VSIMCARD {
> + regulator-name = "vddio_usd";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2900000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-boot-on;
> + };
> +
> + vdd_haptic: VVIB {
> + regulator-name = "vdd_haptic";
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <1000>;
> + };
> +
> + avdd_usb: VUSB {
> + regulator-name = "avdd_usb";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + VAUDIO {
> + regulator-name = "vdd_audio";
> + regulator-min-microvolt = <2775000>;
> + regulator-max-microvolt = <2775000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> + };
> + };
> +
> + cpcap_rtc: rtc {
> + compatible = "motorola,cpcap-rtc";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> deleted file mode 100644
> index 18c3fc26ca93..000000000000
> --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -Motorola CPCAP PMIC device tree binding
> -
> -Required properties:
> -- compatible : One or both of "motorola,cpcap" or "ste,6556002"
> -- reg : SPI chip select
> -- interrupts : The interrupt line the device is connected to
> -- interrupt-controller : Marks the device node as an interrupt controller
> -- #interrupt-cells : The number of cells to describe an IRQ, should be 2
> -- #address-cells : Child device offset number of cells, should be 1
> -- #size-cells : Child device size number of cells, should be 0
> -- spi-max-frequency : Typically set to 3000000
> -- spi-cs-high : SPI chip select direction
> -
> -Optional subnodes:
> -
> -The sub-functions of CPCAP get their own node with their own compatible values,
> -which are described in the following files:
> -
> -- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml
> -- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml
> -- Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> -- Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
> -- Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> -- Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
> -- Documentation/devicetree/bindings/leds/leds-cpcap.txt
> -- Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
> -
> -The only exception is the audio codec. Instead of a compatible value its
> -node must be named "audio-codec".
> -
> -Required properties for the audio-codec subnode:
> -
> -- #sound-dai-cells = <1>;
> -- interrupts : should contain jack detection interrupts, with headset
> - detect interrupt matching "hs" and microphone bias 2
> - detect interrupt matching "mb2" in interrupt-names.
> -- interrupt-names : Contains "hs", "mb2"
> -
> -The audio-codec provides two DAIs. The first one is connected to the
> -Stereo HiFi DAC and the second one is connected to the Voice DAC.
> -
> -Example:
> -
> -&mcspi1 {
> - cpcap: pmic@0 {
> - compatible = "motorola,cpcap", "ste,6556002";
> - reg = <0>; /* cs0 */
> - interrupt-parent = <&gpio1>;
> - interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> - interrupt-controller;
> - #interrupt-cells = <2>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - spi-max-frequency = <3000000>;
> - spi-cs-high;
> -
> - audio-codec {
> - #sound-dai-cells = <1>;
> - interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>;
> - interrupt-names = "hs", "mb2";
> -
> - /* HiFi */
> - port@0 {
> - endpoint {
> - remote-endpoint = <&cpu_dai1>;
> - };
> - };
> -
> - /* Voice */
> - port@1 {
> - endpoint {
> - remote-endpoint = <&cpu_dai2>;
> - };
> - };
> - };
> - };
> -};
> -
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v1 02/10] regulator: cpcap-regulator: add support for Mot regulators
From: Andy Shevchenko @ 2026-01-26 11:50 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, 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: <CAPVz0n0MM6OcjOWnNBaGk=6eYcb09P0XBFDn+MYHtXXcgkcvQQ@mail.gmail.com>
On Mon, Jan 26, 2026 at 12:13:39PM +0200, Svyatoslav Ryhel wrote:
> пн, 26 січ. 2026 р. о 12:10 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > On Sun, Jan 25, 2026 at 03:42:54PM +0200, Svyatoslav Ryhel wrote:
...
> > What a style! (Yeah, I see it's being used elsewhere here...)
>
> I have just made it in same way the other tables present in here.
I understood that (see my note in the parentheses above).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 09/10] mfd: motorola-cpcap: diverge configuration per-board
From: Svyatoslav Ryhel @ 2026-01-26 10:14 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, 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: <aXc-Sklb6QTWLvcE@smile.fi.intel.com>
пн, 26 січ. 2026 р. о 12:13 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sun, Jan 25, 2026 at 03:43:01PM +0200, Svyatoslav Ryhel wrote:
> > MFD have rigid subdevice structure which does not allow flexible dynamic
> > subdevice linking. Address this by diverging CPCAP subdevice composition
> > to take into account board specific configuration.
> >
> > Create a common default subdevice composition, rename existing subdevice
> > composition into cpcap_mapphone_mfd_devices since it targets mainly
> > Mapphone board.
>
> ...
>
> > +#include <linux/of.h>
>
> Why?
>
>
> ...
>
> > + cpcap->cdata = of_device_get_match_data(&spi->dev);
>
> device_get_match_data() from property.h.
>
noted
> > + if (!cpcap->cdata)
> > + return -ENODEV;
> > +
>
> ...
>
> > +static const struct of_device_id cpcap_of_match[] = {
> > + { .compatible = "motorola,cpcap", .data = &cpcap_default_data },
> > + { .compatible = "st,6556002", .data = &cpcap_default_data },
> > + { .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
>
> > + { /* sentinel */ },
>
> No trailing comma for sentinel.
>
noted
> > +};
> > +MODULE_DEVICE_TABLE(of, cpcap_of_match);
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v1 02/10] regulator: cpcap-regulator: add support for Mot regulators
From: Svyatoslav Ryhel @ 2026-01-26 10:13 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, 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: <aXc9n_gc7TEFvNA8@smile.fi.intel.com>
пн, 26 січ. 2026 р. о 12:10 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sun, Jan 25, 2026 at 03:42:54PM +0200, Svyatoslav Ryhel wrote:
> > Add support for regulator set used in Motorola Mot board, used as a base
> > for Atrix 4G and Droid X2 smartphones.
>
> ...
>
> > +static const unsigned int sw_mot_val_tbl[] = { 600000, 612500, 625000,
> > + 637500, 650000, 662500,
> > + 675000, 687500, 700000,
> > + 712500, 725000, 737500,
> > + 750000, 762500, 775000,
> > + 787500, 800000, 812500,
> > + 825000, 837500, 850000,
> > + 862500, 875000, 887500,
> > + 900000, 912500, 925000,
> > + 937500, 950000, 962500,
> > + 975000, 987500, 1000000,
> > + 1012500, 1025000, 1037500,
> > + 1050000, 1062500, 1075000,
> > + 1087500, 1100000, 1112500,
> > + 1125000, 1137500, 1150000,
> > + 1162500, 1175000, 1187500,
> > + 1200000, 1212500, 1225000,
> > + 1237500, 1250000, 1262500,
> > + 1275000, 1287500, 1300000,
> > + 1312500, 1325000, 1337500,
> > + 1350000, 1362500, 1375000,
> > + 1387500, 1400000, 1412500,
> > + 1425000, 1437500, 1450000,
> > + 1462500, 1475000, };
>
> What a style! (Yeah, I see it's being used elsewhere here...)
>
I have just made it in same way the other tables present in here.
> ...
>
> > + CPCAP_REG(VAUDIO, CPCAP_REG_VAUDIOC, CPCAP_REG_ASSIGN4,
> > + CPCAP_BIT_VAUDIO_SEL, vaudio_val_tbl,
> > + 0x16, 0x1, 0x5, 0, 0),
>
> > + { /* sentinel */ },
>
> No trailing comma for sentinel.
>
noted
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v1 09/10] mfd: motorola-cpcap: diverge configuration per-board
From: Andy Shevchenko @ 2026-01-26 10:13 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, 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: <20260125134302.45958-10-clamor95@gmail.com>
On Sun, Jan 25, 2026 at 03:43:01PM +0200, Svyatoslav Ryhel wrote:
> MFD have rigid subdevice structure which does not allow flexible dynamic
> subdevice linking. Address this by diverging CPCAP subdevice composition
> to take into account board specific configuration.
>
> Create a common default subdevice composition, rename existing subdevice
> composition into cpcap_mapphone_mfd_devices since it targets mainly
> Mapphone board.
...
> +#include <linux/of.h>
Why?
...
> + cpcap->cdata = of_device_get_match_data(&spi->dev);
device_get_match_data() from property.h.
> + if (!cpcap->cdata)
> + return -ENODEV;
> +
...
> +static const struct of_device_id cpcap_of_match[] = {
> + { .compatible = "motorola,cpcap", .data = &cpcap_default_data },
> + { .compatible = "st,6556002", .data = &cpcap_default_data },
> + { .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
> + { /* sentinel */ },
No trailing comma for sentinel.
> +};
> +MODULE_DEVICE_TABLE(of, cpcap_of_match);
--
With Best Regards,
Andy Shevchenko
^ 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