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: <CAPVz0n1-jN5WLFq4e0CZrneExrN_A=GNeGTwGHTCj14NAta+jQ@mail.gmail.com>
Date: Thu, 16 Oct 2025 10:00:56 +0300
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: 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>, 
	Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH v1 0/2 RESEND] i2c: muxes: Add GPIO-detected hotplug I2C

чт, 16 жовт. 2025 р. о 01:50 Andi Shyti <andi.shyti@...nel.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