Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Fri, 1 Apr 2022 19:26:35 +0200
From:   Alexandre Belloni <alexandre.belloni@bootlin.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     linux-rtc@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] RTC for 5.18
Message-ID: <Ykc1y1yQC3Z059Uo@mail.local>
References: <YkYpfK5ubwafd+Rw@mail.local>
 <CAHk-=wjuUZWMeUaTGtfivNQYeuqsQb2C4HnbbPLe+qFXU5Y70Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wjuUZWMeUaTGtfivNQYeuqsQb2C4HnbbPLe+qFXU5Y70Q@mail.gmail.com>
Precedence: bulk

On 01/04/2022 09:50:30-0700, Linus Torvalds wrote:
> On Thu, Mar 31, 2022 at 3:21 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > Here is the RTC subsystem pull request for 5.18. The bulk of the patches
> > are about replacing the uie_unsupported struct rtc_device member by a
> > feature bit.
> 
> Hmm.
> 
> I've pulled this, but I don't see the point of the ALARM_RES_2S bit.
> 
> In particular, I don't see it used anywhere, and the two drivers that
> now set it clear both the UPDATE_INTERRUPT and ALARM features.
> 
> So what's the point of that feature bit?
> 

The features member is exposed to userspace which will be the main
consumer in order to know what to expect from a particular RTC.

ALARM_RES_2S could also be used to forbid setting the alarm for two
consecutive seconds but this is not yet implemented as you observed.
This is not the most pressing issue but currently it is allowed and you
will not get any interrupt from the RTC for the second alarm so this is
silently ignored.
Note that these two are probably not the only ones that are affected,
those are the ones I did test.

Regards,

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