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