linux-kernel - RE: [PATCH 2/2] dt-bindings: rtc: add bindings for 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: <DM8PR03MB6247E7E2C830482CE3F7D8BA962D9@DM8PR03MB6247.namprd03.prod.outlook.com>
Date:   Fri, 21 Oct 2022 13:56:02 +0000
From:   "Tilki, Ibrahim" <Ibrahim.Tilki@...log.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
CC:     "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "Arslanbenzer, Zeynep" <Zeynep.Arslanbenzer@...log.com>
Subject: RE: [PATCH 2/2] dt-bindings: rtc: add bindings for max313xx RTCs

> On 21/10/2022 09:05, Tilki, Ibrahim wrote:
> >> On 21/10/2022 11:44:12+0000, Tilki, Ibrahim wrote:
> >>>>> +  interrupt-names:
> >>>>> +    description: |
> >>>>> +      Name of the interrupt pin of the RTC used for IRQ. Not required for
> >>>>> +      RTCs that only have single interrupt pin available. Some of the RTCs
> >>>>> +      share interrupt pins with clock input/output pins.
> >>>>> +    minItems: 1
> >>>>> +    items:
> >>>>> +      - enum: [INTA, INTB]
> >>>>> +      - enum: [INTA, INTB]
> >>>>> +
> >>>>
> >>>> I don't think this is right, what this is doing is essentially 
> >>>> pinmuxing interrupts versus clocks. What happens if you want INTB 
> >>>> but this goes directly to a PMIC instead of the SoC?
> >>>> It is not something you can express with your current bindings.
> >>>>
> >>>
> >>> Why would a user want INTB when it is not connected to SoC?
> >>> User can specify none, either one or both of the interrupt pins.
> >>> I don't see what the problem here is.
> >>>
> >>
> >> the interrupt pin may be connected to a PMIC that is able to start or 
> >> wake up the platform. In that case, the user would not have any 
> >> interrupt-names and your driver will fail to mux the interrupt on INTB.
> >> Please fix.
> > 
> > Interrupt muxing depends on the clock configuration, not the interrupt-names property.
> > Devices don't support muxing the alarm interrupt independently.
> > 
> > For example in the case of max31329, alarm interrupt is muxed into INTA by default.
> > Alarm interrupt is muxed into INTB pin if and only if clkin is 
> > enabled.\
> 
> Just to be sure: are you now describing hardware or Linux driver behavior?
> 

That is hardware behavior.

Below is Interrupt Modes Table from max31329 datasheet:
+--------+---------+------------------------------------------+-----------------------------------------+
| ENCLKO | ENCLKIN |               INTA/CLKIN                 |               INTB/CLKOUT               |
+--------+---------+------------------------------------------+-----------------------------------------+
|      0 |       0 | INTA: Alarm1, Timer, PFAIL, DIN          | INTB: Alarm2                            |
|      0 |       1 | CLKIN                                    | INTB: Alarm1, Alarm2, Timer, PFAIL, DIN |
|      1 |       0 | INTA: Alarm1, Alarm2, Timer, PFAIL, DIN  | CLKOUT                                  |
|      1 |       1 | CLKIN                                    | CLKOUT                                  |
+--------+---------+------------------------------------------+-----------------------------------------+

> > 
> > This means that if a user wants the alarm interrupt on INTB pin, they 
> > have to provide a clock input through "clocks" property. If that is 
> > the case, they can provide an interrupt for INTB pin, otherwise the alarm feature of the rtc gets disabled.
> > 
> > Side note: Some devices have 2 Alarms but Alarm2 does not have a 
> > register for matching "seconds" so only Alarm1 is used by the driver.


Regards,
Ibrahim