Re: [PATCH v5 09/20] dt-bindings: PCI: dwc: Add interrupts/interrupt-names common properties

[Serge Semin <fancer.lancer@gmail.com>]

@Rob, anything to say on what I suggested below?

On Sun, Sep 11, 2022 at 10:02:25PM +0300, Serge Semin wrote:
> On Wed, Aug 31, 2022 at 04:24:43PM -0500, Rob Herring wrote:
> > On Mon, Aug 22, 2022 at 09:46:50PM +0300, Serge Semin wrote:
> > > Currently the 'interrupts' and 'interrupt-names' are defined being too
> > > generic to really describe any actual IRQ interface. Moreover the DW PCIe
> > > End-point devices are left with no IRQ signals. All of that can be fixed
> > > by adding the IRQ-related properties to the common DW PCIe DT-schema and
> > > defining a common and device-specific set of the IRQ names in accordance
> > > with the hardware reference manual. Seeing there are common and dedicated
> > > IRQ signals for DW PCIe Root Port and End-point controllers we suggest to
> > > split the IRQ names up into two sets: common definitions available in the
> > > snps,dw-pcie-common.yaml schema and Root Port specific names defined in
> > > the snps,dw-pcie.yaml schema. The former one will be applied to both DW
> > > PCIe RP and EP controllers, while the later one - for the RP only.
> > > 
> > > Note since there are DW PCI-based vendor-specific DT-bindings with the
> > > custom names assigned to the same IRQ resources we have no much choice but
> > > to add them to the generic DT-schemas in order to have the schemas being
> > > applicable for such devices. Let's mark these names as deprecated so not
> > > to encourage the new DT-bindings to use them.
> > > 
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > 
> > > ---
> > > 
> > > Changelog v3:
> > > - This is a new patch unpinned from the next one:
> > >   https://lore.kernel.org/linux-pci/20220503214638.1895-2-Sergey.Semin@baikalelectronics.ru/
> > >   by the Rob' request. (@Rob)
> > > 
> > > Changelog v5:
> > > - Add platform-specific interrupt names, but mark them as deprecated.
> > > ---
> > >  .../bindings/pci/snps,dw-pcie-common.yaml     | 51 ++++++++++++++
> > >  .../bindings/pci/snps,dw-pcie-ep.yaml         | 17 +++++
> > >  .../devicetree/bindings/pci/snps,dw-pcie.yaml | 67 ++++++++++++++++++-
> > >  3 files changed, 132 insertions(+), 3 deletions(-)
> > 
> 
> > I still don't like how you've done interrupts/clocks/reg. I'd suggest 
> > dropping it if you want this series applied soonish.
> 
> I can't drop this modification because what is currently done with the
> generic resource names much worse. Most importantly the generic names
> suggested here are also added to the driver in the framework of this
> patchset. So one way or another these new names need to be
> added to the DT-bindings.
> 
> As I already said many times we need to find a solution which would
> suit both of us. For me it's to add the new names with detailed
> description and if possible restrict the non-standard resource names
> usage. For you it's to implement a suitable named properties
> constraints. At the same time you keep pushing only what you need
> without concerning what is required for this patchset to be coherent
> in accordance with the new functionality.
> 
> I've listed all the possible options in this message:
> https://lore.kernel.org/linux-pci/20220619163727.xjdlx2jf565uhids@mobilestation/
> I asked you many times to pay your attention to it, but you kept
> ignoring these requests so I had to resubmit the series after waiting
> more than two months for your response. Please let's find out a
> solution which would suit both of us this time.
> 
> So you don't like having the "definitions" keyword in the DT-schemas.
> Do you? Ok. I'll just move all the names defined in there right in the
> named properties constraints. But in any case since these are the
> common DT-schemas we are talking about we can't expect the names being
> specified in a fixed order since at the very least some of them can be
> absent in particular device implementation. What do you say on this?
> Do you have any alternative solution I miss?
> 
> -Sergey
> 
> > 
> > Rob