From: Joonhoe Kim <26rote@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Abel Vesa <abel.vesa@oss.qualcomm.com>,
Wesley Cheng <wesley.cheng@oss.qualcomm.com>,
Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Val Packett <val@packett.cool>,
Balaji Kalkonda <balaji.kalkonda@oss.qualcomm.com>,
Vladyslav Tymoshchuk <tvlad744@gmail.com>,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: usb: qcom,snps-dwc3: Add mode-switch
Date: Sat, 7 Nov 2026 11:12:08 +0900 [thread overview]
Message-ID: <20261107021208.934-1-26rote@gmail.com> (raw)
In-Reply-To: <20261104-bipedal-supportive-earwig-2aae26@quoll>
On Wed, Nov 04, 2026 at 02:13:21PM +0100, Krzysztof Kozlowski wrote:
> On Tue, Nov 03, 2026 at 10:50:55PM +0900, Joonhoe Kim wrote:
> > The QMP USB3-DP combo PHY stops the USB3 PIPE clock when a Type-C
> > DisplayPort pin assignment gives it all four lanes for DisplayPort,
> > while the controller can keep running its USB 2.0 port. The controller
> > has to move to the UTMI clock before that happens, so it needs the
> > Type-C mux state as well. fwnode_typec_mux_get() only matches graph
>
> Controller does not perform the switch, does it?
No, it does not route any signals. It only needs to know the mode: in
pin assignments C and E it selects the UTMI clock as its PIPE clock
before the PHY stops the PIPE clock.
usb-switch.yaml describes mode-switch as "Possible handler of altmode
switching". The WCD939x codec uses it in a similar way: its mux
callback only reports the audio accessory mode to its headset
detection. The codec nodes in sm8650-qrd.dts and sm8750-mtp.dts have
mode-switch.
> > nodes that have the "mode-switch" property, so allow it on the
> > controller node.
>
> So judging by this, you would need to fix fwnode_typec_mux_get() or
> opther driver code, not the binding?
The binding is needed because typec_mux_match() checks this property
before the mux driver has probed (see the comment in typec_mux_match(),
drivers/usb/typec/mux.c). Without that check, any graph neighbour that
is not a mux would make fwnode_typec_mux_get() return -EPROBE_DEFER
forever.
Apple and Rockchip handle this in the PHY driver, because there the PHY
driver can reach the controller-side USB3 control (the Apple PIPE
handler, the Rockchip USB GRF). On Qualcomm the clock
select is in the dwc3 glue (QSCRATCH), so the alternative would be a new
interface for the QMP PHY to notify the controller. I found no existing
one. It would have one advantage: the PHY knows when it actually
switches. I can try that if you prefer it.
> > + mode-switch: true
>
> Drop, but you might explicitly disallow orientation and retimer, if
> entire solution stays after review.
OK. v3 will keep the usb-switch.yaml reference, drop this line and set
orientation-switch and retimer-switch to false.
Thanks,
Joonhoe Kim
next prev parent reply other threads:[~2026-11-07 2:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 13:50 [PATCH v2 0/3] usb: dwc3: qcom: Keep USB 2.0 working in DisplayPort-only modes Joonhoe Kim
2026-11-03 13:50 ` [PATCH v2 1/3] dt-bindings: usb: qcom,snps-dwc3: Add mode-switch Joonhoe Kim
2026-11-03 14:10 ` sashiko-bot
2026-11-04 13:13 ` Krzysztof Kozlowski
2026-11-07 2:12 ` Joonhoe Kim [this message]
2026-11-03 13:50 ` [PATCH v2 2/3] usb: dwc3: qcom: Use the UTMI clock as PIPE clock in DisplayPort-only modes Joonhoe Kim
2026-11-03 14:35 ` sashiko-bot
2026-11-03 13:50 ` [PATCH v2 3/3] arm64: dts: qcom: kaanapali: Mark the USB controller as a Type-C mode switch Joonhoe Kim
2026-11-03 15:05 ` sashiko-bot
2026-11-04 8:12 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261107021208.934-1-26rote@gmail.com \
--to=26rote@gmail.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=abel.vesa@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=balaji.kalkonda@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krishna.kurapati@oss.qualcomm.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=tvlad744@gmail.com \
--cc=val@packett.cool \
--cc=wesley.cheng@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.