Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Alexander Stein <alexander.stein@ew.tq-group.com>
To:     Doug Anderson <dianders@chromium.org>,
        Matthias Kaehlcke <mka@chromium.org>,
        Icenowy Zheng <uwu@icenowy.me>,
        Stefan Wahren <stefan.wahren@i2se.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
        stable@vger.kernel.org,
        Ravi Chandra Sadineni <ravisadineni@chromium.org>
Subject: Re: [PATCH v2 1/2] usb: misc: onboard_usb_hub: Don't create platform devices for DT nodes without 'vdd-supply'
Date:   Mon, 02 Jan 2023 15:38:19 +0100
Message-ID: <1783674.3VsfAaAtOV@steina-w>
Organization: TQ-Systems GmbH
In-Reply-To: <fdfe4b3c-1e7c-b9d5-6173-ce2c0e8dd52b@i2se.com>
References: <20221222022605.v2.1.If5e7ec83b1782e4dffa6ea759416a27326c8231d@changeid> <3724284.kQq0lBPeGt@steina-w> <fdfe4b3c-1e7c-b9d5-6173-ce2c0e8dd52b@i2se.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Stefan,

Am Montag, 2. Januar 2023, 12:44:33 CET schrieb Stefan Wahren:
> Hello Alexander,
>=20
> Am 02.01.23 um 10:20 schrieb Alexander Stein:
> > Hi everybody,
> >=20
> > Am Freitag, 23. Dezember 2022, 08:46:45 CET schrieb Icenowy Zheng:
> >> =E5=9C=A8 2022-12-22=E6=98=9F=E6=9C=9F=E5=9B=9B=E7=9A=84 11:26 -0800=
=EF=BC=8CDoug Anderson=E5=86=99=E9=81=93=EF=BC=9A
> >>=20
> >>> Hi,
> >>>=20
> >>> On Wed, Dec 21, 2022 at 6:26 PM Matthias Kaehlcke <mka@chromium.org>
> >>>=20
> >>> wrote:
> >>>> The primary task of the onboard_usb_hub driver is to control the
> >>>> power of an onboard USB hub. The driver gets the regulator from the
> >>>> device tree property "vdd-supply" of the hub's DT node. Some boards
> >>>> have device tree nodes for USB hubs supported by this driver, but
> >>>> don't specify a "vdd-supply". This is not an error per se, it just
> >>>> means that the onboard hub driver can't be used for these hubs, so
> >>>> don't create platform devices for such nodes.
> >>>>=20
> >>>> This change doesn't completely fix the reported regression. It
> >>>> should fix it for the RPi 3 B Plus and boards with similar hub
> >>>> configurations (compatible DT nodes without "vdd-supply"), boards
> >>>> that actually use the onboard hub driver could still be impacted
> >>>> by the race conditions discussed in that thread. Not creating the
> >>>> platform devices for nodes without "vdd-supply" is the right
> >>>> thing to do, independently from the race condition, which will
> >>>> be fixed in future patch.
> >>>>=20
> >>>> Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver")
> >>>> Link:
> >>>> https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.=
com
> >>>> /
> >>>> Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >>>> ---
> >>>>=20
> >>>> Changes in v2:
> >>>> - don't create platform devices when "vdd-supply" is missing,
> >>>>=20
> >>>>    rather than returning an error from _find_onboard_hub()
> >>>>=20
> >>>> - check for "vdd-supply" not "vdd" (Johan)
> >>>> - updated subject and commit message
> >>>> - added 'Link' tag (regzbot)
> >>>>=20
> >>>>   drivers/usb/misc/onboard_usb_hub_pdevs.c | 13 +++++++++++++
> >>>>   1 file changed, 13 insertions(+)
> >>>=20
> >>> I'm a tad bit skeptical.
> >>>=20
> >>> It somehow feels a bit too much like "inside knowledge" to add this
> >>> here. I guess the "onboard_usb_hub_pdevs.c" is already pretty
> >>> entangled with "onboard_usb_hub.c", but I'd rather the "pdevs" file
> >>> keep the absolute minimum amount of stuff in it and all of the
> >>> details
> >>> be in the other file.
> >>>=20
> >>> If this was the only issue though, I'd be tempted to let it slide. As
> >>> it is, I'm kinda worried that your patch will break Alexander Stein,
> >>> who should have been CCed (I've CCed him now) or Icenowy Zheng (also
> >>> CCed now). I believe those folks are using the USB hub driver
> >>> primarily to drive a reset GPIO. Looking at the example in the
> >>> bindings for one of them (genesys,gl850g.yaml), I even see that the
> >>> reset-gpio is specified but not a vdd-supply. I think you'll break
> >>> that?
> >>=20
> >> Well technically in my final DT a regulator is included (to have the
> >> Vbus enabled when enabling the hub), however I am still against this
> >> patch, because the driver should work w/o vdd-supply (or w/o reset-
> >> gpios), and changing this behavior is a DT binding stability breakage.
> >=20
> > I second that. The bindings don't require neither vdd-supply nor
> > reset-gpios.
> >=20
> > But I have to admit I lack to understand the purpose of this series in =
the
> > first place. What is the benefit or fix?
>=20
> did you followed the provided link from the patch?

Ah, I didn't notice that. Thanks. Admittedly I've yet to fully understand t=
hat=20
race condition, but Matthias already suspects this series might not be enou=
gh,=20
even for boards which do use vdd-supply.

Just for the record, this series breaks my board if, as suspected by Doug=20
Anderson and Icenowy Zheng, there is no vdd-supply. The reset line will nev=
er=20
be touched.

Best regards,
Alexander

> Best regards
>=20
> > Best regards,
> > Alexader
> >=20
> >> In addition the kernel never fails because of a lacking regulator
> >> unless explicitly forbid dummy regulators.
> >>=20
> >> BTW USB is a discoverable bus, and if a hub do not need special
> >> handlement, it just does not need to appear in the DT, thus no onboard
> >> hub DT node.
> >>=20
> >>> In general, it feels like it should actually be fine to create the
> >>> USB
> >>> hub driver even if vdd isn't supplied. Sure, it won't do a lot, but
> >>> it
> >>> shouldn't actively hurt anything. You'll just be turning off and on
> >>> bogus regulators and burning a few CPU cycles. I guess the problem is
> >>> some race condition that you talk about in the commit message. I'd
> >>> rather see that fixed... That being said, if we want to be more
> >>> efficient and not burn CPU cycles and memory in Stefan Wahren's case,
> >>> maybe the USB hub driver itself could return a canonical error value
> >>> from its probe when it detects that it has no useful job and then
> >>> "onboard_usb_hub_pdevs" could just silently bail out?
> >>=20
> >> I agree.