All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: Frank.Li@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	robh@kernel.org, devicetree@vger.kernel.org,
	linux-hwmon@vger.kernel.org, conor+dt@kernel.org,
	linux-i3c@lists.infradead.org
Subject: Re: [PATCH v6 05/12] i3c: master: Add support for devices without PID
Date: Tue, 21 Jul 2026 04:26:04 +0000	[thread overview]
Message-ID: <20260721042604.87E791F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260721040805.1696503-6-akhilrajeev@nvidia.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The static address matching logic for devices without a PID in `i3c_master_attach_boardinfo` is unreachable and contains a structurally impossible condition.
- [Medium] Devices requiring a PID can now be registered with an invalid Manufacturer ID of 0.
--

--- Patch [5]: [PATCH v6 05/12] i3c: master: Add support for devices without PID ---
commit 671c3fae66002e874a13051a9c956e9987d76674
Author: Akhil R <akhilrajeev@nvidia.com>

i3c: master: Add support for devices without PID
    
Devices using SETAASA for address assignment are not required to have
a 48-bit PID according to the I3C specification. Allow such devices to
register and use the static address where PID was required.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index b18dda89c4737..7b2f819bf4437 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c

[ ... ]

> @@ -2389,8 +2398,18 @@ static void i3c_master_attach_boardinfo(struct i3c_dev_desc *i3cdev)
>  	struct i3c_dev_boardinfo *i3cboardinfo;
>  
>  	list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
> -		if (i3cdev->info.pid != i3cboardinfo->pid)
> -			continue;
> +		/*
> +		 * For devices without PID (e.g., SETAASA devices), match by
> +		 * static address. For devices with PID, match by PID.
> +		 */
> +		if (i3cboardinfo->pid) {
> +			if (i3cdev->info.pid != i3cboardinfo->pid)
> +				continue;
> +		} else {
> +			if (!i3cboardinfo->static_addr ||
> +			    i3cdev->info.static_addr != i3cboardinfo->static_addr)
> +				continue;
> +		}

[Severity: Medium]
Will this static address matching logic ever evaluate to false?

Since i3c_master_attach_boardinfo() is only called during the dynamic
address assignment (ENTDAA) phase, i3cdev->info.static_addr is inherently 0
in this context.

Because i3cboardinfo->static_addr is validated to be non-zero at creation,
the condition i3cdev->info.static_addr != i3cboardinfo->static_addr will
evaluate to 0 != non-zero, which is always true.

This means the loop will always continue, making this branch effectively
dead code that fails to perform the intended matching.

>  
>  		i3cdev->boardinfo = i3cboardinfo;
>  		i3cdev->info.static_addr = i3cboardinfo->static_addr;

[ ... ]

> @@ -2848,9 +2871,16 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
>  
>  	boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
>  
> -	if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
> -	    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
> -		return -EINVAL;
> +	/* For SETAASA devices, validate the static address instead of PID */
> +	if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
> +		if (!boardinfo->static_addr)
> +			return -EINVAL;
> +	} else {
> +		if (!boardinfo->pid ||
> +		    (boardinfo->pid & GENMASK_ULL(63, 48)) ||
> +		    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
> +			return -EINVAL;
> +	}
>  
>  	boardinfo->init_dyn_addr = init_dyn_addr;
>  	boardinfo->fwnode = fwnode_handle_get(fwnode);
> @@ -2873,10 +2903,10 @@ static int i3c_master_add_of_dev(struct i3c_master_controller *master,
>  		return ret;
>  
>  	/*
> -	 * The manufacturer ID can't be 0. If reg[1] == 0 that means we're
> -	 * dealing with an I2C device.
> +	 * I3C device should have either the manufacturer ID specified or the
> +	 * address discovery method specified. Else treat it as an I2C device.
>  	 */
> -	if (!reg[1])
> +	if (!reg[1] && !fwnode_property_present(fwnode, "mipi-i3c-static-method"))
>  		ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
>  	else
>  		ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);

[Severity: Medium]
Could this change allow devices requiring a PID to be registered with an
invalid Manufacturer ID of 0?

By permitting reg[1] == 0 when mipi-i3c-static-method is present in
i3c_master_add_of_dev(), it appears we can bypass the strict Manufacturer ID
validation in i3c_master_add_i3c_boardinfo().

If the method is SETDASA, which still requires a PID, boardinfo->pid is set
to ((u64)0 << 32) | reg[2].  If reg[2] is non-zero, !boardinfo->pid is false.

Would this result in successfully registering the device despite the zero
Manufacturer ID, violating the MIPI I3C specification?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721040805.1696503-1-akhilrajeev@nvidia.com?part=5

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: Frank.Li@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	robh@kernel.org, devicetree@vger.kernel.org,
	linux-hwmon@vger.kernel.org, conor+dt@kernel.org,
	linux-i3c@lists.infradead.org
Subject: Re: [PATCH v6 05/12] i3c: master: Add support for devices without PID
Date: Tue, 21 Jul 2026 04:26:04 +0000	[thread overview]
Message-ID: <20260721042604.87E791F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260721040805.1696503-6-akhilrajeev@nvidia.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The static address matching logic for devices without a PID in `i3c_master_attach_boardinfo` is unreachable and contains a structurally impossible condition.
- [Medium] Devices requiring a PID can now be registered with an invalid Manufacturer ID of 0.
--

--- Patch [5]: [PATCH v6 05/12] i3c: master: Add support for devices without PID ---
commit 671c3fae66002e874a13051a9c956e9987d76674
Author: Akhil R <akhilrajeev@nvidia.com>

i3c: master: Add support for devices without PID
    
Devices using SETAASA for address assignment are not required to have
a 48-bit PID according to the I3C specification. Allow such devices to
register and use the static address where PID was required.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index b18dda89c4737..7b2f819bf4437 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c

[ ... ]

> @@ -2389,8 +2398,18 @@ static void i3c_master_attach_boardinfo(struct i3c_dev_desc *i3cdev)
>  	struct i3c_dev_boardinfo *i3cboardinfo;
>  
>  	list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
> -		if (i3cdev->info.pid != i3cboardinfo->pid)
> -			continue;
> +		/*
> +		 * For devices without PID (e.g., SETAASA devices), match by
> +		 * static address. For devices with PID, match by PID.
> +		 */
> +		if (i3cboardinfo->pid) {
> +			if (i3cdev->info.pid != i3cboardinfo->pid)
> +				continue;
> +		} else {
> +			if (!i3cboardinfo->static_addr ||
> +			    i3cdev->info.static_addr != i3cboardinfo->static_addr)
> +				continue;
> +		}

[Severity: Medium]
Will this static address matching logic ever evaluate to false?

Since i3c_master_attach_boardinfo() is only called during the dynamic
address assignment (ENTDAA) phase, i3cdev->info.static_addr is inherently 0
in this context.

Because i3cboardinfo->static_addr is validated to be non-zero at creation,
the condition i3cdev->info.static_addr != i3cboardinfo->static_addr will
evaluate to 0 != non-zero, which is always true.

This means the loop will always continue, making this branch effectively
dead code that fails to perform the intended matching.

>  
>  		i3cdev->boardinfo = i3cboardinfo;
>  		i3cdev->info.static_addr = i3cboardinfo->static_addr;

[ ... ]

> @@ -2848,9 +2871,16 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
>  
>  	boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
>  
> -	if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
> -	    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
> -		return -EINVAL;
> +	/* For SETAASA devices, validate the static address instead of PID */
> +	if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
> +		if (!boardinfo->static_addr)
> +			return -EINVAL;
> +	} else {
> +		if (!boardinfo->pid ||
> +		    (boardinfo->pid & GENMASK_ULL(63, 48)) ||
> +		    I3C_PID_RND_LOWER_32BITS(boardinfo->pid))
> +			return -EINVAL;
> +	}
>  
>  	boardinfo->init_dyn_addr = init_dyn_addr;
>  	boardinfo->fwnode = fwnode_handle_get(fwnode);
> @@ -2873,10 +2903,10 @@ static int i3c_master_add_of_dev(struct i3c_master_controller *master,
>  		return ret;
>  
>  	/*
> -	 * The manufacturer ID can't be 0. If reg[1] == 0 that means we're
> -	 * dealing with an I2C device.
> +	 * I3C device should have either the manufacturer ID specified or the
> +	 * address discovery method specified. Else treat it as an I2C device.
>  	 */
> -	if (!reg[1])
> +	if (!reg[1] && !fwnode_property_present(fwnode, "mipi-i3c-static-method"))
>  		ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
>  	else
>  		ret = i3c_master_add_i3c_boardinfo(master, fwnode, reg);

[Severity: Medium]
Could this change allow devices requiring a PID to be registered with an
invalid Manufacturer ID of 0?

By permitting reg[1] == 0 when mipi-i3c-static-method is present in
i3c_master_add_of_dev(), it appears we can bypass the strict Manufacturer ID
validation in i3c_master_add_i3c_boardinfo().

If the method is SETDASA, which still requires a PID, boardinfo->pid is set
to ((u64)0 << 32) | reg[2].  If reg[2] is non-zero, !boardinfo->pid is false.

Would this result in successfully registering the device despite the zero
Manufacturer ID, violating the MIPI I3C specification?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721040805.1696503-1-akhilrajeev@nvidia.com?part=5

  reply	other threads:[~2026-07-21  4:26 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21  4:07 [PATCH v6 00/12] Support ACPI and SETAASA device discovery Akhil R
2026-07-21  4:07 ` Akhil R
2026-07-21  4:07 ` [PATCH v6 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:16   ` sashiko-bot
2026-07-21  4:16     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 02/12] i3c: master: Use unified device property interface Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:25   ` sashiko-bot
2026-07-21  4:25     ` sashiko-bot
2026-07-22 10:38   ` Adrian Hunter
2026-07-22 10:38     ` Adrian Hunter
2026-07-21  4:07 ` [PATCH v6 03/12] i3c: master: Support ACPI enumeration of child devices Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:32   ` sashiko-bot
2026-07-21  4:32     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 04/12] i3c: master: Add support for devices using SETAASA Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:30   ` sashiko-bot
2026-07-21  4:30     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 05/12] i3c: master: Add support for devices without PID Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:26   ` sashiko-bot [this message]
2026-07-21  4:26     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 06/12] i3c: master: match I3C device through DT and ACPI Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:25   ` sashiko-bot
2026-07-21  4:25     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:24   ` sashiko-bot
2026-07-21  4:24     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 08/12] i3c: dw-i3c-master: Add ACPI core clock frequency quirk Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:26   ` sashiko-bot
2026-07-21  4:26     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410 Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:22   ` sashiko-bot
2026-07-21  4:22     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 10/12] hwmon: spd5118: Remove 16-bit addressing Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:25   ` sashiko-bot
2026-07-21  4:25     ` sashiko-bot
2026-07-21  4:07 ` [PATCH v6 11/12] hwmon: spd5118: Add I3C support Akhil R
2026-07-21  4:07   ` Akhil R
2026-07-21  4:35   ` sashiko-bot
2026-07-21  4:35     ` sashiko-bot
2026-07-21  4:08 ` [PATCH v6 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon Akhil R
2026-07-21  4:08   ` Akhil R
2026-07-21  4:28   ` sashiko-bot
2026-07-21  4:28     ` sashiko-bot
2026-07-21 16:52 ` [PATCH v6 00/12] Support ACPI and SETAASA device discovery Frank Li
2026-07-21 16:52   ` Frank Li

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=20260721042604.87E791F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=akhilrajeev@nvidia.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i3c@lists.infradead.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.