Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965345AbaLLIqf (ORCPT ); Fri, 12 Dec 2014 03:46:35 -0500 Received: from mga01.intel.com ([192.55.52.88]:17287 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933349AbaLLIqe (ORCPT ); Fri, 12 Dec 2014 03:46:34 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,561,1413270000"; d="scan'208";a="646543957" Message-ID: <548AAB67.9050005@linux.intel.com> Date: Fri, 12 Dec 2014 16:46:31 +0800 From: Jiang Liu Organization: Intel User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Thomas Gleixner , Yinghai Lu CC: LKML , the arch/x86 maintainers , Bjorn Helgaas , "Rafael J. Wysocki" , Borislav Petkov Subject: Re: [patch 4/4] acpi: ioapic: Respect the resource flags References: <20141211191853.613107396@linutronix.de> <20141211193112.813391696@linutronix.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2014/12/12 15:53, Thomas Gleixner wrote: > On Thu, 11 Dec 2014, Yinghai Lu wrote: >> On Thu, Dec 11, 2014 at 11:48 AM, Thomas Gleixner wrote: >>> +static inline bool is_valid_mem_resource(struct resource *res) >>> +{ >>> + return !(res->flags & IORESOURCE_DISABLED) && >>> + (res->flags & IORESOURCE_MEM); >>> +} >>> + >> There is minor problem about mem pref handling, original code will ignore them. > > Bah. I missed that in that well documented function... > >> with this patch will let it follow through. >> >> should change is_valid_mem_resource to is_valid_mem_nonpref_resource()... >> >> +static inline bool is_valid_mem_nonpref_resource(struct resource *res) >> { >> return !(res->flags & IORESOURCE_DISABLED) && >> - (res->flags & IORESOURCE_MEM); >> + (res->flags & IORESOURCE_MEM) && >> + !(res->flags & IORESOURCE_PREFETCH); >> } > > Unfortunately that does not help, because nothing sets the > IORESOURCE_PREFETCH flag. Will fix it proper. > > I still have no explanation why the translation offset needs to be > applied here. Hi Thomas, I have read related section in ACPI spec, seems the addition of translation_offset is redundant here. Quotation from ACPI spec 5a, 6.4.3.5.1 For bridges that translate addresses across the bridge, this is the offset that must be added to the address on the secondary side to obtain the address on the primary side. Non-bridge devices must list 0 for all Address Translation offset bits. Quotation from ACPI spec 5, 9.17 I/O APIC Device: It must also contain a _CRS object that reports the base address of the I/O APIC device. The _CRS object is required to contain only one resource, a memory resource pointing to the I/O APIC register base. IO APIC is not a bridge, so translation_offset should always be zero. Thanks! Gerry > > Thanks, > > tglx > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/