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: <166449bc-4c33-b923-f53d-6df4f83dc267@kernel.org>
Date:   Fri, 13 Aug 2021 09:35:53 +0300
From:   Roger Quadros <rogerq@...nel.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Felipe Balbi <balbi@...nel.org>,
        Bastien Nocera <hadess@...ess.net>,
        Peter Chen <peter.chen@...nel.org>, devicetree@...r.kernel.org,
        Michal Simek <michal.simek@...inx.com>,
        linux-kernel@...r.kernel.org,
        Douglas Anderson <dianders@...omium.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        linux-usb@...r.kernel.org,
        Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Al Cooper <alcooperx@...il.com>,
        Andrey Zhizhikin <andrey.zhizhikin@...ca-geosystems.com>,
        Andy Gross <agross@...nel.org>,
        Aswath Govindraju <a-govindraju@...com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Fabio Estevam <festevam@...il.com>,
        Guido Günther <agx@...xcpu.org>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Nishanth Menon <nm@...com>,
        Pawel Laszczak <pawell@...ence.com>,
        Shawn Guo <shawnguo@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Will Deacon <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v15 0/6] usb: misc: Add onboard_usb_hub driver

Hi Matthias,

On 12/08/2021 20:08, Matthias Kaehlcke wrote:
> Hi Roger,
> 
> On Wed, Aug 11, 2021 at 03:56:15PM +0300, Roger Quadros wrote:
>>
>>
>> On 11/08/2021 15:38, Roger Quadros wrote:
>>> Hi Matthias,
>>>
>>> On 09/08/2021 18:49, Matthias Kaehlcke wrote:
>>>> Hi Greg,
>>>>
>>>> Just wanted to check if this series is still on your radar. Is
>>>> there anything that blocks it from landing (further ACKs, ...)?
>>>>
>>>> Thanks
>>>>
>>>> Matthias
>>>>
>>>> On Mon, Jul 26, 2021 at 05:41:12PM -0700, Matthias Kaehlcke wrote:
>>>>> This series adds:
>>>>> - the onboard_usb_hub_driver
>>>>> - glue in the xhci-plat driver to create and destroy the
>>>>>   onboard_usb_hub platform devices if needed
>>>>> - a device tree binding for the Realtek RTS5411 USB hub controller
>>>>> - device tree changes that add RTS5411 entries for the QCA SC7180
>>>>>   based boards trogdor and lazor
>>>>> - a couple of stubs for platform device functions to avoid
>>>>>   unresolved symbols with certain kernel configs
>>>>>
>>>>> The main issue the driver addresses is that a USB hub needs to be
>>>>> powered before it can be discovered. For discrete onboard hubs (an
>>>>> example for such a hub is the Realtek RTS5411) this is often solved
>>>>> by supplying the hub with an 'always-on' regulator, which is kind
>>>>> of a hack. Some onboard hubs may require further initialization
>>>>> steps, like changing the state of a GPIO or enabling a clock, which
>>>>> requires even more hacks. This driver creates a platform device
>>>>> representing the hub which performs the necessary initialization.
>>>>> Currently it only supports switching on a single regulator, support
>>>>> for multiple regulators or other actions can be added as needed.
>>>>> Different initialization sequences can be supported based on the
>>>>> compatible string.
>>>>>
>>>>> Besides performing the initialization the driver can be configured
>>>>> to power the hub off during system suspend. This can help to extend
>>>>> battery life on battery powered devices which have no requirements
>>>>> to keep the hub powered during suspend. The driver can also be
>>>>> configured to leave the hub powered when a wakeup capable USB device
>>>>> is connected when suspending, and power it off otherwise.
>>>>>
>>>>> Changes in v15:
>>>>> - adjusted dependencies of USB_DWC3_CORE to make sure it can only
>>>>>   be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
>>>>>   or USB_DWC3_DUAL_ROLE is selectable
>>>>>
>>>>> Changes in v14:
>>>>> - rebased on top of v5.14-rc1
>>>>> - dropped DT binding patch which landed in v5.13
>>>>>
>>>>> Changes in v13:
>>>>> - added patch "usb: Specify dependency on USB_XHCI_PLATFORM with
>>>>>   'depends on'" to the series to avoid Kconfig conflicts
>>>>> - added patch "arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM"
>>>>>   to the series to keep effective defconfig unchanged
>>>>>
>>>>> Changes in v12:
>>>>> - onboard_hub driver: use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE)
>>>>>   in onboard_hub.h to also check for the driver built as module
>>>>> - onboard_hub_driver: include onboard_hub.h again to make sure there
>>>>>   are prototype declarations for the public functions
>>>>>
>>>>> Changes in v11:
>>>>> - support multiple onboard hubs connected to the same parent
>>>>> - don't include ‘onboard_hub.h’ from the onboard hub driver
>>>>>
>>>>> Changes in v10:
>>>>> - always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
>>>>> - keep 'regulator-boot-on' property for pp3300_hub
>>>>>
>>>>> Changes in v9:
>>>>> - added dependency on ONBOARD_USB_HUB (or !!ONBOARD_USB_HUB) to
>>>>>   USB_PLATFORM_XHCI
>>>>>
>>>>> Changes in v7:
>>>>> - updated DT binding
>>>>> - series rebased on qcom/arm64-for-5.13
>>>>>
>>>>> Changes in v6:
>>>>> - updated summary
>>>>>
>>>>> Changes in v5:
>>>>> - cover letter added
>>>>>
>>>>> Matthias Kaehlcke (6):
>>>>>   usb: misc: Add onboard_usb_hub driver
>>>>>   of/platform: Add stubs for of_platform_device_create/destroy()
>>>>>   arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
>>>>>   usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
>>>>>   usb: host: xhci-plat: Create platform device for onboard hubs in
>>>>>     probe()
>>>>>   arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
>>>>>
>>>>>  .../sysfs-bus-platform-onboard-usb-hub        |   8 +
>>>>>  MAINTAINERS                                   |   7 +
>>>>>  .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts |  19 +-
>>>>>  .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts |  12 +-
>>>>>  .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts |  19 +-
>>>>>  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |  19 +-
>>>>>  arch/arm64/configs/defconfig                  |   1 +
>>>>>  drivers/usb/cdns3/Kconfig                     |   2 +-
>>>>>  drivers/usb/dwc3/Kconfig                      |   5 +-
>>>>>  drivers/usb/host/Kconfig                      |   5 +-
>>>
>>> These Kconfig changes are causing the resulting .config to be different.
>>> For example, if I start with omap2plus_defconfig, the resulting .config
>>> before and after your series is different as shown below
>>>
>>> :/work/linux$ diff /tmp/.config .config
>>> 1902d1901
>>> < # CONFIG_HISI_HIKEY_USB is not set
>>> 4992c4991
>>> < CONFIG_USB_XHCI_PLATFORM=m
>>> ---
>>>> # CONFIG_USB_XHCI_PLATFORM is not set
>>> 5073,5075c5072
>>> < # CONFIG_USB_DWC3_HOST is not set
>>> < # CONFIG_USB_DWC3_GADGET is not set
>>> < CONFIG_USB_DWC3_DUAL_ROLE=y
>>> ---
>>>> CONFIG_USB_DWC3_GADGET=y
>>> 5173a5171
>>>> # CONFIG_USB_ONBOARD_HUB is not set
>>> 5285c5283
>>> < CONFIG_USB_ROLE_SWITCH=m
>>> ---
>>>> # CONFIG_USB_ROLE_SWITCH is not set
>>>
>>> I would expect the same issues for multi_v7_defconfig and multi_v8_defconfig as well.
>>
>> Sorry I meant defconfig for arm64, not multi_v8_defconfig.
>>
>> I checked that for arm64 defconfig it is ok.
>>
>>> I'm ok to update the relevant defconfigs files so that the resulting .config is identical to
>>> before your series. Thanks!
>>
>> With the below patch you can fix it for omap2plus_defconfig and multi_v7_defconfig.
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index d9abaae118dd..8c175ab37377 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -787,6 +787,7 @@ CONFIG_SND_AUDIO_GRAPH_CARD=m
>>  CONFIG_USB=y
>>  CONFIG_USB_OTG=y
>>  CONFIG_USB_XHCI_HCD=y
>> +CONFIG_USB_XHCI_PLATFORM=y
>>  CONFIG_USB_XHCI_MVEBU=y
>>  CONFIG_USB_XHCI_TEGRA=m
>>  CONFIG_USB_EHCI_HCD=y
>> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
>> index 2ac2418084ab..a015fb04fa25 100644
>> --- a/arch/arm/configs/omap2plus_defconfig
>> +++ b/arch/arm/configs/omap2plus_defconfig
>> @@ -562,6 +562,7 @@ CONFIG_USB=m
>>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>>  CONFIG_USB_MON=m
>>  CONFIG_USB_XHCI_HCD=m
>> +CONFIG_USB_XHCI_PLATFORM=m
>>  CONFIG_USB_EHCI_HCD=m
>>  CONFIG_USB_OHCI_HCD=m
>>  CONFIG_USB_ACM=m
> 
> Thanks for testing!
> 
> I completely forgot that arm32 has all these different defconfigs.
> 
> While trying to adjust qcom_defconfig I came across something that confuses
> me. The original defconfig results in:
> 
> # CONFIG_USB_XHCI_HCD is not set
> CONFIG_USB_DWC3_DUAL_ROLE=y

The original Kconfig was:

> config USB_DWC3_DUAL_ROLE
>         bool "Dual Role mode"
>         depends on ((USB=y || USB=USB_DWC3) && (USB_GADGET=y || USB_GADGET=USB_DWC3))
>         depends on (EXTCON=y || EXTCON=USB_DWC3)

Which means USB_DWC3_DUAL_ROLE can be enabled even without CONFIG_USB_XHCI_HCD.

All the dual role code does is add/remove the host/gadget controller platform devices.
It doesn't care whether there is a driver for it or not.
i.e. there is no build dependency on CONFIG_USB_XHCI_HCD.

> 
> My assumption was that xHCI support is need for dwc3 dual mode (which is
> made explicit by https://lore.kernel.org/patchwork/patch/1468240/), is
> that incorrect? Maybe without xHCI support the controller can still
> operate in USB 2.0 dual role mode?
> 

Without xHCI support the host functionality will not work at all on dwc3 dual role.
So I think your Kconfig changes for USB_DWC3_DUAL_ROLE to depend on USB_XHCI_PLATFORM
are correct.

cheers,
-roger

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ