Re: [patch 4/4] acpi: ioapic: Respect the resource flags

From: Thomas Gleixner
Date: Fri Dec 12 2014 - 06:43:38 EST


On Fri, 12 Dec 2014, Jiang Liu wrote:
> 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 <tglx@xxxxxxxxxxxxx> 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.

Right and we really need a proper interface for this on the acpi side,
so we can avoid all that dance in the usage sites.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/