From: sashiko-bot@kernel.org
To: "Lakshay Piplani" <lakshay.piplani@nxp.com>
Cc: robh@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-watchdog@vger.kernel.org, conor+dt@kernel.org,
linux-rtc@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v7 3/5] rtc: pcf85363: add timestamp support with configurable timestamp mode
Date: Tue, 15 Sep 2026 03:55:04 +0000 [thread overview]
Message-ID: <20260915035504.9FC211F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915034452.4086683-3-lakshay.piplani@nxp.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] rtc: pcf85363: uninitialized ts_last_event state when DT property is missing
- [High] rtc: pcf85363: incorrect TSR3_SHIFT misconfigures hardware
- [High] rtc: pcf85363: GENMASK used as value misconfigures TS pin mode
--
commit f0ef4cbc1465704e262d43ce6c2e731b6a23a590
Author: Lakshay Piplani <lakshay.piplani@nxp.com>
Subject: rtc: pcf85363: add timestamp support with configurable timestamp mode
Add support for the timestamp capture registers on PCF85263/PCF85363,
which latch the time on selected events (TS pin or battery switch-over).
The capture source is selected via the nxp,timestamp-mode device tree
property and latched values are exported through read-only sysfs
attributes.
> diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
> index 00f37ffcca260..ef846dd231a04 100644
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
[ ... ]
> @@ -102,22 +109,50 @@
> #define PIN_IO_INTA_OUT 2
> #define PIN_IO_INTA_HIZ 3
>
> +#define PIN_IO_TSPM GENMASK(3, 2)
> +#define PIN_IO_TSIM BIT(4)
>
> #define OSC_CAP_SEL GENMASK(1, 0)
> #define OSC_CAP_6000 0x01
> #define OSC_CAP_12500 0x02
>
> #define STOP_EN_STOP BIT(0)
>
> +#define RTCM_BIT BIT(4)
>
> #define RESET_CPR 0xa4
>
> #define NVRAM_SIZE 0x40
>
> +#define TSR1_MASK 0x03
> +#define TSR2_MASK 0x07
> +#define TSR3_MASK 0x03
> +#define TSR1_SHIFT 0
> +#define TSR2_SHIFT 2
> +#define TSR3_SHIFT 6
[Severity: High]
Is TSR3_SHIFT correct here? The DT_TS_MODE register uses bits 7:5 for TSR3,
so the shift should be 5. Shifting by 6 maps the value to bits 7:6, corrupting
the TSR3 configuration when written to the hardware.
[ ... ]
> @@ -539,29 +761,72 @@ static int pcf85363_probe(struct i2c_client *client)
> .reg_write = pcf85363_nvram_write,
> },
> };
>
> if (data)
> config = data;
>
> - pcf85363 = devm_kzalloc(&client->dev, sizeof(struct pcf85363),
> - GFP_KERNEL);
> + pcf85363 = devm_kzalloc(&client->dev, sizeof(*pcf85363), GFP_KERNEL);
> if (!pcf85363)
> return -ENOMEM;
>
[ ... ]
> + if (!device_property_read_u32_array(dev, "nxp,timestamp-mode", tsr_mode, 3)) {
[Severity: High]
Can this result in an uninitialized ts_last_event state?
If the "nxp,timestamp-mode" property is missing from the device tree, this
block is skipped and pcf85363_classify_ts_modes() is never called. This leaves
ts_last_event as false (from kzalloc).
If the hardware was pre-configured to a last-event mode by a bootloader, the
driver will treat it as a first-event mode, bypassing the stable-read retry
loop and exposing userspace to torn reads.
> + bool ts_pin_used;
> +
> + tsr_mode[0] &= TSR1_MASK;
> + tsr_mode[1] &= TSR2_MASK;
> + tsr_mode[2] &= TSR3_MASK;
> +
> + val = (tsr_mode[2] << TSR3_SHIFT) |
> + (tsr_mode[1] << TSR2_SHIFT) |
> + (tsr_mode[0] << TSR1_SHIFT);
> +
> + ret = regmap_write(pcf85363->regmap, DT_TS_MODE, val);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to write timestamp mode register\n");
> +
> + pcf85363_classify_ts_modes(pcf85363, val);
> +
> + ts_mode_configured = tsr_mode[0] || tsr_mode[1] || tsr_mode[2];
> +
> + /*
> + * Only the TS-pin capture modes drive the TS pin. Select the
> + * timestamp function (TSPM) for those and leave the input mode
> + * (TSIM) at its reset default rather than forcing the
> + * mechanical-switch detector.
> + */
> + ts_pin_used = tsr_mode[0] == PCF85363_TSR1_FE ||
> + tsr_mode[0] == PCF85363_TSR1_LE ||
> + tsr_mode[1] == PCF85363_TSR2_FE ||
> + tsr_mode[1] == PCF85363_TSR2_LE;
> +
> + if (ts_pin_used) {
> + ret = regmap_update_bits(pcf85363->regmap, CTRL_PIN_IO,
> + PIN_IO_TSPM, PIN_IO_TSPM);
[Severity: High]
Does this misconfigure the TS pin mode?
PIN_IO_TSPM evaluates to 0x0C (binary 11 in bits 3:2). Using it as both the
mask and the value to regmap_update_bits() sets bits 3:2 to 11, which
configures the pin as an output according to the datasheet.
To capture timestamps from external events, shouldn't the TS pin be configured
as an input (mode 10)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260915034452.4086683-1-lakshay.piplani@nxp.com?part=3
next prev parent reply other threads:[~2026-09-15 3:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 3:44 [PATCH v7 1/5] dt-bindings: rtc: nxp,pcf85363: add timestamp mode config Lakshay Piplani
2026-09-15 3:44 ` [PATCH v7 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL Lakshay Piplani
2026-09-15 3:53 ` sashiko-bot
2026-09-15 3:44 ` [PATCH v7 3/5] rtc: pcf85363: add timestamp support with configurable timestamp mode Lakshay Piplani
2026-09-15 3:55 ` sashiko-bot [this message]
2026-09-15 5:34 ` [EXT] " Lakshay Piplani
2026-09-15 3:44 ` [PATCH v7 4/5] rtc: pcf85363: add oscillator offset calibration support Lakshay Piplani
2026-09-15 3:49 ` sashiko-bot
2026-09-15 3:44 ` [PATCH v7 5/5] rtc: pcf85363: add watchdog support with configurable step size Lakshay Piplani
2026-09-15 4:05 ` sashiko-bot
2026-09-15 3:47 ` [PATCH v7 1/5] dt-bindings: rtc: nxp,pcf85363: add timestamp mode config sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260915035504.9FC211F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lakshay.piplani@nxp.com \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox