phy: apple: atc: Fall back to USB2 when pipehandler state is DUMMY

[p4ulcristian]

When DP alt mode is active on a TypeC port, atcphy is configured in DP
mode and atcphy_modes[mode].pipehandler_state is
ATCPHY_PIPEHANDLER_STATE_DUMMY. If DWC3/xHCI then calls
phy_set_mode(PHY_MODE_USB_HOST) on the USB3 PHY,
atcphy_configure_pipehandler() hits the default: branch and returns
-EINVAL.

This propagates through usb_phy_roothub_set_mode() → usb_add_hcd()
as error -22, failing the entire xhci-hcd probe. USB2 data to the
TypeC device is lost, even though D+/D- are unaffected by DP alt mode.

Fix this by configuring the dummy pipehandler instead of returning
-EINVAL. DUMMY pipehandler state means SS lanes are not available
for USB3, so DWC3/xHCI initialises in USB2-only mode and devices
enumerate normally. This is consistent with how
ATCPHY_PIPEHANDLER_STATE_USB4 is already handled.

Tested on apple,j413 (M2 MacBook Air 13") with DP alt mode active:
xhci-hcd.3.auto now probes successfully and USB2 HID devices enumerate
(USB HID glasses idVendor=1bbb idProduct=af50 on USB bus 1).

Signed-off-by: Paul Cristian p4ulcristian@gmail.com

[ibrahim-mubarak]

Independently hit this and root-caused it to the same -EINVAL in atcphy_configure_pipehandler() before finding this PR.

Reproduced on apple,j413 (MacBook Air M2 2022, fairydust branch) with a USB-C monitor that has an integrated USB hub, negotiating pin assignment C (4-lane DP): xhci-hcd.4.auto failed probe with error -22 and the monitor's hub was completely dead while the display worked.

With the equivalent fix applied (explicit case ATCPHY_PIPEHANDLER_STATE_DUMMY: doing the dummy fallback), the xHCI probes cleanly and the monitor's hub plus downstream keyboard/mouse enumerate at 480M alongside the active display.