Re: [PATCH v7 01/20] dt-bindings: imx6q-pcie: Fix clock names for imx6sx and imx8mq

[Serge Semin]

On Wed, Nov 16, 2022 at 02:38:12PM -0600, Rob Herring wrote:
> On Sun, Nov 13, 2022 at 10:12:42PM +0300, Serge Semin wrote:
> > Originally as it was defined the legacy bindings the pcie_inbound_axi and
> > pcie_aux clock names were supposed to be used in the fsl,imx6sx-pcie and
> > fsl,imx8mq-pcie devices respectively. But the bindings conversion has been
> > incorrectly so now the fourth clock name is defined as "pcie_inbound_axi
> > for imx6sx-pcie, pcie_aux for imx8mq-pcie", which is completely wrong.
> > Let's fix that by conditionally apply the clock-names constraints based on
> > the compatible string content.
> > 
> > Fixes: 751ca492f131 ("dt-bindings: PCI: imx6: convert the imx pcie controller to dtschema")
> > Signed-off-by: Serge Semin <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx>
> > Acked-by: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx>
> > 
> > ---
> > 
> > Changelog v5:
> > - This is a new patch added on the v5 release of the patchset.
> > 
> > Changelog v7:
> > - Move the allOf clause to the bottom of the bindings. (@Krzysztof)
> > - Get back the names to the clock-names property and make sure the
> >   platform-specific name constraint is applied in the allOf clause.
> >   (@Rob)
> > ---
> >  .../bindings/pci/fsl,imx6q-pcie.yaml          | 46 +++++++++++++++++--
> >  1 file changed, 42 insertions(+), 4 deletions(-)
> 
> We have 2 patches doing the same thing:
> 
> https://lore.kernel.org/all/20221109002449.35936-1-marex@xxxxxxx/

It seems to me that that patch does two things at a time:
1. Fixes invalid fourth clock-names entry.
2. Fixes the fsl,imx8mm-pcie device having the "pcie_aux" clock name
required instead of "pcie_phy".

My patch does only the first part. What about moving my patch to that
series and converting the Marek' patch to being applicable on top of
it and fixing the imx8mm part only? That seems reasonable.

-Sergey

> 
> Please hash out which one you all want. Both seem to have clock 
> warnings still...
> 
> Reviewed-by: Rob Herring <robh@xxxxxxxxxx>