linux-kernel - Re: [PATCH 1/3] dt-bindings: i2c: gpio: Add 'transition-delay-ms' property

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]

Date: Tue, 28 May 2024 08:59:06 +0200
From: Bastien Curutchet <bastien.curutchet@...tlin.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Peter Rosin <peda@...ntia.se>,
 Andi Shyti <andi.shyti@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Peter Korsgaard <peter.korsgaard@...co.com>,
 Wolfram Sang <wsa@...nel.org>
Cc: linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, herve.codina@...tlin.com,
 christophercordahi@...ometrics.ca
Subject: Re: [PATCH 1/3] dt-bindings: i2c: gpio: Add 'transition-delay-ms'
 property

Hi Krzysztof,

On 5/27/24 16:38, Krzysztof Kozlowski wrote:
> On 27/05/2024 13:39, Bastien Curutchet wrote:
>> The i2c-gpio-mux can be used to describe a multiplexer built upon
>> several i2c isolators having an enable pin (such as LTC4310). These
>> isolators can need some time between their enable pin's assertion and
>> the first i2c transfer.
>>
>> Add a 'transition-delay-ms' property that indicates the delay to be
>> respected before doing the first i2c transfer.
>>
> 
> That's quite limited hardware description, comparing to cover letter.
> Please provide full description here, not in cover letter. This is the
> binding, so the hardware part.

Ok, I'll add details in next iteration.

> 
> Anyway, this does not look like property of mux itself. If there is no
> isolator, the mux would work fine, right?
> 
In the case I'm thinking about, there is no mux at all on the hardware, 
only two isolators. Each of them have several devices behind. I use the 
i2c-gpio-mux to drive the isolators enable pins to always enable only 
one of the isolators at a time.

> Then why you are not adding this property to every possible bus and I2C
> controller? I2C isolator could be placed there as well.
> 
I actually thought about adding a description of I2C isolators because 
my real use case is only one I2C isolator on a I2C bus. The isolator has 
an enable pin that I want to drive low when the bus is unused to save 
power.
But I didn't find a proper way to describe it. I think a property for 
I2C controllers is not ideal to describe the GPIO, the transition-delay 
and the fact that there could be devices in front of the isolator and/or 
devices behind it (see below)
 

                                                      +------------+ 

                                                      |   GPIO     | 

                                                      | controller | 

                                                      +------------+ 

   +------------+                                           | 

   |    I2C     |------+-------------+                      | 

   | controller |      |             |                      | 

   +------------+  +---+---+  +------+------+               | 

                   | dev A |  |    I2C    EN|---------------+ 

                   +-------+  |  isolator   | 

                              +------+------+ 

                                     | 

                                     +-------+-----------+------- 

                                             |           | 

                                         +---+---+   +---+---+ 

                                         | dev B |   | dev C | 

                                         +-------+   +-------+ 


So I started to describe it as a device itself but then I realized that 
I was doing something very similar to the i2c-gpio-mux description 
that's why I finally submitted this patch series.

> So just like RC binding, that's not a property of I2C mux. Maybe this
> fits usage of GPIO RC / delay binding.
> 

IMHO that’s more of a MUX property than an RC binding because every MUX 
needs some time to switch from one bus to another. It’s just that for 
the vast majority of MUXes, this time is so small that it doesn’t need 
to be described.


Best regards,
Bastien