Re: [PATCH v4 5/7] usb: dwc3: qcom: Snapshot driver for backwards compatibilty

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Wed, Feb 26, 2025, Bjorn Andersson wrote:
> In order to more tightly integrate the Qualcomm glue driver with the
> dwc3 core the driver is redesigned to avoid splitting the implementation
> using the driver model. But due to the strong coupling to the Devicetree
> binding needs to be updated as well.
> 
> Various ways to provide backwards compatibility with existing Devicetree
> blobs has been explored, but migrating the Devicetree information
> between the old and the new binding is non-trivial.
> 
> For the vast majority of boards out there, the kernel and Devicetree are
> generated and handled together, which in practice means that backwards
> compatibility needs to be managed across about 1 kernel release.
> 
> For some though, such as the various Snapdragon laptops, the Devicetree
> blobs live a life separate of the kernel. In each one of these, with the
> continued extension of new features, it's recommended that users would
> upgrade their Devicetree somewhat frequently.
> 
> With this in mind, simply carrying a snapshot/copy of the current driver
> is simpler than creating and maintaining the migration code.
> 
> The driver is kept under the same Kconfig option, to ensure that Linux
> distributions doesn't drop USB support on these platforms.
> 
> The driver, which is going to be refactored to handle the newly
> introduced qcom,snps-dwc3 compatible, is updated to temporarily not
> match against any compatible.
> 
> This driver should be removed after 2 LTS releases.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
>  drivers/usb/dwc3/Makefile           |   1 +
>  drivers/usb/dwc3/dwc3-qcom-legacy.c | 934 ++++++++++++++++++++++++++++++++++++
>  drivers/usb/dwc3/dwc3-qcom.c        |   1 -
>  3 files changed, 935 insertions(+), 1 deletion(-)
> 

This is a bit concerning if there's no matching compatible string. ie.
we don't have user for the new driver without downstream dependencies
(or some workaround in the driver binding).

While I understand the intention, I'm afraid we may have to support and
maintain this much longer than the proposed 2 LTS releases (as seen with
anything tagged with "legacy" in the upstream kernel). If possible, I'd
prefer the complications of maintenance of the migration code be handled
downstream.

Thanks,
Thinh