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

[Thinh Nguyen]

On Tue, Mar 04, 2025, Thinh Nguyen wrote:
> 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@xxxxxxxxxxxxxxxx>
> > ---
> >  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).

Ignore the comment above, I missed the "temporarily" in your log
above. However, the comment below still stands.

> 
> 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