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.

Michał Mirosław (1):
  i2c: muxes: Add GPIO-detected hotplug I2C

Svyatoslav Ryhel (1):
  dt-bindings: i2c: Document GPIO detected hot-plugged I2C bus

 .../bindings/i2c/i2c-hotplug-gpio.yaml        |  65 +++++
 drivers/i2c/muxes/Kconfig                     |  11 +
 drivers/i2c/muxes/Makefile                    |   1 +
 drivers/i2c/muxes/i2c-hotplug-gpio.c          | 263 ++++++++++++++++++
 4 files changed, 340 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-hotplug-gpio.yaml
 create mode 100644 drivers/i2c/muxes/i2c-hotplug-gpio.c

-- 
2.48.1

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.

Thanks,
Andi

Hi Andy,

+Cc David Gibson 

On Thu, 16 Oct 2025 00:50:47 +0200
Andi Shyti <andi.shyti@kernel.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/

чт, 16 жовт. 2025 р. о 01:50 Andi Shyti <andi.shyti@kernel.org> пише:
>
> 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.

Yes

> 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.

Herve and Luca did not come up with anything meaningful, they provided
just a few rough ideas. It will take an inconsiderate amount of time
before there will be any consensus between them and schema
maintainers, and even more time would be requited to settle this into
schemas and implement into drivers. Why should I suffer from this? Why
should changes I need be halted due to some incomplete 'ideas'? This
driver uses existing i2c mux framework and fits into it just fine.

> Thanks,
> Andi

Hi Svyatoslav,

> Herve and Luca did not come up with anything meaningful, they provided
> just a few rough ideas. It will take an inconsiderate amount of time

Well, IIRC they said that your use case can be mapped onto their
approach. Which is meaningful in my book.

> before there will be any consensus between them and schema
> maintainers, and even more time would be requited to settle this into
> schemas and implement into drivers. Why should I suffer from this? Why
> should changes I need be halted due to some incomplete 'ideas'? This
> driver uses existing i2c mux framework and fits into it just fine.

I am sorry to bring you bad news, but you need to suffer because this is
how development goes. If I get presented a generic solution (see Herve's
mail) and a specific solution (your driver), for this case I as a
maintainer will prefer the generic solution. Generic solutions need more
time because there are more things to handle, of course. This is typical
for development, I would say, it is not Linux or Free Software specific.

I appreciate that you tackled your issue and were open to share it with
the community. I see the work being done there. However, there are so
many things going on independently that I can't really prevent double
development from happening despite it having a high priority for me. As
soon as I get aware of people working on similar issues, I connect them.
That's what I did here as well.

So, if you want upstream supported I2C hot-plugging, you need to wait
for Luca's and Herve's work being accepted. Or provide a superior
solution. Or, if you want, join the ride. You already have experience in
this field (and hardware plus use case), you would be a very welcome
contributor, I would say.

All the best,

   Wolfram

On Thu, Oct 16, 2025 at 09:32:24AM +0200, Wolfram Sang wrote:
> Hi Svyatoslav,
> 
> > Herve and Luca did not come up with anything meaningful, they provided
> > just a few rough ideas. It will take an inconsiderate amount of time
> 
> Well, IIRC they said that your use case can be mapped onto their
> approach. Which is meaningful in my book.
> 
> > before there will be any consensus between them and schema
> > maintainers, and even more time would be requited to settle this into
> > schemas and implement into drivers. Why should I suffer from this? Why
> > should changes I need be halted due to some incomplete 'ideas'? This
> > driver uses existing i2c mux framework and fits into it just fine.
> 
> I am sorry to bring you bad news, but you need to suffer because this is
> how development goes. If I get presented a generic solution (see Herve's
> mail) and a specific solution (your driver), for this case I as a
> maintainer will prefer the generic solution. Generic solutions need more
> time because there are more things to handle, of course. This is typical
> for development, I would say, it is not Linux or Free Software specific.
> 
> I appreciate that you tackled your issue and were open to share it with
> the community. I see the work being done there. However, there are so
> many things going on independently that I can't really prevent double
> development from happening despite it having a high priority for me. As
> soon as I get aware of people working on similar issues, I connect them.
> That's what I did here as well.
> 
> So, if you want upstream supported I2C hot-plugging, you need to wait
> for Luca's and Herve's work being accepted. Or provide a superior
> solution. Or, if you want, join the ride. You already have experience in
> this field (and hardware plus use case), you would be a very welcome
> contributor, I would say.

Agreed.

What really slows things down is when there is only 1 user of a new 
binding. Too many times have I accepted one only for the 2nd user to 
show up right after accepting it and wanting something different. So 
now I just require more than 1 user and it is on the submitter(s) to do 
that. After all, it is their itch, not mine.

Rob

Hi Svyatoslav,

On Thu, Oct 16, 2025 at 09:32:24AM +0200, Wolfram Sang wrote:
> > Herve and Luca did not come up with anything meaningful, they provided
> > just a few rough ideas. It will take an inconsiderate amount of time
> 
> Well, IIRC they said that your use case can be mapped onto their
> approach. Which is meaningful in my book.
> 
> > before there will be any consensus between them and schema
> > maintainers, and even more time would be requited to settle this into
> > schemas and implement into drivers. Why should I suffer from this? Why
> > should changes I need be halted due to some incomplete 'ideas'? This
> > driver uses existing i2c mux framework and fits into it just fine.
> 
> I am sorry to bring you bad news, but you need to suffer because this is
> how development goes. If I get presented a generic solution (see Herve's
> mail) and a specific solution (your driver), for this case I as a
> maintainer will prefer the generic solution. Generic solutions need more
> time because there are more things to handle, of course. This is typical
> for development, I would say, it is not Linux or Free Software specific.
> 
> I appreciate that you tackled your issue and were open to share it with
> the community. I see the work being done there. However, there are so
> many things going on independently that I can't really prevent double
> development from happening despite it having a high priority for me. As
> soon as I get aware of people working on similar issues, I connect them.
> That's what I did here as well.
> 
> So, if you want upstream supported I2C hot-plugging, you need to wait
> for Luca's and Herve's work being accepted. Or provide a superior
> solution. Or, if you want, join the ride. You already have experience in
> this field (and hardware plus use case), you would be a very welcome
> contributor, I would say.

I agree with all what is said above. I just want to add that
Herve has provided links to all his work and what I would do is
to rebase all my work on top of theirs; make sure their work
together with yours work in your system and, perhaps, merge the
series.

Please, let me know if this works.

Andi