Message-ID: <Y8lJiJHHcUO7MXQY@orome>
Date:   Thu, 19 Jan 2023 14:45:44 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Greg KH <greg@...ah.com>
Cc:     Vinod Koul <vkoul@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Kishon Vijay Abraham I <kishon@...com>,
        Jon Hunter <jonathanh@...dia.com>,
        Sing-Han Chen <singhanc@...dia.com>,
        Wayne Chang <waynec@...dia.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: duplicate patches in the phy-next tree

On Thu, Jan 19, 2023 at 07:54:15AM +0100, Greg KH wrote:
> On Thu, Jan 19, 2023 at 11:42:43AM +0530, Vinod Koul wrote:
> > On 19-01-23, 15:31, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > The following commits are also in the usb tree as different commits
> > > (but the same patches):
> > > 
> > >   5c7f94f8bad8 ("phy: tegra: xusb: Add Tegra234 support")
> > >   e5f9124404d0 ("phy: tegra: xusb: Disable trk clk when not in use")
> > > 
> > > they are commits
> > > 
> > >   d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support")
> > >   71d9e899584e ("phy: tegra: xusb: Disable trk clk when not in use")
> > 
> > Ah, ideally these should go thru phy tree!
> 
> Yeah, but they were submitted as a larger set of patches with USB
> changes to me, so I took the whole series (it's hard to pick and choose
> from a series).

This has been a recurring theme, so I'm trying to get a better
understanding of what people expect here. Some maintainers want to see
a whole series for a single feature (in this case it was Tegra234 USB
support) even if it crosses multiple subsystems/trees. This has the
advantage that patches can be arranged such that all dependencies are
resolved. Other maintainers like things to be split up so that patches
are easier to pick up.

Submitters can spell out in the cover letter how they think things
should be picked up, but they're not always aware of what else is going
on in the respective trees, so they may get it wrong.

I personally prefer to pick up DT bindings into the platform tree since
we're getting into a place where device trees can be properly validated
and keeping bindings and DTS files in the same tree helps with that.

But I know that DT maintainers prefer bindings to go through subsystem
trees because it can help reduce conflicts and that outweighs the DT
validation benefits, which some platforms may still be far away from
being able to use.

DTS changes on the other hand are a different thing. In my opinion it is
much better for them to be applied through platform trees because of the
greater potential for conflicts. In any given cycle there are often
multiple patches touching the same DTS files and currently a lot of
clean up is going on for validation.

So I wonder if we should just move away from the current process of how
we submit series. Maybe a less confusing way would be to strictly
separate driver and DTS changes into two series. That way maintainers
would better understand what patches to pick. It also has its own set of
disadvantages (can't validate DTS changes against DT bindings, and it
may not even be clear where certain DTS changes are documented).

The only other alternative I can think of would be for maintainers to
default to picking up driver (and perhaps DT binding) changes from
bigger series.

Is it worth codifying this in our process documentation?

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists