Re: linux-next: manual merge of the pci tree with the arm-soc tree

[Thierry Reding]

On Thu, Dec 15, 2022 at 01:07:35AM +0300, Serge Semin wrote:
> On Wed, Dec 14, 2022 at 03:37:35PM +0100, Thierry Reding wrote:
> > On Wed, Dec 14, 2022 at 02:36:49AM +0300, Serge Semin wrote:
> > > On Tue, Dec 13, 2022 at 02:07:33PM -0600, Bjorn Helgaas wrote:
> > > > On Tue, Dec 13, 2022 at 01:53:13PM -0600, Bjorn Helgaas wrote:
> > > > > On Tue, Dec 13, 2022 at 10:03:10PM +0300, Serge Semin wrote:
> > > > > > On Tue, Dec 13, 2022 at 05:48:53PM +0100, Thierry Reding wrote:
> > > > > > > On Tue, Dec 13, 2022 at 10:21:03AM -0600, Bjorn Helgaas wrote:
> > > > > > > > On Mon, Dec 05, 2022 at 09:57:38AM +1100, Stephen Rothwell wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > Today's linux-next merge of the pci tree got a conflict in:
> > > > > > > > > 
> > > > > > > > >   Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
> > > > > > > > > 
> > > > > > > > > between commit:
> > > > > > > > > 
> > > > > > > > >   5c3741492d2e ("dt-bindings: PCI: tegra234: Add ECAM support")
> > > > > > > > > 
> > > > > > > > > from the arm-soc tree and commit:
> > > > > > > > > 
> > > > > > > > >   4cc13eedb892 ("dt-bindings: PCI: dwc: Add reg/reg-names common properties")
> > > > > > > > > 
> > > > > > > > > from the pci tree.
> > > > > > > > > 
> > > > > > > > > I didn't know how to fix this up, so I just used the latter (and so lost
> > > > > > > > > the addition of "ecam").
> > > > > > > > 
> > > > > > > > Did I miss a suggested resolution for this?
> > > > > > 
> > > > > > > We had a brief discussion about this in another thread. So basically
> > > > > > > Stephen's resolution is fine here and the plan is to instead add the
> > > > > > > ECAM bits that the Tegra patch does in a separate patch on top of
> > > > > > > Serge's patch. I should get around to sending that patch tomorrow.
> > > > > > 
> > > > > > Actually the discussion still goes. I haven't got a respond to my
> > > > > > last suggestion which seems to me more reasonable than extending the
> > > > > > DT-bindings with another vendor-specific reg-name. @Bjorn, please join
> > > > > > the discussion here:
> > > > > > https://lore.kernel.org/linux-pci/20221114155333.234496-2-jonathanh@xxxxxxxxxx/
> > > > > 
> > > 
> > > > > Sorry, it's really too late for discussion.  I need to send the v6.2
> > > > > pull request today or at the very latest, tomorrow, so the only thing
> > > > > to decide is how to resolve the merge conflict in the simplest
> > > > > possible way.  Unless there's a very compelling reason to resolve it
> > > > > differently than Stephen did, that's going to be the answer.
> > > 
> > > Sigh... One more redundant vendor-specific name. I wish I was in the
> > > Cc-list of the original series.
> > > 
> > > > 
> > > > To be more specific, the current answer is this (which is the same as
> > > > what's in next-20221213):
> > > > 
> > > >   https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/tree/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml?id=f64171fdd171
> > > 
> > > Thanks. I've got it from the @Stephen message. @Thierry will submit a
> > > new patch with the same 'ecam'-names change rebased on top of the
> > > updated DT-schema.
> > 
> 
> > If Rob doesn't mind this being broken in linux-next for a few more days,
> > I can discuss this internally with our PCI and UEFI teams and find out
> > if your proposal could be made to work.
> 
> That would be awesome if you managed to work with the already defined
> 'config' reg-name so the DT-schema would look a bit cleaner. Thanks
> in advance.

Looks like Linus has now pulled this in and resolved the conflict
himself. I think there is some benefit in "ecam" being more specific
than "config" and with ECAM being a PCIe standard mapping, it doesn't
seem like it's worth overcomplicating things by overloading the meaning
of "config".

Thierry

Attachment: signature.asc
Description: PGP signature