[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025071518-aware-tipping-4e27@gregkh>
Date: Tue, 15 Jul 2025 19:47:20 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Krishna Kurapati <krishna.kurapati@....qualcomm.com>
Cc: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] usb: dwc3: qcom: Remove extcon functionality from glue
On Mon, Jul 14, 2025 at 10:17:02AM +0530, Krishna Kurapati wrote:
> Deprecate usage of extcon functionality from the glue driver. Now
> that the glue driver is a flattened implementation, all existing
> DTs would eventually move to new bindings. While doing so let them
> make use of role-switch/ typec frameworks to provide role data
> rather than using extcon.
"Deprecate"? Looks like you are just deleting all of this code, what is
going to break when this is removed? Are there any in-kernel users of
it?
> On upstream, summary of targets/platforms using extcon is as follows:
>
> 1. MSM8916 and MSM8939 use Chipidea controller, hence the changes have no
> effect on them.
Ok, so those are fine, but:
> 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.
When is that going to happen? Where are those patches?
> 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 chip to provide extcon. If usb on this platform is
> being flattneed, then effort should be put in to define a usb-c-connector
> device in DT and make use of role switch functionality in TUSB320L driver.
Again, when is that going to be changed? We can't break in-kernel users
:(
thanks,
greg k-h
Powered by blists - more mailing lists