From: Mark Salter <msalter@redhat.com>
To: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>, Al Stone <ahs3@redhat.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Bjorn Helgaas <bhelgaas@google.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Yijing Wang <wangyijing@huawei.com>,
Lv Zheng <lv.zheng@intel.com>,
"lenb @ kernel . org" <lenb@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
"x86 @ kernel . org" <x86@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core
Date: Thu, 04 Jun 2015 11:51:45 -0400 [thread overview]
Message-ID: <1433433105.24429.30.camel@deneb.redhat.com> (raw)
In-Reply-To: <556FF32B.9010900@linux.intel.com>
On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote:
> On 2015/6/4 14:31, Hanjun Guo wrote:
> > Hi Jiang,
> >
> > On 2015年06月04日 09:54, Jiang Liu wrote:
> >> On 2015/6/4 4:27, Al Stone wrote:
> >>> On 06/02/2015 12:12 AM, Jiang Liu wrote:
> >>>> This patch set consolidates common code to support ACPI PCI root on x86
> >>>> and IA64 platforms into ACPI core, to reproduce duplicated code and
> >>>> simplify maintenance. And a patch set based on this to support ACPI
> >>>> based
> >>>> PCIe host bridge on ARM64 has been posted at:
> >>>
> >>> Link is missing (or it's a typo of some flavor).
> >> HI Al,
> >> Sorry, I missed the link. It has been posted at:
> >> https://lkml.org/lkml/2015/5/26/207
> >
> > I failed to get io resources for PCI hostbridge when I was testing PCI
> > on ARM64 QEMU, I debugged this for quite a while, and finally found out
> > that ACPI resource parsing for IO is not suitable for ARM64, because io
> > space for x86 is 64K, but 16M for ARM64.
> >
> > This issue is only found when the firmware representing the io resource
> > using the type ACPI_RESOURCE_TYPE_ADDRESS32, so the io address will
> > greater than 64k.
> >
> > In drivers/acpi/resource.c:
> >
> > static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
> > u8 io_decode, u8 translation_type)
> > {
> > res->flags = IORESOURCE_IO;
> >
> > [...]
> >
> > if (res->end >= 0x10003)
> > res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
> >
> > [...]
> > }
> >
> > so the code will filter out res->end >= 0x10003, and in my case, it will
> > more than 64K, so we can't get the IO resources.
> >
> > I got a question, why we use if (res->end >= 0x10003) here?
> > I mean 64k will be 0x10000, and in that case, we should use
> > if (res->end >= 0x10000) here, not 0x10003, any history behind that?
>
> Hi Hanjun,
> This is a special tricky for x86. You may read a dword(four bytes) from
> IO port 0xffff, so the effective io port space is 0x10003 bytes.
>
Is there something in ACPI spec which would limit PCI IO space to 64K?
PCI itself allows 32-bit IO addresses and at least some arm64 platforms
use PCI bus addresses above 64K for IO transactions. From a PCI view,
the (res->end >= 0x10003) check doesn't make sense. Am I missing
something?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Mark Salter <msalter@redhat.com>
To: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>, Al Stone <ahs3@redhat.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Bjorn Helgaas <bhelgaas@google.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Yijing Wang <wangyijing@huawei.com>,
Lv Zheng <lv.zheng@intel.com>,
"lenb @ kernel . org" <lenb@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
"x86 @ kernel . org" <x86@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core
Date: Thu, 04 Jun 2015 11:51:45 -0400 [thread overview]
Message-ID: <1433433105.24429.30.camel@deneb.redhat.com> (raw)
In-Reply-To: <556FF32B.9010900@linux.intel.com>
On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote:
> On 2015/6/4 14:31, Hanjun Guo wrote:
> > Hi Jiang,
> >
> > On 2015年06月04日 09:54, Jiang Liu wrote:
> >> On 2015/6/4 4:27, Al Stone wrote:
> >>> On 06/02/2015 12:12 AM, Jiang Liu wrote:
> >>>> This patch set consolidates common code to support ACPI PCI root on x86
> >>>> and IA64 platforms into ACPI core, to reproduce duplicated code and
> >>>> simplify maintenance. And a patch set based on this to support ACPI
> >>>> based
> >>>> PCIe host bridge on ARM64 has been posted at:
> >>>
> >>> Link is missing (or it's a typo of some flavor).
> >> HI Al,
> >> Sorry, I missed the link. It has been posted at:
> >> https://lkml.org/lkml/2015/5/26/207
> >
> > I failed to get io resources for PCI hostbridge when I was testing PCI
> > on ARM64 QEMU, I debugged this for quite a while, and finally found out
> > that ACPI resource parsing for IO is not suitable for ARM64, because io
> > space for x86 is 64K, but 16M for ARM64.
> >
> > This issue is only found when the firmware representing the io resource
> > using the type ACPI_RESOURCE_TYPE_ADDRESS32, so the io address will
> > greater than 64k.
> >
> > In drivers/acpi/resource.c:
> >
> > static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
> > u8 io_decode, u8 translation_type)
> > {
> > res->flags = IORESOURCE_IO;
> >
> > [...]
> >
> > if (res->end >= 0x10003)
> > res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
> >
> > [...]
> > }
> >
> > so the code will filter out res->end >= 0x10003, and in my case, it will
> > more than 64K, so we can't get the IO resources.
> >
> > I got a question, why we use if (res->end >= 0x10003) here?
> > I mean 64k will be 0x10000, and in that case, we should use
> > if (res->end >= 0x10000) here, not 0x10003, any history behind that?
>
> Hi Hanjun,
> This is a special tricky for x86. You may read a dword(four bytes) from
> IO port 0xffff, so the effective io port space is 0x10003 bytes.
>
Is there something in ACPI spec which would limit PCI IO space to 64K?
PCI itself allows 32-bit IO addresses and at least some arm64 platforms
use PCI bus addresses above 64K for IO transactions. From a PCI view,
the (res->end >= 0x10003) check doesn't make sense. Am I missing
something?
WARNING: multiple messages have this Message-ID (diff)
From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core
Date: Thu, 04 Jun 2015 11:51:45 -0400 [thread overview]
Message-ID: <1433433105.24429.30.camel@deneb.redhat.com> (raw)
In-Reply-To: <556FF32B.9010900@linux.intel.com>
On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote:
> On 2015/6/4 14:31, Hanjun Guo wrote:
> > Hi Jiang,
> >
> > On 2015?06?04? 09:54, Jiang Liu wrote:
> >> On 2015/6/4 4:27, Al Stone wrote:
> >>> On 06/02/2015 12:12 AM, Jiang Liu wrote:
> >>>> This patch set consolidates common code to support ACPI PCI root on x86
> >>>> and IA64 platforms into ACPI core, to reproduce duplicated code and
> >>>> simplify maintenance. And a patch set based on this to support ACPI
> >>>> based
> >>>> PCIe host bridge on ARM64 has been posted at:
> >>>
> >>> Link is missing (or it's a typo of some flavor).
> >> HI Al,
> >> Sorry, I missed the link. It has been posted at:
> >> https://lkml.org/lkml/2015/5/26/207
> >
> > I failed to get io resources for PCI hostbridge when I was testing PCI
> > on ARM64 QEMU, I debugged this for quite a while, and finally found out
> > that ACPI resource parsing for IO is not suitable for ARM64, because io
> > space for x86 is 64K, but 16M for ARM64.
> >
> > This issue is only found when the firmware representing the io resource
> > using the type ACPI_RESOURCE_TYPE_ADDRESS32, so the io address will
> > greater than 64k.
> >
> > In drivers/acpi/resource.c:
> >
> > static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
> > u8 io_decode, u8 translation_type)
> > {
> > res->flags = IORESOURCE_IO;
> >
> > [...]
> >
> > if (res->end >= 0x10003)
> > res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
> >
> > [...]
> > }
> >
> > so the code will filter out res->end >= 0x10003, and in my case, it will
> > more than 64K, so we can't get the IO resources.
> >
> > I got a question, why we use if (res->end >= 0x10003) here?
> > I mean 64k will be 0x10000, and in that case, we should use
> > if (res->end >= 0x10000) here, not 0x10003, any history behind that?
>
> Hi Hanjun,
> This is a special tricky for x86. You may read a dword(four bytes) from
> IO port 0xffff, so the effective io port space is 0x10003 bytes.
>
Is there something in ACPI spec which would limit PCI IO space to 64K?
PCI itself allows 32-bit IO addresses and at least some arm64 platforms
use PCI bus addresses above 64K for IO transactions. From a PCI view,
the (res->end >= 0x10003) check doesn't make sense. Am I missing
something?
next prev parent reply other threads:[~2015-06-04 15:51 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 6:12 [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 1/8] ACPI/PCI: Enhance ACPI core to support sparse IO space Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 2/8] ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 3/8] ia64/PCI: Use common struct resource_entry to replace struct iospace_resource Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 4/8] x86/PCI: Rename struct pci_sysdata as struct pci_controller Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 5/8] ARM64/PCI/ACPI: Introduce struct pci_controller for ACPI Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 9:35 ` Lorenzo Pieralisi
2015-06-02 9:35 ` Lorenzo Pieralisi
2015-06-03 8:44 ` Hanjun Guo
2015-06-03 8:44 ` Hanjun Guo
2015-06-03 8:44 ` Hanjun Guo
2015-06-03 9:36 ` Jiang Liu
2015-06-03 9:36 ` Jiang Liu
2015-06-03 10:03 ` Lorenzo Pieralisi
2015-06-03 10:03 ` Lorenzo Pieralisi
2015-06-03 10:21 ` Jiang Liu
2015-06-03 10:21 ` Jiang Liu
2015-06-03 12:49 ` Lorenzo Pieralisi
2015-06-03 12:49 ` Lorenzo Pieralisi
2015-06-02 6:12 ` [Patch v4 6/8] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 7/8] x86/PCI/ACPI: Use common interface to support PCI host bridge Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` [Patch v4 8/8] ia64/PCI/ACPI: " Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:12 ` Jiang Liu
2015-06-02 6:46 ` [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core Hanjun Guo
2015-06-02 6:46 ` Hanjun Guo
2015-06-02 6:46 ` Hanjun Guo
2015-06-03 20:27 ` Al Stone
2015-06-03 20:27 ` Al Stone
2015-06-04 1:54 ` Jiang Liu
2015-06-04 1:54 ` Jiang Liu
2015-06-04 6:31 ` Hanjun Guo
2015-06-04 6:31 ` Hanjun Guo
2015-06-04 6:41 ` Jiang Liu
2015-06-04 6:41 ` Jiang Liu
2015-06-04 6:41 ` Jiang Liu
2015-06-04 7:02 ` Hanjun Guo
2015-06-04 7:02 ` Hanjun Guo
2015-06-04 7:02 ` Hanjun Guo
2015-06-04 15:51 ` Mark Salter [this message]
2015-06-04 15:51 ` Mark Salter
2015-06-04 15:51 ` Mark Salter
2015-06-04 16:29 ` Jiang Liu
2015-06-04 16:29 ` Jiang Liu
2015-06-04 16:57 ` Mark Salter
2015-06-04 16:57 ` Mark Salter
2015-06-08 3:59 ` Hanjun Guo
2015-06-08 3:59 ` Hanjun Guo
2015-06-08 3:59 ` Hanjun Guo
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=1433433105.24429.30.camel@deneb.redhat.com \
--to=msalter@redhat.com \
--cc=Liviu.Dudau@arm.com \
--cc=ahs3@redhat.com \
--cc=bhelgaas@google.com \
--cc=hanjun.guo@linaro.org \
--cc=jiang.liu@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=rjw@rjwysocki.net \
--cc=wangyijing@huawei.com \
--cc=x86@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.