Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc:     John Stultz <john.stultz@linaro.org>,
        Stephen Boyd <sboyd@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] alarmtimer: check RTC features instead of ops
In-Reply-To: <YJAX60DSp/imRstL@piout.net>
References: <20210429214902.2612338-1-alexandre.belloni@bootlin.com> <877dkkfdif.ffs@nanos.tec.linutronix.de> <YIu7ZqowGScElHBr@piout.net> <871rasf8qe.ffs@nanos.tec.linutronix.de> <YJAX60DSp/imRstL@piout.net>
Date:   Mon, 03 May 2021 20:00:53 +0200
Message-ID: <87wnsfd7e2.ffs@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Mon, May 03 2021 at 17:34, Alexandre Belloni wrote:
> On 30/04/2021 10:59:53+0200, Thomas Gleixner wrote:
>> I'm even more confused. So RTC0 does not have .set_alarm() but why does
>> it turn on RTC_FEATURE_ALARM? I'm obviously misinterpreting the above...
>> 
>
> I'm sorry for not being clear.
>
> With RTC0 not having alarms and RTC1 having alarms:
>
> The previous situation was:
>
> The driver for RTC0 didn't have any .set_alarm() to signel it doesn't
> support alarms.
> On registration, alarmtimer_rtc_add_device finds out it doesn't have the
> .set_alarm() callback and doesn't select that RTC.
> On registration of RTC1, alarmtimer_rtc_add_device finds .set_alarm()
> and RTC1 is now the alarmtimer rtcdev.
>
> The new situation is:
>
> The driver for RTC0 always have .set_alarm() but clears
> RTC_FEATURE_ALARM to signal it doesn't support alarms.
> On registration, alarmtimer_rtc_add_device finds .set_alarm() and RTC0
> is now the alarmtimer rtcdev, leading to an error when rtc_timer_start()
> is called.
>
> I hope this is clearer.

Yes, that makes sense now!