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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ffa2a954-d161-45f1-a83f-509148be3b6f@lucaceresoli.net>
Date: Tue, 16 Sep 2025 09:50:26 +0200
From: Luca Ceresoli <luca@...aceresoli.net>
To: Herve Codina <herve.codina@...tlin.com>,
 Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Svyatoslav Ryhel <clamor95@...il.com>, Andi Shyti
 <andi.shyti@...nel.org>, 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@...tlin.com
Subject: Re: [PATCH v1 0/2] i2c: muxes: Add GPIO-detected hotplug I2C

Hello,

thanks Wolfram for pulling Hervé and me in.

+Cc my Bootlin e-mail address

Il 16/09/25 08:19, Herve Codina ha scritto:
> Hi Wolfram,
> 
> On Mon, 15 Sep 2025 17:42:06 +0200
> Wolfram Sang <wsa+renesas@...g-engineering.com> wrote:
> 
>> On Mon, Sep 15, 2025 at 02:53:23PM +0300, Svyatoslav Ryhel wrote:
>>> пн, 15 вер. 2025 р. о 14:35 Wolfram Sang
>>> <wsa+renesas@...g-engineering.com> пише:  
>>>>
>>>> On Mon, Sep 15, 2025 at 09:01:36AM +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.
>>>>>
>>>>> 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  
>>>>
>>>> Adding Herve and Luca to CC because they want to achieve the same with
>>>> their I2C bus extensions, no?  
>>
>> Sorry, a misunderstanding: the question was for Herve and Luca. I wanted
>> to ask for a comment from them if this is the same problem (which I
>> think it is). The question was not meant for you.
>>
> 
> Indeed, we try to handle the same use case.
> 
> The i2c-hotplug-gpio.c driver handles only an connector with an I2C bus.
> 
> On our side, we try to have something more generic that can handle more
> than one I2C and some other busses and resources (gpio, pwm, ...) wired
> to a connector.
> 
> To move this i2c-hotplug-gpio to our proposal direction, this should become
> a connector driver with a i2c bus extension and an addon DT describing the
> i2c devices available on the addon board.
> 
> The connector driver should monitor the gpio and apply the addon DT when it
> detects the addon plugged.
> 
> Also, I am waiting for conclusions in the export symbols discussion [1] to
> re-spin the i2c bus extension series.

I just have one question to add to what Hervé wrote.

I guess in the big picture you have a device tree where all
hot-pluggable I2C devices are always described, but they won't probe
until i2c_hotplug_activate() adds an adapter for them. Is my
understanding correct?

If correct, this implies you can connect only one type of dock. Multple
dock models with different peripherals cannot be supported.

Best regards,
Luca


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ