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] [day] [month] [year] [list]
Message-ID: <ba53cd50-dedd-43a7-9183-83caca16b637@collabora.com>
Date: Tue, 23 Jan 2024 12:52:02 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Conor Dooley <conor@...nel.org>
Cc: gregkh@...uxfoundation.org, robh+dt@...nel.org,
 krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 heikki.krogerus@...ux.intel.com, matthias.bgg@...il.com,
 dmitry.baryshkov@...aro.org, neil.armstrong@...aro.org,
 andersson@...nel.org, nathan@...nel.org, luca.weiss@...rphone.com,
 tianping.fang@...iatek.com, linux-usb@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 kernel@...labora.com
Subject: Re: [PATCH v2 1/2] dt-bindings: usb: Introduce ITE IT5205 Alt. Mode
 Passive MUX

Il 22/01/24 19:06, Conor Dooley ha scritto:
> On Mon, Jan 22, 2024 at 11:27:11AM +0100, AngeloGioacchino Del Regno wrote:
>> Il 19/01/24 17:18, Conor Dooley ha scritto:
>>> On Fri, Jan 19, 2024 at 01:58:11PM +0100, AngeloGioacchino Del Regno wrote:
>>>> Introduce a binding for the ITE IT5205 Alternate Mode Passive MUX,
>>>> used for connecting, disconnecting and switching orientation and
>>>> control the SBU signals for alternate modes on USB Type-C ports.
>>>>
>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>>>> ---
>>>>    .../devicetree/bindings/usb/ite,it5205.yaml   | 72 +++++++++++++++++++
>>>>    1 file changed, 72 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/usb/ite,it5205.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/ite,it5205.yaml b/Documentation/devicetree/bindings/usb/ite,it5205.yaml
>>>> new file mode 100644
>>>> index 000000000000..36ec4251b5f2
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/usb/ite,it5205.yaml
>>>> @@ -0,0 +1,72 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/usb/ite,it5205.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: ITE IT5202 Type-C USB Alternate Mode Passive MUX
>>>> +
>>>> +maintainers:
>>>> +  - AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>>>> +  - Tianping Fang <tianping.fang@...iatek.com>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: ite,it5205
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  vcc-supply:
>>>> +    description: Power supply for VCC pin (3.3V)
>>>> +
>>>> +  mode-switch:
>>>> +    description: Flag the port as possible handle of altmode switching
>>>> +    type: boolean
>>>> +
>>>> +  orientation-switch:
>>>> +    description: Flag the port as possible handler of orientation switching
>>>> +    type: boolean
>>>> +
>>>> +  ite,ovp-enable:
>>>> +    description: Enable Over Voltage Protection functionality
>>>> +    type: boolean
>>>
>>> Bitta devil's advocacy perhaps, but why is this DT property? Is it not
>>> known whether or not this is supported based on the compatible, and
>>> whether or not to enable it is a decision for the operating system to
>>> make?
>>>
>>>
>>
>> AFAIK, not all board designs can use the OVP. On some, this may be unstable - the
>> use case where this can be safely enabled is when there's nothing in between the
>> mux and the controller, and between the mux and the port.
> 
> Okay, if it varies based on the configuration that makes sense. Perhaps
> in the future consider mentioning stuff like that in the commit message.
> 
> Reviewed-by: Conor Dooley <conor.dooley@...rochip.com>
> 

You're right, it's totally sensible to write that in the commit message,
will do next time.

P.S.: I have been too much impatient and already sent a v3 because I had to
fix an issue with the code, could you please give your R-b to the v3 as well?
There's no change in the bindings commit.

https://lore.kernel.org/r/20240122110446.140226-2-angelogioacchino.delregno@collabora.com

Thanks again,
Angelo



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ