LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Cc: linux-kernel@vger.kernel.org,
	Alessandro Zummo <a.zummo@towertech.it>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/4] RTC regression fixups
Date: Thu, 03 Feb 2011 13:37:27 -0800	[thread overview]
Message-ID: <1296769047.3336.332.camel@work-vm> (raw)
In-Reply-To: <AANLkTikgTNVkxeb+4HQonce-Y=z7EpxXn_SuwVj=EdE2@mail.gmail.com>

On Thu, 2011-02-03 at 18:31 -0200, Marcelo Roberto Jimenez wrote:
> Hi John,
> 
> Currently, the RTC driver _must_ declare the read_alarm() callback,
> even if it does nothing. But the code in drivers/rtc/interface.c does
> 
> 	if (rtc->ops == NULL)
> 		err = -ENODEV;
> 	else if (!rtc->ops->read_alarm)
> 		err = -EINVAL;
> 	else {
> 		memset(alarm, 0, sizeof(struct rtc_wkalrm));
> 		alarm->enabled = rtc->aie_timer.enabled;
> 		alarm->time = rtc_ktime_to_tm(rtc->aie_timer.node.expires);
> 	}
> 
> The read_alarm() callback is not being performed.

So this was recently added by d5553a556165535337ece8592f066407c62eec2e
to handle the cases where the driver didn't support alarm irqs, and the
error wasn't being properly propagated upwards.

> Two questions:
> 
> 1 - Should the callback be removed or should it be kept and called in
> the else part?

So, we probably should change the check to set_alarm or some other flag
to check if the hardware supports irqs, then remove the driver
read_alarm() function.


> 2 - In case we are keeping it, should it be enforced like it is now,
> or should it be kept optional? I'd rather have it optional, that means
> less useless code in the drivers.

Yes. We want to minimize the unnecessary code. I'll take a shot at it
shortly here.

Also, to avoid duplicate work, please see my dev/rtc-cleanups branch
here:
http://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=shortlog;h=refs/heads/dev/rtc-cleanups

I've got some patches that remove the dead irq_set_state, irq_set_freq
and update_irq_enable functions from the rtc drivers. It would be great
if you were able to give those patches a whirl to make sure I didn't
flub anything.

thanks
-john




  reply	other threads:[~2011-02-03 21:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03  2:14 John Stultz
2011-02-03  2:14 ` [PATCH 1/4] RTC: Prevents a division by zero in kernel code John Stultz
2011-02-03  2:14 ` [PATCH 2/4] RTC: Fix rtc driver ioctl specific shortcutting John Stultz
2011-02-03  8:43   ` Wolfram Sang
2011-02-03 19:01     ` John Stultz
2011-02-03  2:14 ` [PATCH 3/4] RTC: Convert rtc drivers to use the alarm_irq_enable method John Stultz
2011-02-03  2:14 ` [PATCH 4/4] RTC: Fix minor compile warning John Stultz
2011-02-03 17:30 ` [PATCH 0/4] RTC regression fixups Marcelo Roberto Jimenez
2011-02-03 19:16   ` John Stultz
2011-02-03 20:31     ` Marcelo Roberto Jimenez
2011-02-03 21:37       ` John Stultz [this message]
2011-02-03 22:27         ` john stultz

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=1296769047.3336.332.camel@work-vm \
    --to=john.stultz@linaro.org \
    --cc=a.zummo@towertech.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mroberto@cpti.cetuc.puc-rio.br \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH 0/4] RTC regression fixups' \
    /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

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).