Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <99b0e568-ee2d-bbd0-dfd0-fb0953cd556c@kernel.org>
Date:   Wed, 16 Feb 2022 08:36:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH v20 5/5] arm64: dts: qcom: sc7180-trogdor: Add nodes for
 onboard USB hub
Content-Language: en-US
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Doug Anderson <dianders@chromium.org>
Cc:     Matthias Kaehlcke <mka@chromium.org>,
        Alan Stern <stern@rowland.harvard.edu>,
        Rob Herring <robh+dt@kernel.org>,
        Frank Rowand <frowand.list@gmail.com>,
        Mathias Nyman <mathias.nyman@intel.com>,
        Felipe Balbi <balbi@kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, Stephen Boyd <swboyd@chromium.org>,
        Peter Chen <peter.chen@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Roger Quadros <rogerq@kernel.org>,
        Michal Simek <michal.simek@xilinx.com>,
        Linux USB List <linux-usb@vger.kernel.org>,
        Bastien Nocera <hadess@hadess.net>,
        Ravi Chandra Sadineni <ravisadineni@chromium.org>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>
References: <20220119204345.3769662-1-mka@chromium.org>
 <20220119124327.v20.5.Ie0d2c1214b767bb5551dd4cad38398bd40e4466f@changeid>
 <YgJMkFAxjazkUDZd@kroah.com> <YgLCswtX/0THkzXT@google.com>
 <CAD=FV=WMP8M5HTRNv9_scvrytbpE0iBdUack=XaHoypGNLJeVA@mail.gmail.com>
 <Ygv3FSDS/fq1oePy@kroah.com>
From:   Krzysztof Kozlowski <krzk@kernel.org>
In-Reply-To: <Ygv3FSDS/fq1oePy@kroah.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 15/02/2022 19:55, Greg Kroah-Hartman wrote:
> 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@chromium.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@chromium.org>
>>>>> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
>>>>> Reviewed-by: Douglas Anderson <dianders@chromium.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.

I don't have problems picking individual patches - either b4 am on each
patch or on entire series and dropping later unneeded commits.

> 
> 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.

DTS is a description of the hardware and we take it via separate
branches of SoC-fami0ly repositories. These are always separated from
the driver changes. Always. For several reasons:
1. By convention,
2. To be sure there is no dependency on driver code thus an ABI break,
3. To have a nice and clean history of DTS changes, properly organized.

What is more, if this was coming via my Samsung SoC tree towards SoC
folks, I could not take it in one branch. I would need to physically
split it, otherwise Arnd/Olof would bounce back my pull request saying I
am mixing DTS with driver. Of course you do not have such requirement -
I am just saying that splitting DTS is quite common and proper way.


Best regards,
Krzysztof