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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251014123658.sobt6ab6gnbafyme@hu-kamalw-hyd.qualcomm.com>
Date: Tue, 14 Oct 2025 18:06:58 +0530
From: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: 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

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.

> 
> Konrad

Regards,
Kamal