Re: [PATCH v1 0/2] Fix the wrong order of phy callbacks

From: Bjorn Helgaas
Date: Tue Aug 30 2022 - 11:05:44 EST


On Tue, Aug 30, 2022 at 07:50:55AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
> > Sent: 2022年8月30日 15:16
> > To: Hongxing Zhu <hongxing.zhu@xxxxxxx>; l.stach@xxxxxxxxxxxxxx;
> > bhelgaas@xxxxxxxxxx; lorenzo.pieralisi@xxxxxxx; vkoul@xxxxxxxxxx; Marcel
> > Ziswiler <marcel.ziswiler@xxxxxxxxxxx>; kishon@xxxxxx
> > Cc: linux-pci@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; dl-linux-imx
> > <linux-imx@xxxxxxx>; kernel@xxxxxxxxxxxxxx; linux-phy@xxxxxxxxxxxxxxxxxxx;
> > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v1 0/2] Fix the wrong order of phy callbacks

The above quoting style makes it harder than necessary to follow
conversation. See hints at:

https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
https://people.kernel.org/tglx/notes-about-netiquette

The ideal thing would be something like this, where there's a single
line for each sender:

On Tue, Aug 30, 2022 at 07:50:55AM +0000, Hongxing Zhu wrote:
> On Tue, Aug 30, 2022, at 03:16PM, Ahmad Fatoum wrote:
> > On 30.08.22 05:47, Hongxing Zhu wrote:
> > > Do you mean to squash this fix to the preview series?
> > > I'm afraid that it's not easy to do that.
> > > Because there are a lot of pci-imx6 code changes after
> > > commit: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie
> > > standalone phy driver").
> >
> > The way I understand it, if a bisect ends up between your two
> > patches, i.MX8M PCIe will be broken, whereas it worked before. I
> > thus wonder if we shouldn't instead squash this series here into a
> > single patch.
>
> Yes, it's a possible case when do the bisect.
> Since these changes are belong to different git repo.

I don't understand the point about different git repos. Patch 1/2
touches drivers/pci/controller/dwc/pci-imx6.c, patch 2/2 touches
drivers/phy/freescale/phy-fsl-imx8m-pcie.c. They're in different
directories, of course, but are in the same Linux kernel source repo.

They're maintained by different people, but we can easily deal with
that by getting an ack from one and merging via the other.

> It will bring maintain difficulties if these two patches are squashed into a
> single one.
> It's difficult to make a choice.

What maintenance difficulty do you see here? I think it looks
*easier* if these are squashed -- that would avoid the possibility of
backporting one without the other, which would certainly be a problem.

If a bisect lands after patch 1/2 but before 2/2, it looks like i.MX8M
will break unnecessarily.

I think Ahmad is right that patches 1/2 and 2/2 should be squashed
into a single patch to avoid this bisection hole.

Bjorn