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;
Message-ID: <fdfe4b3c-1e7c-b9d5-6173-ce2c0e8dd52b@i2se.com>
Date:   Mon, 2 Jan 2023 12:44:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: [PATCH v2 1/2] usb: misc: onboard_usb_hub: Don't create platform
 devices for DT nodes without 'vdd-supply'
To:     Alexander Stein <alexander.stein@ew.tq-group.com>,
        Doug Anderson <dianders@chromium.org>,
        Matthias Kaehlcke <mka@chromium.org>,
        Icenowy Zheng <uwu@icenowy.me>
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>
References: <20221222022605.v2.1.If5e7ec83b1782e4dffa6ea759416a27326c8231d@changeid>
 <CAD=FV=XNxZ3iDYAAqKWqDVLihJ63Du4L7kDdKO55avR9nghc5A@mail.gmail.com>
 <aa9fdfc04c3b6a3bba688bac244a157242faab82.camel@icenowy.me>
 <3724284.kQq0lBPeGt@steina-w>
Content-Language: en-US
From:   Stefan Wahren <stefan.wahren@i2se.com>
In-Reply-To: <3724284.kQq0lBPeGt@steina-w>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
UI-OutboundReport: notjunk:1;M01:P0:tYGoUjyvkw0=;f2l2XlgSgtAduqMOWaKN9HvdtXM
 AhQt8sS4YPTFpa5YCkp//cMSKWHQb11Xw073mmPeOTwDsElXMVssdoWeyXq9GG64GMEn7Eyyt
 St13qc/kWToWP4sHpOpaA0m/pb3emfkbv6pVfze/acHmPxYsmBDiLDl/jcyXZHhSOjYNpq2Tk
 Qdj1QtQas4gYML9TtGp3OmT4VKpDBs/cklrRAHW5ekpXUER6GUniB0iNZ2zjEOw4mk/KyE4P0
 M+UIwvSuuqjo4JBz+CVgYlCa2w+B7dZtIKtYkZOS5Ah8V+snoJMVVLuXNEuX6QNe2BaQjSpwj
 vVfybHq/YP2kc2OWj28r8kmsN8hKF1RaLIvC76ZUNijt2HEVO5h0GWo1gJZxY07jcyLZo+8Hh
 wtqyW2tGNBSTRA2t6teLhOvSIgjGMwCBt7xZASWPQJw48+/MJxElyNG9lvXkwHEb9iUWNYXf5
 IRbaEX+zP9N/+TqDCwIj9jpBIYcvZcSHbVkDsw7C0aR3Mvnc++1A4Ur+JJzdfGV96tziWuW3P
 rJoSj+V45HkbhYLpi29VzGj23Vyn5HSJfAWaLg8Trdjzp6GostEzARnv/Ar1Wx+M7M9iDAeIl
 pqR19xEH5/XXJyzk/ReUiOLs0Sv5Tbb08otxF3L0nVKbldtoIoIs4jMtHhkuz7CmsxDqcEOlv
 toeJsTOowifGGZCXj2eWbF0FYG787OVv6QIEBn8EiA==
Precedence: bulk

Hello Alexander,

Am 02.01.23 um 10:20 schrieb Alexander Stein:
> Hi everybody,
>
> Am Freitag, 23. Dezember 2022, 08:46:45 CET schrieb Icenowy Zheng:
>> 在 2022-12-22星期四的 11:26 -0800，Doug Anderson写道：
>>
>>> Hi,
>>>
>>> On Wed, Dec 21, 2022 at 6:26 PM Matthias Kaehlcke <mka@chromium.org>
>>>
>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - don't create platform devices when "vdd-supply" is missing,
>>>>    rather than returning an error from _find_onboard_hub()
>>>> - check for "vdd-supply" not "vdd" (Johan)
>>>> - updated subject and commit message
>>>> - added 'Link' tag (regzbot)
>>>>
>>>>   drivers/usb/misc/onboard_usb_hub_pdevs.c | 13 +++++++++++++
>>>>   1 file changed, 13 insertions(+)
>>> I'm a tad bit skeptical.
>>>
>>> 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.
>>>
>>> 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?
>> 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.
> I second that. The bindings don't require neither vdd-supply nor reset-gpios.
>
> But I have to admit I lack to understand the purpose of this series in the
> first place. What is the benefit or fix?

did you followed the provided link from the patch?

Best regards

>
> Best regards,
> Alexader
>
>> In addition the kernel never fails because of a lacking regulator
>> unless explicitly forbid dummy regulators.
>>
>> 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.
>>
>>> 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?
>> I agree.
>
>
>