linux-kernel - Re: [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251016091106.14499fab@bootlin.com>
Date: Thu, 16 Oct 2025 09:11:06 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: Svyatoslav Ryhel <clamor95@...il.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Peter Rosin <peda@...ntia.se>, Michał Mirosław <mirq-linux@...e.qmqm.pl>, Jonas
 Schwöbel <jonasschwoebel@...oo.de>,
 linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Luca Ceresoli <luca@...aceresoli.net>, David
 Gibson <david@...son.dropbear.id.au>
Subject: Re: [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C

Hi Andy,

+Cc David Gibson 

On Thu, 16 Oct 2025 00:50:47 +0200
Andi Shyti <andi.shyti@...nel.org> wrote:

> Hi,
> 
> On Mon, Oct 13, 2025 at 09:00:15AM +0300, Svyatoslav Ryhel wrote:
> > Implement driver for hot-plugged I2C busses, where some devices on
> > a bus are hot-pluggable and their presence is indicated by GPIO line.
> > This feature is used by the ASUS Transformers family, by the  Microsoft
> > Surface RT/2 and maybe more.
> > 
> > ASUS Transformers expose i2c line via proprietary 40 pin plug and wire
> > that line through optional dock accessory. Devices in the dock are
> > connected to this i2c line and docks presence is detected by a dedicted
> > GPIO.  
> 
> This is a resend of the previous series. I want to understand
> whether this effort can align with what Herve and Luca are
> working on. I have not looked into the implementation details
> yet, but I want to avoid overlapping or conflicting patches.
> 

Here, in this series, a fake i2c mux is proposed to handle this case.

This can work if only i2c devices are added by the dock on the 40 pin
plug. If this 40 pin connector provide other resources or busses usable
by the dock, the fake i2c mux will not be enough.

Even if this fake mux is accepted, we will not use it.

Indeed, in our case more resources are provided at the connector and are
used by the addon. We have:
 - Some gpios used as reset and interrupts on the addon
 - One PWM
 - Two I2C busses
   Described and handled at connector level I2C extension busses.
 - ...

With that, different addon can be connected. We detect connection
with GPIOs and identify the addon connected thanks to an I2C EEPROM
available on the addon.

On our side, we handle this case using:
 - A connector driver
   This driver handle the connector. Its purpose is:
     - Detect insertion an removal of the addon
     - Identify the addon
     - Load a DT overlay that describes the addon

 - A DT overlay describing the addon
   This DT overlay has to be board agnostic. I mean from
   the addon point of view, only the connector is known.
   The addon DT describes devices connected at the I2C bus
   available at the connector but it shouldn't have to know
   if this I2C bus is i2c3 or i2c4 in the base board.

To do that we introduced a first draft of i2c bus extension implementation [1]
and its binding [2].

Also we introduce export symbols. This is the main blocking point.

Having the export symbols feature working with device-tree overlay has been
a no go from device-tree maintainers Rob Herring and David Gibson (dtc
maintainer) and we need the export symbols feature to have the addon
described.

Luca did a really clear presentation at ELCE related to our issue and explained
the purpose of i2c bus extension and export symbols feature. His slides [3] and
the video of the talk [4] are available.

Discussion is ongoing related to the export symbols feature [5] and depending
on the conclusion of the discussion, the binding and the implementation of
i2c bus extension could change. This is the reason why I didn't send a new
iteration of the I2C bus extension binding and its related implementation.

IHMO, export symbols feature is the key to unlock the situation and move
forward.

That's said, if you want a more up to date i2c bus extension binding and
implementation, I can send a new iterations but you have to be prepare for
changes in the future. Again, depending of the conclusion of export symbols
feature discussion, the current proposal for i2c bus extension binding and
implementation could be obsolete.

Feel free to ask for more details if needed.

Best regards,
Hervé

[1] https://lore.kernel.org/all/20250205173918.600037-1-herve.codina@bootlin.com/
[2] https://lore.kernel.org/all/20250618082313.549140-1-herve.codina@bootlin.com/
[3] https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
[4] https://www.youtube.com/watch?v=C8dEQ4OzMnc
[5] https://lore.kernel.org/all/20250902105710.00512c6d@booty/