devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mateusz Jończyk" <mat.jonczyk@o2.pl>
To: Alex Elder <elder@riscstar.com>,
	lee@kernel.org, alexandre.belloni@bootlin.com,
	lgirdwood@gmail.com, broonie@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org
Cc: dlan@gentoo.org, wangruikang@iscas.ac.cn,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, alex@ghiti.fr, troymitchell988@gmail.com,
	guodong@riscstar.com, devicetree@vger.kernel.org,
	spacemit@lists.linux.dev, linux-rtc@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v3 4/7] rtc: spacemit: support the SpacemiT P1 RTC
Date: Mon, 23 Jun 2025 20:54:34 +0200	[thread overview]
Message-ID: <d35922c4-fbd0-4d13-9bcd-2688b48c0045@o2.pl> (raw)
In-Reply-To: <20250622032941.3768912-5-elder@riscstar.com>

W dniu 22.06.2025 o 05:29, Alex Elder pisze:
> Add support for the RTC found in the SpacemiT P1 PMIC.  Initially
> only setting and reading the time are supported.
>
> The PMIC is implemented as a multi-function device.  This RTC is
> probed based on this driver being named in a MFD cell in the simple
> MFD I2C driver.
>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> v3: - Added this driver to the series, in response to Lee Jones saying
>        more than one MFD sub-device was required to be acceptable
[snip]
> +static int p1_rtc_read_time(struct device *dev, struct rtc_time *t)
> +{
> +	struct p1_rtc *p1 = dev_get_drvdata(dev);
> +	u8 time[tu_count];
> +	int ret;
> +
> +	ret = regmap_bulk_read(p1->regmap, RTC_COUNT_BASE, &time, sizeof(time));
> +	if (ret)
> +		return ret;

Hello,

Are you sure that you read the time parts consistently here? I mean:
is there a risk that the clock is updating below you - so that for
example during the transition

12:59:59 -> 13:00:00

you are going to read 12:00:00 or 12:59:00?

If so, you could for example read the time in a loop until you get
two same readouts.

> +
> +	t->tm_sec = time[tu_second] & GENMASK(5, 0);
> +	t->tm_min = time[tu_minute] & GENMASK(5, 0);
> +	t->tm_hour = time[tu_hour] & GENMASK(4, 0);
> +	t->tm_mday = (time[tu_day] & GENMASK(4, 0)) + 1;
> +	t->tm_mon = time[tu_month] & GENMASK(3, 0);
> +	t->tm_year = (time[tu_year] & GENMASK(5, 0)) + 100;

Is it necessary to use the bitmasks here? Are the higher bits undefined
in hardware? If so, is it necessary to mask them while writing the time
in p1_rtc_set_time()?

> +	/* tm_wday, tm_yday, and tm_isdst aren't used */
> +
> +	return 0;
> +}
> +
> +static int p1_rtc_set_time(struct device *dev, struct rtc_time *t)
> +{
> +	struct p1_rtc *p1 = dev_get_drvdata(dev);
> +	u8 time[tu_count];
> +	int ret;
> +
> +	time[tu_second] = t->tm_sec;
> +	time[tu_minute] = t->tm_min;
> +	time[tu_hour] = t->tm_hour;
> +	time[tu_day] = t->tm_mday - 1;
> +	time[tu_month] = t->tm_mon;
> +	time[tu_year] = t->tm_year - 100;
> +
> +	/* Disable the RTC to update; re-enable again when done */
> +	ret = regmap_update_bits(p1->regmap, RTC_CTRL, RTC_EN, 0);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_bulk_write(p1->regmap, RTC_COUNT_BASE, time, sizeof(time));
> +
> +	(void)regmap_update_bits(p1->regmap, RTC_CTRL, RTC_EN, RTC_EN);
Perhaps you shouldn't ignore any errors here - failing to restart
the clock should make p1_rtc_set_time() return an error code.
> +
> +	return ret;
> +}
> +

Greetings,

Mateusz


  reply	other threads:[~2025-06-23 19:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-22  3:29 [PATCH v3 0/7] spacemit: introduce P1 PMIC support Alex Elder
2025-06-22  3:29 ` [PATCH v3 1/7] dt-bindings: mfd: add support the SpacemiT P1 PMIC Alex Elder
2025-06-22  3:29 ` [PATCH v3 2/7] mfd: simple-mfd-i2c: add SpacemiT P1 support Alex Elder
2025-06-23 10:00   ` kernel test robot
2025-06-23 10:00   ` kernel test robot
2025-06-22  3:29 ` [PATCH v3 3/7] regulator: spacemit: support SpacemiT P1 regulators Alex Elder
2025-06-22  3:29 ` [PATCH v3 4/7] rtc: spacemit: support the SpacemiT P1 RTC Alex Elder
2025-06-23 18:54   ` Mateusz Jończyk [this message]
2025-06-23 19:57     ` Alex Elder
2025-06-23 19:14   ` Alexandre Belloni
2025-06-23 20:03     ` Alex Elder
2025-06-23 21:46       ` Alexandre Belloni
2025-06-22  3:29 ` [PATCH v3 5/7] riscv: dts: spacemit: enable the i2c8 adapter Alex Elder
2025-06-22  3:29 ` [PATCH v3 6/7] riscv: dts: spacemit: define fixed regulators Alex Elder
2025-06-22  3:29 ` [PATCH v3 7/7] riscv: dts: spacemit: define regulator constraints Alex Elder

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=d35922c4-fbd0-4d13-9bcd-2688b48c0045@o2.pl \
    --to=mat.jonczyk@o2.pl \
    --cc=alex@ghiti.fr \
    --cc=alexandre.belloni@bootlin.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlan@gentoo.org \
    --cc=elder@riscstar.com \
    --cc=guodong@riscstar.com \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=spacemit@lists.linux.dev \
    --cc=troymitchell988@gmail.com \
    --cc=wangruikang@iscas.ac.cn \
    /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;
as well as URLs for NNTP newsgroup(s).