From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] usb: dwc3: qcom: Remove extcon functionality from glue
Date: Tue, 22 Jul 2025 12:48:18 +0530 [thread overview]
Message-ID: <a6e26f6d-67ba-47b2-a4d6-6d4c6be1e914@oss.qualcomm.com> (raw)
In-Reply-To: <2025072021-rounding-oversized-5b4b@gregkh>
On 7/20/2025 5:10 PM, Greg Kroah-Hartman wrote:
> On Fri, Jul 18, 2025 at 11:08:56AM +0530, Krishna Kurapati wrote:
>> Deprecate usage of extcon functionality from the glue driver.
>
> It's not "deprecate", it is "delete". "deprecate" means that you don't
> want future users of this, you are flat out deleting it entirely.
>
ACK, will rephrase it to "removing code".
>> Now
>> that the glue driver is a flattened implementation, all existing
>> DTs would eventually move to new bindings.
>
> When is this happening?
>
>> While doing so let them
>> make use of role-switch/ typec frameworks to provide role data
>> rather than using extcon. None of the existing in-kernel extcon users
>> have moved to using new bindings yet, so this change doesn't affect
>> any existing users.
>
> I don't understand, who does this affect?
>
>> On upstream, summary of targets/platforms using extcon is as follows:
>
> What is "upstream" here? In-tree? We only have one development place :)
>
>> 1. MSM8916 and MSM8939 use Chipidea controller, hence the changes have no
>> effect on them.
>>
>> 2. Of the other extcon users, most of them use "linux,extcon-usb-gpio"
>> driver which relies on id/vbus gpios to inform role changes. This can be
>> transitioned to role switch based driver (usb-conn-gpio) while flattening
>> those platforms to move away from extcon and rely on role switching.
>
> "most" do, but not all.
>
>> 3. The one target that uses dwc3 controller and extcon and is not based
>> on reading gpios is "arch/arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi".
>> This platform uses TI's Type-C Port controller chip to provide extcon. If
>> usb on this platform is being flattened, then effort should be put in to
>> define a usb-c-connector device in DT and make use of role switch in
>> TUSB320L driver.
>
> I really still do not understand what is happening here.
>
> Does this break existing in-tree users? If yes, we can't do that. If
> no, they this is just unused code? That's all that we should be
> concerned about here.
>
Thanks for the comments Greg. Basically, all extcon users today use
legacy glue bindings (dwc3-qcom-legacy.c). In the new bindings
(dwc3-qcom.c), we wanted to remove extcon functionality and enforce
usage of usb-role-switch framework instead. So no existing users of
extcon would be affected now. But when the above mentioned platforms
(the ones that use extcon-usb-gpio driver and
msm8996-xiaomi-common.dtsi) are being flattened (by anyone), we want to
enforce usage of role-switch (moving to use usb-conn-gpio driver). Would
it be clear if I incorporated the following in commit text:
1. Extcon users today use legacy bindings, so this change wont affect
any existing in-kernel users since no flattened dT today uses extcon.
2. Extcon code is being removed and usage of role-switch is being
encouraged instead.
3. Effort to be be put in while flattening platforms using extcon based
on gpio to convert them to use ubs-conn-gpio based on role switch.
Let me know your thoughts on this. And thanks for taking the time to
review the patch.
Regards,
Krishna,
prev parent reply other threads:[~2025-07-22 7:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 5:38 Krishna Kurapati
2025-07-18 8:52 ` Konrad Dybcio
2025-07-20 11:40 ` Greg Kroah-Hartman
2025-07-22 7:18 ` Krishna Kurapati [this message]
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=a6e26f6d-67ba-47b2-a4d6-6d4c6be1e914@oss.qualcomm.com \
--to=krishna.kurapati@oss.qualcomm.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®