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

[Serge Semin <Sergey.Semin@baikalelectronics.ru>]

On Thu, Dec 15, 2022 at 01:06:29PM +0100, Thierry Reding wrote:
> 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@nvidia.com/
> > > > > > 
> > > > 
> > > > > > 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".

It's vise versa actually. Adding the new name overcomplicates the
DT-interface for no reason. Using the 'config' name for mapping both
the unrolled and single-sided cfg-spaces would look much cleaner.

-Serge(y)

> 
> Thierry