All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	linux-kernel@vger.kernel.org,
	Peter Robinson <pbrobinson@gmail.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Rob Herring <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	Michal Simek <michal.simek@xilinx.com>,
	Ley Foon Tan <ley.foon.tan@intel.com>,
	rfi@lists.rocketboards.org, Jingoo Han <jingoohan1@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2] PCI: rockchip: Avoid accessing PCIe registers with clocks gated
Date: Tue, 29 Jun 2021 18:14:10 -0500	[thread overview]
Message-ID: <20210629231410.GA4097899@bjorn-Precision-5520> (raw)
In-Reply-To: <3d5a983f-bfdd-d79b-4ec9-357ea26dd2c8@arm.com>

On Tue, Jun 29, 2021 at 11:52:44AM +0100, Robin Murphy wrote:
> On 2021-06-29 07:17, Javier Martinez Canillas wrote:
> > On 6/29/21 2:38 AM, Bjorn Helgaas wrote:
> > > On Thu, Jun 24, 2021 at 05:40:40PM -0500, Bjorn Helgaas wrote:
> > 
> > [snip]
> > 
> > > > > 
> > > > > So let's just move all the IRQ init before the pci_host_probe() call, that
> > > > > will prevent issues like this and seems to be the correct thing to do too.
> > > > 
> > > > Previously we registered rockchip_pcie_subsys_irq_handler() and
> > > > rockchip_pcie_client_irq_handler() before the PCIe clocks were
> > > > enabled.  That's a problem because they depend on those clocks being
> > > > enabled, and your patch fixes that.
> > > > 
> > > > rockchip_pcie_legacy_int_handler() depends on rockchip->irq_domain,
> > > > which isn't initialized until rockchip_pcie_init_irq_domain().
> > > > Previously we registered rockchip_pcie_legacy_int_handler() as the
> > > > handler for the "legacy" IRQ before rockchip_pcie_init_irq_domain().
> > > > 
> > > > I think your patch *also* fixes that problem, right?
> > > 
> > > The lack of consistency in how we use
> > > irq_set_chained_handler_and_data() really bugs me.
> > > 
> > > Your patch fixes the ordering issue where we installed
> > > rockchip_pcie_legacy_int_handler() before initializing data
> > > (rockchip->irq_domain) that it depends on.
> > > 
> > > But AFAICT, rockchip still has the problem that we don't *unregister*
> > > rockchip_pcie_legacy_int_handler() when the rockchip-pcie module is
> > > removed.  Doesn't this mean that if we unload the module, then receive
> > > an interrupt from the device, we'll try to call a function that is no
> > > longer present?
> > 
> > Good question, I don't to be honest. I'll have to dig deeper on this but
> > my experience is that the module removal (and device unbind) is not that
> > well tested on ARM device drivers in general.
> 
> Well, it does use devm_request_irq() so the handler should be unregistered
> by devres *after* ->remove has finished, however that does still leave a
> potential race window in which a pending IRQ could be taken during the later
> part of rockchip_pcie_remove() after it has started turning off critical
> things. Unless the clocks and regulators can also be delegated to devres, it
> might be more robust to explicitly manage the IRQs as well. Mixing the two
> schemes can be problematic when the exact order of both setup and teardown
> matters.

I don't understand the devm_request_irq() connection.  I'm looking at
this irq_set_chained_handler_and_data() call [1]:

  static int rockchip_pcie_setup_irq(struct rockchip_pcie *rockchip)
  {
    ...
    irq = platform_get_irq_byname(pdev, "legacy");
    irq_set_chained_handler_and_data(irq,
				     rockchip_pcie_legacy_int_handler,
				     rockchip);

    irq = platform_get_irq_byname(pdev, "client");
    ...

We look up "irq", pass it to irq_set_chained_handler_and_data(), and
throw it away without saving it anywhere.  How would anything know how
to unregister rockchip_pcie_legacy_int_handler()?

I could imagine irq_set_chained_handler_and_data() saving what's
needed for unregistration, but I would think that would require a
device pointer, which we don't give it.

I'm IRQ-illiterate, so please educate me!

Bjorn

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pcie-rockchip-host.c?id=v5.13#n562

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	linux-kernel@vger.kernel.org,
	Peter Robinson <pbrobinson@gmail.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Rob Herring <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	Michal Simek <michal.simek@xilinx.com>,
	Ley Foon Tan <ley.foon.tan@intel.com>,
	rfi@lists.rocketboards.org, Jingoo Han <jingoohan1@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2] PCI: rockchip: Avoid accessing PCIe registers with clocks gated
Date: Tue, 29 Jun 2021 18:14:10 -0500	[thread overview]
Message-ID: <20210629231410.GA4097899@bjorn-Precision-5520> (raw)
In-Reply-To: <3d5a983f-bfdd-d79b-4ec9-357ea26dd2c8@arm.com>

On Tue, Jun 29, 2021 at 11:52:44AM +0100, Robin Murphy wrote:
> On 2021-06-29 07:17, Javier Martinez Canillas wrote:
> > On 6/29/21 2:38 AM, Bjorn Helgaas wrote:
> > > On Thu, Jun 24, 2021 at 05:40:40PM -0500, Bjorn Helgaas wrote:
> > 
> > [snip]
> > 
> > > > > 
> > > > > So let's just move all the IRQ init before the pci_host_probe() call, that
> > > > > will prevent issues like this and seems to be the correct thing to do too.
> > > > 
> > > > Previously we registered rockchip_pcie_subsys_irq_handler() and
> > > > rockchip_pcie_client_irq_handler() before the PCIe clocks were
> > > > enabled.  That's a problem because they depend on those clocks being
> > > > enabled, and your patch fixes that.
> > > > 
> > > > rockchip_pcie_legacy_int_handler() depends on rockchip->irq_domain,
> > > > which isn't initialized until rockchip_pcie_init_irq_domain().
> > > > Previously we registered rockchip_pcie_legacy_int_handler() as the
> > > > handler for the "legacy" IRQ before rockchip_pcie_init_irq_domain().
> > > > 
> > > > I think your patch *also* fixes that problem, right?
> > > 
> > > The lack of consistency in how we use
> > > irq_set_chained_handler_and_data() really bugs me.
> > > 
> > > Your patch fixes the ordering issue where we installed
> > > rockchip_pcie_legacy_int_handler() before initializing data
> > > (rockchip->irq_domain) that it depends on.
> > > 
> > > But AFAICT, rockchip still has the problem that we don't *unregister*
> > > rockchip_pcie_legacy_int_handler() when the rockchip-pcie module is
> > > removed.  Doesn't this mean that if we unload the module, then receive
> > > an interrupt from the device, we'll try to call a function that is no
> > > longer present?
> > 
> > Good question, I don't to be honest. I'll have to dig deeper on this but
> > my experience is that the module removal (and device unbind) is not that
> > well tested on ARM device drivers in general.
> 
> Well, it does use devm_request_irq() so the handler should be unregistered
> by devres *after* ->remove has finished, however that does still leave a
> potential race window in which a pending IRQ could be taken during the later
> part of rockchip_pcie_remove() after it has started turning off critical
> things. Unless the clocks and regulators can also be delegated to devres, it
> might be more robust to explicitly manage the IRQs as well. Mixing the two
> schemes can be problematic when the exact order of both setup and teardown
> matters.

I don't understand the devm_request_irq() connection.  I'm looking at
this irq_set_chained_handler_and_data() call [1]:

  static int rockchip_pcie_setup_irq(struct rockchip_pcie *rockchip)
  {
    ...
    irq = platform_get_irq_byname(pdev, "legacy");
    irq_set_chained_handler_and_data(irq,
				     rockchip_pcie_legacy_int_handler,
				     rockchip);

    irq = platform_get_irq_byname(pdev, "client");
    ...

We look up "irq", pass it to irq_set_chained_handler_and_data(), and
throw it away without saving it anywhere.  How would anything know how
to unregister rockchip_pcie_legacy_int_handler()?

I could imagine irq_set_chained_handler_and_data() saving what's
needed for unregistration, but I would think that would require a
device pointer, which we don't give it.

I'm IRQ-illiterate, so please educate me!

Bjorn

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pcie-rockchip-host.c?id=v5.13#n562

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	linux-kernel@vger.kernel.org,
	Peter Robinson <pbrobinson@gmail.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Rob Herring <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	Michal Simek <michal.simek@xilinx.com>,
	Ley Foon Tan <ley.foon.tan@intel.com>,
	rfi@lists.rocketboards.org, Jingoo Han <jingoohan1@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2] PCI: rockchip: Avoid accessing PCIe registers with clocks gated
Date: Tue, 29 Jun 2021 18:14:10 -0500	[thread overview]
Message-ID: <20210629231410.GA4097899@bjorn-Precision-5520> (raw)
In-Reply-To: <3d5a983f-bfdd-d79b-4ec9-357ea26dd2c8@arm.com>

On Tue, Jun 29, 2021 at 11:52:44AM +0100, Robin Murphy wrote:
> On 2021-06-29 07:17, Javier Martinez Canillas wrote:
> > On 6/29/21 2:38 AM, Bjorn Helgaas wrote:
> > > On Thu, Jun 24, 2021 at 05:40:40PM -0500, Bjorn Helgaas wrote:
> > 
> > [snip]
> > 
> > > > > 
> > > > > So let's just move all the IRQ init before the pci_host_probe() call, that
> > > > > will prevent issues like this and seems to be the correct thing to do too.
> > > > 
> > > > Previously we registered rockchip_pcie_subsys_irq_handler() and
> > > > rockchip_pcie_client_irq_handler() before the PCIe clocks were
> > > > enabled.  That's a problem because they depend on those clocks being
> > > > enabled, and your patch fixes that.
> > > > 
> > > > rockchip_pcie_legacy_int_handler() depends on rockchip->irq_domain,
> > > > which isn't initialized until rockchip_pcie_init_irq_domain().
> > > > Previously we registered rockchip_pcie_legacy_int_handler() as the
> > > > handler for the "legacy" IRQ before rockchip_pcie_init_irq_domain().
> > > > 
> > > > I think your patch *also* fixes that problem, right?
> > > 
> > > The lack of consistency in how we use
> > > irq_set_chained_handler_and_data() really bugs me.
> > > 
> > > Your patch fixes the ordering issue where we installed
> > > rockchip_pcie_legacy_int_handler() before initializing data
> > > (rockchip->irq_domain) that it depends on.
> > > 
> > > But AFAICT, rockchip still has the problem that we don't *unregister*
> > > rockchip_pcie_legacy_int_handler() when the rockchip-pcie module is
> > > removed.  Doesn't this mean that if we unload the module, then receive
> > > an interrupt from the device, we'll try to call a function that is no
> > > longer present?
> > 
> > Good question, I don't to be honest. I'll have to dig deeper on this but
> > my experience is that the module removal (and device unbind) is not that
> > well tested on ARM device drivers in general.
> 
> Well, it does use devm_request_irq() so the handler should be unregistered
> by devres *after* ->remove has finished, however that does still leave a
> potential race window in which a pending IRQ could be taken during the later
> part of rockchip_pcie_remove() after it has started turning off critical
> things. Unless the clocks and regulators can also be delegated to devres, it
> might be more robust to explicitly manage the IRQs as well. Mixing the two
> schemes can be problematic when the exact order of both setup and teardown
> matters.

I don't understand the devm_request_irq() connection.  I'm looking at
this irq_set_chained_handler_and_data() call [1]:

  static int rockchip_pcie_setup_irq(struct rockchip_pcie *rockchip)
  {
    ...
    irq = platform_get_irq_byname(pdev, "legacy");
    irq_set_chained_handler_and_data(irq,
				     rockchip_pcie_legacy_int_handler,
				     rockchip);

    irq = platform_get_irq_byname(pdev, "client");
    ...

We look up "irq", pass it to irq_set_chained_handler_and_data(), and
throw it away without saving it anywhere.  How would anything know how
to unregister rockchip_pcie_legacy_int_handler()?

I could imagine irq_set_chained_handler_and_data() saving what's
needed for unregistration, but I would think that would require a
device pointer, which we don't give it.

I'm IRQ-illiterate, so please educate me!

Bjorn

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pcie-rockchip-host.c?id=v5.13#n562

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-29 23:14 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08  8:04 [PATCH v2] PCI: rockchip: Avoid accessing PCIe registers with clocks gated Javier Martinez Canillas
2021-06-08  8:04 ` Javier Martinez Canillas
2021-06-08  8:04 ` Javier Martinez Canillas
2021-06-12 22:02 ` Peter Robinson
2021-06-12 22:02   ` Peter Robinson
2021-06-12 22:02   ` Peter Robinson
2021-06-22 10:31 ` Lorenzo Pieralisi
2021-06-22 10:31   ` Lorenzo Pieralisi
2021-06-22 10:31   ` Lorenzo Pieralisi
2021-06-24 21:57 ` Bjorn Helgaas
2021-06-24 21:57   ` Bjorn Helgaas
2021-06-24 21:57   ` Bjorn Helgaas
2021-06-24 23:18   ` Robin Murphy
2021-06-24 23:18     ` Robin Murphy
2021-06-24 23:18     ` Robin Murphy
2021-06-24 23:28     ` Bjorn Helgaas
2021-06-24 23:28       ` Bjorn Helgaas
2021-06-24 23:28       ` Bjorn Helgaas
2021-06-24 23:51       ` Robin Murphy
2021-06-24 23:51         ` Robin Murphy
2021-06-24 23:51         ` Robin Murphy
2021-06-24 22:40 ` Bjorn Helgaas
2021-06-24 22:40   ` Bjorn Helgaas
2021-06-24 22:40   ` Bjorn Helgaas
2021-06-25  7:09   ` Javier Martinez Canillas
2021-06-25  7:09     ` Javier Martinez Canillas
2021-06-25  7:09     ` Javier Martinez Canillas
2021-06-25 14:32     ` Bjorn Helgaas
2021-06-25 14:32       ` Bjorn Helgaas
2021-06-25 14:32       ` Bjorn Helgaas
2021-06-25 18:34       ` Javier Martinez Canillas
2021-06-25 18:34         ` Javier Martinez Canillas
2021-06-25 18:34         ` Javier Martinez Canillas
2021-06-29  0:38   ` Bjorn Helgaas
2021-06-29  0:38     ` Bjorn Helgaas
2021-06-29  0:38     ` Bjorn Helgaas
2021-06-29  6:17     ` Javier Martinez Canillas
2021-06-29  6:17       ` Javier Martinez Canillas
2021-06-29  6:17       ` Javier Martinez Canillas
2021-06-29 10:52       ` Robin Murphy
2021-06-29 10:52         ` Robin Murphy
2021-06-29 10:52         ` Robin Murphy
2021-06-29 23:14         ` Bjorn Helgaas [this message]
2021-06-29 23:14           ` Bjorn Helgaas
2021-06-29 23:14           ` Bjorn Helgaas
2021-06-30  9:44           ` Robin Murphy
2021-06-30  9:44             ` Robin Murphy
2021-06-30  9:44             ` Robin Murphy
2021-06-30 18:49         ` Bjorn Helgaas
2021-06-30 18:49           ` Bjorn Helgaas
2021-06-30 18:49           ` Bjorn Helgaas
2021-06-30 18:59 ` Bjorn Helgaas
2021-06-30 18:59   ` Bjorn Helgaas
2021-06-30 18:59   ` Bjorn Helgaas
2021-06-30 19:59   ` Javier Martinez Canillas
2021-06-30 19:59     ` Javier Martinez Canillas
2021-06-30 19:59     ` Javier Martinez Canillas
2021-06-30 20:30     ` Bjorn Helgaas
2021-06-30 20:30       ` Bjorn Helgaas
2021-06-30 20:30       ` Bjorn Helgaas
2021-06-30 20:46       ` Peter Robinson
2021-06-30 20:46         ` Peter Robinson
2021-06-30 20:46         ` Peter Robinson
2021-06-30 22:09       ` Javier Martinez Canillas
2021-06-30 22:09         ` Javier Martinez Canillas
2021-06-30 22:09         ` Javier Martinez Canillas
2021-07-01 13:59         ` Bjorn Helgaas
2021-07-01 13:59           ` Bjorn Helgaas
2021-07-01 13:59           ` Bjorn Helgaas
2021-07-01 14:59           ` Javier Martinez Canillas
2021-07-01 14:59             ` Javier Martinez Canillas
2021-07-01 14:59             ` Javier Martinez Canillas

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=20210629231410.GA4097899@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=heiko@sntech.de \
    --cc=javierm@redhat.com \
    --cc=jingoohan1@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=ley.foon.tan@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=pbrobinson@gmail.com \
    --cc=rfi@lists.rocketboards.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=thierry.reding@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.