Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-29 Thread Jerry Hoemann
On Tue, Jan 29, 2019 at 09:01:03AM +0200, Matti Vaittinen wrote:
> On Mon, Jan 28, 2019 at 01:26:56PM -0700, Jerry Hoemann wrote:
> > On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:
> > > On 1/25/19 3:05 AM, Matti Vaittinen wrote:
> > > > +static int bd70528_set_wake(struct bd70528 *bd70528,
> > > > +   int enable, int *old_state)
> > > > +{
> > > > +   int ret;
> > > > +   unsigned int ctrl_reg;
> > > > +
> > > > +   ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WAKE_EN, 
> > > > &ctrl_reg);
> > > > +   if (ret)
> > > > +   return ret;
> > > > +
> > > > +   if (old_state) {
> > > > +   if (ctrl_reg & BD70528_MASK_WAKE_EN)
> > > > +   *old_state |= BD70528_WAKE_STATE_BIT;
> > > > +   else
> > > > +   *old_state &= ~BD70528_WAKE_STATE_BIT;
> > > > +
> > > > +   if ((!enable) == (!(*old_state & 
> > > > BD70528_WAKE_STATE_BIT)))
> > > > +   return 0;
> > > 
> > > I think
> > >   if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
> > > would be much better readable. Even if not, there are way too many ()
> > > in the above conditional.
> > > 
> > 
> > The substitution is not equivalent to original.  I think you mean:
> > 
> > if (!!enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
> 
> Thanks Jerry! Good catch! I originally wanted that all non-zero values
> of 'enable' would be 'true'. So maybe I just use the original approach
> but get rid of extra parenthesis which were pointed out by Guenter.
> 
>   if (!enable == !(*old_state & BD70528_WAKE_STATE_BIT))
> should do it just fine, right?
> 

The use of "!!" to turn an int into one of two Boolean values (0 | 1)
is used extensively in Linux and as such might make the intent of
the code a bit clearer which I take as checking to see the states
match.

But, I will defer to you and Guenter on the question.

-- 

-
Jerry Hoemann  Software Engineer   Hewlett Packard Enterprise
-


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-29 Thread Matti Vaittinen
Hello Alexandre,

Big thanks for the review!

On Mon, Jan 28, 2019 at 10:20:09PM +0100, Alexandre Belloni wrote:
> Hello,
> 
> On 25/01/2019 13:05:36+0200, Matti Vaittinen wrote:
> > +static const struct rtc_class_ops bd70528_rtc_ops = {
> > +   .read_time  = bd70528_get_time,
> > +   .set_time   = bd70528_set_time,
> > +   .read_alarm = bd70528_read_alarm,
> > +   .set_alarm  = bd70528_set_alarm,
> 
> You actually need to provide a .alarm_irq_enable callback, else there is
> no way to disable a set alarm.

Glad that you pointed this out. I thought the RTC core would use
set_alarm with enabled in struct rtc_wkalrm being zero for disabling
the alarm. I'll add alarm_irq_enable for disabling alarm at v3.

> > +   rtc = devm_rtc_device_register(&pdev->dev, "bd70528-rtc",
> > +  &bd70528_rtc_ops, THIS_MODULE);
> > +   if (IS_ERR(rtc)) {
> > +   dev_err(&pdev->dev, "Registering RTC failed\n");
> > +   return PTR_ERR(rtc);
> > +   }
> 
> Please use devm_rtc_allocate_device() and set rtc->range_min and
> rtc->range_max before registering with rtc_register_device() (which can
> be done after trying to request the irq).

Right. I should've noted that devm_rtc_device_register was marked
deprecated. I'll fix this too at v3.

Br,
Matti Vaittinen


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-28 Thread Matti Vaittinen
On Mon, Jan 28, 2019 at 01:26:56PM -0700, Jerry Hoemann wrote:
> On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:
> > On 1/25/19 3:05 AM, Matti Vaittinen wrote:
> > > +static int bd70528_set_wake(struct bd70528 *bd70528,
> > > + int enable, int *old_state)
> > > +{
> > > + int ret;
> > > + unsigned int ctrl_reg;
> > > +
> > > + ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WAKE_EN, &ctrl_reg);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (old_state) {
> > > + if (ctrl_reg & BD70528_MASK_WAKE_EN)
> > > + *old_state |= BD70528_WAKE_STATE_BIT;
> > > + else
> > > + *old_state &= ~BD70528_WAKE_STATE_BIT;
> > > +
> > > + if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
> > > + return 0;
> > 
> > I think
> > if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
> > would be much better readable. Even if not, there are way too many ()
> > in the above conditional.
> > 
> 
> The substitution is not equivalent to original.  I think you mean:
> 
>   if (!!enable == !!(*old_state & BD70528_WAKE_STATE_BIT))

Thanks Jerry! Good catch! I originally wanted that all non-zero values
of 'enable' would be 'true'. So maybe I just use the original approach
but get rid of extra parenthesis which were pointed out by Guenter.

if (!enable == !(*old_state & BD70528_WAKE_STATE_BIT))
should do it just fine, right?

Br,
Matti


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-28 Thread Alexandre Belloni
Hello,

On 25/01/2019 13:05:36+0200, Matti Vaittinen wrote:
> +static const struct rtc_class_ops bd70528_rtc_ops = {
> + .read_time  = bd70528_get_time,
> + .set_time   = bd70528_set_time,
> + .read_alarm = bd70528_read_alarm,
> + .set_alarm  = bd70528_set_alarm,

You actually need to provide a .alarm_irq_enable callback, else there is
no way to disable a set alarm.

> + rtc = devm_rtc_device_register(&pdev->dev, "bd70528-rtc",
> +&bd70528_rtc_ops, THIS_MODULE);
> + if (IS_ERR(rtc)) {
> + dev_err(&pdev->dev, "Registering RTC failed\n");
> + return PTR_ERR(rtc);
> + }

Please use devm_rtc_allocate_device() and set rtc->range_min and
rtc->range_max before registering with rtc_register_device() (which can
be done after trying to request the irq).


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


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-28 Thread Jerry Hoemann
On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:
> On 1/25/19 3:05 AM, Matti Vaittinen wrote:



> > +static int bd70528_set_wake(struct bd70528 *bd70528,
> > +   int enable, int *old_state)
> > +{
> > +   int ret;
> > +   unsigned int ctrl_reg;
> > +
> > +   ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WAKE_EN, &ctrl_reg);
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (old_state) {
> > +   if (ctrl_reg & BD70528_MASK_WAKE_EN)
> > +   *old_state |= BD70528_WAKE_STATE_BIT;
> > +   else
> > +   *old_state &= ~BD70528_WAKE_STATE_BIT;
> > +
> > +   if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
> > +   return 0;
> 
> I think
>   if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
> would be much better readable. Even if not, there are way too many ()
> in the above conditional.
> 

The substitution is not equivalent to original.  I think you mean:

if (!!enable == !!(*old_state & BD70528_WAKE_STATE_BIT))



-- 

-
Jerry Hoemann  Software Engineer   Hewlett Packard Enterprise
-


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-28 Thread Matti Vaittinen
On Mon, Jan 28, 2019 at 06:02:47AM -0800, Guenter Roeck wrote:
> On 1/27/19 11:48 PM, Matti Vaittinen wrote:
> > Thanks again Guenter,
> > 
> > On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:
> > > On 1/25/19 3:05 AM, Matti Vaittinen wrote:
> > > > +/*
> > > > + * We read regs RTC_SEC => RTC_YEAR
> > > > + * this struct is ordered according to chip registers.
> > > > + * Keep it u8 only to avoid padding issues.
> > > > + */
> > > > +struct bd70528_rtc_day {
> > > > +   u8 sec;
> > > > +   u8 min;
> > > > +   u8 hour;
> > > > +};
> > > > +
> > > > +struct bd70528_rtc_data {
> > > > +   struct bd70528_rtc_day time;
> > > > +   u8 week;
> > > > +   u8 day;
> > > > +   u8 month;
> > > > +   u8 year;
> > > > +};
> > > > +
> > > > +struct bd70528_rtc_wake {
> > > > +   struct bd70528_rtc_day time;
> > > > +   u8 ctrl;
> > > > +};
> > > > +
> > > > +struct bd70528_rtc_alm {
> > > > +   struct bd70528_rtc_data data;
> > > > +   u8 alm_mask;
> > > > +   u8 alm_repeat;
> > > > +};
> > > 
> > > At least some of the above are directly associated with chip registers.
> > > I don't think this will work for all architectures without explicit packed
> > > attribute.
> > 
> > Allright. I was thinking of that but thought that most of the
> > architectures using this PMIC would handle alignments fine if I used
> > only u8 members. I did consider using __attribute__((packed)) - but I'm
> > not sure if we hit into troubles with that too. I guess some people
> > would like to compile kernel with other compiler(s) but gcc - although
> > I'm not sure if this should be taken into account. I'll try doing some
> > study on this - unless someone replies to this and just tells how this
> > should be done. (I am pretty sure I can find the answer from mail
> > archives though). I'll try adding some packing hint for compiler at v3.
> > 
> 
> Use __packed ?

Right. That appends to __attribute__((packed)) on gcc. I'll use that.
Thanks for the tip :)

Br,
Matti Vaittinen


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-28 Thread Guenter Roeck

On 1/27/19 11:48 PM, Matti Vaittinen wrote:

Thanks again Guenter,

On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:

On 1/25/19 3:05 AM, Matti Vaittinen wrote:

+/*
+ * We read regs RTC_SEC => RTC_YEAR
+ * this struct is ordered according to chip registers.
+ * Keep it u8 only to avoid padding issues.
+ */
+struct bd70528_rtc_day {
+   u8 sec;
+   u8 min;
+   u8 hour;
+};
+
+struct bd70528_rtc_data {
+   struct bd70528_rtc_day time;
+   u8 week;
+   u8 day;
+   u8 month;
+   u8 year;
+};
+
+struct bd70528_rtc_wake {
+   struct bd70528_rtc_day time;
+   u8 ctrl;
+};
+
+struct bd70528_rtc_alm {
+   struct bd70528_rtc_data data;
+   u8 alm_mask;
+   u8 alm_repeat;
+};


At least some of the above are directly associated with chip registers.
I don't think this will work for all architectures without explicit packed
attribute.


Allright. I was thinking of that but thought that most of the
architectures using this PMIC would handle alignments fine if I used
only u8 members. I did consider using __attribute__((packed)) - but I'm
not sure if we hit into troubles with that too. I guess some people
would like to compile kernel with other compiler(s) but gcc - although
I'm not sure if this should be taken into account. I'll try doing some
study on this - unless someone replies to this and just tells how this
should be done. (I am pretty sure I can find the answer from mail
archives though). I'll try adding some packing hint for compiler at v3.



Use __packed ?


+   if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
+   return 0;


I think
if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
would be much better readable. Even if not, there are way too many ()
in the above conditional.


Allright. I'll fix this
  

+   if (alm.alm_mask & BD70528_MASK_ALM_EN)
+   a->enabled = 0;
+   else
+   a->enabled = 1;
+

Without conditional:
a->enabled = !(alm.alm_mask & BD70528_MASK_ALM_EN);



Right. Much nicer, thanks! I'll change this.


+static int bd70528_set_time(struct device *dev, struct rtc_time *t)
+{
+   int ret, old_states;
+   struct bd70528_rtc_data rtc_data;
+   struct bd70528_rtc *r = dev_get_drvdata(dev);
+   struct bd70528 *bd70528 = r->mfd;
+
+   ret = bd70528_disable_rtc_based_timers(r, &old_states);
+


AFAICS the disable/enable functions are only called once. Since they
also apply set / clear a mutex, I find that a bit confusing. I think
it would be better to fold the code into this function. If anything,
I could imagine something like

mutex_lock();
ret = bd70528_set_time_locked();
mutex_unlock()

to simplify error handling.


Yep. Makes sense. I'll tidy this.


+   ret = regmap_bulk_read(bd70528->chip.regmap,
+  BD70528_REG_RTC_START, &rtc_data,
+  sizeof(rtc_data));
+
+   tm2rtc(t, &rtc_data);
+
+   ret = regmap_bulk_write(bd70528->chip.regmap,
+   BD70528_REG_RTC_START, &rtc_data,
+   sizeof(rtc_data));
+
+   ret = bd70528_re_enable_rtc_based_timers(r, old_states);
+


Kind of off that all the error returns are ignored here.


And I'll fix this too.

Br,
Matti Vaittinen





Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-27 Thread Matti Vaittinen
Thanks again Guenter,

On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:
> On 1/25/19 3:05 AM, Matti Vaittinen wrote:
> > +/*
> > + * We read regs RTC_SEC => RTC_YEAR
> > + * this struct is ordered according to chip registers.
> > + * Keep it u8 only to avoid padding issues.
> > + */
> > +struct bd70528_rtc_day {
> > +   u8 sec;
> > +   u8 min;
> > +   u8 hour;
> > +};
> > +
> > +struct bd70528_rtc_data {
> > +   struct bd70528_rtc_day time;
> > +   u8 week;
> > +   u8 day;
> > +   u8 month;
> > +   u8 year;
> > +};
> > +
> > +struct bd70528_rtc_wake {
> > +   struct bd70528_rtc_day time;
> > +   u8 ctrl;
> > +};
> > +
> > +struct bd70528_rtc_alm {
> > +   struct bd70528_rtc_data data;
> > +   u8 alm_mask;
> > +   u8 alm_repeat;
> > +};
> 
> At least some of the above are directly associated with chip registers.
> I don't think this will work for all architectures without explicit packed
> attribute.

Allright. I was thinking of that but thought that most of the
architectures using this PMIC would handle alignments fine if I used
only u8 members. I did consider using __attribute__((packed)) - but I'm
not sure if we hit into troubles with that too. I guess some people
would like to compile kernel with other compiler(s) but gcc - although
I'm not sure if this should be taken into account. I'll try doing some
study on this - unless someone replies to this and just tells how this
should be done. (I am pretty sure I can find the answer from mail
archives though). I'll try adding some packing hint for compiler at v3.

> > +   if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
> > +   return 0;
> 
> I think
>   if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
> would be much better readable. Even if not, there are way too many ()
> in the above conditional.

Allright. I'll fix this
 
> > +   if (alm.alm_mask & BD70528_MASK_ALM_EN)
> > +   a->enabled = 0;
> > +   else
> > +   a->enabled = 1;
> > +
> Without conditional:
>   a->enabled = !(alm.alm_mask & BD70528_MASK_ALM_EN);
> 

Right. Much nicer, thanks! I'll change this.

> > +static int bd70528_set_time(struct device *dev, struct rtc_time *t)
> > +{
> > +   int ret, old_states;
> > +   struct bd70528_rtc_data rtc_data;
> > +   struct bd70528_rtc *r = dev_get_drvdata(dev);
> > +   struct bd70528 *bd70528 = r->mfd;
> > +
> > +   ret = bd70528_disable_rtc_based_timers(r, &old_states);
> > +
> 
> AFAICS the disable/enable functions are only called once. Since they
> also apply set / clear a mutex, I find that a bit confusing. I think
> it would be better to fold the code into this function. If anything,
> I could imagine something like
> 
>   mutex_lock();
>   ret = bd70528_set_time_locked();
>   mutex_unlock()
> 
> to simplify error handling.

Yep. Makes sense. I'll tidy this.

> > +   ret = regmap_bulk_read(bd70528->chip.regmap,
> > +  BD70528_REG_RTC_START, &rtc_data,
> > +  sizeof(rtc_data));
> > +
> > +   tm2rtc(t, &rtc_data);
> > +
> > +   ret = regmap_bulk_write(bd70528->chip.regmap,
> > +   BD70528_REG_RTC_START, &rtc_data,
> > +   sizeof(rtc_data));
> > +
> > +   ret = bd70528_re_enable_rtc_based_timers(r, old_states);
> > +
> 
> Kind of off that all the error returns are ignored here.

And I'll fix this too.

Br,
Matti Vaittinen


Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-26 Thread Guenter Roeck

On 1/25/19 3:05 AM, Matti Vaittinen wrote:

Support RTC block in ROHM bd70528 power management IC. Support
getting and setting the time and date as well as arming an alarm
which can also be used to wake the PMIC from standby state.

HW supports wake interrupt only for the next 24 hours (sec, minute
and hour information only) so we limit also the alarm interrupt to
this 24 hours for the sake of consistency.

Signed-off-by: Matti Vaittinen 
---
  drivers/rtc/Kconfig   |   8 +
  drivers/rtc/Makefile  |   1 +
  drivers/rtc/rtc-bd70528.c | 451 ++
  3 files changed, 460 insertions(+)
  create mode 100644 drivers/rtc/rtc-bd70528.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 225b0b8516f3..df6211cbd83f 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -487,6 +487,14 @@ config RTC_DRV_M41T80_WDT
help
  If you say Y here you will get support for the
  watchdog timer in the ST M41T60 and M41T80 RTC chips series.
+config RTC_DRV_BD70528
+   tristate "ROHM BD70528 PMIC RTC"
+   help
+ If you say Y here you will get support for the RTC
+ on ROHM BD70528 Power Management IC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-bd70528.
  
  config RTC_DRV_BQ32K

tristate "TI BQ32000"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df022d820bee..740b13840913 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_RTC_DRV_ASM9260) += rtc-asm9260.o
  obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
  obj-$(CONFIG_RTC_DRV_AT91SAM9)+= rtc-at91sam9.o
  obj-$(CONFIG_RTC_DRV_AU1XXX)  += rtc-au1xxx.o
+obj-$(CONFIG_RTC_DRV_BD70528)  += rtc-bd70528.o
  obj-$(CONFIG_RTC_DRV_BQ32K)   += rtc-bq32k.o
  obj-$(CONFIG_RTC_DRV_BQ4802)  += rtc-bq4802.o
  obj-$(CONFIG_RTC_DRV_BRCMSTB) += rtc-brcmstb-waketimer.o
diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
new file mode 100644
index ..250fb218c784
--- /dev/null
+++ b/drivers/rtc/rtc-bd70528.c
@@ -0,0 +1,451 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2018 ROHM Semiconductors
+//
+// RTC driver for ROHM BD70528 PMIC
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * We read regs RTC_SEC => RTC_YEAR
+ * this struct is ordered according to chip registers.
+ * Keep it u8 only to avoid padding issues.
+ */
+struct bd70528_rtc_day {
+   u8 sec;
+   u8 min;
+   u8 hour;
+};
+
+struct bd70528_rtc_data {
+   struct bd70528_rtc_day time;
+   u8 week;
+   u8 day;
+   u8 month;
+   u8 year;
+};
+
+struct bd70528_rtc_wake {
+   struct bd70528_rtc_day time;
+   u8 ctrl;
+};
+
+struct bd70528_rtc_alm {
+   struct bd70528_rtc_data data;
+   u8 alm_mask;
+   u8 alm_repeat;
+};


At least some of the above are directly associated with chip registers.
I don't think this will work for all architectures without explicit packed
attribute.


+
+struct bd70528_rtc {
+   struct bd70528 *mfd;
+   struct device *dev;
+};
+
+static int bd70528_set_wake(struct bd70528 *bd70528,
+   int enable, int *old_state)
+{
+   int ret;
+   unsigned int ctrl_reg;
+
+   ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WAKE_EN, &ctrl_reg);
+   if (ret)
+   return ret;
+
+   if (old_state) {
+   if (ctrl_reg & BD70528_MASK_WAKE_EN)
+   *old_state |= BD70528_WAKE_STATE_BIT;
+   else
+   *old_state &= ~BD70528_WAKE_STATE_BIT;
+
+   if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
+   return 0;


I think
if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
would be much better readable. Even if not, there are way too many ()
in the above conditional.



+   }
+
+   if (enable)
+   ctrl_reg |= BD70528_MASK_WAKE_EN;
+   else
+   ctrl_reg &= ~BD70528_MASK_WAKE_EN;
+
+   return regmap_write(bd70528->chip.regmap, BD70528_REG_WAKE_EN,
+   ctrl_reg);
+}
+
+static int bd70528_set_elapsed_tmr(struct bd70528 *bd70528,
+  int enable, int *old_state)
+{
+   int ret;
+   unsigned int ctrl_reg;
+
+   /*
+* TBD
+* What is the purpose of elapsed timer ?
+* Is the timeout registers counting down, or is the disable - re-enable
+* going to restart the elapsed-time counting? If counting is restarted
+* the timeout should be decreased by the amount of time that has
+* elapsed since starting the timer. Maybe we should store the monotonic
+* clock value when timer is started so that if RTC is set while timer
+* is armed we could do the compensation. This is a hack if RTC/system
+* clk are drifting. OTOH, 

[RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC

2019-01-25 Thread Matti Vaittinen
Support RTC block in ROHM bd70528 power management IC. Support
getting and setting the time and date as well as arming an alarm
which can also be used to wake the PMIC from standby state.

HW supports wake interrupt only for the next 24 hours (sec, minute
and hour information only) so we limit also the alarm interrupt to
this 24 hours for the sake of consistency.

Signed-off-by: Matti Vaittinen 
---
 drivers/rtc/Kconfig   |   8 +
 drivers/rtc/Makefile  |   1 +
 drivers/rtc/rtc-bd70528.c | 451 ++
 3 files changed, 460 insertions(+)
 create mode 100644 drivers/rtc/rtc-bd70528.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 225b0b8516f3..df6211cbd83f 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -487,6 +487,14 @@ config RTC_DRV_M41T80_WDT
help
  If you say Y here you will get support for the
  watchdog timer in the ST M41T60 and M41T80 RTC chips series.
+config RTC_DRV_BD70528
+   tristate "ROHM BD70528 PMIC RTC"
+   help
+ If you say Y here you will get support for the RTC
+ on ROHM BD70528 Power Management IC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-bd70528.
 
 config RTC_DRV_BQ32K
tristate "TI BQ32000"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df022d820bee..740b13840913 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_RTC_DRV_ASM9260) += rtc-asm9260.o
 obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
 obj-$(CONFIG_RTC_DRV_AT91SAM9) += rtc-at91sam9.o
 obj-$(CONFIG_RTC_DRV_AU1XXX)   += rtc-au1xxx.o
+obj-$(CONFIG_RTC_DRV_BD70528)  += rtc-bd70528.o
 obj-$(CONFIG_RTC_DRV_BQ32K)+= rtc-bq32k.o
 obj-$(CONFIG_RTC_DRV_BQ4802)   += rtc-bq4802.o
 obj-$(CONFIG_RTC_DRV_BRCMSTB)  += rtc-brcmstb-waketimer.o
diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
new file mode 100644
index ..250fb218c784
--- /dev/null
+++ b/drivers/rtc/rtc-bd70528.c
@@ -0,0 +1,451 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2018 ROHM Semiconductors
+//
+// RTC driver for ROHM BD70528 PMIC
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * We read regs RTC_SEC => RTC_YEAR
+ * this struct is ordered according to chip registers.
+ * Keep it u8 only to avoid padding issues.
+ */
+struct bd70528_rtc_day {
+   u8 sec;
+   u8 min;
+   u8 hour;
+};
+
+struct bd70528_rtc_data {
+   struct bd70528_rtc_day time;
+   u8 week;
+   u8 day;
+   u8 month;
+   u8 year;
+};
+
+struct bd70528_rtc_wake {
+   struct bd70528_rtc_day time;
+   u8 ctrl;
+};
+
+struct bd70528_rtc_alm {
+   struct bd70528_rtc_data data;
+   u8 alm_mask;
+   u8 alm_repeat;
+};
+
+struct bd70528_rtc {
+   struct bd70528 *mfd;
+   struct device *dev;
+};
+
+static int bd70528_set_wake(struct bd70528 *bd70528,
+   int enable, int *old_state)
+{
+   int ret;
+   unsigned int ctrl_reg;
+
+   ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WAKE_EN, &ctrl_reg);
+   if (ret)
+   return ret;
+
+   if (old_state) {
+   if (ctrl_reg & BD70528_MASK_WAKE_EN)
+   *old_state |= BD70528_WAKE_STATE_BIT;
+   else
+   *old_state &= ~BD70528_WAKE_STATE_BIT;
+
+   if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
+   return 0;
+   }
+
+   if (enable)
+   ctrl_reg |= BD70528_MASK_WAKE_EN;
+   else
+   ctrl_reg &= ~BD70528_MASK_WAKE_EN;
+
+   return regmap_write(bd70528->chip.regmap, BD70528_REG_WAKE_EN,
+   ctrl_reg);
+}
+
+static int bd70528_set_elapsed_tmr(struct bd70528 *bd70528,
+  int enable, int *old_state)
+{
+   int ret;
+   unsigned int ctrl_reg;
+
+   /*
+* TBD
+* What is the purpose of elapsed timer ?
+* Is the timeout registers counting down, or is the disable - re-enable
+* going to restart the elapsed-time counting? If counting is restarted
+* the timeout should be decreased by the amount of time that has
+* elapsed since starting the timer. Maybe we should store the monotonic
+* clock value when timer is started so that if RTC is set while timer
+* is armed we could do the compensation. This is a hack if RTC/system
+* clk are drifting. OTOH, RTC controlled via I2C is in any case
+* inaccurate...
+*/
+   ret = regmap_read(bd70528->chip.regmap, BD70528_REG_ELAPSED_TIMER_EN,
+ &ctrl_reg);
+   if (ret)
+   return ret;
+
+   if (old_state) {
+   if (ctrl_reg & BD70528_MASK_ELAPSED_TIMER_EN)
+   *old_state |= BD70528_ELAPSED_STATE_BIT;
+