From: Jim Quinlan <james.quinlan@broadcom.com>
To: "Krzysztof Wilczyński" <kw@linux.com>
Cc: Jim Quinlan <jim2101024@gmail.com>,
"open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS"
<linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
Rob Herring <robh@kernel.org>, Mark Brown <broonie@kernel.org>,
"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
<bcm-kernel-feedback-list@broadcom.com>,
Sean V Kelley <sean.v.kelley@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Keith Busch <kbusch@kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 5/8] PCI/portdrv: add mechanism to turn on subdev regulators
Date: Mon, 15 Nov 2021 15:26:22 -0500 [thread overview]
Message-ID: <CA+-6iNzyduQskgfEkQMiU15N8f2-gRAoqx=eNfYtOEQiV38SAg@mail.gmail.com> (raw)
In-Reply-To: <YY2pdNMnYQ/EcQoo@rocinante>
On Thu, Nov 11, 2021 at 6:38 PM Krzysztof Wilczyński <kw@linux.com> wrote:
>
> Hi Jim,
>
> [...]
> > [1] These regulators typically govern the actual power supply to the
> > endpoint chip. Sometimes they may be a the official PCIe socket
>
> In the above, did you mean to say "be at the"?
Yep.
>
> > +static void *alloc_subdev_regulators(struct device *dev)
> > +{
> > + static const char * const supplies[] = {
> > + "vpcie3v3",
> > + "vpcie3v3aux",
> > + "vpcie12v",
> > + };
> > + const size_t size = sizeof(struct subdev_regulators)
> > + + sizeof(struct regulator_bulk_data) * ARRAY_SIZE(supplies);
>
> [...]
> > +int pci_subdev_regulators_add_bus(struct pci_bus *bus)
> > +{
> > + struct device *dev = &bus->dev;
> > + struct subdev_regulators *sr;
> > + int ret;
> > +
> > + if (!pcie_is_port_dev(bus->self))
> > + return 0;
> > +
> > + if (WARN_ON(bus->dev.driver_data))
> > + dev_err(dev, "multiple clients using dev.driver_data\n");
>
> I have to ask - is the WARN_ON() above adding value given the nature of the
> error? Would dumping a stack be of interest to someone?
Hello Krzysztof,
It doesn't need to be a warning. You are right, the backtrace will
not help anyone figure out how to fix the problem.
>
> Having said that, why do we even need to assert this? Can there be some
> sort of a race condition with access happening here?
This commit-set is claiming the driver_data field of the PCIe port
device and I am concerned that something else in the future would
unknowingly do the same. It would not be a race, just two separate
pieces of code stomping on the same variable. If I am over-worrying I
can use a dev_err or nothing at all.
>
> I am asking as pci_subdev_regulators_remove_bus() does not seem to be
> concerned about this sort of thing yet it also accesses the same driver
> data, and such.
Yes, but when pci_subdev_regulators_remove_bus() accesses the port
driver driver_data and it is non-NULL it does not know whether it
is the expected pointer or something else.
>
> [...]
> > +/* forward declaration */
> > +static struct pci_driver pcie_portdriver;
>
> The comment above might not be needed as it's quite obvious what the code
> at this line is for, I believe.
Okay.
>
> [...]
> > @@ -131,6 +155,13 @@ static int pcie_portdrv_probe(struct pci_dev *dev,
> > if (status)
> > return status;
> >
> > + if (dev->bus->ops &&
> > + dev->bus->ops->add_bus &&
> > + dev->bus->dev.driver_data) {
> > + pcie_portdriver.resume = subdev_regulator_resume;
> > + pcie_portdriver.suspend = subdev_regulator_suspend;
> > + }
> > +
> > pci_save_state(dev);
>
> [...]
> > @@ -237,6 +268,7 @@ static struct pci_driver pcie_portdriver = {
> > .err_handler = &pcie_portdrv_err_handler,
> >
> > .driver.pm = PCIE_PORTDRV_PM_OPS,
> > + /* Note: suspend and resume may be set during probe */
>
> This comment here is for the "driver.pm" line above, correct? If so, then
> I would move it above the statement. It's a little bit confusing
> otherwise.
I'm planning to remove this comment and the code that sets
pcie_portdriver.{resume,suspend} and instead put this code into the
int pcie_port_device_{suspend,remove}() functions.
Regards,
Jim Quinlan
Broadcom STB
>
> Krzysztof
>
next prev parent reply other threads:[~2021-11-16 0:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-10 22:14 [PATCH v8 0/8] PCI: brcmstb: have portdrv turn on sub-device power Jim Quinlan
2021-11-10 22:14 ` [PATCH v8 1/8] PCI: brcmstb: Change brcm_phy_stop() to return void Jim Quinlan
2021-11-11 21:57 ` Bjorn Helgaas
2021-11-15 20:56 ` Jim Quinlan
2021-11-16 20:40 ` Bjorn Helgaas
2021-11-10 22:14 ` [PATCH v8 2/8] dt-bindings: PCI: Correct brcmstb interrupts, interrupt-map Jim Quinlan
2021-11-10 22:14 ` [PATCH v8 3/8] dt-bindings: PCI: Add bindings for Brcmstb EP voltage regulators Jim Quinlan
2021-11-11 22:17 ` Bjorn Helgaas
2021-11-12 18:25 ` Jim Quinlan
2021-11-12 20:20 ` Bjorn Helgaas
2021-11-12 21:46 ` Rob Herring
2021-11-13 11:38 ` Pali Rohár
2021-11-10 22:14 ` [PATCH v8 4/8] PCI/portdrv: Create pcie_is_port_dev() func from existing code Jim Quinlan
2021-11-11 21:51 ` Florian Fainelli
2021-11-11 22:53 ` Rob Herring
2021-11-11 23:50 ` Krzysztof Wilczyński
2021-11-12 18:14 ` Jim Quinlan
2021-11-10 22:14 ` [PATCH v8 5/8] PCI/portdrv: add mechanism to turn on subdev regulators Jim Quinlan
2021-11-11 22:12 ` Bjorn Helgaas
2021-11-11 22:50 ` Rob Herring
2021-11-11 22:56 ` Rob Herring
2021-11-15 20:44 ` Jim Quinlan
2021-11-16 17:41 ` Rob Herring
2021-11-16 20:53 ` Pali Rohár
2021-11-17 15:14 ` Jim Quinlan
2021-11-17 15:45 ` Pali Rohár
2021-11-18 15:36 ` Jim Quinlan
2021-11-18 15:50 ` Pali Rohár
2021-11-17 14:46 ` Jim Quinlan
2021-11-11 23:38 ` Krzysztof Wilczyński
2021-11-15 20:26 ` Jim Quinlan [this message]
2021-11-10 22:14 ` [PATCH v8 6/8] PCI/portdrv: Do not turn off subdev regulators if EP can wake up Jim Quinlan
2021-11-10 22:14 ` [PATCH v8 7/8] PCI: brcmstb: Split brcm_pcie_setup() into two funcs Jim Quinlan
2021-11-10 22:14 ` [PATCH v8 8/8] PCI: brcmstb: Add control of subdevice voltage regulators 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='CA+-6iNzyduQskgfEkQMiU15N8f2-gRAoqx=eNfYtOEQiV38SAg@mail.gmail.com' \
--to=james.quinlan@broadcom.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=jim2101024@gmail.com \
--cc=kbusch@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nsaenz@kernel.org \
--cc=qiuxu.zhuo@intel.com \
--cc=robh@kernel.org \
--cc=sean.v.kelley@intel.com \
/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).