linux-kernel - Re: [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output property

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: <20231026005008b8255799@mail.local>
Date:   Thu, 26 Oct 2023 02:50:08 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Javier Carrasco <javier.carrasco@...fvision.net>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-rtc@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: rtc: nxp,pcf8563: add hiz-output
 property

On 26/10/2023 01:23:21+0200, Javier Carrasco wrote:
> >>> +  hiz-output:
> >>> +    description:
> >>> +      Use enabled if the output should stay in high-impedance. This
> >>> +      mode will mask the output as an interrupt source.
> >>> +      Use sleep if the otuput should be only active in sleep mode.
> >>> +      This mode is compatible with any other output configuration.
> >>> +      The disabled value acts as if the property was not defined.
> >>> +    enum:
> >>> +      - enabled
> >>> +      - sleep
> >>> +      - disabled
> >>> +    default: disabled
> >>> +
> >>
> >> If instead of using a custom property, you consider this as what it
> >> actually is: pinmuxing, then everything else comes for free. With
> >> pinctrl, you can define different states for runtime and sleep and they
> >> will get applied automatically instead of open coding in the driver.
> 
> I am not sure if your solution would cover all my needs:
> 
> 1.- With pinctrl I can model the SoC pins, right? That would not stop
> the RTC output though, so the 32 kHz signal would be generated anyways
> even though the SoC would ignore it. That is one of the things I want to
> avoid.
> 

No, you would model the INTA pin.

> 2.- What happens if the RTC output is a clock for an external device
> that is only required when the SoC is in sleep mode? In that case I
> would like the RTC driver to control the output with the modes it provides.

Even if I doubt this is a valid use case, this would be possible as long
as the external device node has the correct pinctrl-* properties.


> >>
> >> Also, how you define this property means that everyone currently using
> >> this RTC is going to have a new warning that they should just ignore.
> >>
> >>
> > Thanks for your reply. The warning can only be triggered if the property
> > is defined, so in principle no one could have that warning yet. Only the
> > ones who actually define it and use an invalid value would get the warning.
> > 
> > On the other hand I did not consider your approach, which might make
> > this patch irrelevant. So I will have a look at it to make sure that it
> > achieves the same results.
> > 
> > Thanks again and best regards,
> > Javier Carrasco
> > 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com