lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221117075956.4dw4g7cswr2iamro@mobilestation>
Date:   Thu, 17 Nov 2022 10:59:56 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Rob Herring <robh@...nel.org>, Marek Vasut <marex@...x.de>,
        Alexander Stein <alexander.stein@...tq-group.com>,
        Fabio Estevam <festevam@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Cai Huoqing <cai.huoqing@...ux.dev>,
        Robin Murphy <robin.murphy@....com>,
        Jingoo Han <jingoohan1@...il.com>,
        Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
        Richard Zhu <hongxing.zhu@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        NXP Linux Team <linux-imx@....com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Krzysztof WilczyƄski <kw@...ux.com>,
        Frank Li <Frank.Li@....com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        caihuoqing <caihuoqing@...du.com>, Vinod Koul <vkoul@...nel.org>,
        linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v7 01/20] dt-bindings: imx6q-pcie: Fix clock names for
 imx6sx and imx8mq

On Thu, Nov 17, 2022 at 10:43:22AM +0300, Serge Semin wrote:
> 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@...kalelectronics.ru>
> > > Acked-by: Alexander Stein <alexander.stein@...tq-group.com>
> > > 
> > > ---
> > > 
> > > 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@denx.de/
> 

> 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.

BTW, if this patch is moved from here the series will fail the
dt_binding_check procedure.

-Sergey

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ