arm64: dts: rockchip: flipper-one: wire Type-C up port VBUS to the connector

[munzzyy]

Fixes #19.

vbus-supply on &usbmux never reaches the driver. hd3ss3220 reads the vbus regulator from the connector fwnode, and with no connector child node present it finds that by walking the graph:

ep = fwnode_graph_get_next_endpoint(dev_fwnode(hd3ss3220->dev), NULL);
connector = fwnode_graph_get_remote_port_parent(ep);
...
vbus = devm_of_regulator_get_optional(hd3ss3220->dev, to_of_node(connector), "vbus");

On F0B1C2 that lands on &typec_up_con, not on &usbmux, so the lookup returns -ENODEV, hd3ss3220->vbus stays NULL and hd3ss3220_regulator_control() is never reached. VBUS on the up port is only present because the regulator is marked regulator-always-on.

The property isn't valid where it sits now either. CHECK_DTBS=y on current flipper-devel:

usb-mux@47 (ti,hd3ss3220): 'vbus-supply' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/usb/ti,hd3ss3220.yaml

So this moves it to &typec_up_con, which usb-connector.yaml already describes as carrying vbus-supply, and drops regulator-always-on now that the driver owns the enable. The comment on that line asks for exactly that once VBUS is wired up.

No upstream binding change is needed. My first read of #19 assumed a connector subnode was required and that turned out to be wrong; the graph path already resolves to a node that's allowed to carry the property.

Checked

• rk3576-flipper-one-rev-f0b1c2.dtb builds clean
• CHECK_DTBS=y errors on the board before this change and is quiet after
• checkpatch.pl --strict: 0 errors, 0 warnings, 0 checks
• decompiled the resulting dtb: usbmux port@0 → remote endpoint resolves into usb-c-connector port@1, and that connector's vbus-supply phandle matches vusb_typec_up

Not checked

The actual switching, which needs a board. With regulator-always-on gone the rail is only up when the driver asserts it, so what's worth watching is VBUS appearing on the up port in host mode and dropping otherwise, with ID still able to veto through the NOR gate. If that behaves differently than expected, dropping regulator-always-on is the line to revert first — the move itself is independently correct.

[alchark]

This won't work, because a generic Type-C connector which is not managed by an actual device (such as the mux here) has no idea how or when to switch the VBUS on or off. It's just the dumb receptacle on the board.

VBUS management is a feature of the mux controller, so the property must belong there (either directly or in a subnode)

[munzzyy]

I think the driver already does exactly that, and there's a mainline board relying on it.

hd3ss3220 is the thing that requests VBUS, and it doesn't look on its own node. With no connector child it walks the graph to the connector and looks there:

ep = fwnode_graph_get_next_endpoint(dev_fwnode(hd3ss3220->dev), NULL);
connector = fwnode_graph_get_remote_port_parent(ep);
...
vbus = devm_of_regulator_get_optional(hd3ss3220->dev, to_of_node(connector), "vbus");

arch/arm64/boot/dts/qcom/lemans-evk.dts has the same shape this patch produces: a standalone connector-0 with compatible = "usb-c-connector" carrying vbus-supply = <&usb0_vbus>, whose port@1 endpoint links to the hd3ss3220's port@0. That board depends on the lookup succeeding, since id-gpios is only read when hd3ss3220->vbus came back non-NULL, and its whole VBUS-follows-ID behaviour hangs off that.

It's also where the feature came from. f8d2bf7c0c5d ("usb: typec: hd3ss3220: Enable VBUS based on ID pin state") is Krishna Kurapati's, reviewed by Heikki Krogerus, and lemans-evk is the Qualcomm board it was written against.

On the modelling point, I don't think we disagree. VBUS management stays with the mux, and the mux driver is still what enables and disables the regulator. vbus-supply on the connector isn't claiming the receptacle manages anything, it describes which regulator feeds that receptacle's VBUS pin, which is why usb-connector.yaml is where the property is defined rather than in each controller's binding.

If you'd still rather it sat on &usbmux, that's possible but it needs two upstream changes first: a binding change, because ti,hd3ss3220.yaml is additionalProperties: false and describes neither vbus-supply nor a connector subnode, and a driver change, because nothing looks for the regulator on the mux node today. I'm happy to write both if that's the shape you want. The connector placement is just the one that works with no upstream changes at all.

[munzzyy]

One more thing on the subnode option, since that's the other shape you floated and I don't think it does what we'd want here.

Adding a connector child to &usbmux changes which branch probe takes:

connector = device_get_named_child_node(hd3ss3220->dev, "connector");
if (connector) {
	hd3ss3220->role_sw = fwnode_usb_role_switch_get(connector);
} else {
	...
	hd3ss3220->role_sw = usb_role_switch_get(hd3ss3220->dev);
}

A bare connector { vbus-supply = <&vusb_typec_up>; } has no usb-role-switch reference, and its parent is the mux rather than a role switch, so fwnode_usb_role_switch_get() comes back NULL. NULL isn't an error, so probe carries on happily, and then usb_role_switch_set_role() opens with if (IS_ERR_OR_NULL(sw)) return 0;. Role switching would go quietly dead: no probe failure, nothing in dmesg. Same shape of bug as the VBUS one.

To use the subnode we'd have to re-describe the role-switch link inside it too, on top of a binding patch to allow connector at all.

So the three shapes, as I see them:

• connector node (this patch): works on current mainline, no kernel changes needed, precedent in qcom/lemans-evk.dts
• connector subnode of the mux: binding patch, plus re-wiring the role switch into the subnode or role switching silently stops
• directly on &usbmux: binding patch plus a driver patch, since nothing reads the regulator from the mux node today

Happy to write the patches for either of the bottom two if that's the shape you want. I just wanted the tradeoff visible before we pick one.