All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: 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 08:17:03 +0200	[thread overview]
Message-ID: <2317a4bc-bd4d-53a7-7fa6-87728d5393cd@redhat.com> (raw)
In-Reply-To: <20210629003829.GA3978248@bjorn-Precision-5520>

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.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering


WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: 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 08:17:03 +0200	[thread overview]
Message-ID: <2317a4bc-bd4d-53a7-7fa6-87728d5393cd@redhat.com> (raw)
In-Reply-To: <20210629003829.GA3978248@bjorn-Precision-5520>

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.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering


_______________________________________________
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: Javier Martinez Canillas <javierm@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: 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 08:17:03 +0200	[thread overview]
Message-ID: <2317a4bc-bd4d-53a7-7fa6-87728d5393cd@redhat.com> (raw)
In-Reply-To: <20210629003829.GA3978248@bjorn-Precision-5520>

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.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering


_______________________________________________
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  6:17 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 [this message]
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
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=2317a4bc-bd4d-53a7-7fa6-87728d5393cd@redhat.com \
    --to=javierm@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=heiko@sntech.de \
    --cc=helgaas@kernel.org \
    --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=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.