Issue:
- # hwclock -w
hwclock: RTC_SET_TIME: Invalid argument
Why:
- Relative commit: 8b9f9d4dc511309918c4f6793bae7387c0c638af, this patch
will always check for unwritable registers, it will compare reg
with max_register in regmap_writeable.
- In drivers/rtc/rtc-pcf85363.c, CTRL_STOP_EN is 0x2e, but DT_100THS
is 0, max_regiter is 0x2f, then reg will be equal to 0x30,
'0x30 < 0x2f' is false,so regmap_writeable will return false.
- The pcf85363/pcf85263 has the capability of address wrapping
which means if you access a continuous address range across a
certain boundary(max_register of struct regmap_config) the
hardware actually wraps the access to a lower address. But the
address violation check of regmap rejects such access.
How:
- Split of writing regs to two parts, first part writes control
registers about stop_enable and resets, second part writes
RTC time and date registers.
Signed-off-by: Biwen Li <[email protected]>
---
Change in v4:
- use old scheme
- replace link to lkml.org with commit
- add proper explanation
Change in v3:
- replace old scheme with new scheme:
increase max_register.
Change in v2:
- add Why and How into commit message.
drivers/rtc/rtc-pcf85363.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index a075e77617dc..3450d615974d 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -166,7 +166,12 @@ static int pcf85363_rtc_set_time(struct device *dev, struct rtc_time *tm)
buf[DT_YEARS] = bin2bcd(tm->tm_year % 100);
ret = regmap_bulk_write(pcf85363->regmap, CTRL_STOP_EN,
- tmp, sizeof(tmp));
+ tmp, 2);
+ if (ret)
+ return ret;
+
+ ret = regmap_bulk_write(pcf85363->regmap, DT_100THS,
+ buf, sizeof(tmp) - 2);
if (ret)
return ret;
--
2.17.1
On 8/27/19 7:37 AM, Biwen Li wrote:
> - In drivers/rtc/rtc-pcf85363.c, CTRL_STOP_EN is 0x2e, but DT_100THS
> is 0, max_regiter is 0x2f, then reg will be equal to 0x30,
> '0x30 < 0x2f' is false,so regmap_writeable will return false.
>
> - The pcf85363/pcf85263 has the capability of address wrapping
> which means if you access a continuous address range across a
> certain boundary(max_register of struct regmap_config) the
> hardware actually wraps the access to a lower address. But the
> address violation check of regmap rejects such access.
nitpick: This 2 paragraphs could be combined to clear up the issue:
`
The pcf85363/pcf85263 has the capability of address wrapping
which means if you access an address outside the allowed range
(0x00-0x2f) the hardware actually wraps the access to a lower address.
The rtc-pf85363 driver will use this feature to configure the time and
execute 2 actions in the same i2c write operation (stopping the clock
and configure the time). However the driver has also configured the
`regmap maxregister` protection mechanism that will block accessing
addresses outside valid range (0x00-0x2f).
`
nitpick: I would also use separate buffers for this actions. Up to you :)
Otherwise LGTM +1
Nandor
>
> On 8/27/19 7:37 AM, Biwen Li wrote:
> > - In drivers/rtc/rtc-pcf85363.c, CTRL_STOP_EN is 0x2e, but DT_100THS
> > is 0, max_regiter is 0x2f, then reg will be equal to 0x30,
> > '0x30 < 0x2f' is false,so regmap_writeable will return false.
> >
> > - The pcf85363/pcf85263 has the capability of address wrapping
> > which means if you access a continuous address range across a
> > certain boundary(max_register of struct regmap_config) the
> > hardware actually wraps the access to a lower address. But the
> > address violation check of regmap rejects such access.
>
> nitpick: This 2 paragraphs could be combined to clear up the issue:
>
> `
> The pcf85363/pcf85263 has the capability of address wrapping which means if
> you access an address outside the allowed range
> (0x00-0x2f) the hardware actually wraps the access to a lower address.
> The rtc-pf85363 driver will use this feature to configure the time and execute 2
> actions in the same i2c write operation (stopping the clock and configure the
> time). However the driver has also configured the `regmap maxregister`
> protection mechanism that will block accessing addresses outside valid range
> (0x00-0x2f).
> `
>
> nitpick: I would also use separate buffers for this actions. Up to you :)
>
> Otherwise LGTM +1
Thanks, it's a beautiful explanation.
>
> Nandor