All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qian Cai <quic_qiancai@quicinc.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: Arm64 double PCI ECAM reservations in acpi_resource_consumer()
Date: Thu, 3 Jun 2021 11:44:45 -0400	[thread overview]
Message-ID: <d3f73fb9-af75-0fdb-fc29-44dc92422c01@quicinc.com> (raw)
In-Reply-To: <20210603141641.GA17284@lpieralisi>



On 6/3/2021 10:16 AM, Lorenzo Pieralisi wrote:
> This is not the "reservation". AFAICS acpi_resource_consumer() checks
> whether the ECAM region is part of _a_ given ACPI device _CRS in the
> namespace, it does not "reserve" anything.
> 
> IIUC the issue here is that we request the ECAM region in
> pci_ecam_create() and later the code in:

Okay, I was confused by the code. I thought once acpi_resource_consumer() returned something, it is "reserved".

	adev = acpi_resource_consumer(&cfgres);
	if (adev)
		dev_info(dev, "ECAM area %pR reserved by %s\n", &cfgres,
			 dev_name(&adev->dev));
	else
		dev_warn(dev, FW_BUG "ECAM area %pR not reserved in ACPI namespace\n",
			 &cfgres);

> 
> drivers/pnp/system.c
> 
> tries to request the ECAM region (that lives in the PNP0C02 _CRS) and
> fails (see reserve_range() and request_mem_region()).
> 
> As the comment in reserve_range() goes, this is harmless, not sure
> whether there is anything to do about it.

Actually, the comment said it is "usually harmless", so it is a tricky for an average Joe to figure out if one case falls into the "usual" bracket or not at the first place.

WARNING: multiple messages have this Message-ID
From: Qian Cai <quic_qiancai@quicinc.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: Arm64 double PCI ECAM reservations in acpi_resource_consumer()
Date: Thu, 3 Jun 2021 11:44:45 -0400	[thread overview]
Message-ID: <d3f73fb9-af75-0fdb-fc29-44dc92422c01@quicinc.com> (raw)
In-Reply-To: <20210603141641.GA17284@lpieralisi>



On 6/3/2021 10:16 AM, Lorenzo Pieralisi wrote:
> This is not the "reservation". AFAICS acpi_resource_consumer() checks
> whether the ECAM region is part of _a_ given ACPI device _CRS in the
> namespace, it does not "reserve" anything.
> 
> IIUC the issue here is that we request the ECAM region in
> pci_ecam_create() and later the code in:

Okay, I was confused by the code. I thought once acpi_resource_consumer() returned something, it is "reserved".

	adev = acpi_resource_consumer(&cfgres);
	if (adev)
		dev_info(dev, "ECAM area %pR reserved by %s\n", &cfgres,
			 dev_name(&adev->dev));
	else
		dev_warn(dev, FW_BUG "ECAM area %pR not reserved in ACPI namespace\n",
			 &cfgres);

> 
> drivers/pnp/system.c
> 
> tries to request the ECAM region (that lives in the PNP0C02 _CRS) and
> fails (see reserve_range() and request_mem_region()).
> 
> As the comment in reserve_range() goes, this is harmless, not sure
> whether there is anything to do about it.

Actually, the comment said it is "usually harmless", so it is a tricky for an average Joe to figure out if one case falls into the "usual" bracket or not at the first place.

_______________________________________________
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-03 15:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 21:49 Arm64 double PCI ECAM reservations in acpi_resource_consumer() Qian Cai
2021-06-02 22:09 ` Bjorn Helgaas
2021-06-02 22:09   ` Bjorn Helgaas
2021-06-03  0:15   ` Qian Cai
2021-06-03  0:15     ` Qian Cai
2021-06-03 14:16     ` Lorenzo Pieralisi
2021-06-03 14:16       ` Lorenzo Pieralisi
2021-06-03 15:44       ` Qian Cai [this message]
2021-06-03 15:44         ` Qian Cai

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=d3f73fb9-af75-0fdb-fc29-44dc92422c01@quicinc.com \
    --to=quic_qiancai@quicinc.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=will@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 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.