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