mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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,

      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®