linux-kernel - Re: [PATCH v3 1/5] rtc: pm8xxx: implement qcom,no-alarm flag for non-HLOS owned alarm

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: <Zw-5TA9SZtZ_gSIP@hovoldconsulting.com>
Date: Wed, 16 Oct 2024 15:02:04 +0200
From: Johan Hovold <johan@...nel.org>
To: Jonathan Marek <jonathan@...ek.ca>
Cc: linux-arm-msm@...r.kernel.org,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	"open list:REAL TIME CLOCK (RTC) SUBSYSTEM" <linux-rtc@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/5] rtc: pm8xxx: implement qcom,no-alarm flag for
 non-HLOS owned alarm

On Wed, Oct 16, 2024 at 08:44:26AM -0400, Jonathan Marek wrote:
> On 10/16/24 2:42 AM, Johan Hovold wrote:
> > On Mon, Oct 14, 2024 at 08:47:26PM -0400, Jonathan Marek wrote:
> >> Qualcomm x1e80100 firmware sets the ownership of the RTC alarm to ADSP.
> >> Thus writing to RTC alarm registers and receiving alarm interrupts is not
> >> possible.
> >>
> >> Add a qcom,no-alarm flag to support RTC on this platform.
> > 
> > An alternative may be to drop the alarm interrupt from DT and use that
> > as an indicator.
> 
> That wouldn't be right, the registers/interrupt still exist and should 
> be described in DT.

Yeah, the registers are still there, and are probably readable too
(IIRC), but the OS will never receive any interrupts.

> (if you have firmware that allows access to the alarm, now you only have 
> to delete the qcom,no-alarm property in your dts to use it)

Fair enough. And the new flag mirrors the old.

> >> Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
> >> ---
> >>   drivers/rtc/rtc-pm8xxx.c | 44 +++++++++++++++++++++++++++-------------
> >>   1 file changed, 30 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/rtc/rtc-pm8xxx.c b/drivers/rtc/rtc-pm8xxx.c
> >> index c32fba550c8e0..1e78939625622 100644
> >> --- a/drivers/rtc/rtc-pm8xxx.c
> >> +++ b/drivers/rtc/rtc-pm8xxx.c
> >> @@ -61,6 +61,7 @@ struct pm8xxx_rtc {
> >>   	struct rtc_device *rtc;
> >>   	struct regmap *regmap;
> >>   	bool allow_set_time;
> >> +	bool no_alarm;
> > 
> > How about inverting this one and naming it has_alarm or similar to avoid
> > the double negation in your conditionals (!no_alarm)?
> > 
> 
> My reasoning is that the DT flag has to be negative, and its better to 
> use the same name as the DT flag, but inverting it is OK.

I agree about the dt parameter, but I still I prefer a non-negated
variable (similar to allow_set_time).

> >>   	int alarm_irq;
> >>   	const struct pm8xxx_rtc_regs *regs;
> >>   	struct device *dev;
> >> @@ -473,9 +474,14 @@ static int pm8xxx_rtc_probe(struct platform_device *pdev)
> >>   	if (!rtc_dd->regmap)
> >>   		return -ENXIO;
> >>   
> >> -	rtc_dd->alarm_irq = platform_get_irq(pdev, 0);
> >> -	if (rtc_dd->alarm_irq < 0)
> >> -		return -ENXIO;
> >> +	rtc_dd->no_alarm = of_property_read_bool(pdev->dev.of_node,
> >> +						 "qcom,no-alarm");
> >> +
> > 
> > Stray newline.
> > 
> 
> That's not a stray newline?

There was no empty line between the assignment and check before this
change, but now there is even though there should not be.
 
> >> +	if (!rtc_dd->no_alarm) {
> >> +		rtc_dd->alarm_irq = platform_get_irq(pdev, 0);
> >> +		if (rtc_dd->alarm_irq < 0)
> >> +			return -ENXIO;
> >> +	}

Johan