rtc: abx80x: add support for abx81x
Subsystems (2)
v2 cover rtc: abx80x: add support for abx81x
Hello,
This patch series adds support for the ABX81X RTCs, which are essentially SPI versions of the ABX80X RTCs. The first patches (P2-P3) contain bug fixes (added after sashiko's review in v1), then (P4-P7) we have some cleanup and reorganization changes (converting the driver to use the regmap API was needed for this), followed by the actual ABX81X support.
Kind regards,
Antoni Pokusinski
---
Changes since v1:
* PATCH 1 ("dt-bindings: rtc: abx80x: document ABX81X RTCs")
- added missing "spi-peripherals-props" reference
- added abx815 compatible strings to the trickle charger enum list
* PATCH 2 ("rtc: abx80x: move part autodetection before RV1805 configuration") New patch
* PATCH 3 ("rtc: abx80x: properly handle shared IRQs")
New patch
* PATCH 5 ("rtc: abx80x: use regmap instead of I2C specific API")
- changed regmap_read() argument types from int to unsigned int
---
Antoni Pokusinski (8):
dt-bindings: rtc: abx80x: document ABX81X RTCs
rtc: abx80x: move part autodetection before RV1805 configuration
rtc: abx80x: properly handle shared IRQs
rtc: abx80x: add irq to struct abx80x_priv
rtc: abx80x: use regmap instead of I2C specific API
rtc: abx80x: replace read-modify-write pattern with regmap helpers
rtc: abx80x: create abx80x_i2c_probe()
rtc: abx80x: add support for ABX81X
.../bindings/rtc/abracon,abx80x.yaml | 18 +- drivers/rtc/Kconfig | 25 +- drivers/rtc/rtc-abx80x.c | 650 +++++++++++------- 3 files changed, 421 insertions(+), 272 deletions(-)
Signature · 1 line
2.55.0
PATCH v2 1/8 dt-bindings: rtc: abx80x: document ABX81X RTCs
Abracon AB0815 and AB1815 are RTC modules with SPI interface.
--- .../bindings/rtc/abracon,abx80x.yaml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml +17 -1
@@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Abracon ABX80X I2C ultra low power RTC/Alarm chip +title: Abracon ABX80X (I2C) and ABX81X (SPI) ultra low power RTC/Alarm chips maintainers: - [email protected]
@@ -21,10 +21,12 @@ properties: - abracon,ab0803 - abracon,ab0804 - abracon,ab0805 + - abracon,ab0815 - abracon,ab1801 - abracon,ab1803 - abracon,ab1804 - abracon,ab1805 + - abracon,ab1815 - microcrystal,rv1805 reg:
@@ -61,6 +63,7 @@ required: - reg allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# - $ref: rtc.yaml# - if: properties:
@@ -73,6 +76,8 @@ allOf: - abracon,ab1804 - abracon,ab0805 - abracon,ab1805 + - abracon,ab0815 + - abracon,ab1815 then: properties: abracon,tc-diode: false
@@ -96,3 +101,14 @@ examples: interrupts = <44 IRQ_TYPE_EDGE_FALLING>; }; }; + + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + rtc@0 { + compatible = "abracon,ab1815"; + reg = <0>; + }; + };
Signature · 1 line
2.55.0
Re: [PATCH v2 1/8] dt-bindings: rtc: abx80x: document ABX81X RTCs
Quoted 7 lines · Antoni Pokusinski
Abracon AB0815 and AB1815 are RTC modules with SPI interface.
Signed-off-by Antoni Pokusinski <[email protected]>--- .../bindings/rtc/abracon,abx80x.yaml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
Best regards,
Krzysztof
[email protected]
AI reviewRe: [PATCH v2 1/8] dt-bindings: rtc: abx80x: document ABX81X RTCs
In reply to Antoni PokusinskiSashiko has reviewed this patch and found no issues. It looks great!
Quoted 3 lines
Abracon AB0815 and AB1815 are RTC modules with SPI interface.
Signed-off-by Antoni Pokusinski <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
PATCH v2 2/8 rtc: abx80x: move part autodetection before RV1805 configuration
In reply to Antoni PokusinskiWhen the driver is bound using the generic "abracon,abx80x" compatible string or I2C ID, the RV1805 configuration is silently skipped because it happens before the part autodetection. Fix this by moving
the autodetection before the RV1805-specific configuration.
--- drivers/rtc/rtc-abx80x.c | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-)
drivers/rtc/rtc-abx80x.c +19 -19
@@ -814,6 +814,25 @@ static int abx80x_probe(struct i2c_client *client)return -EIO ; } +/* part autodetection */ +if (part ==ABX80X ) { +for (i =0 ; abx80x_caps[i].pn; i++) +if (partnumber == abx80x_caps[i].pn) +break ; +if (abx80x_caps[i].pn ==0 ) { +dev_err (&client->dev,"Unknown part: %04x\n" , + partnumber); +return -EINVAL ; + } + part = i; + } + +if (partnumber != abx80x_caps[part].pn) { +dev_err (&client->dev,"partnumber mismatch %04x != %04x\n" , + partnumber, abx80x_caps[part].pn); +return -EINVAL ; + } +/* Configure RV1805 specifics */ if (part ==RV1805 ) {/*
@@ -865,25 +884,6 @@ static int abx80x_probe(struct i2c_client *client) } } -/* part autodetection */ -if (part ==ABX80X ) { -for (i =0 ; abx80x_caps[i].pn; i++) -if (partnumber == abx80x_caps[i].pn) -break ; -if (abx80x_caps[i].pn ==0 ) { -dev_err (&client->dev,"Unknown part: %04x\n" , - partnumber); -return -EINVAL ; - } - part = i; - } - -if (partnumber != abx80x_caps[part].pn) { -dev_err (&client->dev,"partnumber mismatch %04x != %04x\n" , - partnumber, abx80x_caps[part].pn); -return -EINVAL ; - } -if (np && abx80x_caps[part].has_tc) trickle_cfg =abx80x_dt_trickle_cfg (client);
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 2/8] rtc: abx80x: move part autodetection before RV1805 configuration
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The patch fails to resolve the issue it describes because part autodetection for the RV1805…
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch fails to resolve the issue it describes because part autodetection for the RV1805 incorrectly resolves to AB1805. --
--- Patch [2]: [PATCH v2 2/8] rtc: abx80x: move part autodetection before RV1805 configuration --- commit e37ea6c1257442ff3423e6bacb742916beb85bbb
Author: Antoni Pokusinski <[email protected]>
rtc: abx80x: move part autodetection before RV1805 configuration
This commit moves the part autodetection logic before the RV1805 configuration block. The intention is to ensure the RV1805 specifics are applied even when the driver is bound using a generic compatible string.
drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 821
Quoted 13 lines
drivers/rtc/rtc-abx80x.c +5
-0@@ -814,6 +814,25 @@ static int abx80x_probe(struct i2c_client *client)return -EIO ; } +/* part autodetection */ +if (part ==ABX80X ) { +for (i =0 ; abx80x_caps[i].pn; i++) +if (partnumber == abx80x_caps[i].pn) +break ;
[Severity: Medium]
Does this code introduce a regression by preventing the RV1805 configuration from running during autodetection?
Since AB1805 and RV1805 share the same part number (0x1805), and AB1805 appears earlier in the abx80x_caps array, it appears this loop will always match AB1805 first.
If the driver is bound using the generic abracon,abx80x compatible string, part will be set to AB1805 instead of RV1805.
Quoted 6 lines
drivers/rtc/rtc-abx80x.c +6
-0+if (abx80x_caps[i].pn ==0 ) { +dev_err (&client->dev,"Unknown part: %04x\n" , + partnumber); +return -EINVAL ; + } + part = i;
drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 837
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +8
-0+ } + +if (partnumber != abx80x_caps[part].pn) { +dev_err (&client->dev,"partnumber mismatch %04x != %04x\n" , + partnumber, abx80x_caps[part].pn); +return -EINVAL ; + } +/* Configure RV1805 specifics */ if (part ==RV1805 ) {
[Severity: Medium]
Will this check now evaluate to false due to the autodetection resolving to AB1805 above?
If part is overwritten with AB1805 during autodetection, the RV1805 specifics will continue to be silently skipped. This leaves the device vulnerable to accidentally entering test mode and leaking extra power, meaning the patch might not resolve the issue it describes.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Re: [PATCH v2 2/8] rtc: abx80x: move part autodetection before RV1805 configuration
Quoted 32 lines · On Sat, Jul 25, 2026 at 03:07:52PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch fails to resolve the issue it describes because part autodetection for the RV1805 incorrectly resolves to AB1805. ----- Patch [2]: [PATCH v2 2/8] rtc: abx80x: move part autodetection before RV1805 configuration --- commit
e37ea6c1257442ff3423e6bacb742916beb85bbb
Author: Antoni Pokusinski <[email protected]>rtc: abx80x: move part autodetection before RV1805 configuration
This commit moves the part autodetection logic before the RV1805 configuration block. The intention is to ensure the RV1805 specifics are applied even when the driver is bound using a generic compatible string.
drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 821
Quoted 13 lines
drivers/rtc/rtc-abx80x.c +5
-0@@ -814,6 +814,25 @@ static int abx80x_probe(struct i2c_client *client)return -EIO ; } +/* part autodetection */ +if (part ==ABX80X ) { +for (i =0 ; abx80x_caps[i].pn; i++) +if (partnumber == abx80x_caps[i].pn) +break ;[Severity: Medium]
Does this code introduce a regression by preventing the RV1805 configuration from running during autodetection?
Quoted 7 lines
Since AB1805 and RV1805 share the same part number (
0x1805), and AB1805 appears earlier in theabx80x_capsarray, it appears this loop will always match AB1805 first.If the driver is bound using the generic abracon,abx80x compatible string, part will be set to AB1805 instead of RV1805.
Ok so I missed the fact that "AB1805 and RV1805 share the same part number". Hence, I see no way to make the driver run the RV1805 configuration when it is bound using the generic ABX80X, because it may happen that the detected part is RV1805 even though the real one is AB1805 or the reverse (depending on the order that we define in abx80x_caps[]). Therefore, I'll drop this patch in v3 and leave things as they were (i.e. autodetecton after the if (part == RV1805) ).
Quoted 28 lines
Quoted 6 lines
drivers/rtc/rtc-abx80x.c +6
-0+if (abx80x_caps[i].pn ==0 ) { +dev_err (&client->dev,"Unknown part: %04x\n" , + partnumber); +return -EINVAL ; + } + part = i;drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 837
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +8
-0+ } + +if (partnumber != abx80x_caps[part].pn) { +dev_err (&client->dev,"partnumber mismatch %04x != %04x\n" , + partnumber, abx80x_caps[part].pn); +return -EINVAL ; + } +/* Configure RV1805 specifics */ if (part ==RV1805 ) {[Severity: Medium]
Will this check now evaluate to false due to the autodetection resolving to AB1805 above?If part is overwritten with AB1805 during autodetection, the RV1805 specifics will continue to be silently skipped. This leaves the device vulnerable to accidentally entering test mode and leaking extra power, meaning the patch might not resolve the issue it describes.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Alexandre Belloni
maintainerRe: [PATCH v2 2/8] rtc: abx80x: move part autodetection before RV1805 configuration
Quoted 40 lines · Antoni Pokusinski
Quoted 32 lines · On Sat, Jul 25, 2026 at 03:07:52PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch fails to resolve the issue it describes because part autodetection for the RV1805 incorrectly resolves to AB1805. ----- Patch [2]: [PATCH v2 2/8] rtc: abx80x: move part autodetection before RV1805 configuration --- commit
e37ea6c1257442ff3423e6bacb742916beb85bbb
Author: Antoni Pokusinski <[email protected]>rtc: abx80x: move part autodetection before RV1805 configuration
This commit moves the part autodetection logic before the RV1805 configuration block. The intention is to ensure the RV1805 specifics are applied even when the driver is bound using a generic compatible string.
drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 821
Quoted 13 lines
drivers/rtc/rtc-abx80x.c +5
-0@@ -814,6 +814,25 @@ static int abx80x_probe(struct i2c_client *client)return -EIO ; } +/* part autodetection */ +if (part ==ABX80X ) { +for (i =0 ; abx80x_caps[i].pn; i++) +if (partnumber == abx80x_caps[i].pn) +break ;[Severity: Medium]
Does this code introduce a regression by preventing the RV1805 configuration from running during autodetection?Quoted 7 lines
Since AB1805 and RV1805 share the same part number (
0x1805), and AB1805 appears earlier in theabx80x_capsarray, it appears this loop will always match AB1805 first.If the driver is bound using the generic abracon,abx80x compatible string, part will be set to AB1805 instead of RV1805.
Quoted 7 lines
Ok so I missed the fact that "AB1805 and RV1805 share the same part number". Hence, I see no way to make the driver run the RV1805 configuration when it is bound using the generic ABX80X, because it may happen that the detected part is RV1805 even though the real one is AB1805 or the reverse (depending on the order that we define in
abx80x_caps[]). Therefore, I'll drop this patch in v3 and leave things as they were (i.e. autodetecton after theif (part == RV1805)).
Yes, don't bother. Autodetection was a bad idea anyway and will never be used with an rv1805.
Signature · 3 lines
Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
PATCH v2 3/8 rtc: abx80x: properly handle shared IRQs
In reply to Antoni PokusinskiThe abx80x RTC driver registers its interrupt handler with IRQF_SHARED, but the handler always returned IRQ_HANDLED and cleared the status register even when no interrupt source from the RTC was active.
This could cause the driver to claim interrupts belonging to other devices sharing the same IRQ line and could also clear unrelated status bits in the RTC status register.
Only handle the interrupt when the alarm or watchdog flags are set, and clear only those interrupt status bits that were handled. Return IRQ_NONE when the interrupt was not generated by the RTC.
--- drivers/rtc/rtc-abx80x.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/rtc/rtc-abx80x.c +12 -5
@@ -261,25 +261,32 @@ static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)struct i2c_client *client = dev_id;struct abx80x_priv *priv =i2c_get_clientdata (client);struct rtc_device *rtc = priv->rtc; +irqreturn_t handled =IRQ_NONE ;int status; status =i2c_smbus_read_byte_data (client,ABX8XX_REG_STATUS );if (status <0 ) -return IRQ_NONE ; +return handled; -if (status &ABX8XX_STATUS_AF ) +if (status &ABX8XX_STATUS_AF ) {rtc_update_irq (rtc,1 ,RTC_AF |RTC_IRQF ); + handled =IRQ_HANDLED ; + }/* * It is unclear if we'll get an interrupt before the external * reset kicks in. */ -if (status &ABX8XX_STATUS_WDT ) +if (status &ABX8XX_STATUS_WDT ) {dev_alert (&client->dev,"watchdog timeout interrupt.\n" ); + handled =IRQ_HANDLED ; + } -i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS ,0 ); +if (handled ==IRQ_HANDLED ) +i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS , + status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT )); -return IRQ_HANDLED ; +return handled; }static int abx80x_read_alarm (struct device *dev,struct rtc_wkalrm *t)
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 3/8] rtc: abx80x: properly handle shared IRQs
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Read-Modify-Write race condition causes lost hardware interrupts on a Write-0-to-Clear (W0C)…
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Read-Modify-Write race condition causes lost hardware interrupts on a Write-0-to-Clear (W0C) register.
- [High] Returning IRQ_NONE for unhandled RTC interrupts causes a hard interrupt storm.
--
--- Patch [3]: [PATCH v2 3/8] rtc: abx80x: properly handle shared IRQs --- commit 3fccf3aa21cff336c32ceacf1b3d453203dbb5b8
Author: Antoni Pokusinski <[email protected]>
rtc: abx80x: properly handle shared IRQs
The abx80x RTC driver registers its interrupt handler with IRQF_SHARED, but previously always returned IRQ_HANDLED and cleared the status register even when no interrupt source from the RTC was active. This patch updates the handler to only handle the interrupt when alarm or watchdog flags are set, clearing only those handled bits. It returns IRQ_NONE when the interrupt was not generated by the RTC.
Quoted 5 lines
drivers/rtc/rtc-abx80x.c +0
-0@@ -261,25 +261,32 @@ static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)
[ ... ]
drivers/rtc/rtc-abx80x.c static irqreturn_t abx80x_handle_irq(int irq, void *dev_id) · line 287
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +3
-1-i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS ,0 ); +if (handled ==IRQ_HANDLED ) +i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS , + status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT ));
[Severity: High]
Does this read-modify-write operation introduce a regression by creating a race condition that could lose hardware interrupts?
The ABX8XX_REG_STATUS register has Write-0-to-Clear (W0C) semantics, meaning writing 0 clears a bit and writing 1 preserves it. Because this writes status & ~(ABX8XX_STATUS_AF | ABX8XX_STATUS_WDT), it writes 0 to any bit that was 0 at the time of the earlier i2c_smbus_read_byte_data() call.
If a new status event is asserted by the hardware between the read and the write, won't this write of 0 unintentionally clear it?
drivers/rtc/rtc-abx80x.c static irqreturn_t abx80x_handle_irq(int irq, void *dev_id) · line 290
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +1
-1-return IRQ_HANDLED ; +return handled; }
[Severity: High]
Could returning IRQ_NONE here without clearing the status register cause a regression where an interrupt storm occurs if an unhandled RTC interrupt fires?
Since abx80x_probe() does not initialize the interrupt mask register (ABX8XX_REG_IRQ), a bootloader could leave an unknown interrupt enabled. If one of these unhandled interrupts fires, handled remains IRQ_NONE.
Because the register is only cleared when handled == IRQ_HANDLED, the unhandled interrupt is never cleared from the RTC. Returning IRQ_NONE would then cause the IRQ core to re-trigger the handler in an infinite loop until the spurious IRQ detector permanently disables the shared IRQ line.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
PATCH v2 4/8 rtc: abx80x: add irq to struct abx80x_priv
In reply to Antoni PokusinskiThis way the irq number is not tied to the i2c_client and can be easily accessed also in the case of ABX81X SPI clocks.
--- drivers/rtc/rtc-abx80x.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
drivers/rtc/rtc-abx80x.c +11 -7
@@ -127,6 +127,7 @@ struct abx80x_priv {struct rtc_device *rtc;struct i2c_client *client;struct watchdog_device wdog; +int irq; };static int abx80x_write_config_key (struct i2c_client *client,u8 key)
@@ -292,11 +293,12 @@ static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)static int abx80x_read_alarm (struct device *dev,struct rtc_wkalrm *t) {struct i2c_client *client =to_i2c_client (dev); +struct abx80x_priv *priv =i2c_get_clientdata (client);unsigned char buf[7 ];int irq_mask, err; -if (client->irq <=0 ) +if (priv->irq <=0 )return -EINVAL ; err = i2c_smbus_read_i2c_block_data(client, ABX8XX_REG_ASC,
@@ -324,10 +326,11 @@ static int abx80x_read_alarm(struct device *dev, struct rtc_wkalrm *t)static int abx80x_set_alarm (struct device *dev,struct rtc_wkalrm *t) {struct i2c_client *client =to_i2c_client (dev); +struct abx80x_priv *priv =i2c_get_clientdata (client);u8 alarm[6 ];int err; -if (client->irq <=0 ) +if (priv->irq <=0 )return -EINVAL ; alarm[0 ] =0x0 ;
@@ -915,6 +918,7 @@ static int abx80x_probe(struct i2c_client *client) priv->rtc->ops = &abx80x_rtc_ops; priv->client = client; + priv->irq = client->irq;i2c_set_clientdata (client, priv);
@@ -928,19 +932,19 @@ static int abx80x_probe(struct i2c_client *client)if (err)return err; -if (client->irq >0 ) { -dev_info (&client->dev,"IRQ %d supplied\n" , client->irq); - err =devm_request_threaded_irq (&client->dev, client->irq,NULL , +if (priv->irq >0 ) { +dev_info (&client->dev,"IRQ %d supplied\n" , priv->irq); + err =devm_request_threaded_irq (&client->dev, priv->irq,NULL , abx80x_handle_irq,IRQF_SHARED |IRQF_ONESHOT ,"abx8xx" , client);if (err) {dev_err (&client->dev,"unable to request IRQ, alarms disabled\n" ); - client->irq =0 ; + priv->irq =0 ; } } -if (client->irq <=0 ) +if (priv->irq <=0 )clear_bit (RTC_FEATURE_ALARM , priv->rtc->features); err =rtc_add_group (priv->rtc, &rtc_calib_attr_group);
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 4/8] rtc: abx80x: add irq to struct abx80x_priv
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The interrupt handler indiscriminately clears unrelated and newly arrived interrupts due to a…
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The interrupt handler indiscriminately clears unrelated and newly arrived interrupts due to a read-modify-write race condition. --
--- Patch [4]: [PATCH v2 4/8] rtc: abx80x: add irq to struct abx80x_priv --- commit c9bf7d6c99deb7b828f721f449db552d3b1510a0
Author: Antoni Pokusinski <[email protected]>
rtc: abx80x: add irq to struct abx80x_priv
This patch adds an irq field to the abx80x_priv struct to decouple the interrupt number from the i2c_client. This enables the irq to be easily accessed for both i2c and spi variants. It also updates the interrupt handler to selectively clear status bits.
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0
[ ... ]
Quoted 22 lines
drivers/rtc/rtc-abx80x.c +5
-2@@ -261,35 +262,43 @@ static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)struct i2c_client *client = dev_id;struct abx80x_priv *priv =i2c_get_clientdata (client);struct rtc_device *rtc = priv->rtc; +irqreturn_t handled =IRQ_NONE ;int status; status =i2c_smbus_read_byte_data (client,ABX8XX_REG_STATUS );if (status <0 ) -return IRQ_NONE ; +return handled; -if (status &ABX8XX_STATUS_AF ) +if (status &ABX8XX_STATUS_AF ) {rtc_update_irq (rtc,1 ,RTC_AF |RTC_IRQF ); + handled =IRQ_HANDLED ; + }/* * It is unclear if we'll get an interrupt before the external * reset kicks in. */
drivers/rtc/rtc-abx80x.c static irqreturn_t abx80x_handle_irq(int irq, void *dev_id) · line 288
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +6
-2-if (status &ABX8XX_STATUS_WDT ) +if (status &ABX8XX_STATUS_WDT ) {dev_alert (&client->dev,"watchdog timeout interrupt.\n" ); + handled =IRQ_HANDLED ; + } -i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS ,0 ); +if (handled ==IRQ_HANDLED ) +i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS , + status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT ));
[Severity: High]
Does this status write introduce a race condition that could cause us to lose newly arrived interrupts?
If a new interrupt (such as a watchdog or alarm event) triggers immediately after the status register is read, its corresponding hardware bit becomes 1, but it remains 0 in the local status variable.
When writing back status & ~(ABX8XX_STATUS_AF | ABX8XX_STATUS_WDT), this writes 0 to the newly triggered interrupt's bit. Since this chip appears to use write-0-to-clear semantics, writing 0 clears the new interrupt before it can be handled, effectively losing the hardware event.
Would it be better to write ~(ABX8XX_STATUS_AF | ABX8XX_STATUS_WDT) directly to ensure any unhandled bits remain untouched?
Quoted 3 lines
drivers/rtc/rtc-abx80x.c +1
-1-return IRQ_HANDLED ; +return handled; }
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4
PATCH v2 5/8 rtc: abx80x: use regmap instead of I2C specific API
In reply to Antoni PokusinskiRework the driver so that it uses regmap_* functions for communication with the device instead of the i2c_smbus_* API. This way the support for ABX81X RTCs which use SPI can be added later.
--- drivers/rtc/Kconfig | 1 + drivers/rtc/rtc-abx80x.c | 343 +++++++++++++++++++++------------------ 2 files changed, 189 insertions(+), 155 deletions(-)
drivers/rtc/Kconfig +1 -0
@@ -215,6 +215,7 @@ config RTC_DRV_ABEOZ9 config RTC_DRV_ABX80X tristate "Abracon ABx80x" select WATCHDOG_CORE if WATCHDOG + select REGMAP_I2C help If you say yes here you get support for Abracon AB080X and AB180X families of ultra-low-power battery- and capacitor-backed real-time
drivers/rtc/rtc-abx80x.c +188 -155
689 lines not on this page · raw message
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 5/8] rtc: abx80x: use regmap instead of I2C specific API
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] The true error code from devm_regmap_init_i2c is discarded and masked as a hardcoded -EIO.
Pre-existing issues:
- [Critical] Missing synchronization in NVMem transfer function leads to SRAM address page corruption.
- [High] Unprotected read-modify-write sequences on the RTC status register (ABX8XX_REG_STATUS) between process context and the threaded IRQ handler. --
--- Patch [5]: [PATCH v2 5/8] rtc: abx80x: use regmap instead of I2C specific API --- commit 5491aafa92a95d35d02d312fb0fd904216ed5a97
Author: Antoni Pokusinski <[email protected]>
rtc: abx80x: use regmap instead of I2C specific API
Rework the driver so that it uses regmap_* functions for communication with the device instead of the i2c_smbus_* API. This way the support for ABX81X RTCs which use SPI can be added later.
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0
[ ... ]
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0@@ -279,36 +283,35 @@ static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)* reset kicks in. */ if (status &ABX8XX_STATUS_WDT ) {
drivers/rtc/rtc-abx80x.c static irqreturn_t abx80x_handle_irq(int irq, void *dev_id) · line 292
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +3
-3-dev_alert (&client->dev,"watchdog timeout interrupt.\n" ); +dev_alert (dev,"watchdog timeout interrupt.\n" ); handled =IRQ_HANDLED ; }if (handled ==IRQ_HANDLED ) -i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS , - status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT )); +regmap_write (priv->regmap,ABX8XX_REG_STATUS , + status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT ));
[Severity: High]
This is a pre-existing issue, but can concurrent read-modify-write sequences on the ABX8XX_REG_STATUS register overwrite each other's changes?
The threaded IRQ handler abx80x_handle_irq() acknowledges interrupts with an unlocked read-modify-write. At the same time, abx80x_ioctl() does an unlocked read-modify-write to clear the BLF bit:
abx80x_ioctl()
case RTC_VL_CLR:
err = regmap_read(priv->regmap, ABX8XX_REG_STATUS, &status);
status &= ~ABX8XX_STATUS_BLF;
err = regmap_write(priv->regmap, ABX8XX_REG_STATUS, status);If the ioctl races with the threaded IRQ handler, could this lead to lost interrupt acknowledgments or lost battery low flags?
[ ... ]
Quoted 15 lines
drivers/rtc/rtc-abx80x.c +1
-3@@ -702,31 +704,27 @@ static int abx80x_nvmem_xfer(struct abx80x_priv *priv, unsigned int offset,int ret;while (bytes) { -u8 extram, reg, len, lower, upper; +u8 reg, len, lower, upper; lower =FIELD_GET (NVMEM_ADDR_LOWER , offset); upper =FIELD_GET (NVMEM_ADDR_UPPER , offset); - extram =FIELD_PREP (ABX8XX_EXTRAM_XADS , upper); reg =ABX8XX_SRAM_BASE + lower; len =min (lower + bytes, (size_t )ABX8XX_SRAM_WIN_SIZE ) - lower; len =min_t (u8, len,I2C_SMBUS_BLOCK_MAX ); - ret = i2c_smbus_write_byte_data(priv->client, ABX8XX_REG_EXTRAM,
drivers/rtc/rtc-abx80x.c static int abx80x_nvmem_xfer(struct abx80x_priv *priv, unsigned int offset, · line 721
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +3
-3- extram); + ret =regmap_update_bits (priv->regmap,ABX8XX_REG_EXTRAM , +ABX8XX_EXTRAM_XADS , upper);if (ret)return ret;if (write) { - ret =i2c_smbus_write_i2c_block_data (priv->client, reg, - len, val); + ret =regmap_bulk_write (priv->regmap, reg, val, len);
[Severity: Critical]
This is a pre-existing issue, but does this missing synchronization lead to SRAM address page corruption?
The NVMem core does not serialize device callbacks, which means two threads could access NVMem concurrently. If Thread A updates ABX8XX_REG_EXTRAM to select the address page, could Thread B preempt and update the same register to a different page before Thread A performs its bulk write?
Would Thread A then write data to the wrong SRAM page?
[ ... ]
Quoted 9 lines
drivers/rtc/rtc-abx80x.c +1
-0@@ -779,6 +809,7 @@ MODULE_DEVICE_TABLE(i2c, abx80x_id);static int abx80x_probe (struct i2c_client *client) { +struct regmap *regmap;struct device_node *np = client->dev.of_node;struct abx80x_priv *priv;int i, data, err, trickle_cfg = -EINVAL ;
drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 831
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +5
-2@@ -793,8 +824,27 @@ static int abx80x_probe(struct i2c_client *client)if (!i2c_check_functionality (client->adapter,I2C_FUNC_I2C ))return -ENODEV ; - err =i2c_smbus_read_i2c_block_data (client,ABX8XX_REG_ID0 , -sizeof (buf), buf); + regmap =devm_regmap_init_i2c (client, &abx80x_regmap_config_i2c); +if (IS_ERR (regmap)) { +dev_err (&client->dev,"Unable to allocate regmap\n" ); +return -EIO ; + }
[Severity: Medium]
Should this code return the actual error code from devm_regmap_init_i2c() (such as -ENOMEM or -ENODEV) via PTR_ERR(regmap) instead of discarding it for a hardcoded -EIO?
Masking the original error code could make debugging initialization failures more difficult.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5
Re: [PATCH v2 5/8] rtc: abx80x: use regmap instead of I2C specific API
Quoted 88 lines · On Sat, Jul 25, 2026 at 03:13:13PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] The true error code fromdevm_regmap_init_i2cis discarded and masked as a hardcoded-EIO.Pre-existing issues:
- [Critical] Missing synchronization in NVMem transfer function leads to SRAM address page corruption.
- [High] Unprotected read-modify-write sequences on the RTC status register (ABX8XX_REG_STATUS) between process context and the threaded IRQ handler. ----- Patch [5]: [PATCH v2 5/8] rtc: abx80x: use regmap instead of I2C specific API --- commit
5491aafa92a95d35d02d312fb0fd904216ed5a97
Author: Antoni Pokusinski <[email protected]>rtc: abx80x: use regmap instead of I2C specific API
Rework the driver so that it uses regmap_* functions for communication with the device instead of the i2c_smbus_* API. This way the support for ABX81X RTCs which use SPI can be added later.
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0[ ... ]
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0@@ -279,36 +283,35 @@ static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)* reset kicks in. */ if (status &ABX8XX_STATUS_WDT ) {drivers/rtc/rtc-abx80x.c static irqreturn_t abx80x_handle_irq(int irq, void *dev_id) · line 292
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +3
-3-dev_alert (&client->dev,"watchdog timeout interrupt.\n" ); +dev_alert (dev,"watchdog timeout interrupt.\n" ); handled =IRQ_HANDLED ; }if (handled ==IRQ_HANDLED ) -i2c_smbus_write_byte_data (client,ABX8XX_REG_STATUS , - status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT )); +regmap_write (priv->regmap,ABX8XX_REG_STATUS , + status & ~(ABX8XX_STATUS_AF |ABX8XX_STATUS_WDT ));[Severity: High]
This is a pre-existing issue, but can concurrent read-modify-write sequences on theABX8XX_REG_STATUSregister overwrite each other's changes?The threaded IRQ handler
abx80x_handle_irq()acknowledges interrupts with an unlocked read-modify-write. At the same time,abx80x_ioctl()does an unlocked read-modify-write to clear the BLF bit:
abx80x_ioctl()case RTC_VL_CLR: err = regmap_read(priv->regmap, ABX8XX_REG_STATUS, &status); status &= ~ABX8XX_STATUS_BLF; err = regmap_write(priv->regmap, ABX8XX_REG_STATUS, status);If the ioctl races with the threaded IRQ handler, could this lead to lost interrupt acknowledgments or lost battery low flags?
[ ... ]
Quoted 15 lines
drivers/rtc/rtc-abx80x.c +1
-3@@ -702,31 +704,27 @@ static int abx80x_nvmem_xfer(struct abx80x_priv *priv, unsigned int offset,int ret;while (bytes) { -u8 extram, reg, len, lower, upper; +u8 reg, len, lower, upper; lower =FIELD_GET (NVMEM_ADDR_LOWER , offset); upper =FIELD_GET (NVMEM_ADDR_UPPER , offset); - extram =FIELD_PREP (ABX8XX_EXTRAM_XADS , upper); reg =ABX8XX_SRAM_BASE + lower; len =min (lower + bytes, (size_t )ABX8XX_SRAM_WIN_SIZE ) - lower; len =min_t (u8, len,I2C_SMBUS_BLOCK_MAX ); - ret = i2c_smbus_write_byte_data(priv->client, ABX8XX_REG_EXTRAM,drivers/rtc/rtc-abx80x.c static int abx80x_nvmem_xfer(struct abx80x_priv *priv, unsigned int offset, · line 721
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +3
-3- extram); + ret =regmap_update_bits (priv->regmap,ABX8XX_REG_EXTRAM , +ABX8XX_EXTRAM_XADS , upper);if (ret)return ret;if (write) { - ret =i2c_smbus_write_i2c_block_data (priv->client, reg, - len, val); + ret =regmap_bulk_write (priv->regmap, reg, val, len);[Severity: Critical]
This is a pre-existing issue, but does this missing synchronization lead to SRAM address page corruption?
Quoted 6 lines
The NVMem core does not serialize device callbacks, which means two threads could access NVMem concurrently. If Thread A updates
ABX8XX_REG_EXTRAMto select the address page, could Thread B preempt and update the same register to a different page before Thread A performs its bulk write?Would Thread A then write data to the wrong SRAM page?
Ok so according to the review this driver is missing locking altogether. Most of the comments from sashiko in this v2 regard some race conditions that exist here. To sum up, the problems are:
* concurrent accesses to the NVMEM xfer function
* lack of synchronization for any "write_config_key + reg_write" operation
* concurrent accesses to REG_STATUS
I think that adding a single mutex and proper lock guards all over the driver code would be sufficient, will do that in v3 in a separate patch.
Perhaps some finer-grained locking would be possible but this would complicate things too much in my opinion.
Quoted 27 lines
[ ... ]
Quoted 9 lines
drivers/rtc/rtc-abx80x.c +1
-0@@ -779,6 +809,7 @@ MODULE_DEVICE_TABLE(i2c, abx80x_id);static int abx80x_probe (struct i2c_client *client) { +struct regmap *regmap;struct device_node *np = client->dev.of_node;struct abx80x_priv *priv;int i, data, err, trickle_cfg = -EINVAL ;drivers/rtc/rtc-abx80x.c static int abx80x_probe(struct i2c_client *client) · line 831
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +5
-2@@ -793,8 +824,27 @@ static int abx80x_probe(struct i2c_client *client)if (!i2c_check_functionality (client->adapter,I2C_FUNC_I2C ))return -ENODEV ; - err =i2c_smbus_read_i2c_block_data (client,ABX8XX_REG_ID0 , -sizeof (buf), buf); + regmap =devm_regmap_init_i2c (client, &abx80x_regmap_config_i2c); +if (IS_ERR (regmap)) { +dev_err (&client->dev,"Unable to allocate regmap\n" ); +return -EIO ; + }[Severity: Medium]
Should this code return the actual error code fromdevm_regmap_init_i2c()(such as-ENOMEMor-ENODEV) viaPTR_ERR(regmap)instead of discarding it for a hardcoded-EIO?
Quoted 2 lines
Masking the original error code could make debugging initialization failures more difficult.
Yes, there should be PTR_ERR() in here, same situation as with the devm_regmap_init_spi() in PATCH 8.
Quoted 3 lines
Signature · 2 lines
-- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5
PATCH v2 6/8 rtc: abx80x: replace read-modify-write pattern with regmap helpers
In reply to Antoni PokusinskiBefore introducing the regmap usage in the driver, updating specific bits of a register was performed using the read-modify-write pattern. Now, the functions regmap_update_bits() and regmap_write_bits() can be used to simplify the code.
--- drivers/rtc/rtc-abx80x.c | 105 +++++++++++---------------------------- 1 file changed, 28 insertions(+), 77 deletions(-)
drivers/rtc/rtc-abx80x.c +28 -77
@@ -224,7 +224,7 @@ static int abx80x_rtc_set_time(struct device *dev, struct rtc_time *tm) {struct abx80x_priv *priv =dev_get_drvdata (dev);unsigned char buf[8 ]; -int err, flags; +int err;if (tm->tm_year <100 )return -EINVAL ;
@@ -246,18 +246,11 @@ static int abx80x_rtc_set_time(struct device *dev, struct rtc_time *tm) }/* Clear the OF bit of Oscillator Status Register */ - err =regmap_read (priv->regmap,ABX8XX_REG_OSS , &flags); + err =regmap_update_bits (priv->regmap,ABX8XX_REG_OSS ,ABX8XX_OSS_OF ,0 );if (err <0 ) -return err; - - err =regmap_write (priv->regmap,ABX8XX_REG_OSS , - flags & ~ABX8XX_OSS_OF ); -if (err <0 ) {dev_err (dev,"Unable to write oscillator status register\n" ); -return err; - } -return 0 ; +return err; }static irqreturn_t abx80x_handle_irq (int irq,void *dev_id)
@@ -363,7 +356,7 @@ static int abx80x_rtc_set_autocalibration(struct device *dev, int autocalibration) {struct abx80x_priv *priv =dev_get_drvdata (dev); -int retval, flags =0 ; +int flags =0 ;if ((autocalibration !=0 ) && (autocalibration !=1024 ) && (autocalibration !=512 )) {
@@ -371,10 +364,6 @@ static int abx80x_rtc_set_autocalibration(struct device *dev,return -EINVAL ; } - retval =regmap_read (priv->regmap,ABX8XX_REG_OSC , &flags); -if (retval <0 ) -return retval; -if (autocalibration ==0 ) { flags &= ~(ABX8XX_OSC_ACAL_512 |ABX8XX_OSC_ACAL_1024 ); }else if (autocalibration ==1024 ) {
@@ -390,9 +379,9 @@ static int abx80x_rtc_set_autocalibration(struct device *dev,if (abx80x_write_config_key (dev,ABX8XX_CFG_KEY_OSC ) <0 )return -EIO ; - retval =regmap_write (priv->regmap,ABX8XX_REG_OSC , flags); - -return retval; +return regmap_write_bits (priv->regmap,ABX8XX_REG_OSC , +ABX8XX_OSC_ACAL_1024 |ABX8XX_OSC_ACAL_512 , + flags); }static int abx80x_rtc_get_autocalibration (struct device *dev)
@@ -455,7 +444,7 @@ static ssize_t oscillator_store(struct device *dev, const char *buf, size_t count) {struct abx80x_priv *priv =dev_get_drvdata (dev->parent); -int retval, flags, rc_mode =0 ; +int retval, rc_mode =0 ;if (strncmp (buf,"rc" ,2 ) ==0 ) { rc_mode =1 ;
@@ -466,24 +455,14 @@ static ssize_t oscillator_store(struct device *dev,return -EINVAL ; } - retval =regmap_read (priv->regmap,ABX8XX_REG_OSC , &flags); -if (retval <0 ) -return retval; - -if (rc_mode ==0 ) - flags &= ~(ABX8XX_OSC_OSEL ); -else - flags |= (ABX8XX_OSC_OSEL ); -/* Unlock write access on Oscillator Control register */ if (abx80x_write_config_key (dev->parent,ABX8XX_CFG_KEY_OSC ) <0 )return -EIO ; - retval =regmap_write (priv->regmap,ABX8XX_REG_OSC , flags); -if (retval <0 ) { + retval =regmap_write_bits (priv->regmap,ABX8XX_REG_OSC ,ABX8XX_OSC_OSEL , + rc_mode ==0 ?0 : (ABX8XX_OSC_OSEL )); +if (retval <0 )dev_err (dev,"Failed to write Oscillator Control register\n" ); -return retval; - }return retval ? retval : count; }
@@ -550,17 +529,8 @@ static int abx80x_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)return put_user (tmp, (unsigned int __user *)arg);case RTC_VL_CLR : - err =regmap_read (priv->regmap,ABX8XX_REG_STATUS , &status); -if (err <0 ) -return err; - - status &= ~ABX8XX_STATUS_BLF ; - - err =regmap_write (priv->regmap,ABX8XX_REG_STATUS , status); -if (err <0 ) -return err; - -return 0 ; +return regmap_update_bits (priv->regmap,ABX8XX_REG_STATUS , +ABX8XX_STATUS_BLF ,0 );default :return -ENOIOCTLCMD ;
@@ -812,7 +782,7 @@ static int abx80x_probe(struct i2c_client *client)struct regmap *regmap;struct device_node *np = client->dev.of_node;struct abx80x_priv *priv; -int i, data, err, trickle_cfg = -EINVAL ; +int i, err, trickle_cfg = -EINVAL ;char buf[7 ];unsigned int part = (uintptr_t )i2c_get_match_data (client);unsigned int partnumber;
@@ -859,14 +829,9 @@ static int abx80x_probe(struct i2c_client *client)dev_info (&client->dev,"model %04x, revision %u.%u, lot %x, wafer %x, uid %x\n" , partnumber, majrev, minrev, lot, wafer, uid); - err =regmap_read (regmap,ABX8XX_REG_CTRL1 , &data); -if (err <0 ) { -dev_err (&client->dev,"Unable to read control register\n" ); -return -EIO ; - } - - err =regmap_write (regmap,ABX8XX_REG_CTRL1 , - (data & ~(ABX8XX_CTRL_12_24 |ABX8XX_CTRL_ARST )) |ABX8XX_CTRL_WRITE ); + err =regmap_update_bits (regmap,ABX8XX_REG_CTRL1 , +ABX8XX_CTRL_12_24 |ABX8XX_CTRL_ARST |ABX8XX_CTRL_WRITE , +ABX8XX_CTRL_WRITE );if (err <0 ) {dev_err (&client->dev,"Unable to write control register\n" );return -EIO ;
@@ -899,30 +864,10 @@ static int abx80x_probe(struct i2c_client *client)* register is set. RV-1805-C3 datasheet indicates that * the bit should be cleared in section 11h - Control2. */ - err =regmap_read (regmap,ABX8XX_REG_CTRL2 , &data); -if (err <0 ) { -dev_err (&client->dev, -"Unable to read control2 register\n" ); -return -EIO ; - } - - err =regmap_write (regmap,ABX8XX_REG_CTRL2 , - data & ~ABX8XX_CTRL2_RSVD ); -if (err <0 ) { -dev_err (&client->dev, -"Unable to write control2 register\n" ); -return -EIO ; - } - -/* -* Avoid extra power leakage. The RV1805 uses smaller -* 10pin package and the EXTI input is not present. -* Disable it to avoid leakage. -*/ - err =regmap_read (regmap,ABX8XX_REG_OUT_CTRL , &data); + err =regmap_update_bits (regmap,ABX8XX_REG_CTRL2 , +ABX8XX_CTRL2_RSVD ,0 );if (err <0 ) { -dev_err (&client->dev, -"Unable to read output control register\n" ); +dev_err (&client->dev,"Unable to write control2 register\n" );return -EIO ; }
@@ -933,8 +878,14 @@ static int abx80x_probe(struct i2c_client *client)if (abx80x_write_config_key (&client->dev,ABX8XX_CFG_KEY_MISC ) <0 )return -EIO ; - err =regmap_write (regmap,ABX8XX_REG_OUT_CTRL , - data |ABX8XX_OUT_CTRL_EXDS ); +/* +* Avoid extra power leakage. The RV1805 uses smaller +* 10pin package and the EXTI input is not present. +* Disable it to avoid leakage. +*/ + err =regmap_write_bits (regmap,ABX8XX_REG_OUT_CTRL , +ABX8XX_OUT_CTRL_EXDS , +ABX8XX_OUT_CTRL_EXDS );if (err <0 ) {dev_err (&client->dev,"Unable to write output control register\n" );
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 6/8] rtc: abx80x: replace read-modify-write pattern with regmap helpers
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Hardware state machine race in Read-Modify-Write on Write-0-To-Clear status registers causes lost interrupts.
- [Medium] Unprotected non-atomic configuration key write allows concurrent operations to silently lock the hardware. --
--- Patch [6]: [PATCH v2 6/8] rtc: abx80x: replace read-modify-write pattern with regmap helpers --- commit f4c200ec9260a52df31083ec22d071486d5b6fcb
Author: Antoni Pokusinski <[email protected]>
rtc: abx80x: replace read-modify-write pattern with regmap helpers
Before introducing the regmap usage in the driver, updating specific bits of a register was performed using the read-modify-write pattern. Now, the functions regmap_update_bits() and regmap_write_bits() can be used to simplify the code.
drivers/rtc/rtc-abx80x.c static int abx80x_rtc_set_time(struct device *dev, struct rtc_time *tm) · line 249
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +1
-1@@ -246,18 +246,11 @@ static int abx80x_rtc_set_time(struct device *dev, struct rtc_time *tm) }/* Clear the OF bit of Oscillator Status Register */ - err =regmap_read (priv->regmap,ABX8XX_REG_OSS , &flags); + err =regmap_update_bits (priv->regmap,ABX8XX_REG_OSS ,ABX8XX_OSS_OF ,0 );
[Severity: High]
This is a pre-existing issue, but does using regmap_update_bits() here create a race condition that could lose hardware interrupts? If a hardware event triggers between the read and write operations inside regmap_update_bits() and sets a flag to 1 in the ABX8XX_REG_OSS register, this write will write back a 0 for that flag since it was 0 when read. Because the hardware clears flags when a 0 is written, the new interrupt flag would be cleared before it can be processed.
[ ... ]
drivers/rtc/rtc-abx80x.c static int abx80x_rtc_set_autocalibration(struct device *dev, · line 385
Quoted 11 lines
drivers/rtc/rtc-abx80x.c +3
-3@@ -390,9 +379,9 @@ static int abx80x_rtc_set_autocalibration(struct device *dev,if (abx80x_write_config_key (dev,ABX8XX_CFG_KEY_OSC ) <0 )return -EIO ; - retval =regmap_write (priv->regmap,ABX8XX_REG_OSC , flags); - -return retval; +return regmap_write_bits (priv->regmap,ABX8XX_REG_OSC , +ABX8XX_OSC_ACAL_1024 |ABX8XX_OSC_ACAL_512 , + flags); }
[Severity: Medium]
This isn't a bug introduced by this patch, but does the configuration key sequence here need to be atomic? The driver unlocks the ABX8XX_REG_OSC register by writing to ABX8XX_CFG_KEY_OSC. If another thread performs a concurrent RTC operation that writes to a different register before the regmap_write_bits() call completes, the hardware resets the configuration key to 0x00 and the write to ABX8XX_REG_OSC will silently fail.
[ ... ]
Quoted 11 lines
drivers/rtc/rtc-abx80x.c +0
-7@@ -466,24 +455,14 @@ static ssize_t oscillator_store(struct device *dev,return -EINVAL ; } - retval =regmap_read (priv->regmap,ABX8XX_REG_OSC , &flags); -if (retval <0 ) -return retval; - -if (rc_mode ==0 ) - flags &= ~(ABX8XX_OSC_OSEL ); -else
drivers/rtc/rtc-abx80x.c static ssize_t oscillator_store(struct device *dev, · line 463
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +2
-4- flags |= (ABX8XX_OSC_OSEL ); -/* Unlock write access on Oscillator Control register */ if (abx80x_write_config_key (dev->parent,ABX8XX_CFG_KEY_OSC ) <0 )return -EIO ; - retval =regmap_write (priv->regmap,ABX8XX_REG_OSC , flags); -if (retval <0 ) { + retval =regmap_write_bits (priv->regmap,ABX8XX_REG_OSC ,ABX8XX_OSC_OSEL , + rc_mode ==0 ?0 : (ABX8XX_OSC_OSEL ));
[Severity: Medium]
This is also a pre-existing issue, but can concurrent operations interrupt the unlock-and-write sequence in oscillator_store()? If another RTC update occurs between abx80x_write_config_key() and regmap_write_bits(), the configuration key will be reset and the oscillator update will be ignored.
[ ... ]
Quoted 7 lines
drivers/rtc/rtc-abx80x.c +0
-3@@ -550,17 +529,8 @@ static int abx80x_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)return put_user (tmp, (unsigned int __user *)arg);case RTC_VL_CLR : - err =regmap_read (priv->regmap,ABX8XX_REG_STATUS , &status); -if (err <0 ) -return err;
drivers/rtc/rtc-abx80x.c static int abx80x_ioctl(struct device *dev, unsigned int cmd, unsigned long arg) · line 533
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +2
-8- - status &= ~ABX8XX_STATUS_BLF ; - - err =regmap_write (priv->regmap,ABX8XX_REG_STATUS , status); -if (err <0 ) -return err; - -return 0 ; +return regmap_update_bits (priv->regmap,ABX8XX_REG_STATUS , +ABX8XX_STATUS_BLF ,0 );
[Severity: High]
This is a pre-existing issue, but does performing a read-modify-write on the ABX8XX_REG_STATUS register risk losing concurrent hardware updates? If an alarm triggers between the read and write phases and sets the ABX8XX_STATUS_AF flag to 1, the read-modify-write will write back 0 for that flag. Because this is a write-0-to-clear register, this clears the alarm interrupt before the handler can process it.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6
PATCH v2 7/8 rtc: abx80x: create abx80x_i2c_probe()
In reply to Antoni PokusinskiMove the I2C-specific code from abx80x_probe() to the newly created function. This is a preparation for introducing the support for ABX81X RTCs which use SPI interface.
--- drivers/rtc/rtc-abx80x.c | 165 ++++++++++++++++++++++++--------------- 1 file changed, 102 insertions(+), 63 deletions(-)
drivers/rtc/rtc-abx80x.c +102 -63
@@ -753,70 +753,35 @@ static const struct regmap_access_table abx80x_write_table = { .n_no_ranges = ARRAY_SIZE(abx80x_no_write_ranges), }; -static const struct regmap_config abx80x_regmap_config_i2c = { - .reg_bits =8 , - .val_bits =8 , - .max_register =ABX8XX_SRAM_BASE +ABX8XX_SRAM_WIN_SIZE -1 , - - .rd_table = &abx80x_read_table, - .wr_table = &abx80x_write_table, -}; - -static const struct i2c_device_id abx80x_id[] = { - { .name ="abx80x" , .driver_data =ABX80X }, - { .name ="ab0801" , .driver_data =AB0801 }, - { .name ="ab0803" , .driver_data =AB0803 }, - { .name ="ab0804" , .driver_data =AB0804 }, - { .name ="ab0805" , .driver_data =AB0805 }, - { .name ="ab1801" , .driver_data =AB1801 }, - { .name ="ab1803" , .driver_data =AB1803 }, - { .name ="ab1804" , .driver_data =AB1804 }, - { .name ="ab1805" , .driver_data =AB1805 }, - { .name ="rv1805" , .driver_data =RV1805 }, - { } -}; -MODULE_DEVICE_TABLE (i2c, abx80x_id); - -static int abx80x_probe (struct i2c_client *client) +static int abx80x_probe (struct device *dev,struct regmap *regmap,int irq, +struct device_node *np,unsigned int part) { -struct regmap *regmap; -struct device_node *np = client->dev.of_node;struct abx80x_priv *priv;int i, err, trickle_cfg = -EINVAL ;char buf[7 ]; -unsigned int part = (uintptr_t )i2c_get_match_data (client);unsigned int partnumber;unsigned int majrev, minrev;unsigned int lot;unsigned int wafer;unsigned int uid; -if (!i2c_check_functionality (client->adapter,I2C_FUNC_I2C )) -return -ENODEV ; - - regmap =devm_regmap_init_i2c (client, &abx80x_regmap_config_i2c); -if (IS_ERR (regmap)) { -dev_err (&client->dev,"Unable to allocate regmap\n" ); -return -EIO ; - } - - priv =devm_kzalloc (&client->dev,sizeof (*priv),GFP_KERNEL ); + priv =devm_kzalloc (dev,sizeof (*priv),GFP_KERNEL );if (priv ==NULL )return -ENOMEM ; - priv->rtc =devm_rtc_allocate_device (&client->dev); + priv->rtc =devm_rtc_allocate_device (dev);if (IS_ERR (priv->rtc))return PTR_ERR (priv->rtc); priv->rtc->ops = &abx80x_rtc_ops; - priv->irq = client->irq; + priv->irq = irq; priv->regmap = regmap; -dev_set_drvdata (&client->dev, priv); +dev_set_drvdata (dev, priv); err =regmap_bulk_read (regmap,ABX8XX_REG_ID0 , buf,sizeof (buf));if (err <0 ) { -dev_err (&client->dev,"Unable to read partnumber\n" ); +dev_err (dev,"Unable to read partnumber\n" );return -EIO ; }
@@ -826,14 +791,14 @@ static int abx80x_probe(struct i2c_client *client) lot = ((buf[4 ] &0x80 ) <<2 ) | ((buf[6 ] &0x80 ) <<1 ) | buf[3 ]; uid = ((buf[4 ] &0x7f ) <<8 ) | buf[5 ]; wafer = (buf[6 ] &0x7c ) >>2 ; -dev_info (&client->dev,"model %04x, revision %u.%u, lot %x, wafer %x, uid %x\n" , +dev_info (dev,"model %04x, revision %u.%u, lot %x, wafer %x, uid %x\n" , partnumber, majrev, minrev, lot, wafer, uid); err =regmap_update_bits (regmap,ABX8XX_REG_CTRL1 ,ABX8XX_CTRL_12_24 |ABX8XX_CTRL_ARST |ABX8XX_CTRL_WRITE ,ABX8XX_CTRL_WRITE );if (err <0 ) { -dev_err (&client->dev,"Unable to write control register\n" ); +dev_err (dev,"Unable to write control register\n" );return -EIO ; }
@@ -843,15 +808,14 @@ static int abx80x_probe(struct i2c_client *client)if (partnumber == abx80x_caps[i].pn)break ;if (abx80x_caps[i].pn ==0 ) { -dev_err (&client->dev,"Unknown part: %04x\n" , - partnumber); +dev_err (dev,"Unknown part: %04x\n" , partnumber);return -EINVAL ; } part = i; }if (partnumber != abx80x_caps[part].pn) { -dev_err (&client->dev,"partnumber mismatch %04x != %04x\n" , +dev_err (dev,"partnumber mismatch %04x != %04x\n" , partnumber, abx80x_caps[part].pn);return -EINVAL ; }
@@ -867,7 +831,7 @@ static int abx80x_probe(struct i2c_client *client) err =regmap_update_bits (regmap,ABX8XX_REG_CTRL2 ,ABX8XX_CTRL2_RSVD ,0 );if (err <0 ) { -dev_err (&client->dev,"Unable to write control2 register\n" ); +dev_err (dev,"Unable to write control2 register\n" );return -EIO ; }
@@ -875,7 +839,7 @@ static int abx80x_probe(struct i2c_client *client)* Write the configuration key register to enable access to * the config2 register */ -if (abx80x_write_config_key (&client->dev,ABX8XX_CFG_KEY_MISC ) <0 ) +if (abx80x_write_config_key (dev,ABX8XX_CFG_KEY_MISC ) <0 )return -EIO ;/*
@@ -887,19 +851,18 @@ static int abx80x_probe(struct i2c_client *client)ABX8XX_OUT_CTRL_EXDS , ABX8XX_OUT_CTRL_EXDS);if (err <0 ) { -dev_err (&client->dev, +dev_err (dev,"Unable to write output control register\n" );return -EIO ; } }if (np && abx80x_caps[part].has_tc) - trickle_cfg =abx80x_dt_trickle_cfg (&client->dev); + trickle_cfg =abx80x_dt_trickle_cfg (dev);if (trickle_cfg >0 ) { -dev_info (&client->dev,"Enabling trickle charger: %02x\n" , - trickle_cfg); -abx80x_enable_trickle_charger (&client->dev, trickle_cfg); +dev_info (dev,"Enabling trickle charger: %02x\n" , trickle_cfg); +abx80x_enable_trickle_charger (dev, trickle_cfg); } err =regmap_write (regmap,ABX8XX_REG_CD_TIMER_CTL ,BIT (2 ));
@@ -907,7 +870,7 @@ static int abx80x_probe(struct i2c_client *client)return err;if (abx80x_caps[part].has_wdog) { - err =abx80x_setup_watchdog (&client->dev); + err =abx80x_setup_watchdog (dev);if (err)return err; }
@@ -917,14 +880,14 @@ static int abx80x_probe(struct i2c_client *client)return err;if (priv->irq >0 ) { -dev_info (&client->dev,"IRQ %d supplied\n" , priv->irq); - err =devm_request_threaded_irq (&client->dev, priv->irq,NULL , +dev_info (dev,"IRQ %d supplied\n" , priv->irq); + err =devm_request_threaded_irq (dev, priv->irq,NULL , abx80x_handle_irq,IRQF_SHARED |IRQF_ONESHOT ,"abx8xx" , - &client->dev); + dev);if (err) { -dev_err (&client->dev,"unable to request IRQ, alarms disabled\n" ); +dev_err (dev,"unable to request IRQ, alarms disabled\n" ); priv->irq =0 ; } }
@@ -933,14 +896,39 @@ static int abx80x_probe(struct i2c_client *client) err =rtc_add_group (priv->rtc, &rtc_calib_attr_group);if (err) { -dev_err (&client->dev,"Failed to create sysfs group: %d\n" , - err); +dev_err (dev,"Failed to create sysfs group: %d\n" , err);return err; }return devm_rtc_register_device (priv->rtc); } +#if IS_ENABLED(CONFIG_I2C) + +static const struct regmap_config abx80x_regmap_config_i2c = { + .reg_bits = 8, + .val_bits = 8, + .max_register = ABX8XX_SRAM_BASE + ABX8XX_SRAM_WIN_SIZE - 1, + + .rd_table = &abx80x_read_table, + .wr_table = &abx80x_write_table, +}; + +static const struct i2c_device_id abx80x_id[] = { + { .name = "abx80x", .driver_data = ABX80X }, + { .name = "ab0801", .driver_data = AB0801 }, + { .name = "ab0803", .driver_data = AB0803 }, + { .name = "ab0804", .driver_data = AB0804 }, + { .name = "ab0805", .driver_data = AB0805 }, + { .name = "ab1801", .driver_data = AB1801 }, + { .name = "ab1803", .driver_data = AB1803 }, + { .name = "ab1804", .driver_data = AB1804 }, + { .name = "ab1805", .driver_data = AB1805 }, + { .name = "rv1805", .driver_data = RV1805 }, + { } +}; +MODULE_DEVICE_TABLE(i2c, abx80x_id); + #ifdef CONFIG_OF static const struct of_device_id abx80x_of_match[] = { {
@@ -988,16 +976,67 @@ static const struct of_device_id abx80x_of_match[] = {MODULE_DEVICE_TABLE (of, abx80x_of_match);#endif +static int abx80x_i2c_probe (struct i2c_client *client) +{ +unsigned int part = (uintptr_t )i2c_get_match_data (client); +struct regmap *regmap; + +if (!i2c_check_functionality (client->adapter,I2C_FUNC_I2C )) +return -ENODEV ; + + regmap =devm_regmap_init_i2c (client, &abx80x_regmap_config_i2c); +if (IS_ERR (regmap)) { +dev_err (&client->dev,"Unable to allocate regmap\n" ); +return -EIO ; + } + +return abx80x_probe (&client->dev, regmap, client->irq, + client->dev.of_node, part); +} +static struct i2c_driver abx80x_driver = { .driver = { .name ="rtc-abx80x" , .of_match_table =of_match_ptr (abx80x_of_match), }, - .probe = abx80x_probe, + .probe = abx80x_i2c_probe, .id_table = abx80x_id, }; -module_i2c_driver (abx80x_driver); +static int abx80x_register_driver (void ) +{ +return i2c_add_driver (&abx80x_driver); +} + +static void abx80x_unregister_driver (void ) +{ +i2c_del_driver (&abx80x_driver); +} + +#else + +static int abx80x_register_driver (void ) +{ +return 0 ; +} + +static void abx80x_unregister_driver (void ) +{ +} + +#endif /* IS_ENABLED(CONFIG_I2C) */ + +static int __init abx80x_init (void ) +{ +return abx80x_register_driver (); +} +module_init (abx80x_init); + +static void __exit abx80x_exit(void) +{ +abx80x_unregister_driver (); +} +module_exit (abx80x_exit);MODULE_AUTHOR ("Philippe De Muyter <[email protected]>" );MODULE_AUTHOR ("Alexandre Belloni <[email protected]>" );
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 7/8] rtc: abx80x: create abx80x_i2c_probe()
Sashiko has reviewed this patch and found no issues. It looks great!
Quoted 5 lines
Move the I2C-specific code from
abx80x_probe()to the newly created function. This is a preparation for introducing the support for ABX81X RTCs which use SPI interface.Signed-off-by Antoni Pokusinski <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7
PATCH v2 8/8 rtc: abx80x: add support for ABX81X
In reply to Antoni PokusinskiAbracon ABX81X is a family of RTCs with SPI interface featuring the same functionalities as the ABX80X I2C clocks.
--- drivers/rtc/Kconfig | 26 +++++----- drivers/rtc/rtc-abx80x.c | 106 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 115 insertions(+), 17 deletions(-)
drivers/rtc/Kconfig +14 -12
@@ -212,18 +212,6 @@ config RTC_DRV_ABEOZ9 This driver can also be built as a module. If so, the module will be called rtc-ab-e0z9. -config RTC_DRV_ABX80X - tristate "Abracon ABx80x" - select WATCHDOG_CORE if WATCHDOG - select REGMAP_I2C - help - If you say yes here you get support for Abracon AB080X and AB180X - families of ultra-low-power battery- and capacitor-backed real-time - clock chips. - - This driver can also be built as a module. If so, the module - will be called rtc-abx80x. - config RTC_DRV_AC100 tristate "X-Powers AC100" depends on MFD_AC100
@@ -955,6 +943,20 @@ config RTC_I2C_AND_SPI comment "SPI and I2C RTC drivers" +config RTC_DRV_ABX80X + tristate "Abracon ABx80x" + depends on RTC_I2C_AND_SPI + select WATCHDOG_CORE if WATCHDOG + select REGMAP_I2C if I2C + select REGMAP_SPI if SPI_MASTER + help + If you say yes here you get support for Abracon AB080X, AB180X, + AB081X and AB181X families of ultra-low-power battery- and + capacitor-backed real-time clock chips. + + This driver can also be built as a module. If so, the module + will be called rtc-abx80x. + config RTC_DRV_DS3232 tristate "Dallas/Maxim DS3232/DS3234" depends on RTC_I2C_AND_SPI
drivers/rtc/rtc-abx80x.c +101 -5
146 lines not on this page · raw message
Signature · 1 line
2.55.0
[email protected]
AI reviewRe: [PATCH v2 8/8] rtc: abx80x: add support for ABX81X
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] Incorrect SPI read/write flag masks invert SPI commands. - [Medium] Masking of valid error codes…
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incorrect SPI read/write flag masks invert SPI commands.
- [Medium] Masking of valid error codes from devm_regmap_init_*().
--
--- Patch [8]: [PATCH v2 8/8] rtc: abx80x: add support for ABX81X --- commit f05e60a6ab0d5bdeb5665a7f2de3be7428abd444
Author: Antoni Pokusinski <[email protected]>
Subject: rtc: abx80x: add support for ABX81X
This commit adds SPI support for the Abracon ABX81X family of RTCs. It introduces the required regmap configuration and SPI driver probe logic.
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0
[ ... ]
Quoted 6 lines
drivers/rtc/rtc-abx80x.c +2
-0@@ -1026,14 +1029,107 @@ static void abx80x_unregister_driver(void)#endif /* IS_ENABLED(CONFIG_I2C) */ +#if IS_ENABLED (CONFIG_SPI_MASTER ) +
drivers/rtc/rtc-abx80x.c static void abx80x_unregister_driver(void) · line 1043
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +10
-0+static const struct regmap_config abx80x_regmap_config_spi = { + .reg_bits =8 , + .val_bits =8 , + .max_register =ABX8XX_SRAM_BASE +ABX8XX_SRAM_WIN_SIZE -1 , + + .rd_table = &abx80x_read_table, + .wr_table = &abx80x_write_table, + + .write_flag_mask =BIT (7 ), +};
[Severity: Medium]
Does the hardware expect MSB=1 for writes and MSB=0 for reads? Since .read_flag_mask is omitted, regmap defaults it to 0. If the device expects the opposite (MSB=1 for reads), the SPI commands could be inverted.
[ ... ]
drivers/rtc/rtc-abx80x.c static void abx80x_unregister_driver(void) · line 1076
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +10
-0+static int abx81x_spi_probe (struct spi_device *spi) +{ +unsigned int part = (uintptr_t )spi_get_device_match_data (spi); +struct regmap *regmap; + + regmap =devm_regmap_init_spi (spi, &abx80x_regmap_config_spi); +if (IS_ERR (regmap)) { +dev_err (&spi->dev,"Unable to allocate regmap\n" ); +return -EIO ; + }
[Severity: Medium]
Should this return PTR_ERR(regmap) instead of a hardcoded -EIO? Returning -EIO here masks the true error code from devm_regmap_init_spi() (like -ENOMEM or -EPROBE_DEFER), which could disrupt probe deferral logic. (It looks like the existing abx80x_i2c_probe() might have the same behavior.)
[ ... ]
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8
Re: [PATCH v2 8/8] rtc: abx80x: add support for ABX81X
Quoted 31 lines · On Sat, Jul 25, 2026 at 03:30:32PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incorrect SPI read/write flag masks invert SPI commands.
- [Medium] Masking of valid error codes fromdevm_regmap_init_*().
----- Patch [8]: [PATCH v2 8/8] rtc: abx80x: add support for ABX81X --- commit
f05e60a6ab0d5bdeb5665a7f2de3be7428abd444
Author: Antoni Pokusinski <[email protected]>
Subject: rtc: abx80x: add support for ABX81XThis commit adds SPI support for the Abracon ABX81X family of RTCs. It introduces the required regmap configuration and SPI driver probe logic.
Quoted 4 lines
drivers/rtc/rtc-abx80x.c +0
-0[ ... ]
Quoted 13 lines
drivers/rtc/rtc-abx80x.c +9
-0@@ -1026,14 +1029,107 @@ static void abx80x_unregister_driver(void)#endif /* IS_ENABLED(CONFIG_I2C) */ +#if IS_ENABLED (CONFIG_SPI_MASTER ) + +static const struct regmap_config abx80x_regmap_config_spi = { + .reg_bits =8 , + .val_bits =8 , + .max_register =ABX8XX_SRAM_BASE +ABX8XX_SRAM_WIN_SIZE -1 , + + .rd_table = &abx80x_read_table, + .wr_table = &abx80x_write_table,
Quoted 8 lines
drivers/rtc/rtc-abx80x.c static void abx80x_unregister_driver(void) · line 1043
Quoted 3 lines
drivers/rtc/rtc-abx80x.c +3
-0+ + .write_flag_mask = BIT(7), +};[Severity: Medium]
Does the hardware expect MSB=1 for writes and MSB=0 for reads? Since .read_flag_mask is omitted, regmap defaults it to 0. If the device expects the opposite (MSB=1 for reads), the SPI commands could be inverted.
Everything ok here. According to the datasheet, the MSB of the register indicates read (if 0) or write (if 1).
Quoted 19 lines
[ ... ]
drivers/rtc/rtc-abx80x.c static void abx80x_unregister_driver(void) · line 1076
Quoted 10 lines
drivers/rtc/rtc-abx80x.c +10
-0+static int abx81x_spi_probe (struct spi_device *spi) +{ +unsigned int part = (uintptr_t )spi_get_device_match_data (spi); +struct regmap *regmap; + + regmap =devm_regmap_init_spi (spi, &abx80x_regmap_config_spi); +if (IS_ERR (regmap)) { +dev_err (&spi->dev,"Unable to allocate regmap\n" ); +return -EIO ; + }[Severity: Medium]
Should this returnPTR_ERR(regmap)instead of a hardcoded-EIO? Returning-EIOhere masks the true error code fromdevm_regmap_init_spi()(like-ENOMEMor -EPROBE_DEFER), which could disrupt probe deferral logic. (It looks like the existingabx80x_i2c_probe()might have the same behavior.)
Quoted 2 lines
[ ... ]
Yes, this should return PTR_ERR(), not sure why I added -EIO here... Will change this in v3.
Quoted 2 lines
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8