linux-kernel - Re: [PATCH v2 3/5] USB: phy: convert usb_phy

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: <20250206015452.GA20613@nchen-desktop>
Date: Thu, 6 Feb 2025 09:54:52 +0800
From: Peter Chen <peter.chen@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, Lyude Paul <lyude@...hat.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Liam Girdwood <lgirdwood@...il.com>, Lukas Wunner <lukas@...ner.de>,
	Mark Brown <broonie@...nel.org>,
	Maíra Canal <mairacanal@...eup.net>,
	Robin Murphy <robin.murphy@....com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Zijun Hu <quic_zijuhu@...cinc.com>, linux-usb@...r.kernel.org,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 3/5] USB: phy: convert usb_phy_generic logic to use a
 faux device

On 25-02-05 14:41:31, Greg Kroah-Hartman wrote:
> On Wed, Feb 05, 2025 at 01:27:30PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 05, 2025 at 06:19:16PM +0800, Peter Chen wrote:
> > > On 25-02-04 12:09:15, Greg Kroah-Hartman wrote:
> > > > The usb_phy_generic code was creating a "fake" platform device to pass
> > > > around in different places.  Instead of doing that, use the faux bus
> > > > instead as that is what is really wanted here.
> > > 
> > > Hi Greg,
> > > 
> > > As far as I know, there are some platforms use the device-tree to get
> > > the system resource (eg, clock, reset, regular) for this driver.
> > > We may not use fake bus for this driver.
> > 
> > But there is no system resources assigned to this device/driver at all,
> > so how is it getting anything here?
> > 
> > > $grep -rn "usb-nop-xceiv" arch/arm64/boot/dts/*
> > > 
> > > arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi:649:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi:275:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi:285:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/freescale/imx93.dtsi:238:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/freescale/imx93.dtsi:245:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/freescale/imx8mn.dtsi:1321:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/intel/socfpga_agilex.dtsi:149:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi:133:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9132-db.dtsi:30:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9132-db.dtsi:44:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9131-db.dtsi:33:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/armada-3720-db.dts:43:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9130-crb.dtsi:49:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9130-crb.dtsi:53:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9130-db.dtsi:52:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/cn9130-db.dtsi:66:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/armada-8040-db.dts:53:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/armada-8040-db.dts:67:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/ac5-98dx35xx-rd.dts:36:		compatible = "usb-nop-xceiv";
> > > arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts:39:		compatible = "usb-nop-xceiv";
> > 
> > Does this actually work at all?

Yes, at least for some NXP i.MX series SoCs, these SoCs use chipidea IP.
At above device tree files, the USB generic PHY device node has enabled,
so the device will be probed and get hardware resources.

During the chipidea core driver->probe, it calls this generic USB phy
driver's phy.init and do some actual hardware operations.

Peter

>> There is no real resouces here that I
> > can see, so what am I missing?
> 
> Hm, maybe I got this one wrong, I'm getting build errors now from
> kbuild, let me go look into this some more...
> 
> greg k-h