From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Waqar Hameed <waqar.hameed@axis.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
kernel@axis.com, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH v2 2/2] rtc: Add driver for Epson RX8111
Date: Fri, 17 Nov 2023 00:34:44 +0100 [thread overview]
Message-ID: <202311162334448082cd88@mail.local> (raw)
In-Reply-To: <pndo7g67t59.fsf@axis.com>
On 06/11/2023 15:36:55+0100, Waqar Hameed wrote:
>
> >> +#define RX8111_TIME_BUF_SZ (RX8111_REG_YEAR - RX8111_REG_SEC + 1)
> >> +#define RX8111_TIME_BUF_IDX(reg) \
> >> + ({ \
> >> + BUILD_BUG_ON_MSG(reg < RX8111_REG_SEC || reg > RX8111_REG_YEAR,\
> >> + "Invalid reg value"); \
> >> + (reg - RX8111_REG_SEC); \
> >> + })
> >
> > I don't feel like this is improving the legibility of the code.
>
> Sure, I just wanted to minimize `reg - RX8111_REG_SEC` expressions
> everywhere. I think it's a matter of taste here. I'll remove the
> macro `RX8111_TIME_BUF_IDX()` altogether.
Simply use offsets, using macro doesn't bring much as the rtc_tm member
name already carry the information.
>
>
> > Also, the BUILD_BUG_ON_MSG is never going to happen and doesn't
> > protect against a frequent issue.
>
> Yeah, it's probably not that frequent. Just wanted to help the next
> person here :)
Well, regmap will do the checking at runtime which is probably enough.
> >
> >> + if (ret) {
> >> + dev_err(data->dev,
> >> + "Could not disable extended functionality (%d)\n", ret);
> >
> > You should cut down on the number of message, this would be a bus error
> > and the user has no actual action after seeing the message.
>
> True, will convert it to `dev_dbg()` then.
Just to be clear, this applies to most of the error messages.
> >> +static int rx8111_read_time(struct device *dev, struct rtc_time *tm)
> >> +{
> >> + struct rx8111_data *data = dev_get_drvdata(dev);
> >> + u8 buf[RX8111_TIME_BUF_SZ];
> >> + unsigned int regval;
> >> + int ret;
> >> +
> >> + /* Check status. */
> >> + ret = rx8111_read_vl_flag(data, ®val);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + if (regval) {
> >> + dev_warn(data->dev,
> >> + "Low voltage detected, time is not reliable\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >
> > Should you check XST too?
>
> According to the datasheet
> (https://support.epson.biz/td/api/doc_check.php?dl=app_RX8111CE&lang=en),
> when the VLF bit is set, "Either power on reset _or_ X'tal oscillation
> stop is detected". It should therefore be sufficient to only check the
> VLF bit?
>
Not sure it is, maybe the oscillator has an issue that is not voltage
related? Or maybe it has been stopped explicitly and never restarted
(like when setting the time and then you get a bus error).
> However, I do understand that it's maybe more "robust" to also check XST
> (and to be able to distinguish and report it). We could add that.
>
> > And with this, using reg_field is worse.
>
> Reading two fields in the same register with `reg_field` sure is worse.
> If we now also want to check XST, a better (usual) way is to do a
> `regmap_read()` and then `FIELD_GET()`. What do you think?
Yes, REG_FIELD is what I prefer.
> >> + /* Start the clock. */
> >> + ret = regmap_field_write(data->regfields[RX8111_REGF_STOP], 0);
> >> + if (ret) {
> >> + dev_err(data->dev, "Could not start the clock (%d)\n", ret);
> >> + return ret;
> >> + }
> >> +
> >
> > You definitively need to handle XST here too.
>
> Do you mean to also clear XST the same way we clear VLF (before stopping
> the clock)?
Yes.
> >> + case RTC_VL_CLR:
> >> + return rx8111_clear_vl_flag(data);
> >
> > Do not allow userspace to clear VLF without setting the time.
>
> Hm, makes sense. Let's remove it here (since we already clear it in
> `rx8111_set_time()`).
>
> (I think I got "fooled" when doing a quick search and seeing some
> drivers allowing this. They sure are in the minority though...)
I think I removed most of those, the remaining one should be clearing a
bit that indicated low voltage and reduced functionality but not loss of
time/date which is right.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-11-16 23:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 10:25 [PATCH v2 0/2] Add a driver for Epson RX8111 RTC Waqar Hameed
2023-08-22 10:25 ` [PATCH v2 2/2] rtc: Add driver for Epson RX8111 Waqar Hameed
2023-09-26 9:20 ` Waqar Hameed
2023-11-03 22:53 ` Alexandre Belloni
2023-11-06 14:36 ` Waqar Hameed
2023-11-16 23:34 ` Alexandre Belloni [this message]
2023-08-22 10:25 ` [PATCH v2 1/2] dt-bindings: rtc: Add " Waqar Hameed
2023-08-22 11:48 ` Krzysztof Kozlowski
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=202311162334448082cd88@mail.local \
--to=alexandre.belloni@bootlin.com \
--cc=a.zummo@towertech.it \
--cc=kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=waqar.hameed@axis.com \
/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).