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

[Bjorn Andersson]

On Tue, Mar 04, 2025 at 12:39:12AM +0000, Thinh Nguyen wrote:
> 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).

There are no products shipping today using dwc3-qcom where Devicetree is
considered firmware. The primary audience for a longer transition is
users of the various laptops with Qualcomm-chip in them. But given the
rapid development in a variety of functional areas, these users will be
highly compelled to update their DTBs within 2 years.

The other obvious user group is to make sure us upstream developers
don't loose USB when things get out of sync.


That said, if the model defined here is to be followed in other cases
(or my other vendors) where Devicetree is treated as firmware, your
concerns are valid - and it might be worth taking the cost of managing
the live-migration code.

> > If possible, I'd
> > prefer the complications of maintenance of the migration code be handled
> > downstream.
> > 

I'm sorry, but here it sounds like you're saying that you don't want any
migration code upstream at all? This is not possible, as this will break
USB for developers and users short term. We can of course discuss the 2
LTS though, if you want a shorter life span for this migration.


In my view, setting a flag date when the dwc3-qcom-legacy.c will be
removed will provide upstream users a transition period, at a very low
additional cost (934 lines of already tested code). If someone
downstream after that flag date wants to retain support for qcom,dwc3
they can just revert the removal of dwc3-qcom-legacy.c.

The alternative is that I try to get the migration code suggested in v3
to a state where it can be merged (right now it's 6x larger) and then
keep investing indefinitely in making sure it's not bit-rotting
(although Rob Herring did request a flag date of the migration code in
v3 as well...).

Regards,
Bjorn