On Mon, Mar 03, 2025, Bjorn Andersson wrote: > 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. > My first concern is now we have a legacy driver that should not be continued to be developed while we also need to address any regression/fixes found in the future from the legacy driver. While I would encourage users to start migrating to the new driver, I won't reject fixes to the legacy driver either. In the next 2 years+, my other concern is that I'm not confident that we can easily remove the legacy driver and the DTS then. Code can break, and that's not unexpected. If 2 LTS releases later and we remove the dwc3-qcom-legacy, things can break then too. This may just as be painful if we need fixes to the legacy driver due to some previous regression. Also, I'm sure your team did a fair share of testing the new driver right? Is there some major concern in the new driver that we haven't addressed? > > 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 same can be said that they can revert the update (or apply fixes) should they found issue with the new change. > > 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...). > All that said, if you believe that this transition will be quite disruptive without preserving the legacy driver/dts, then we will do so. Can I request that you make this snapshot as one of the first patches in the series so reverts/git-blames can easily be traced? BR, Thinh Side question: for Snapdragon laptops, without the corresponding kernel and DTS updates, don't things break easily?
