linux-kernel - Re: [PATCH 17/24] arm64: dts: qcom: glymur-crd: Avoid RTC probe failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cgfxsjr53dz5i3pjinljywah4b2jgeomnglranaty6cazek5wb@gyjpt4auwchd>
Date: Tue, 14 Oct 2025 22:52:10 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Pankaj Patil <pankaj.patil@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/24] arm64: dts: qcom: glymur-crd: Avoid RTC probe
 failure

On Tue, Oct 14, 2025 at 06:06:58PM +0530, Kamal Wadhwa wrote:
> Hi Konrad, 
> 
> On Tue, Oct 14, 2025 at 12:23:23PM +0200, Konrad Dybcio wrote:
> > On 10/13/25 1:04 PM, Kamal Wadhwa wrote:
> > > On Mon, Oct 06, 2025 at 04:28:59PM +0200, Konrad Dybcio wrote:
> > >> On 10/1/25 2:23 PM, Kamal Wadhwa wrote:
> > >>> Hi Krzysztof,
> > >>>
> > >>> On Thu, Sep 25, 2025 at 1:41 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > >>>>
> > >>>> On Thu, 25 Sept 2025 at 15:34, Pankaj Patil
> > >>>> <pankaj.patil@....qualcomm.com> wrote:
> > >>>>>
> > >>>>> From: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
> > >>>>>
> > >>>>> On Glymur boards, the RTC alarm interrupts are routed to SOCCP
> > >>>>> subsystems and are not available to APPS. This can cause the
> > >>>>> RTC probe failure as the RTC IRQ registration will fail in
> > >>>>> probe.
> > >>>>>
> > >>>>> Fix this issue by adding `no-alarm` property in the RTC DT
> > >>>>> node. This will skip the RTC alarm irq registration and
> > >>>>> the RTC probe will return success.
> > >>>>
> > >>>>
> > >>>> This is ridiculous. You just added glymur CRD and you claim now that
> > >>>> it's broken and you need to fix it. So just fix that commit!
> > >>>
> > >>> I'm afraid, but this is an actual limitation we have for Glymur
> > >>> (compared to Kaanapali).
> > >>> The RTC is part of the pmk8850.dtsi that is common between Kaanapali and
> > >>> Glymur. On Glymur (unlike Kaanapali) the APPS processor does *not* have the RTC
> > >>> IRQ permission for the RTC peripheral.
> > >>
> > >> This is interesting.. is that a physical limitation, or some sort of
> > >> a software security policy?
> > > 
> > > This is mostly a limitation for all compute targets(like Glymur). On compute
> > > targets we need to support ACPI TAD feature[1] this feature uses the RTC alarm.
> > > In a nutshell, this feature implements 2 times - AC ( adaptor power) and
> > > DC (battery power) timers, and based on active power source(AC or DC?) at the
> > > time of timer expiry device will either go for a full bootup or stay in power
> > > down.
> > > 
> > > This feature is implemented on a different subsystem (SoCCP subsystem), and
> > > since the SPMI `IRQ` permissions can only be assigned to only one subsystem,
> > > so we can't use the alarms on APPS. This is why we use no-alarms DT to register
> > > RTC device without alarm-irq support.
> > > 
> > > [1] TAD specification - https://uefi.org/sites/default/files/resources/ACPI_5.pdf
> > > section 9.18
> > 
> > Hm, is there maybe some sort of an interface to talk to the SoCCP
> > and set the RTC as we wish, from the OS?
> 
> Yes, the developement is almost done and we have done some testing as well, but
> that kernel driver needs some more cleanup and testing before posting to
> upstream. This will be added in future.

If the series is reposted, please add a comment, pointing out that this
is a temporal measure and should be removed later.

-- 
With best wishes
Dmitry