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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

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")

in the usb tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Vinod Koul]

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!

> 
> in the usb tree.
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
~Vinod

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

[Greg KH]

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

I can revert them from the USB tree, but what harm are they causing now
as duplicates?

thanks,

greg k-h

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2923 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Theodore Ts'o]

On Thu, Jan 19, 2023 at 02:45:44PM +0100, Thierry Reding wrote:
> 
> 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.

Yeah, that's a problem I've seen work both ways.  For example, there
was the "Convert del_timer*() to timer_shutdown*()" series, which was
sent out both as a treewide patch as well as piecewise for each
subsystem.  The patches haven't been applied yet, and it's been on my
todo list to figure out (a) whether I should wait and for it to go in
via some other tree, and (b) whether it's safe to apply it standalone
for ext4, and that's what the patch author was intending.

Personally, I'm happy to do it both ways, especially for fairly
trivial treewide changes.  If it's complex enough that it's going to
cause merge conflict headaches, that would be different, but very
often, it's just 1 or 2 line changes in a very large number of
subsystems.

Cheers,

						- Ted

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

[Greg KH]

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