On 27.01.2016 12:36, Javier Martinez Canillas wrote:

The MAX77686 and MAX77802 RTC IP blocks are very similar with only
these differences:

0) The RTC registers layout and addresses are different.

1) The MAX77686 use 1 bit of the sec/min/hour/etc registers as the
   alarm enable while MAX77802 has a separate register for that.

2) The MAX77686 RTCYEAR register valid values range is 0..99 while
   for MAX77802 is 0..199.

3) The MAX77686 has a separate I2C address for the RTC registers
   while the MAX77802 uses the same I2C address as the PMIC regs.

5) The minimum delay before a RTC update (16 msecs vs 200 usecs).

There are separate drivers for MAX77686 and MAX77802 RTC IP blocks
but the differences are not that big so the driver can be extended
to support both instead of duplicating a lot of code in 2 drivers.

Suggested-by: Krzysztof Kozlowski <redacted>
Signed-off-by: Javier Martinez Canillas <redacted>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Krzysztof Kozlowski <redacted>
Reviewed-by: Andi Shyti <redacted>

---

Changes in v4:
- Add Krzysztof Kozlowski's Tested-by tag to patch #6.
- Add Andi Shyti's Reviewed-by tag to patch #6.
- Reverse alarm enable reg check logic. Suggeted by Krzysztof Kozlowski.
- Return early to avoid an else statement. Suggested by Andi Shyti.

Changes in v3:
- Add Laxman Dewangan's Acked-by tag to patch #6.

Changes in v2:
- Add a MAX77802 prefix to ALARM_ENABLE_VALUE. Suggested by Krzysztof Kozlowski.
- Rename .rtcae to .alarm_enable_reg and .rtcrm to .separate_i2c_addr.
  Suggested by Krzysztof Kozlowski.
- Don't use func and LINE in error messages. Suggested by Krzysztof Kozlowski.
- Remove REG_RTC_AE2 since is not used by neither max77686 nor max77802.
- Check if REG_RTC_AE1 has a valid address before accessing it.

 drivers/rtc/rtc-max77686.c | 196 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 156 insertions(+), 40 deletions(-)

Reviewed-by: Krzysztof Kozlowski <redacted>

One comment at the end...

[...]

At this stage I don't like the idea of messing with parent's state
structure. The driver should not modify any of parents data (the best
way would be to take a pointer to const). In this patch this looks like
breaking the encapsulation. If the parent is responsible for regmaps,
then the parent should set rtc_regmap for children (parent also knows
what type device it is working on).

...but I am assuming that a new patch will be following this one - the
patch moving ownership of i2c dummy and regmap to the RTC driver. In
that case this code makes a lot more sense. Am I thinking correctly?

Best regards,
Krzysztof

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.