[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ygv3FSDS/fq1oePy@kroah.com>
Date: Tue, 15 Feb 2022 19:55:17 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Matthias Kaehlcke <mka@...omium.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>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Stephen Boyd <swboyd@...omium.org>,
Peter Chen <peter.chen@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Roger Quadros <rogerq@...nel.org>,
Michal Simek <michal.simek@...inx.com>,
Linux USB List <linux-usb@...r.kernel.org>,
Bastien Nocera <hadess@...ess.net>,
Ravi Chandra Sadineni <ravisadineni@...omium.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v20 5/5] arm64: dts: qcom: sc7180-trogdor: Add nodes for
onboard USB hub
On Tue, Feb 15, 2022 at 09:54:54AM -0800, Doug Anderson wrote:
> Hi,
>
> On Tue, Feb 8, 2022 at 11:21 AM Matthias Kaehlcke <mka@...omium.org> wrote:
> >
> > On Tue, Feb 08, 2022 at 11:57:20AM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 19, 2022 at 12:43:45PM -0800, Matthias Kaehlcke 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.
> > > >
> > > > Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
> > > > Reviewed-by: Stephen Boyd <swboyd@...omium.org>
> > > > Reviewed-by: Douglas Anderson <dianders@...omium.org>
> > > > ---
> > >
> > > No DT maintainer approval yet? :(
> >
> > Bjorn usually just picks DT changes into the QCOM tree when they are
> > ready, so I wouldn't interpret anything into the lack of an explicit
> > Ack.
>
> Right, so the expectation is that this patch wouldn't land through the
> USB tree but would instead land through the Qualcomm tree, probably a
> revision after the code lands in the USB tree to avoid dependency
> problems.
But our tools pick up the whole series. I can't just do "i will pick
patches 1-4 only" easily, and neither can any other maintainer.
Why not just get their ack so that I know it can come through the USB
tree? That's what normally happens for other changes like this where a
driver change is required first.
thanks,
greg k-h
Powered by blists - more mailing lists