linux-kernel - Re: linux-next: duplicate patches in the phy-next tree

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] [day] [month] [year] [list]

Message-ID: <Y8qe4hd52B3ltXH8@kroah.com>
Date:   Fri, 20 Jan 2023 15:02:10 +0100
From:   Greg KH <greg@...ah.com>
To:     Thierry Reding <thierry.reding@...il.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 02:45:44PM +0100, Thierry Reding wrote:
> 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).

I don't like splitting them up, so keeping them all together is good.
Make it simple for developers to do, and also simple for maintainers.
If we end up with duplicates at times, what's the harm?

thanks,

greg k-h