Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Thu, Dec 11, 2014 at 8:36 AM, Thomas Gleixner wrote:
> On Wed, 10 Dec 2014, Yinghai Lu wrote:
>> On Wed, Dec 10, 2014 at 12:15 PM, Thomas Gleixner wrote:
>> >> - struct resource r = {
>> >> - .flags = 0
>> >> - };
>> >> + struct resource r;
>> >>
>> >> + memset(&r, 0, sizeof(r));
>> >
>> > What's the point of this change? Both initialize r to 0. memset()
>> > generates better code, but that's irrelevant for the problem at hand.
>
> Did you actually read what I wrote?
>
> struct resource r = {
>.flags = 0
> };
>
> initializes r completely to 0. So how do you get a random pointer in r?
ok, I get it now.
I was thinking that compiler will generate code like
struct resource r;
r.flags = 0;
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 5:31 PM, Yinghai Lu wrote: > On Wed, Dec 10, 2014 at 12:15 PM, Thomas Gleixner wrote: >> On Tue, 9 Dec 2014, Yinghai Lu wrote: >> >> Can you please >> ... >> 2) Send patches inline. It's a pain to review and reply and I can't >>use my normal tooling. I agree, it is noticeably more hassle for me to deal with patches sent as attachments. I can do it, but I tend to avoid it because it's a nuisance. > I can not, as gmail does not allow that. I agree, gmail is a pain in the neck in this regard. I personally use mutt with imap to my gmail account to send patches and to review and apply patches. It isn't perfect, and it is a bit of a hassle, but it can be done. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, 10 Dec 2014, Yinghai Lu wrote:
> On Wed, Dec 10, 2014 at 12:15 PM, Thomas Gleixner wrote:
> >> - struct resource r = {
> >> - .flags = 0
> >> - };
> >> + struct resource r;
> >>
> >> + memset(&r, 0, sizeof(r));
> >
> > What's the point of this change? Both initialize r to 0. memset()
> > generates better code, but that's irrelevant for the problem at hand.
>
> late there is
>
> info->res[info->res_num] = r;
>
> don't want the random pointer in r get copied.
Did you actually read what I wrote?
struct resource r = {
.flags = 0
};
initializes r completely to 0. So how do you get a random pointer in r?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 05:57:12PM -0800, Yinghai Lu wrote: > Tried with mutt or thunderbird etc, all kept on downloading Mutt with gmail via imap works just fine for me. set folder="imaps://imap.gmail.com:993" set imap_user="lu...@gmail.com" set imap_pass="SuperSecret" You don't have to set imap_pass if you prefer an interactive prompt. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, 2014-12-10 at 17:57 -0800, Yinghai Lu wrote: > On Wed, Dec 10, 2014 at 4:35 PM, Borislav Petkov wrote: > > On Wed, Dec 10, 2014 at 04:31:22PM -0800, Yinghai Lu wrote: > >> > 2) Send patches inline. It's a pain to review and reply and I can't > >> >use my normal tooling. > >> > >> I can not, as gmail does not allow that. > > > > Lemme guess, this is some kind of a joke you're making, right? > > I am using yhlu.ker...@gmail.com to send as ying...@kernel.org. > > Tried with mutt or thunderbird etc, all kept on downloading All mail clients are sh*t :) Evolution has it's annoyances too, but this ain't one of them. I've set up both imap and pop evolution accounts for gmail. I generally only enable the pop account, but can enable both simultaneously. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 4:35 PM, Borislav Petkov wrote: > On Wed, Dec 10, 2014 at 04:31:22PM -0800, Yinghai Lu wrote: >> > 2) Send patches inline. It's a pain to review and reply and I can't >> >use my normal tooling. >> >> I can not, as gmail does not allow that. > > Lemme guess, this is some kind of a joke you're making, right? I am using yhlu.ker...@gmail.com to send as ying...@kernel.org. Tried with mutt or thunderbird etc, all kept on downloading so have to stuck with the gmail web gui. and it does not allow insert plain text in the mail. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 04:31:22PM -0800, Yinghai Lu wrote: > > 2) Send patches inline. It's a pain to review and reply and I can't > >use my normal tooling. > > I can not, as gmail does not allow that. Lemme guess, this is some kind of a joke you're making, right? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 12:15 PM, Thomas Gleixner wrote:
> On Tue, 9 Dec 2014, Yinghai Lu wrote:
>
> Can you please
>
> 1) Cut out the completely irrelevant information from your replies?
>It's just annoying to scroll through hundreds of quoted lines to
>find the guts of the mail.
ok.
>
> 2) Send patches inline. It's a pain to review and reply and I can't
>use my normal tooling.
I can not, as gmail does not allow that.
>>
>> Attached patch should address them.
>
>> - struct resource r = {
>> - .flags = 0
>> - };
>> + struct resource r;
>>
>> + memset(&r, 0, sizeof(r));
>
> What's the point of this change? Both initialize r to 0. memset()
> generates better code, but that's irrelevant for the problem at hand.
late there is
info->res[info->res_num] = r;
don't want the random pointer in r get copied.
>
>> Please fix it before it get into linus tree.
>
> You can be sure that I'm going to fix the whole mess there proper and
> not by applying a cobbled together bandaid.
Good.
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Tue, 9 Dec 2014, Yinghai Lu wrote:
Can you please
1) Cut out the completely irrelevant information from your replies?
It's just annoying to scroll through hundreds of quoted lines to
find the guts of the mail.
2) Send patches inline. It's a pain to review and reply and I can't
use my normal tooling.
> This one cause one system with Nehalem and one with Westmere failing.
>
> [ 32.353347] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x]; [mem 0x000a-0x000b] ignored
> [ 32.362897] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x]; [mem 0x000d-0x000d] ignored
> [ 32.382862] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x]; [mem 0x-0x] ignored
> [ 32.402889] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x]; [??? 0x-0x flags 0x0] ignored
> [ 32.423000] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x-0x]; [mem 0x-0x] ignored
> [ 32.602921] PCI host bridge to bus :00
> [ 32.603158] pci_bus :00: root bus resource [bus 00-3f]
> [ 32.622782] pci_bus :00: root bus resource [io 0x-0x5fff]
> [ 32.642569] pci_bus :00: root bus resource [mem 0x-0x]
> [ 32.642893] pci_bus :00: root bus resource [mem
> 0xfc0-0xfc07fff pref]
>
> Looks like the commit have several problems.
>
> Attached patch should address them.
> - struct resource r = {
> - .flags = 0
> - };
> + struct resource r;
>
> + memset(&r, 0, sizeof(r));
What's the point of this change? Both initialize r to 0. memset()
generates better code, but that's irrelevant for the problem at hand.
And the "fix" is also missing that the address range check happens for
IORESOURCE_IO as well. Which is silly because
acpi_dev_resource_address_space() has that already for the IO
case. But sure, that does not help, because it does not return false,
it sets the IORESOURCE_DISABLED flag and returns true.
Now the code in setup_resource() clears that flag along with all other
flags which does not make any sense, at least not without a comment.
But clearing and therefor ignoring IORESOURCE_DISABLED does not make
any sense at all and is outright wrong.
So there is another interesting flag: IORESOURCE_WINDOW. That's
cleared as well and of course the rest of that setup code does not
handle it either. If IORESOURCE_WINDOW is not set, then this is
address space which is consumed by the bridge itself. So its just
wrong to treat it as window and try coalescing it with the real window
spaces.
Also why is this x86 bridge specific?
if (addr.resource_type == ACPI_MEMORY_RANGE &&
addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
r.flags |= IORESOURCE_PREFETCH;
and not happening in the acpi code? Just because struct resource does
not have a field for it? Sigh.
This needs more than a hacked together fixup, really. It was wrong
before Jiangs change already.
> Please fix it before it get into linus tree.
You can be sure that I'm going to fix the whole mess there proper and
not by applying a cobbled together bandaid.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
Hi Yinghai,
I have one comment about the attached patch related to
following piece of code. I'm not sure whether we should check
"addr.maximum - addr.minimum + 1 != addr.address_length"
instead of "!addr.address_length". Otherwise:
Reviewed-by: Jiang Liu
Regards!
Gerry
Index: linux-2.6/drivers/acpi/resource.c
===
--- linux-2.6.orig/drivers/acpi/resource.c
+++ linux-2.6/drivers/acpi/resource.c
@@ -199,7 +199,7 @@ bool acpi_dev_resource_address_space(str
}
status = acpi_resource_to_address64(ares, &addr);
- if (ACPI_FAILURE(status))
+ if (ACPI_FAILURE(status) || !addr.address_length)
return false;
res->start = addr.minimum;
On 2014/12/10 12:08, Yinghai Lu wrote:
> On Mon, Nov 3, 2014 at 2:57 AM, tip-bot for Jiang Liu
> wrote:
>> Commit-ID: e22ce93870deae0e9a54e1539f0088538f187780
>> Gitweb:
>> http://git.kernel.org/tip/e22ce93870deae0e9a54e1539f0088538f187780
>> Author: Jiang Liu
>> AuthorDate: Mon, 27 Oct 2014 13:21:34 +0800
>> Committer: Thomas Gleixner
>> CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
>>
>> x86, PCI, ACPI: Kill private function resource_to_addr() in
>> arch/x86/pci/acpi.c
>>
>> Private function resource_to_addr() is used to parse ACPI resources
>> for PCI host bridge. There are public interfaces available for that
>> purpose, so replace resource_to_addr() with public interfaces.
>>
>> Signed-off-by: Jiang Liu
>> Reviewed-by: Bjorn Helgaas
>> Cc: Konrad Rzeszutek Wilk
>> Cc: Tony Luck
>> Cc: Joerg Roedel
>> Cc: Greg Kroah-Hartman
>> Cc: Benjamin Herrenschmidt
>> Cc: Rafael J. Wysocki
>> Cc: Randy Dunlap
>> Cc: Yinghai Lu
>> Cc: Borislav Petkov
>> Link:
>> http://lkml.kernel.org/r/1414387308-27148-5-git-send-email-jiang@linux.intel.com
>> Signed-off-by: Thomas Gleixner
>> ---
>> arch/x86/pci/acpi.c | 144
>> +++-
>> 1 file changed, 53 insertions(+), 91 deletions(-)
>>
>> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
>> index cfd1b13..3f72d93 100644
>> --- a/arch/x86/pci/acpi.c
>> +++ b/arch/x86/pci/acpi.c
>> @@ -218,114 +218,76 @@ static void teardown_mcfg_map(struct pci_root_info
>> *info)
>> }
>> #endif
>>
>> -static acpi_status resource_to_addr(struct acpi_resource *resource,
>> - struct acpi_resource_address64 *addr)
>> -{
>> - acpi_status status;
>> - struct acpi_resource_memory24 *memory24;
>> - struct acpi_resource_memory32 *memory32;
>> - struct acpi_resource_fixed_memory32 *fixed_memory32;
>> -
>> - memset(addr, 0, sizeof(*addr));
>> - switch (resource->type) {
>> - case ACPI_RESOURCE_TYPE_MEMORY24:
>> - memory24 = &resource->data.memory24;
>> - addr->resource_type = ACPI_MEMORY_RANGE;
>> - addr->minimum = memory24->minimum;
>> - addr->address_length = memory24->address_length;
>> - addr->maximum = addr->minimum + addr->address_length - 1;
>> - return AE_OK;
>> - case ACPI_RESOURCE_TYPE_MEMORY32:
>> - memory32 = &resource->data.memory32;
>> - addr->resource_type = ACPI_MEMORY_RANGE;
>> - addr->minimum = memory32->minimum;
>> - addr->address_length = memory32->address_length;
>> - addr->maximum = addr->minimum + addr->address_length - 1;
>> - return AE_OK;
>> - case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
>> - fixed_memory32 = &resource->data.fixed_memory32;
>> - addr->resource_type = ACPI_MEMORY_RANGE;
>> - addr->minimum = fixed_memory32->address;
>> - addr->address_length = fixed_memory32->address_length;
>> - addr->maximum = addr->minimum + addr->address_length - 1;
>> - return AE_OK;
>> - case ACPI_RESOURCE_TYPE_ADDRESS16:
>> - case ACPI_RESOURCE_TYPE_ADDRESS32:
>> - case ACPI_RESOURCE_TYPE_ADDRESS64:
>> - status = acpi_resource_to_address64(resource, addr);
>> - if (ACPI_SUCCESS(status) &&
>> - (addr->resource_type == ACPI_MEMORY_RANGE ||
>> - addr->resource_type == ACPI_IO_RANGE) &&
>> - addr->address_length > 0) {
>> - return AE_OK;
>> - }
>> - break;
>> - }
>> - return AE_ERROR;
>> -}
>> -
>> static acpi_status count_resource(struct acpi_resource *acpi_res, void
>> *data)
>> {
>> struct pci_root_info *info = data;
>> - struct acpi_resource_address64 addr;
>> - acpi_status status;
>> + struct resource r = {
>> + .flags = 0
>> + };
>>
>> - status = resource_to_addr(acpi_res, &addr);
>> - if (ACPI_SUCCESS(status))
>> + if (!acpi_dev_resource_memory(acpi_res, &r) &&
>> + !acpi_dev_resource_add
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Mon, Nov 3, 2014 at 2:57 AM, tip-bot for Jiang Liu wrote:
> Commit-ID: e22ce93870deae0e9a54e1539f0088538f187780
> Gitweb: http://git.kernel.org/tip/e22ce93870deae0e9a54e1539f0088538f187780
> Author: Jiang Liu
> AuthorDate: Mon, 27 Oct 2014 13:21:34 +0800
> Committer: Thomas Gleixner
> CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
>
> x86, PCI, ACPI: Kill private function resource_to_addr() in
> arch/x86/pci/acpi.c
>
> Private function resource_to_addr() is used to parse ACPI resources
> for PCI host bridge. There are public interfaces available for that
> purpose, so replace resource_to_addr() with public interfaces.
>
> Signed-off-by: Jiang Liu
> Reviewed-by: Bjorn Helgaas
> Cc: Konrad Rzeszutek Wilk
> Cc: Tony Luck
> Cc: Joerg Roedel
> Cc: Greg Kroah-Hartman
> Cc: Benjamin Herrenschmidt
> Cc: Rafael J. Wysocki
> Cc: Randy Dunlap
> Cc: Yinghai Lu
> Cc: Borislav Petkov
> Link:
> http://lkml.kernel.org/r/1414387308-27148-5-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner
> ---
> arch/x86/pci/acpi.c | 144
> +++-
> 1 file changed, 53 insertions(+), 91 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index cfd1b13..3f72d93 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -218,114 +218,76 @@ static void teardown_mcfg_map(struct pci_root_info
> *info)
> }
> #endif
>
> -static acpi_status resource_to_addr(struct acpi_resource *resource,
> - struct acpi_resource_address64 *addr)
> -{
> - acpi_status status;
> - struct acpi_resource_memory24 *memory24;
> - struct acpi_resource_memory32 *memory32;
> - struct acpi_resource_fixed_memory32 *fixed_memory32;
> -
> - memset(addr, 0, sizeof(*addr));
> - switch (resource->type) {
> - case ACPI_RESOURCE_TYPE_MEMORY24:
> - memory24 = &resource->data.memory24;
> - addr->resource_type = ACPI_MEMORY_RANGE;
> - addr->minimum = memory24->minimum;
> - addr->address_length = memory24->address_length;
> - addr->maximum = addr->minimum + addr->address_length - 1;
> - return AE_OK;
> - case ACPI_RESOURCE_TYPE_MEMORY32:
> - memory32 = &resource->data.memory32;
> - addr->resource_type = ACPI_MEMORY_RANGE;
> - addr->minimum = memory32->minimum;
> - addr->address_length = memory32->address_length;
> - addr->maximum = addr->minimum + addr->address_length - 1;
> - return AE_OK;
> - case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
> - fixed_memory32 = &resource->data.fixed_memory32;
> - addr->resource_type = ACPI_MEMORY_RANGE;
> - addr->minimum = fixed_memory32->address;
> - addr->address_length = fixed_memory32->address_length;
> - addr->maximum = addr->minimum + addr->address_length - 1;
> - return AE_OK;
> - case ACPI_RESOURCE_TYPE_ADDRESS16:
> - case ACPI_RESOURCE_TYPE_ADDRESS32:
> - case ACPI_RESOURCE_TYPE_ADDRESS64:
> - status = acpi_resource_to_address64(resource, addr);
> - if (ACPI_SUCCESS(status) &&
> - (addr->resource_type == ACPI_MEMORY_RANGE ||
> - addr->resource_type == ACPI_IO_RANGE) &&
> - addr->address_length > 0) {
> - return AE_OK;
> - }
> - break;
> - }
> - return AE_ERROR;
> -}
> -
> static acpi_status count_resource(struct acpi_resource *acpi_res, void *data)
> {
> struct pci_root_info *info = data;
> - struct acpi_resource_address64 addr;
> - acpi_status status;
> + struct resource r = {
> + .flags = 0
> + };
>
> - status = resource_to_addr(acpi_res, &addr);
> - if (ACPI_SUCCESS(status))
> + if (!acpi_dev_resource_memory(acpi_res, &r) &&
> + !acpi_dev_resource_address_space(acpi_res, &r))
> + return AE_OK;
> +
> + if ((r.flags & (IORESOURCE_IO | IORESOURCE_MEM)) && resource_size(&r))
> info->res_num++;
> +
> return AE_OK;
> }
>
> static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data)
> {
> struct pci_root_info *info = data;
> - struct resource *res;
> - struct acpi_resource_address64 addr;
> - acpi_status status;
> - unsigned long flags;
> - u64 start, orig_end, end;
> + u64 translation_offset = 0;
> + struct resource r = {
> + .flags = 0
> + };
> +
> + if (acpi_dev_resource_memory(acpi_res, &r)) {
> + r.flags &= IORESOURCE_MEM | IORESOURCE_IO;
> + } else if (acpi_dev_resource_address_space(acpi_res, &r)) {
> + u64 orig_end;
> + struct acpi_resource_address64 addr;
> +
> +
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Mon, Nov 03, 2014 at 02:57:31AM -0800, tip-bot for Jiang Liu wrote:
> Commit-ID: e22ce93870deae0e9a54e1539f0088538f187780
> Gitweb: http://git.kernel.org/tip/e22ce93870deae0e9a54e1539f0088538f187780
> Author: Jiang Liu
> AuthorDate: Mon, 27 Oct 2014 13:21:34 +0800
> Committer: Thomas Gleixner
> CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
>
> x86, PCI, ACPI: Kill private function resource_to_addr() in
> arch/x86/pci/acpi.c
>
> Private function resource_to_addr() is used to parse ACPI resources
> for PCI host bridge. There are public interfaces available for that
> purpose, so replace resource_to_addr() with public interfaces.
>
> Signed-off-by: Jiang Liu
> Reviewed-by: Bjorn Helgaas
> Cc: Konrad Rzeszutek Wilk
> Cc: Tony Luck
> Cc: Joerg Roedel
> Cc: Greg Kroah-Hartman
> Cc: Benjamin Herrenschmidt
> Cc: Rafael J. Wysocki
> Cc: Randy Dunlap
> Cc: Yinghai Lu
> Cc: Borislav Petkov
> Link:
> http://lkml.kernel.org/r/1414387308-27148-5-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner
> ---
...
> static acpi_status setup_resource(struct acpi_resource *acpi_res, void *data)
> {
> struct pci_root_info *info = data;
> - struct resource *res;
> - struct acpi_resource_address64 addr;
> - acpi_status status;
> - unsigned long flags;
> - u64 start, orig_end, end;
> + u64 translation_offset = 0;
> + struct resource r = {
> + .flags = 0
> + };
> +
> + if (acpi_dev_resource_memory(acpi_res, &r)) {
> + r.flags &= IORESOURCE_MEM | IORESOURCE_IO;
> + } else if (acpi_dev_resource_address_space(acpi_res, &r)) {
> + u64 orig_end;
> + struct acpi_resource_address64 addr;
> +
> + r.flags &= IORESOURCE_MEM | IORESOURCE_IO;
> + if (r.flags == 0)
> + return AE_OK;
>
> - status = resource_to_addr(acpi_res, &addr);
> - if (!ACPI_SUCCESS(status))
> - return AE_OK;
> + if (ACPI_FAILURE(acpi_resource_to_address64(acpi_res, &addr)))
> + return AE_OK;
>
> - if (addr.resource_type == ACPI_MEMORY_RANGE) {
> - flags = IORESOURCE_MEM;
> - if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> - flags |= IORESOURCE_PREFETCH;
> - } else if (addr.resource_type == ACPI_IO_RANGE) {
> - flags = IORESOURCE_IO;
> - } else
> - return AE_OK;
> + if (addr.resource_type == ACPI_MEMORY_RANGE &&
> + addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> + r.flags |= IORESOURCE_PREFETCH;
>
> - start = addr.minimum + addr.translation_offset;
> - orig_end = end = addr.maximum + addr.translation_offset;
> + translation_offset = addr.translation_offset;
> + orig_end = r.end;
> + r.start += translation_offset;
> + r.end += translation_offset;
>
> - /* Exclude non-addressable range or non-addressable portion of range */
> - end = min(end, (u64)iomem_resource.end);
> - if (end <= start) {
> - dev_info(&info->bridge->dev,
> - "host bridge window [%#llx-%#llx] "
> - "(ignored, not CPU addressable)\n", start, orig_end);
> - return AE_OK;
> - } else if (orig_end != end) {
> - dev_info(&info->bridge->dev,
> - "host bridge window [%#llx-%#llx] "
> - "([%#llx-%#llx] ignored, not CPU addressable)\n",
> - start, orig_end, end + 1, orig_end);
> + /* Exclude non-addressable range or non-addressable portion of
> range */
> + r.end = min(r.end, iomem_resource.end);
> + if (r.end <= r.start) {
> + dev_info(&info->bridge->dev,
> + "host bridge window [%#llx-%#llx] (ignored, not
> CPU addressable)\n",
> + r.start, orig_end);
> + return AE_OK;
> + } else if (orig_end != r.end) {
> + dev_info(&info->bridge->dev,
> + "host bridge window [%#llx-%#llx]
> ([%#llx-%#llx] ignored, not CPU addressable)\n",
> + r.start, orig_end, r.end + 1, orig_end);
> + }
I see the warnings below on 32-bit, those resource_size_t things on
32-bit are u32 through the phys_addr_t typedef:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
typedef phys_addr_t resource_size_t;
---
arch/x86/pci/acpi.c: In function ‘setup_resource’:
arch/x86/pci/acpi.c:271:4: warning: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 3 has type ‘resource_size_t’ [-Wformat=]
dev_info(&info->bridge->dev,
^
arch/x86/pci/acpi.c:276:4: warning: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 3 has type ‘re
