From: sashiko-bot@kernel.org
To: "Antoni Pokusinski" <apokusinski01@gmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, linux-rtc@vger.kernel.org,
devicetree@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH 2/6] rtc: abx80x: add irq to struct abx80x_priv
Date: Wed, 22 Jul 2026 20:13:53 +0000 [thread overview]
Message-ID: <20260722201354.3BDA11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260722195814.298552-3-apokusinski01@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The shared IRQ handler unconditionally returns IRQ_HANDLED and inadvertently clears all status bits.
- [High] The `abx80x_read_alarm` function fails unconditionally on success due to incorrect error checking.
--
--- Patch [2]: [PATCH 2/6] rtc: abx80x: add irq to struct abx80x_priv ---
commit ccef71986338cc749e8440b88d073968d465ea5c
Author: Antoni Pokusinski <apokusinski01@gmail.com>
rtc: abx80x: add irq to struct abx80x_priv
This patch moves the irq number into struct abx80x_priv so that it
is no longer tied to the i2c_client. This allows the irq number to
be accessed in the case of ABX81X SPI clocks.
> diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> index 5486d9d0b1e5d..9b0e1d48d9ba3 100644
> --- a/drivers/rtc/rtc-abx80x.c
> +++ b/drivers/rtc/rtc-abx80x.c
[ ... ]
> @@ -285,11 +286,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,
[Severity: High]
This is a pre-existing issue, but doesn't i2c_smbus_read_i2c_block_data()
return the number of bytes read on success?
Looking at drivers/rtc/rtc-abx80x.c:abx80x_read_alarm():
err = i2c_smbus_read_i2c_block_data(client, ABX8XX_REG_ASC,
sizeof(buf), buf);
if (err)
return err;
Since it returns 7 on success, will this unconditionally fail and return
early with an error code, leaving the alarm structure uninitialized?
[ ... ]
> @@ -921,19 +925,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,
[Severity: High]
This isn't a bug introduced by this patch, but since the IRQ is registered
here with IRQF_SHARED, does abx80x_handle_irq() correctly handle shared
interrupts?
Looking at drivers/rtc/rtc-abx80x.c:abx80x_handle_irq():
static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)
{
[ ... ]
status = i2c_smbus_read_byte_data(client, ABX8XX_REG_STATUS);
if (status < 0)
return IRQ_NONE;
[ ... ]
i2c_smbus_write_byte_data(client, ABX8XX_REG_STATUS, 0);
return IRQ_HANDLED;
}
If no relevant interrupt flags are set for this device, it still returns
IRQ_HANDLED and writes 0 to ABX8XX_REG_STATUS, clearing all status bits
including non-IRQ bits like BLF. Can this break other devices sharing the
interrupt line and silently drop hardware status flags?
> "abx8xx",
> client);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260722195814.298552-1-apokusinski01@gmail.com?part=2
next prev parent reply other threads:[~2026-07-22 20:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 19:58 [PATCH 0/6] rtc: abx80x: add support for ABX81X Antoni Pokusinski
2026-07-22 19:58 ` [PATCH 1/6] dt-bindings: rtc: abx80x: document ABX81X RTCs Antoni Pokusinski
2026-07-22 20:09 ` sashiko-bot
2026-07-22 19:58 ` [PATCH 2/6] rtc: abx80x: add irq to struct abx80x_priv Antoni Pokusinski
2026-07-22 20:13 ` sashiko-bot [this message]
2026-07-22 19:58 ` [PATCH 3/6] rtc: abx80x: use regmap instead of I2C specific API Antoni Pokusinski
2026-07-22 20:16 ` sashiko-bot
2026-07-22 19:58 ` [PATCH 4/6] rtc: abx80x: replace read-modify-write pattern with regmap helpers Antoni Pokusinski
2026-07-22 20:11 ` sashiko-bot
2026-07-22 19:58 ` [PATCH 5/6] rtc: abx80x: create abx80x_i2c_probe() Antoni Pokusinski
2026-07-22 20:10 ` sashiko-bot
2026-07-22 19:58 ` [PATCH 6/6] rtc: abx80x: add support for ABX81X Antoni Pokusinski
2026-07-22 20:09 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722201354.3BDA11F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=apokusinski01@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.