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: <bd43a198-6287-40b2-be15-2734c5d2742d@alliedtelesis.co.nz>
Date: Wed, 28 Feb 2024 20:21:35 +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 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.

> Otherwise, this looks good to me - although I do wonder if the
> authorship on the commit (attributed to the analog guys) is still
> accurate.

I think the binding is still pretty close to the last version sent out 
by the analog folks. The driver at this point is probably unrecognizable 
even though I've only really renamed stuff and moved functions around.

I was kind of hoping my prodding would be met with a "oh we've already 
done this in our SDK, here's the latest version" but that hasn't 
happened. I'm fairly close to dropping anything in this series that 
isn't related to the MAX31334 as that is the only hardware I can 
actually test.

>
> Thanks,
> Conor.