Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Peter Chen <peter.chen@nxp.com>
To:     Matthias Kaehlcke <mka@chromium.org>
CC:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ravi Chandra Sadineni <ravisadineni@chromium.org>,
        Douglas Anderson <dianders@chromium.org>,
        Bastien Nocera <hadess@hadess.net>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        Stephen Boyd <swboyd@chromium.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        Alan Stern <stern@rowland.harvard.edu>,
        "Alexander A. Klimov" <grandmaster@al2klimov.de>,
        Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [RFC PATCH] USB: misc: Add usb_hub_pwr driver
Thread-Topic: [RFC PATCH] USB: misc: Add usb_hub_pwr driver
Thread-Index: AQHWgJ2O9T1DMOMaDk2K+eB9hhc5F6lU0zIAgADNTACAAIY4gA==
Date:   Thu, 3 Sep 2020 01:46:18 +0000
Message-ID: <20200903014559.GB11250@b29397-desktop>
References: <20200901132005.RFC.1.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid>
 <20200902053048.GB6837@b29397-desktop> <20200902174536.GE3419728@google.com>
In-Reply-To: <20200902174536.GE3419728@google.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C8652DA30BD7DF40B8C997707D9C17A4@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 58b94e27-fded-4492-a915-08d84fab26fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2020 01:46:18.3902
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: A8R0nw0cqqrHnUijXtVPnQPfZk7oGr7Y9UUtlOdQEnsP7OPGs5K7Fbvz4jAXH2jYpxKZAjukGvAVg31mihKj6A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR04MB6149
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 20-09-02 10:45:36, Matthias Kaehlcke wrote:
> >=20
> > Hi Matthias,
> >=20
> > I did similar several years ago [1], but the concept (power sequence)
> > doesn't be accepted by power maintainer.
>=20
> Yeah, I saw that, I think I even reviewed or tested some early version
> of it :)
>=20
> > Your patch introduce an new way to fix this long-term issue, I have an
> > idea to fix it more generally.
>=20
> > - Create a table (say usb_pm_table) for USB device which needs to do
> > initial power on and power management during suspend suspend/resume bas=
ed
> > on VID and PID, example: usb/core/quirks.c
> > - After hub (both roothub and intermediate hub) device is created, sear=
ch
> > the DT node under this hub, and see if the device is in usb_pm_table. I=
f
> > it is in it, create a platform device, say usb-power-supply, and the
> > related driver is like your usb_hub_psupply.c, the parent of this devic=
e
> > is controller device.
>=20
> This part isn't clear to me. How would the DT look like? Would it have a
> single node per physical hub chip or one node for each 'logical' hub?
> Similarly, would there be a single plaform device or multiple?

One power supply platform device for one physical device, and DT only
describes physical device. HUB driver only probes non-SS HUB port to
avoid create two power supply device for SS HUB, there should be no
SS-only HUB.

Below is the example of DT entry, there is a dwc3 host, and one USB
HUB on it, there is a onboard USB ethernet chip on HUB's port 1.

&usb_1_dwc3 {
	 status =3D "okay";

	 usb2415: hub@1 {
		 compatible =3D "usb424,2514";
		 reg =3D <1>;
		 clocks =3D <&clk, IMX6QDL_CLK_CKO>;
		 reset-gpios =3D <&gpio7 12 GPIO_ACTIVE_LOW>;
		 reset-duration-us =3D <3000>;
		 vdd-supply =3D <&reg_vdd_hub_usb2415>;

		 genesys: ethernet@1 {
			 compatible =3D "usb5e3,608";
			 reg =3D <1>;
			 vdd-supply =3D <&reg_vdd_genesys>;

	};

};

>=20
> I guess when registering the platform device we could pass it the
> corresponding DT node, to allow it to determine its regulators, GPIOs,
> etc during probe.
>=20
> > - After this usb-power-supply device is probed, do initial power on at
> > probe, eg, clock, regulator, reset-gpio.
> > - This usb-power-supply device system suspend operation should be calle=
d after
> > onboard device has suspended since it is created before it. No runtime =
PM ops
> > are needed for it.
> > - When the hub is removed, delete this platform device.
>=20
> What exactly is removal? It seems once the hub is 'removed' it could neve=
r be
> probed again because the platform device that is in charge of the
> initialization is only created when the USB controller is initialized. I =
have
> the impression that the platform device would have to exist as long as th=
e USB
> controller.

This USB power supply device services USB devices on HUB ports (HUB is
also one of USB devices). For USB devices under the roothub, it will be
powered on when the roothub is probed.[1]

[1] https://lore.kernel.org/lkml/1498027328-25078-5-git-send-email-peter.ch=
en@nxp.com/

--=20

Thanks,
Peter Chen=