linux-kernel - Re: [PATCH v8 2/2] dt-bindings: rtc: add max313xx RTCs

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: <b2ebc2a7-0347-40a0-8302-c84ba898fd16@alliedtelesis.co.nz>
Date: Thu, 29 Feb 2024 20:11:16 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Conor Dooley <conor@...nel.org>
CC: "antoniu.miclaus@...log.com" <antoniu.miclaus@...log.com>,
	"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>, "jdelvare@...e.com"
	<jdelvare@...e.com>, "linux@...ck-us.net" <linux@...ck-us.net>,
	"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>, "Zeynep
 Arslanbenzer" <Zeynep.Arslanbenzer@...log.com>
Subject: Re: [PATCH v8 2/2] dt-bindings: rtc: add max313xx RTCs


On 1/03/24 07:07, Conor Dooley wrote:
> On Wed, Feb 28, 2024 at 08:21:35PM +0000, Chris Packham wrote:
>> On 29/02/24 00:58, Conor Dooley wrote:
>>> On Tue, Feb 27, 2024 at 02:03:10PM +1300, Chris Packham wrote:
>>>
>>>>      interrupts:
>>>> +    description:
>>>> +      Alarm1 interrupt line of the RTC. Some of the RTCs have two interrupt
>>>> +      lines and alarm1 interrupt muxing depends on the clockin/clockout
>>>> +      configuration.
>>>>        maxItems: 1
>>> The maxItems: 1 looks odd here when you state "some of the RTCs have two
>>> interrupt lines", which makes it sound as if there are actually two
>>> interrupts that should be exposed here. If those two interrupts get
>>> muxed to the same pin for output I'd suggest that you clarify that here.
>> This may end up changing if I can come up with something that Alexandre
>> is happy with. Basically (some of) the chips have a configurable pin
>> that can either be dedicated to the ALARM1 output (annoyingly labelled
>> as INTB) or to a clock output. There is an INTA line that has other
>> interrupts and if the clock output option is used then it also has
>> ALARM1. The driver doesn't currently do anything with the other
>> interrupt sources so as written this needs to correspond to whichever
>> interrupt output is asserted for ALARM1.
> So you're saying that depending on whether or not the clock output is
> used, there could be two interrupts?
Correct.
> Without looking further, it sounds like you should be setting maxItems
> to 1 if #clock-cells is present and to 2 if it is not.
My idea was an explicit property about the function of the INTB/CLKOUT 
pin. The current code does use #clock-cells as a proxy for this (and 
Alexandre has some concerns with how this is handled).
>   Then if there are
> two interrupts provided, the driver is free to configure whatever way it
> wants. If there aren't, send everything to INTA.
>
> Am I missing something?

Right now the only interrupt that the RTC cares about is for ALARM1 
(which moves between INTA and INTB depending on the clock config). There 
are other hardware events and an ALARM2 that can generate an interrupt 
but these are ignored. I don't think the rtc framework supports more 
than one alarm.

Binding wise I think this should take 1 or 2 interrupts. For simplicity 
the first interrupt should always correspond to ALARM1 (which could be 
INTB or INTA depending on the hardware design). The 2nd interrupt (if 
supplied) would be for the other events (which we don't currently do 
anything with).