[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=UzhOrXgB4LrHO4kaSrfw1GQJMb0RNsQXYfG5kG8EwcRA@mail.gmail.com>
Date: Wed, 27 Apr 2022 14:05:04 -0700
From: Doug Anderson <dianders@...omium.org>
To: Matthias Kaehlcke <mka@...omium.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH v22 1/2] arm64: dts: qcom: sc7180-trogdor: Add nodes for
onboard USB hub
Hi,
On Tue, Apr 26, 2022 at 5:03 PM Matthias Kaehlcke <mka@...omium.org> wrote:
>
> Add nodes for the onboard USB hub on trogdor devices. Remove the
> 'always-on' property from the hub regulator, since the regulator
> is now managed by the onboard_usb_hub driver.
There are people out there that are running trogdor devices with
upstream Linux. There's not much we can do about it, but probably this
patch will cause them to fail to probe USB because they won't have
"CONFIG_USB_ONBOARD_HUB=y". Luckily the commit subject has "USB" in it
so hopefully it'll be easy to spot, but I wonder if we should add
something to the commit message that makes that super obvious and
tells them about the relevant commit, like:
For anyone using trogdor-based devices on Linux, it should be noted
that this requires "CONFIG_USB_ONBOARD_HUB=y".
> Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
> Reviewed-by: Stephen Boyd <swboyd@...omium.org>
> Reviewed-by: Douglas Anderson <dianders@...omium.org>
> ---
> Depends on "usb: misc: Add onboard_usb_hub driver" [1] which landed in
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing
>
> This patch was split off the above series.
>
> [1] https://patchwork.kernel.org/project/linux-usb/list/?series=615531&state=%2A&archive=both
I presume it will be moderately annoying if this lands in the Qualcomm
branch before the driver lands in mainline? Otherwise USB will fully
stop working on the Qualcomm branch. Do we want to postpone landing
this?
-Doug
Powered by blists - more mailing lists