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] [day] [month] [year] [list]
Message-ID: <20211027213754.bnswkijrqinackgt@pali>
Date:   Wed, 27 Oct 2021 23:37:54 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Jim Quinlan <james.quinlan@...adcom.com>,
        Rob Herring <robh@...nel.org>,
        Jim Quinlan <jim2101024@...il.com>,
        "open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS" 
        <linux-pci@...r.kernel.org>,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Mark Brown <broonie@...nel.org>,
        "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Saenz Julienne <nsaenzjulienne@...e.de>,
        "moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP
 voltage regulators

On Wednesday 27 October 2021 11:58:57 Bjorn Helgaas wrote:
> On Tue, Oct 26, 2021 at 05:27:32PM -0400, Jim Quinlan wrote:
> 
> > I don't think it matters but our PCIe controllers only have a single
> > root port.
> 
> Just to kibitz, and I don't know anything about the DT binding under
> discussion here, but I would prefer if DTs and drivers did not have
> the "single root port" assumption baked deeply in them.

+1

Please look also at my proposal for similar/same issue:
https://lore.kernel.org/linux-pci/20211023144252.z7ou2l2tvm6cvtf7@pali/t/#u

> I expect some controllers to support multiple root ports, and it would
> be really nice if the DTs and drivers all had similar structures with
> the single-root-port controllers just being the N=1 case.
> 
> For example, some drivers put their per-root port stuff in
> *_add_pcie_port() functions, which I think is a nice way to do it
> because it leaves the door open for calling *_add_pcie_port() in a
> loop.
> 
> Ironically, the only driver I see that looks like it currently
> supports multiple root ports is pci-mvebu.c, and it doesn't have an
> _add_pcie_port() function.

Ironically, pci-mvebu.c is doing it wrong because HW has basically N
fully independent HW host bridges and pci-mvebu.c driver is registering
one kernel virtual host bridge device and is merging root ports of all
host bridges into this one "virtual" bus which belongs to that kernel
virtual host bridge... Plus root ports are also "virtual" because they
are broken in HW. So correctly pci-mvebu.c should have been split into
separate host bridge DTS nodes, but due to backward compatibility it is
not possible.

> Having this sort of consistent structure and naming across drivers is
> a huge help for ongoing maintenance.
> 
> Bjorn

+1

That is why I sent that my proposal. Defining this as a common way for
(new) drivers would really helps a lot all maintenance.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ