Re: [PATCH 5/6] rtc: abx80x: create abx80x_i2c_probe()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] RV1805 hardware workarounds are skipped during auto-detection.
--

--- Patch [5]: [PATCH 5/6] rtc: abx80x: create abx80x_i2c_probe() ---
commit 0661079a8b8384fb14bc67f5100b45ebe0a01c3e
Author: Antoni Pokusinski <apokusinski01@gmail.com>

rtc: abx80x: create abx80x_i2c_probe()

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.

> diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> index 7761cb353994e..6e0c14695bdf1 100644
> --- a/drivers/rtc/rtc-abx80x.c
> +++ b/drivers/rtc/rtc-abx80x.c
[ ... ]
> @@ -855,7 +820,7 @@ 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;
>  		}
> @@ -867,26 +832,24 @@ 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;
>  	}

[Severity: High]
This is a pre-existing issue, but are the RV1805 hardware workarounds being
skipped during auto-detection?

Looking at abx80x_probe() in drivers/rtc/rtc-abx80x.c, the RV1805 specifics
are configured before the part auto-detection logic resolves the hardware type:

    /* Configure RV1805 specifics */
    if (part == RV1805) {
        ...
    }

    /* part autodetection */
    if (part == ABX80X) {
        for (i = 0; abx80x_caps[i].pn; i++)
            if (partnumber == abx80x_caps[i].pn)
                break;
        ...
        part = i;
    }

When the driver is bound using the generic "abracon,abx80x" compatible string
or I2C ID, the part argument is initialized to ABX80X. Because the workarounds
check if (part == RV1805) before part is updated to RV1805, they appear to be
silently bypassed.

Could this cause the RV1805 RTC to accidentally enter test mode and suffer
from extra power leakage?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722195814.298552-1-apokusinski01@gmail.com?part=5