linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Esben Haabendal <esben@geanix.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] rtc: isl12022: Add alarm support
Date: Wed, 11 Sep 2024 14:24:17 +0200	[thread overview]
Message-ID: <20240911122417388bd35c@mail.local> (raw)
In-Reply-To: <87mske7gaw.fsf@geanix.com>

On 11/09/2024 10:20:07+0200, Esben Haabendal wrote:
> Alexandre Belloni <alexandre.belloni@bootlin.com> writes:
> 
> > Hello Esben,
> >
> > On 10/09/2024 12:27:11+0200, Esben Haabendal wrote:
> >> The ISL12022 RTC has a combined INT/fOUT pin, which can be used for alarm
> >> interrupt when frequency output is not enabled.
> >> 
> >> The device-tree bindings should ensure that interrupt and clock output is
> >> not enabled at the same time.
> >
> > Ideally, we would get a pinmuxing part in the driver to ensure this ;)
> 
> I hope we can leave this as future work :)

Sure.

> 
> >> +static int isl12022_rtc_read_alarm(struct device *dev,
> >> +				   struct rtc_wkalrm *alarm)
> >> +{
> >> +	struct rtc_time *const tm = &alarm->time;
> >> +	struct isl12022 *isl12022 = dev_get_drvdata(dev);
> >> +	struct regmap *regmap = isl12022->regmap;
> >> +	uint8_t buf[ISL12022_ALARM_SECTION_LEN];
> >> +	int ret, yr, i;
> >> +
> >> +	ret = regmap_bulk_read(regmap, ISL12022_ALARM_SECTION,
> >> +			       buf, sizeof(buf));
> >> +	if (ret) {
> >> +		dev_err(dev, "%s: reading ALARM registers failed\n",
> >> +			__func__);
> >
> > I don't really like those error messages because there is nothing the
> > user can actually do apart from trying again and this bloats the
> > kernel.
> 
> Ok. Maybe keep it as dev_dbg() then?

This is fine, there are other I didn't point out.

> >
> >> +	/* The alarm doesn't store the year so get it from the rtc section */
> >> +	ret = regmap_read(regmap, ISL12022_REG_YR, &yr);
> >> +	if (ret) {
> >> +		dev_err(dev, "%s: reading YR register failed\n", __func__);
> >
> > Ditto
> 
> Ditto.
> 
> >> +	isl12022->rtc = rtc;
> >>  
> >>  	rtc->ops = &isl12022_rtc_ops;
> >>  	rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
> >>  	rtc->range_max = RTC_TIMESTAMP_END_2099;
> >>  
> >> +	if (client->irq > 0) {
> >> +		ret = isl12022_setup_irq(isl12022, client->irq);
> >
> > You can't do this in probe, the RTC lifecycle is longer than the linux
> > system. Or said differently: "oh no, my linux has rebooted and now I
> > lost my future alarm" ;)
> 
> Oh.
> 
> We do need to setup the irq here, so I assume you mean I need to drop
> the part of _setup_irq() that clears alarm registers.

Yes, this is the main problematic part. The other one being disabling
the IRQ output when in battery backup mode as this will surely prevent
wakeup of some devices.

> 
> And I guess we need to enable irq in probe as well. At least if/when an
> alarm is set. I think it should be safe to enable irq unconditionally in
> _probe()...

I guess you mean requesting the interrupt on the SoC side. Enabling the
RTC interrupt should be left untouched in the probe.


> 
> >> +		if (ret)
> >> +			return ret;
> >> +	} else {
> >> +		clear_bit(RTC_FEATURE_ALARM, rtc->features);
> >> +	}
> >> +
> >>  	return devm_rtc_register_device(rtc);
> >>  }
> 
> /Esben

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2024-09-11 12:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 10:27 [PATCH 0/2] rtc: isl12022: Add alarm support Esben Haabendal
2024-09-10 10:27 ` [PATCH 1/2] rtc: isl12022: Prepare for extending rtc device drvdata Esben Haabendal
2024-09-10 17:32   ` Rasmus Villemoes
2024-09-10 10:27 ` [PATCH 2/2] rtc: isl12022: Add alarm support Esben Haabendal
2024-09-10 19:13   ` Rasmus Villemoes
2024-09-11  8:11     ` Esben Haabendal
2024-09-11  9:15       ` Rasmus Villemoes
2024-09-11 10:53         ` Esben Haabendal
2024-09-10 19:39   ` Alexandre Belloni
2024-09-11  8:20     ` Esben Haabendal
2024-09-11 12:24       ` Alexandre Belloni [this message]
2024-09-12  7:09         ` Esben Haabendal
2024-09-12  8:21           ` Alexandre Belloni
2024-09-12  8:59             ` Esben Haabendal

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=20240911122417388bd35c@mail.local \
    --to=alexandre.belloni@bootlin.com \
    --cc=esben@geanix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    /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).