Re: [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 a=
utodetection for the RV1805 incorrectly resolves to AB1805.
--

--- Patch [2]: [PATCH v2 2/8] rtc: abx80x: move part autodetection before R=
V1805 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.

> diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> index 5486d9d0b1e5d..ca3af91c29977 100644
> --- a/drivers/rtc/rtc-abx80x.c
> +++ b/drivers/rtc/rtc-abx80x.c
> @@ -814,6 +814,25 @@ static int abx80x_probe(struct i2c_client *client)
>  		return -EIO;
>  	}
> =20
> +	/* part autodetection */
> +	if (part =3D=3D ABX80X) {
> +		for (i =3D 0; abx80x_caps[i].pn; i++)
> +			if (partnumber =3D=3D 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.

> +		if (abx80x_caps[i].pn =3D=3D 0) {
> +			dev_err(&client->dev, "Unknown part: %04x\n",
> +				partnumber);
> +			return -EINVAL;
> +		}
> +		part =3D i;
> +	}
> +
> +	if (partnumber !=3D abx80x_caps[part].pn) {
> +		dev_err(&client->dev, "partnumber mismatch %04x !=3D %04x\n",
> +			partnumber, abx80x_caps[part].pn);
> +		return -EINVAL;
> +	}
> +
>  	/* Configure RV1805 specifics */
>  	if (part =3D=3D 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 specifi=
cs
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.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260725145718.1473=
[email protected]?part=3D2