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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250304003913.bsn5sucnofq6d6jo@synopsys.com>
Date: Tue, 4 Mar 2025 00:39:12 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Bjorn Andersson <bjorn.andersson@....qualcomm.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>, Felipe Balbi <balbi@...nel.org>,
        Wesley Cheng
	<quic_wcheng@...cinc.com>,
        Saravana Kannan <saravanak@...gle.com>,
        Philipp
 Zabel <p.zabel@...gutronix.de>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Frank Li <Frank.li@....com>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 5/7] usb: dwc3: qcom: Snapshot driver for backwards
 compatibilty

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

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