From: Peter Chen <peter.chen@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Lyude Paul" <lyude@redhat.com>,
"Alexander Lobakin" <aleksander.lobakin@intel.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Mark Brown" <broonie@kernel.org>,
"Maíra Canal" <mairacanal@riseup.net>,
"Robin Murphy" <robin.murphy@arm.com>,
"Simona Vetter" <simona.vetter@ffwll.ch>,
"Zijun Hu" <quic_zijuhu@quicinc.com>,
linux-usb@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 3/5] USB: phy: convert usb_phy_generic logic to use a faux device
Date: Thu, 6 Feb 2025 09:54:52 +0800 [thread overview]
Message-ID: <20250206015452.GA20613@nchen-desktop> (raw)
In-Reply-To: <2025020509-imperial-maroon-1bc9@gregkh>
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
next prev parent reply other threads:[~2025-02-06 1:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 11:09 [PATCH v2 0/5] Driver core: Add faux bus devices Greg Kroah-Hartman
2025-02-04 11:09 ` [PATCH v2 1/5] driver core: add a faux bus for use when a simple device/bus is needed Greg Kroah-Hartman
2025-02-04 11:44 ` Danilo Krummrich
2025-02-04 11:52 ` Greg Kroah-Hartman
2025-02-04 12:04 ` Danilo Krummrich
2025-02-04 12:55 ` Greg Kroah-Hartman
2025-02-04 13:57 ` Danilo Krummrich
2025-02-04 12:46 ` Jonathan Cameron
2025-02-04 15:31 ` Alan Stern
2025-02-06 7:44 ` Greg Kroah-Hartman
2025-02-04 16:46 ` Rob Herring
2025-02-04 16:51 ` Rob Herring
2025-02-06 7:43 ` Greg Kroah-Hartman
2025-02-04 22:18 ` Lyude Paul
2025-02-06 10:50 ` Greg Kroah-Hartman
2025-02-04 22:51 ` Lyude Paul
2025-02-05 5:51 ` Greg Kroah-Hartman
2025-02-04 23:10 ` Lyude Paul
2025-02-05 5:53 ` Greg Kroah-Hartman
2025-02-05 7:57 ` Andy Shevchenko
2025-02-05 8:58 ` Greg Kroah-Hartman
2025-02-06 15:34 ` Zijun Hu
2025-02-06 16:19 ` Greg Kroah-Hartman
2025-02-04 11:09 ` [PATCH v2 2/5] regulator: dummy: convert to use the faux bus Greg Kroah-Hartman
2025-02-04 12:35 ` Mark Brown
2025-02-04 12:47 ` Jonathan Cameron
2025-02-04 11:09 ` [PATCH v2 3/5] USB: phy: convert usb_phy_generic logic to use a faux device Greg Kroah-Hartman
2025-02-05 10:19 ` Peter Chen
2025-02-05 12:27 ` Greg Kroah-Hartman
2025-02-05 13:41 ` Greg Kroah-Hartman
2025-02-06 1:54 ` Peter Chen [this message]
2025-02-06 5:46 ` Greg Kroah-Hartman
2025-02-04 11:09 ` [PATCH v2 4/5] x86/microcode: move away from using a fake platform device Greg Kroah-Hartman
2025-02-04 11:09 ` [PATCH v2 5/5] wifi: cfg80211: " Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250206015452.GA20613@nchen-desktop \
--to=peter.chen@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=aleksander.lobakin@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=dakr@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=lyude@redhat.com \
--cc=mairacanal@riseup.net \
--cc=quic_zijuhu@quicinc.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona.vetter@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).