Re: [PATCH v4 8/9] rtc: abx80x: create abx80x_i2c_probe()

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

Pre-existing issues:
- [High] RV1805-specific initialization workarounds are skipped if the device is probed using the generic 'ABX80X' compatible string.
--

--- Patch [8]: [PATCH v4 8/9] rtc: abx80x: create abx80x_i2c_probe() ---
commit 5c7e0bb55f377bff46772b45dbc25f48fd477301
Author: Antoni Pokusinski <[email protected]>

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 ab88af43b4fa0..08b22c0676995 100644
> --- a/drivers/rtc/rtc-abx80x.c
> +++ b/drivers/rtc/rtc-abx80x.c

[ ... ]

> @@ -911,26 +876,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 isn't a bug introduced by this patch, but does this ordering bypass the
RV1805 specific workarounds when part autodetection is used?

If an RV1805 device is probed using the generic "abracon,abx80x" compatible
string, the part variable is initially ABX80X. In abx80x_probe(), the code
checks if (part == RV1805) to apply quirks before executing the
if (part == ABX80X) autodetection block that actually identifies the part
as an RV1805.

Should the RV1805 quirks block be moved after part autodetection so they
are properly applied when an RV1805 is autodetected?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8