linux-kernel - Re: [PATCH v2 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP voltage regulators

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: <20210105153347.GE4487@sirena.org.uk>
Date:   Tue, 5 Jan 2021 15:33:47 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Jim Quinlan <jim2101024@...il.com>
Cc:     Rob Herring <robh@...nel.org>,
        Jim Quinlan <james.quinlan@...adcom.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-arm-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 v2 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP
 voltage regulators

On Tue, Jan 05, 2021 at 10:09:21AM -0500, Jim Quinlan wrote:
> On Tue, Jan 5, 2021 at 9:01 AM Mark Brown <broonie@...nel.org> wrote:

> > > For us, the supplies are for the EP chip's power.  We have the PCIe
> > > controller turning them "on" for power-on/resume and "off" for
> > > power-off/suspend.  We need the "xxx-supply" property in the
> > > controller's DT node because of the chicken-and-egg situation: if the
> > > property was in the EP's DT node, the RC  will never discover the EP
> > > to see that there is a regulator to turn on.   We would be happy with

> > Why can't the controller look at the nodes describing devices for
> > standard properties?

> It just feels wrong for the driver (RC) of one DT node to be acting on
> a property of another driver's (EP) node, even though it is a subnode.

This is something we do for other buses, for example where there's
device specific tuning that is actually implemented in the controller
hardware.

> There is also the possibility of the EP driver acting upon the
> property simultaneously; we don't really have control of what EP
> device and drivers are paired with our SOCs.

If the device is trying to do something with a supply that's a standard
part of the bus outside of the bus it seems like that's going to lead to
problems no matter what, due to the discovery issues the device must be
coordinating with the bus somehow.

> In addition, this just pushes the binding name issue down a level --
> what should these power supplies be called?  They are not slot power
> supplies.  Can the  Broadcom STB PCIe RC driver's binding document
> specify and define the properties of EP sub-nodes?

I assume the supplies have some name in the PCI specs, whatever names
are used there would probably be appropriate.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)