Re: [PATCH v5 2/2] dt-bindings: rtc: add max313xx RTCs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/04/2023 14:26:18+0200, Alexandre Belloni wrote:
> On 04/04/2023 10:35:53+0000, Tilki, Ibrahim wrote:
> > >>>>> +  aux-voltage-chargeable:
> > >>>>> +    enum: [0, 1, 2]
> > >>>>> +    description: |
> > >>>>> +      Enables trickle charger.
> > >>>>> +      0: Charger is disabled (default)
> > >>>>> +      1: Charger is enabled
> > >>>>> +      2: Charger is enabled with a diode
> > >>>>
> > >>>> 2 is not an allowed value. I asked to drop this property. It is coming
> > >>>> from rtc.yaml. I also do not understand "with a diode". So otherwise it
> > >>>> is charging with, I don't know, FET?
> > >>>
> > >>> No, what is not explained here (and maybe not unsterstood by the
> > >>> submitter) is that the RTC has an extra diode so, charging will always
> > >>> enable a diode, select a resistor and then have or not an extra diode.
> > >>> Figure2 of the MAX31329 datasheet is great.
> > >>>
> > >> 
> > >> That is exactly why I had "adi,trickle-diode-enable" property in previous patch.
> > >> So if I can't have "adi,trickle-diode-enable" and can't add an additional value
> > >> to "aux-voltage-chargeable", I am not sure how to add support for the extra
> > >> diode at this point.
> > >
> > > Ask the person who asked you to remove adi,trickle-diode-enable...
> > 
> > That was the purpose.
> > 
> 
> If the earlier submission was clearer my answer would have been
> different but note how I had to dig up the datasheet to understand there
> were two diodes. All the trickle chargers have a schottky diode so
> "adi,trickle-diode-enable" nor the commit log were explicit about the
> second diode (which is a regular diode).
> 
> aux-voltage-chargeable is enabling a diode on all the existing RTC
> drivers so instead of trying to make me look like the bad guy you should
> rather thank for taking the time trying to get better DT bindings.
> 

BTW, Krzysztof, you should focus more on how v5 of the driver is still
abusing the #clock-cells property to do pinmuxing after I repeatedly
explain to not do that.


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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux