[PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Parth Pancholi]

From: Parth Pancholi <parth.pancholi@toradex.com>

Add a compatible entry for the TI TMUXHS4212 GPIO-based
bidirectional 2:1 mux/1:2 demux which can be used for
switching orientation of the SBU lines in USB Type-C
applications.

TMUXHS4212 datasheet: https://www.ti.com/lit/ds/symlink/tmuxhs4212.pdf

Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
---
 Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
index 88e1607cf053..48680721abc1 100644
--- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
+++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
@@ -22,6 +22,7 @@ properties:
           - nxp,cbdtu02043
           - onnn,fsusb43l10x
           - pericom,pi3usb102
+          - ti,tmuxhs4212
       - const: gpio-sbu-mux
 
   enable-gpios:
-- 
2.34.1

Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Krzysztof Kozlowski]

On 17/05/2024 13:11, Parth Pancholi wrote:
> From: Parth Pancholi <parth.pancholi@toradex.com>
> 
> Add a compatible entry for the TI TMUXHS4212 GPIO-based
> bidirectional 2:1 mux/1:2 demux which can be used for
> switching orientation of the SBU lines in USB Type-C
> applications.
> 
> TMUXHS4212 datasheet: https://www.ti.com/lit/ds/symlink/tmuxhs4212.pdf
> 
> Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
> ---
>  Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml | 1 +
>  1 file changed, 1 insertion(+)

Where is an user of this?

Best regards,
Krzysztof

Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Francesco Dolcini]

Hello Krzysztof,
thanks for the review.

On Sun, May 19, 2024 at 07:38:07PM +0200, Krzysztof Kozlowski wrote:
> On 17/05/2024 13:11, Parth Pancholi wrote:
> > From: Parth Pancholi <parth.pancholi@toradex.com>
> > 
> > Add a compatible entry for the TI TMUXHS4212 GPIO-based
> > bidirectional 2:1 mux/1:2 demux which can be used for
> > switching orientation of the SBU lines in USB Type-C
> > applications.
> > 
> > TMUXHS4212 datasheet: https://www.ti.com/lit/ds/symlink/tmuxhs4212.pdf
> > 
> > Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
> > ---
> >  Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Where is an user of this?

The Linux driver (drivers/usb/typec/mux/gpio-sbu-mux.c) is using only
"gpio-sbu-mux", just in case you did not check yourself already.

As of now there is no DT file in-tree using this new compatible, FWIW
"onnn,fsusb43l10x" in the same file is not used by anybody. From some
old discussion here [1] (not exactly the same - I know, and coming not
from a DT kernel maintainer) I assumed that it was fine to send such
a change.

If it's not the case we'll send the patch later on, however some
DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to
just accept DT file in which the binding changes are already merged
therefore I was trying to be a little bit proactive here.

Francesco

[1] https://lore.kernel.org/all/YgJjalw5O1aoBIX0@sirena.org.uk/

Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Krzysztof Kozlowski]

On 19/05/2024 22:27, Francesco Dolcini wrote:
> Hello Krzysztof,
> thanks for the review.
> 
> On Sun, May 19, 2024 at 07:38:07PM +0200, Krzysztof Kozlowski wrote:
>> On 17/05/2024 13:11, Parth Pancholi wrote:
>>> From: Parth Pancholi <parth.pancholi@toradex.com>
>>>
>>> Add a compatible entry for the TI TMUXHS4212 GPIO-based
>>> bidirectional 2:1 mux/1:2 demux which can be used for
>>> switching orientation of the SBU lines in USB Type-C
>>> applications.
>>>
>>> TMUXHS4212 datasheet: https://www.ti.com/lit/ds/symlink/tmuxhs4212.pdf
>>>
>>> Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
>>> ---
>>>  Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> Where is an user of this?
> 
> The Linux driver (drivers/usb/typec/mux/gpio-sbu-mux.c) is using only
> "gpio-sbu-mux", just in case you did not check yourself already.
> 
> As of now there is no DT file in-tree using this new compatible, FWIW
> "onnn,fsusb43l10x" in the same file is not used by anybody. From some
> old discussion here [1] (not exactly the same - I know, and coming not
> from a DT kernel maintainer) I assumed that it was fine to send such
> a change.
> 
> If it's not the case we'll send the patch later on, however some
> DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to
> just accept DT file in which the binding changes are already merged
> therefore I was trying to be a little bit proactive here.

TI? Never heard something like this from them... Such requirement would
seriously slow down any work, so it's not really reasonable. Expectation
is to post both binding change and an user, so DTS, in case of USB in
separate patchsets.

Otherwise you will get such questions, so your biondings patches also
won't have easy path to merging...


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Nishanth Menon]

On 08:53-20240520, Krzysztof Kozlowski wrote:
> On 19/05/2024 22:27, Francesco Dolcini wrote:

[...]
> > If it's not the case we'll send the patch later on, however some
> > DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to
> > just accept DT file in which the binding changes are already merged
> > therefore I was trying to be a little bit proactive here.
> 
> TI? Never heard something like this from them... Such requirement would
> seriously slow down any work, so it's not really reasonable. Expectation
> is to post both binding change and an user, so DTS, in case of USB in
> separate patchsets.

There is a reason we have set that "soft rule":
- Driver subsystem merges have known to be broken from time to time and
  the dt maintainer is left holding compatibles that have not made to
  master.
- ARM subsystem merges prefers not to see checkpatch warnings -
  typically, this happens with new compatibles in the driver subsystem.
- Off chance that driver subsystem maintainer picks up the dt changes as
  well (should not happen, but has happened)

We have however flexed the rule when:
a) driver maintainer is willing to provide us an immutable tag that we
   can merge in and base the dts on top.
b) We felt that the chances of the driver not making it is very very low
   (typically after 1+ month in next) and the dts change is in the wider
   interest of the community. In such case, we have to explicitly take
   the action of letting the patch submitter, driver subsystem to let us
   know if something bad happens to the PR, also in our PR to SoC
   maintainers, we have to call it out along with rationale why this is
   OK. This is a bunch of work from a lot of folks, so prefer only to
   trigger this path in case of exceptional cases - there have been a
   few far in between.

Again, the default rule (driver in one window, binding in next) has
kept us out of trouble for a few years now at the detriment of pace
of merges, but that took care of a lot of conflicts that we had seen
during initial days of k3 - there are few chains in the lakml list
where this was the direction we ended up in after discussion.

But, yes - as you mentioned, send the patches of the "user" of the dt
binding and driver gives the subsystem and dt maintainers a chance to
review in the context of usage prior to the driver and binding merge.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Nishanth Menon]

On 07:14-20240520, Nishanth Menon wrote:
> On 08:53-20240520, Krzysztof Kozlowski wrote:
> > On 19/05/2024 22:27, Francesco Dolcini wrote:
> 
> [...]
> > > If it's not the case we'll send the patch later on, however some
> > > DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to
> > > just accept DT file in which the binding changes are already merged
> > > therefore I was trying to be a little bit proactive here.
> > 
> > TI? Never heard something like this from them... Such requirement would
> > seriously slow down any work, so it's not really reasonable. Expectation
> > is to post both binding change and an user, so DTS, in case of USB in
> > separate patchsets.
> 
> There is a reason we have set that "soft rule":
> - Driver subsystem merges have known to be broken from time to time and
>   the dt maintainer is left holding compatibles that have not made to
>   master.
> - ARM subsystem merges prefers not to see checkpatch warnings -
>   typically, this happens with new compatibles in the driver subsystem.
> - Off chance that driver subsystem maintainer picks up the dt changes as
>   well (should not happen, but has happened)
> 
> We have however flexed the rule when:
> a) driver maintainer is willing to provide us an immutable tag that we
>    can merge in and base the dts on top.
> b) We felt that the chances of the driver not making it is very very low
>    (typically after 1+ month in next) and the dts change is in the wider
>    interest of the community. In such case, we have to explicitly take
>    the action of letting the patch submitter, driver subsystem to let us
>    know if something bad happens to the PR, also in our PR to SoC
>    maintainers, we have to call it out along with rationale why this is
>    OK. This is a bunch of work from a lot of folks, so prefer only to
>    trigger this path in case of exceptional cases - there have been a
>    few far in between.
> 
> Again, the default rule (driver in one window, binding in next) has

That went out wrong :( - correction:

s/driver in one window, binding in next/driver and binding in one
window, dts in the next window/

Apologies on the confusion.

> kept us out of trouble for a few years now at the detriment of pace
> of merges, but that took care of a lot of conflicts that we had seen
> during initial days of k3 - there are few chains in the lakml list
> where this was the direction we ended up in after discussion.
> 
> But, yes - as you mentioned, send the patches of the "user" of the dt
> binding and driver gives the subsystem and dt maintainers a chance to
> review in the context of usage prior to the driver and binding merge.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH] dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212

[Krzysztof Kozlowski]

On 20/05/2024 14:14, Nishanth Menon wrote:
> On 08:53-20240520, Krzysztof Kozlowski wrote:
>> On 19/05/2024 22:27, Francesco Dolcini wrote:
> 
> [...]
>>> If it's not the case we'll send the patch later on, however some
>>> DT files maintainers (e.g. arch/arm64/boot/dts/ti/) have a policy to
>>> just accept DT file in which the binding changes are already merged
>>> therefore I was trying to be a little bit proactive here.
>>
>> TI? Never heard something like this from them... Such requirement would
>> seriously slow down any work, so it's not really reasonable. Expectation
>> is to post both binding change and an user, so DTS, in case of USB in
>> separate patchsets.
> 
> There is a reason we have set that "soft rule":
> - Driver subsystem merges have known to be broken from time to time and
>   the dt maintainer is left holding compatibles that have not made to
>   master.

You mean driver tree took the bindings (because then you take the DTS)
but they did not make it up to the master? Yeah, happens, but postponing
DTS code for this is quite harsh.

> - ARM subsystem merges prefers not to see checkpatch warnings -
>   typically, this happens with new compatibles in the driver subsystem.

Never heard any comment about this. Maybe because I always do checkpatch
tests (part of workflow), so then any warning, which there are pretty
lot like touching maintainer files, is understood as accepted.

> - Off chance that driver subsystem maintainer picks up the dt changes as
>   well (should not happen, but has happened)

DTS changes? Yes, that's why they should be in separate patchsets for
few known trees, like USB, net, media.

> 
> We have however flexed the rule when:
> a) driver maintainer is willing to provide us an immutable tag that we
>    can merge in and base the dts on top.

You cannot base DTS on top of any driver branch. In the past Arnd and
Olof were rejecting this, recently this got more flexible, but still cannot.

This implies dependency, which is a no-go.

> b) We felt that the chances of the driver not making it is very very low
>    (typically after 1+ month in next) and the dts change is in the wider
>    interest of the community. In such case, we have to explicitly take
>    the action of letting the patch submitter, driver subsystem to let us
>    know if something bad happens to the PR, also in our PR to SoC
>    maintainers, we have to call it out along with rationale why this is
>    OK. This is a bunch of work from a lot of folks, so prefer only to
>    trigger this path in case of exceptional cases - there have been a
>    few far in between.
> 
> Again, the default rule (driver in one window, binding in next) has
> kept us out of trouble for a few years now at the detriment of pace
> of merges, but that took care of a lot of conflicts that we had seen
> during initial days of k3 - there are few chains in the lakml list
> where this was the direction we ended up in after discussion.
> 
> But, yes - as you mentioned, send the patches of the "user" of the dt
> binding and driver gives the subsystem and dt maintainers a chance to
> review in the context of usage prior to the driver and binding merge.

Anyway, I am fine, but then I expect from the contributor to explain
where is the user.

Specifically, for completely new bindings I will NAK them if there is no
driver or DTS posted. Why? Because experience shown me that people post
some bindings and then entirely different DTS, without running full
dtbs_check. Therefore I want to see both - bindings and DTS, if applicable.

It is easy to fulfill both requirements - mine and yours. Post bindings.
Post DTS and link the bindings, with explanation it should be picked up
*later*, because that's what TI expects. That's way I can still find
both pieces, but you do not risk taking DTS too early.


Best regards,
Krzysztof