linux-kernel - Re: [External] : RE: [EXT] [PATCH v2 1/1] PCI: layerscape: Add EP mode support for ls1028a

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]

Date:   Wed, 8 Feb 2023 16:23:11 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Frank Li <frank.li@....com>
Cc:     ALOK TIWARI <alok.a.tiwari@...cle.com>,
        "M.H. Lian" <minghuan.lian@....com>,
        Mingkai Hu <mingkai.hu@....com>, Roy Zang <roy.zang@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "open list:PCI DRIVER FOR FREESCALE LAYERSCAPE" 
        <linuxppc-dev@...ts.ozlabs.org>,
        "open list:PCI DRIVER FOR FREESCALE LAYERSCAPE" 
        <linux-pci@...r.kernel.org>,
        "moderated list:PCI DRIVER FOR FREESCALE LAYERSCAPE" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        "imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: Re: [External] : RE: [EXT] [PATCH v2 1/1] PCI: layerscape: Add EP
 mode support for ls1028a

On Tue, Feb 07, 2023 at 04:20:21PM +0000, Frank Li wrote:
> > Subject: Re: [External] : RE: [EXT] [PATCH v2 1/1] PCI: layerscape: Add EP
> > mode support for ls1028a
> > 
> >          { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > +       { .compatible = "fsl,ls1028a-pcie-ep", .data = &ls1_ep_drvdata },
> >         { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > 
> > can it be like this for better readability. ?
> 
> It is just chip name and follow name conversion, which already
> upstreamed and documented. 
>
> Why do you think it not is good readability? 

I thought maybe ALOK's point was to sort the list, which does make a
lot of sense.  But if you want to sort by the .data member, I would
think you would make .compatible a secondary sort key, which means
ls1028a would come before ls1046a, so you would end up with this
instead:

 static const struct of_device_id ls_pcie_ep_of_match[] = {
+       { .compatible = "fsl,ls1028a-pcie-ep", .data = &ls1_ep_drvdata },
        { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
        { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
        { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
        { .compatible = "fsl,lx2160ar2-pcie-ep", .data = &lx2_ep_drvdata },
        { },
 };