[PATCH AUTOSEL 6.16-5.4] i3c: don't fail if GETHDRCAP is unsupported

[PATCH AUTOSEL 6.16-5.4] i3c: don't fail if GETHDRCAP is unsupported

[Sasha Levin]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

[ Upstream commit 447270cdb41b1c8c3621bb14b93a6749f942556e ]

'I3C_BCR_HDR_CAP' is still spec v1.0 and has been renamed to 'advanced
capabilities' in v1.1 onwards. The ST pressure sensor LPS22DF does not
have HDR, but has the 'advanced cap' bit set. The core still wants to
get additional information using the CCC 'GETHDRCAP' (or GETCAPS in v1.1
onwards). Not all controllers support this CCC and will notify the upper
layers about it. For instantiating the device, we can ignore this
unsupported CCC as standard communication will work. Without this patch,
the device will not be instantiated at all.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250704204524.6124-1-wsa+renesas@sang-engineering.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and the surrounding code, here's my
assessment:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **Fixes a real bug that prevents device instantiation**: The commit
   message clearly states that "Without this patch, the device will not
   be instantiated at all." This is a concrete functionality issue where
   legitimate I3C devices (like the ST pressure sensor LPS22DF) cannot
   be used with controllers that don't support the GETHDRCAP CCC
   command.

2. **Small and contained fix**: The change is minimal - only 2 lines
   changed:
   - Line 1441: Changed from `if (ret)` to `if (ret && ret !=
     -ENOTSUPP)`
   - This allows the function to continue when GETHDRCAP returns
     -ENOTSUPP instead of failing

3. **Clear regression prevention**: The fix prevents device
   initialization failure for hardware combinations that should work.
   The I3C spec evolved from v1.0 to v1.1, and this handles backward
   compatibility gracefully.

4. **No architectural changes**: This is a simple error handling
   adjustment that doesn't change any core functionality or introduce
   new features.

5. **Fixes interoperability issue**: The commit addresses a real-world
   hardware compatibility problem between certain I3C controllers and
   devices, which is exactly the type of bug that stable kernels should
   fix.

6. **Low risk of regression**: The change only affects the error path
   when GETHDRCAP fails with -ENOTSUPP. It doesn't change behavior for
   successful cases or other error conditions.

7. **Follows stable rules**:
   - It's obviously correct (treats unsupported CCC as non-fatal)
   - It's tiny (2-line change)
   - Fixes one specific issue
   - Fixes a real bug that prevents hardware from working

The commit allows I3C device initialization to proceed even when the
controller doesn't support the GETHDRCAP command, which is reasonable
since HDR capabilities are optional and standard I3C communication will
still work without them.

 drivers/i3c/master.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index fd81871609d9..e53c69d24873 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1439,7 +1439,7 @@ static int i3c_master_retrieve_dev_info(struct i3c_dev_desc *dev)
 
 	if (dev->info.bcr & I3C_BCR_HDR_CAP) {
 		ret = i3c_master_gethdrcap_locked(master, &dev->info);
-		if (ret)
+		if (ret && ret != -ENOTSUPP)
 			return ret;
 	}
 
-- 
2.39.5


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

[PATCH AUTOSEL 6.16-5.4] i3c: add missing include to internal header

[Sasha Levin]

From: Wolfram Sang <wsa+renesas@sang-engineering.com>

[ Upstream commit 3b661ca549b9e5bb11d0bc97ada6110aac3282d2 ]

LKP found a random config which failed to build because IO accessors
were not defined:

   In file included from drivers/i3c/master.c:21:
   drivers/i3c/internals.h: In function 'i3c_writel_fifo':
>> drivers/i3c/internals.h:35:9: error: implicit declaration of function 'writesl' [-Werror=implicit-function-declaration]

Add the proper header to where the IO accessors are used.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202507150208.BZDzzJ5E-lkp@intel.com/
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250717120046.9022-2-wsa+renesas@sang-engineering.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **Fixes a real build failure**: The commit fixes an actual
   compilation error where `writesl` function is used without including
   the proper header (`<linux/io.h>`). This is a concrete build
   regression that prevents kernel compilation in certain
   configurations.

2. **Minimal and safe change**: The fix is extremely simple - it only
   adds a single `#include <linux/io.h>` line to the internals.h header
   file. This is a one-line change with virtually no risk of introducing
   regressions.

3. **Detected by kernel test robot**: The issue was found by the Linux
   Kernel Test Robot (LKP), indicating it affects real-world build
   configurations that are tested regularly. The error message shows:
  ```
  drivers/i3c/internals.h:35:9: error: implicit declaration of function
  'writesl'
  ```

4. **Affects core I3C infrastructure**: The internals.h header is
   included by core I3C files (master.c and device.c), so a build
   failure here can prevent the entire I3C subsystem from compiling.

5. **Recent regression**: Looking at the git history, the
   `i3c_writel_fifo()` and `i3c_readl_fifo()` functions were recently
   added in commit 733b439375b4, and are already being used by I3C
   controller drivers (dw-i3c-master.c and cdns-i3c-master.c as shown in
   commits 6e055b1fb2fc and c20d3fa70491). This missing include is a
   regression that breaks builds after these recent changes.

6. **Clear stable backport criteria**: This meets the stable kernel
   rules perfectly:
   - It fixes a real bug (build failure)
   - It's obviously correct (missing include for used functions)
   - It's a minimal change (1 line)
   - No new features or architectural changes
   - Zero risk of functional regression

The commit is a textbook example of what should be backported to stable
trees - a simple, obvious fix for a build regression with no side
effects.

 drivers/i3c/internals.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i3c/internals.h b/drivers/i3c/internals.h
index 433f6088b7ce..ce04aa4f269e 100644
--- a/drivers/i3c/internals.h
+++ b/drivers/i3c/internals.h
@@ -9,6 +9,7 @@
 #define I3C_INTERNALS_H
 
 #include <linux/i3c/master.h>
+#include <linux/io.h>
 
 void i3c_bus_normaluse_lock(struct i3c_bus *bus);
 void i3c_bus_normaluse_unlock(struct i3c_bus *bus);
-- 
2.39.5


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

[PATCH AUTOSEL 6.16-6.1] i3c: master: Initialize ret in i3c_i2c_notifier_call()

[Sasha Levin]

From: Jorge Marques <jorge.marques@analog.com>

[ Upstream commit 290ce8b2d0745e45a3155268184523a8c75996f1 ]

Set ret to -EINVAL if i3c_i2c_notifier_call() receives an invalid
action, resolving uninitialized warning.

Signed-off-by: Jorge Marques <jorge.marques@analog.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250622-i3c-master-ret-uninitialized-v1-1-aabb5625c932@analog.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should be backported to stable kernel trees. Here's my
extensive analysis:

## Bug Analysis

The commit fixes a serious uninitialized variable bug in
`i3c_i2c_notifier_call()`. Looking at the code:

1. **The Bug**: The function declares `int ret` at line 2449 but doesn't
   initialize it. The switch statement only handles two cases
   (`BUS_NOTIFY_ADD_DEVICE` and `BUS_NOTIFY_DEL_DEVICE`), leaving `ret`
   uninitialized for any other action values.

2. **When It Triggers**: Since this notifier is registered with
   `bus_register_notifier(&i2c_bus_type, &i2cdev_notifier)`, it receives
   ALL bus notification events for I2C devices, including:
   - `BUS_NOTIFY_REMOVED_DEVICE`
   - `BUS_NOTIFY_BIND_DRIVER`
   - `BUS_NOTIFY_BOUND_DRIVER`
   - `BUS_NOTIFY_UNBIND_DRIVER`
   - `BUS_NOTIFY_UNBOUND_DRIVER`
   - `BUS_NOTIFY_DRIVER_NOT_BOUND`

3. **Impact**: When any of these unhandled actions occur, the function
   returns an uninitialized stack value, which could:
   - Accidentally return `NOTIFY_STOP` or `NOTIFY_BAD`, halting the
     notification chain
   - Cause unpredictable behavior in the device/driver binding process
   - Lead to intermittent, hard-to-debug failures

## Backport Criteria Analysis

1. **Fixes a real bug**: ✓ Yes - fixes an uninitialized variable that
   causes undefined behavior
2. **Small and contained**: ✓ Yes - adds only 2 lines (default case
   returning -EINVAL)
3. **No side effects**: ✓ Correct - the fix properly handles unexpected
   actions by returning an error
4. **No architectural changes**: ✓ Correct - simple bug fix, no design
   changes
5. **Critical subsystem**: ✓ Yes - affects I3C/I2C device management and
   driver binding
6. **Follows stable rules**: ✓ Yes - important bugfix with minimal risk

## Additional Context

- The bug was introduced in commit 72a4501b5d08 ("i3c: support
  dynamically added i2c devices") in January 2022
- The I3C subsystem has had other uninitialized variable fixes (e.g.,
  commit 6cbf8b38dfe3)
- This is a classic compiler warning fix that prevents real runtime
  issues
- The fix is conservative, returning -EINVAL for unexpected actions
  rather than silently ignoring them

This is exactly the type of bug that stable kernels should fix: a real
issue with unpredictable runtime consequences, fixed with a minimal,
safe change.

 drivers/i3c/master.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index e53c69d24873..dfa0bad991cf 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -2467,6 +2467,8 @@ static int i3c_i2c_notifier_call(struct notifier_block *nb, unsigned long action
 	case BUS_NOTIFY_DEL_DEVICE:
 		ret = i3c_master_i2c_detach(adap, client);
 		break;
+	default:
+		ret = -EINVAL;
 	}
 	i3c_bus_maintenance_unlock(&master->bus);
 
-- 
2.39.5


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