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
