linux-kernel - Re: [PATCHv3 1/2] dt-bindings: usb: typec: anx7688: start a binding document

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: <025d268f-96d0-49fa-9a67-f80ab81ed102@linaro.org>
Date: Thu, 11 Apr 2024 21:59:35 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Ondřej Jirman <megi@....cz>, Pavel Machek
 <pavel@....cz>, phone-devel@...r.kernel.org,
 kernel list <linux-kernel@...r.kernel.org>, fiona.klute@....de,
 martijn@...xit.nl, samuel@...lland.org, heikki.krogerus@...ux.intel.com,
 gregkh@...uxfoundation.org, linux-usb@...r.kernel.org, robh+dt@...nel.org,
 krzysztof.kozlowski+dt@...aro.org, devicetree@...r.kernel.org
Subject: Re: [PATCHv3 1/2] dt-bindings: usb: typec: anx7688: start a binding
 document

On 10/04/2024 04:20, Ondřej Jirman wrote:
> On Mon, Apr 08, 2024 at 10:12:30PM GMT, Krzysztof Kozlowski wrote:
>> On 08/04/2024 17:17, Ondřej Jirman wrote:
>>>
>>> Now for things to not fail during suspend/resume based on PM callbacks
>>> invocation order, anx7688 driver needs to enable this regulator too, as long
>>> as it needs it.
>>
>> No, the I2C bus driver needs to manage it. Not one individual I2C
>> device. Again, why anx7688 is specific? If you next phone has anx8867,
>> using different driver, you also add there i2c-supply? And if it is
>> nxp,ptn5100 as well?
> 
> Yes, that could work, if I2C core would manage this.

Either I don't understand about which I2C regulator you speak or this is
not I2C core regulator. This is a regulator to be managed by the I2C
controller, not by I2C core.


> 
>>>
>>> I can put bus-supply to I2C controller node, and read it from the ANX7688 driver
>>> I guess, by going up a DT node. Whether that's going to be acceptable, I don't
>>> know. 
>>>
>>>
>>> VCONN regulator I don't know where else to put either. It doesn't seem to belong
>>> anywhere. It's not something directly connected to Type-C connector, so
>>> not part of connector bindings, and there's nothing else I can see, other
>>> than anx7688 device which needs it for core functionality.
>>
>> That sounds like a GPIO, not regulator. anx7688 has GPIOs, right? On
>> Pinephone they go to regulator, but on FooPhone also using anx7688 they
>> go somewhere else, so why this anx7688 assumes this is a regulator?
> 
> CC1/CC2_VCONN control pins are "GPIO" of anx7688, sort of. They have fixed
> purpose of switching external 5V regulator output to one of the CC pins
> on type-c port. I don't care what other purpose with some other firmware
> someone puts to those pins. It's irrelevant to the use case of anx7688
> as a type-c controller/HDMI bridge, which we're describing here.
> 
> VCONN regulator is an actual GPIO controlled regulator on the board, and
> needs to be controlled by the anx7688 driver. So that CC1/CC2_VCONN control
> pins driven by the firmware actually do what they're supposed to do.
> 
> Not sure why it would be a business of anything else but anx7688 driver
> enabling this regulator, because only this driver knows and cares about this.
> If some other board doesn't have the need to manually enable the regulator, or
> doesn't have the regulator, it can simply be optional.
> 
> There are also some other funky supplies in the bindings, that are not connected
> to the chip in any way, but need to be controlled by the driver:
> 
> +  vbus-supply: true
> +  vbus-in-supply: true

Yeah, the vconn looks reasonable. Just provide description of the
supply, so it will be obvious.

> 



Best regards,
Krzysztof