linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jim Quinlan <jim2101024@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
	<linux-rpi-kernel@lists.infradead.org>,
	"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators
Date: Wed, 7 Apr 2021 12:27:13 +0100	[thread overview]
Message-ID: <20210407112713.GB5510@sirena.org.uk> (raw)
In-Reply-To: <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:

> I'm a little confused -- here is how I remember the chronology of the
> "DT bindings" commit reviews, please correct me if I'm wrong:

> o JimQ submitted a pullreq for using voltage regulators in the same
> style as the existing "rockport" PCIe driver.
> o After some deliberation, RobH preferred that the voltage regulators
> should go into the PCIe subnode device's DT node.
> o JimQ put the voltage regulators in the subnode device's DT node.
> o MarkB didn't like the fact that the code did a global search for the
> regulator since it could not provide the owning struct device* handle.
> o RobH relented, and said that if it is just two specific and standard
> voltage regulators, perhaps they can go in the parent DT node after
> all.
> o JimQ put the regulators back in the PCIe node.
> o MarkB now wants the regulators to go back into the child node again?

...having pointed out a couple of times now that there's no physical
requirement that the supplies be shared between slots never mind with
the controller.  Also note that as I've said depending on what the
actual requirements of the controller node are you might want to have
the regulators in both places, and further note that the driver does not
have to actively use everything in the binding document (although if
it's not using something that turns out to be a requirement it's likely
to run into hardware where that causes bugs at some point).

Frankly I'm not clear why you're trying to handle powering on PCI slots
in a specific driver, surely PCI devices are PCI devices regardless of
the controller?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-04-07 11:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 21:21 [PATCH v4 0/6] PCI: brcmstb: add slot0 device regulators and panic handler Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 1/6] PCI: brcmstb: Check return value of clk_prepare_enable() Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators Jim Quinlan
2021-04-06 16:47   ` Mark Brown
2021-04-06 17:26     ` Jim Quinlan
2021-04-06 17:32       ` Mark Brown
2021-04-06 18:25         ` Jim Quinlan
2021-04-07 11:27           ` Mark Brown [this message]
2021-04-07 18:35             ` Florian Fainelli
2021-04-07 20:07               ` Mark Brown
2021-04-08 16:20           ` Rob Herring
2021-04-08 16:33             ` Mark Brown
2021-04-08 16:58             ` Jim Quinlan
2021-04-08 17:55               ` Rob Herring
2021-04-08 17:41     ` Rob Herring
2021-04-01 21:21 ` [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 " Jim Quinlan
2021-04-06 16:34   ` Mark Brown
2021-04-06 16:59     ` Jim Quinlan
2021-04-06 17:23       ` Mark Brown
2021-04-06 17:29         ` Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 4/6] PCI: brcmstb: Do not turn off regulators if EP can wake up Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 5/6] PCI: brcmstb: Give 7216 SOCs their own config type Jim Quinlan
2021-04-01 21:21 ` [PATCH v4 6/6] PCI: brcmstb: Add panic/die handler to RC driver Jim Quinlan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210407112713.GB5510@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=jim2101024@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=nsaenzjulienne@suse.de \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).