Re: [PATCH v5 0/2] drivers: rtc: add max313xx series rtc driver

["Nuno Sá" <noname.nuno@gmail.com>]

On Fri, 2024-02-02 at 00:28 +0000, Chris Packham wrote:
> 
> On 29/01/24 20:55, Nuno Sá wrote:
> > On Mon, 2024-01-29 at 03:28 +0000, Chris Packham wrote:
> > > On 26/01/24 20:51, Nuno Sá wrote:
> > > > On Fri, 2024-01-26 at 02:22 +0000, Chris Packham wrote:
> > > > > Hi All,
> > > > > 
> > > > > On 4/04/23 03:43, Ibrahim Tilki wrote:
> > > > > > changelog:
> > > > > > since v5:
> > > > > >      - dt-binding: add enum value "2" to aux-voltage-chargable
> > > > > >      - dt-binding: remove adi,trickle-diode-enable
> > > > > >      - dt-binding: change description of trickle-resistor-ohms
> > > > > >      - dt-binding: reorder as in example schema
> > > > > >      - parse "wakeup-source" when irq not requested
> > > > > >      - remove limitation on max31328 irq and clokout
> > > > > >      - remove error and warning messages during trickle charger setup
> > > > > > 
> > > > > > since v4:
> > > > > >      - dt-binding: remove interrupt names.
> > > > > >      - dt-binding: add description for "interrupts" property
> > > > > >      - dt-binding: replace deprecated property "trickle-diode-disable"
> > > > > >          by "aux-voltage-chargeable"
> > > > > >      - dt-binding: add new property "adi,trickle-diode-enable"
> > > > > >      - dt-binding: remove "wakeup-source"
> > > > > >      - use clear_bit instead of __clear_bit
> > > > > >      - use devm_of_clk_add_hw_provider instead of of_clk_add_provider
> > > > > >      - use chip_desc pointer as driver data instead of enum.
> > > > > > 
> > > > > > since v3:
> > > > > >      - add "break" to fix warning: unannotated fall-through
> > > > > >        Reported-by: kernel test robot <lkp@intel.com>
> > > > > > 
> > > > > > since v2:
> > > > > >      - dt-binding: update title and description
> > > > > >      - dt-binding: remove last example
> > > > > >      - drop watchdog support
> > > > > >      - support reading 12Hr format instead of forcing 24hr at probe time
> > > > > >      - use "tm_year % 100" instead of range check
> > > > > >      - refactor max313xx_init for readability
> > > > > > 
> > > > > > Ibrahim Tilki (2):
> > > > > >      drivers: rtc: add max313xx series rtc driver
> > > > > >      dt-bindings: rtc: add max313xx RTCs
> > > > > > 
> > > > > >     .../devicetree/bindings/rtc/adi,max313xx.yaml |  144 +++
> > > > > >     drivers/rtc/Kconfig                           |   11 +
> > > > > >     drivers/rtc/Makefile                          |    1 +
> > > > > >     drivers/rtc/rtc-max313xx.c                    | 1053
> > > > > > +++++++++++++++++
> > > > > >     4 files changed, 1209 insertions(+)
> > > > > >     create mode 100644
> > > > > > Documentation/devicetree/bindings/rtc/adi,max313xx.yaml
> > > > > >     create mode 100644 drivers/rtc/rtc-max313xx.c
> > > > > What happened to this series in the end? It kind of went off my radar
> > > > > and I forgot about it.
> > > > > 
> > > > > We've been carrying a version of these changes in our local tree for a
> > > > > while (and using it quite happily I should add).
> > > > > 
> > > > Hi Chris,
> > > > 
> > > > Also not sure.... In the meantime Ibrahim left ADI so if this is not in
> > > > shape to
> > > > be merged he won't be able to re-spin. If there's a need for a re-spin,
> > > > please
> > > > let me know so I can see internally if there's someone who can continue this
> > > > work. I would do it myself if I had the HW.
> > > I've got a board with a max31331 so I can test that. I don't have any of
> > > the interrupts hooked up so I won't be able to test that. Looks like
> > > there was some outstanding discussion around the trickle-charge
> > > devicetree properties so I'd need to figure out what was wanted there.
> > > I'll try to pick up the last series from the mailing list and go from there.
> 
> I see that in the meantime Antoniu has landed a max31335 driver. Does 
> anyone know off-hand how close the max31335 is to the other max313xx 
> variants? Should I leave them separate or attempt to integrate the two.
> 

Hi Chris,

I did not looked into the devices datasheets but typically, if the register map is
close enough we should try to integrate them in the same driver.

Thanks for continuing this work btw!
- Nuno Sa