On Feb 3, 2026, at 10:50 AM, Abdurrahman Hussain [off-list ref] wrote:

quoted

On Feb 3, 2026, at 10:31 AM, Andrew Lunn [off-list ref] wrote:

On Tue, Feb 03, 2026 at 10:14:49AM -0800, Abdurrahman Hussain wrote:

quoted

quoted

On Feb 3, 2026, at 7:45 AM, Andy Shevchenko [off-list ref] wrote:

On Mon, Feb 02, 2026 at 08:37:23PM +0000, Abdurrahman Hussain via B4 Relay wrote:

quoted

Use i2c_add_numbered_adapter() to allow platform devices to specify
fixed bus numbers when needed.

Not sure about this. Doesn't it break the current approach? Please, double
check that.

-- 
With Best Regards,
Andy Shevchenko

If pdev->id is PLATFORM_DEVID_NONE(-1) then i2c_add_numbered_adapter()
falls back to dynamic allocation and calls i2c_add_adapter().

Many existing i2c drivers use the same approach, see i2c-pxa.c and
i2c-pnx.c etc.

It is not about if other drivers do this. Its about does this change
the behaviour of this driver, so that I2C busses get different IDs
then before, and so cause regressions?

You need to explain in the commit message why you think this is safe.

  Andrew

Before, the driver was always doing the dynamic allocation due to
i2c_add_adapter(). So there could not have been a system that relied on
consistent i2c bus numbering. Even between reboots bus numbering could change.

The systems that did set pdev->id and were expecting a consistent i2c bus
numbering were broken to begin with.

This patch won’t break any existing systems or cause regressions.

I can add the following to the commit if you find the wording acceptable:

Previously, the i2c bus numbers were dynamically allocated because of the use of
the i2c_add_adapter() call. This meant there were no guarantees about consistent
bus numbering. However, with this change, on systems that don’t set their platform
device ID and leave it at the default PLATFORM_DEVID_NONE, the bus numbers will
still be dynamically allocated because of the check in i2c_add_numbered_adapter().
Therefore there won’t be any change in behavior.