Message-ID: <CAJZ5v0jtv8pB4EJHVLpsMfeqi7stnH1vvANbhFSTKiaU2RB1Ug@mail.gmail.com>
Date:	Fri, 10 Apr 2015 02:28:48 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>, Len Brown <lenb@...nel.org>,
	Lv Zheng <lv.zheng@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

On Fri, Apr 10, 2015 at 12:37 AM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Thursday, April 09, 2015 05:00:08 PM Bjorn Helgaas wrote:
>> On Thu, Apr 9, 2015 at 4:37 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> > On Thursday, April 09, 2015 10:50:02 AM Jiang Liu wrote:
>> >> On 2015/4/9 7:44, Rafael J. Wysocki wrote:
>> >> > On Wednesday, April 08, 2015 01:48:46 PM Jiang Liu wrote:
>> >> >> On 2015/4/7 8:28, Rafael J. Wysocki wrote:
>> >> >>> On Friday, April 03, 2015 10:04:11 PM Bjorn Helgaas wrote:
>> >> >>>> Hi Jiang,
>> >> >> <snip>
>> >> >>>>> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
>> >> >>>>> host bridge and IOAPIC driver, so it shouldn't affect other drivers.
>> >> >>>>
>> >> >>>> We should assume it will eventually be used for all ACPI devices,
>> >> >>>> shouldn't we?
>> >> >>>
>> >> >>> I'm not sure about that, really.  In fact, I'd restrict its use to devices
>> >> >>> types that actually can "produce" resources (ie. do not require the resources
>> >> >>> to be provided by their ancestors or to be available from a global pool).
>> >> >>>
>> >> >>> Otherwise we're pretty much guaranteed to get into trouble.
>> >> >>>
>> >> >>> And all of the above rules need to be documented in the kernel source tree
>> >> >>> or people will get confused.
>> >> >> Hi Rafael,
>> >> >>     How about following comments for acpi_dev_filter_resource_type()?
>> >> >> Thanks!
>> >> >> Gerry
>> >> >> --------------------------------------------------------------------
>> >> >> /**
>> >> >>  * According to ACPI specifications, Consumer/Producer flag in ACPI resource
>> >> >>  * descriptor means:
>> >> >>  *      1(CONSUMER): This device consumes this resource
>> >> >>  *      0(PRODUCER): This device produces and consumes this resource
>> >> >>  * But for ACPI PCI host bridge, it is interpreted in another way:
>> >> >
>> >> > So first of all, this leads to a question: Why is it interpreted for ACPI PCI
>> >> > host bridges differently?
>> >> >
>> >> > Is it something we've figured out from experience, or is there a standard
>> >> > mandating that?
>> >> Hi Rafael,
>> >>       I think we got this knowledge by experiences. PCI FW spec only
>> >> states _CRS reports resources assigned to the host bridge by firmware.
>> >> There's no statement about whether the resource is consumed by host
>> >> bridge itself or provided to it's child bus/devices. On x86/IA64 side,
>> >> the main resource consumed by PCI host bridge is IOPORT 0xCF8-0xCFF,
>> >> but not sure about ARM64 side. So how about:
>> >
>> > This:
>> >
>> >> PCI Firmware specification states that _CRS reports resources
>> >> assigned to the host bridge, but there's no way to tell whether
>> >> the resource is consumed by host bridge itself or provided to
>> >> its child bus/devices.
>> >
>> > looks OK to me, but I'd replace the below with something like:
>> >
>> > "However, experience shows, that in the PCI host bridge case firmware writers
>> >  expect the resource to be provided to devices on the bus (below the bridge) for
>> >  consumption entirely if its Consumer/Producer flag is clear.  That expectation
>> >  is reflected by the code in this routine as follows:".
>>
>> What a mess.  The spec is regrettably lacking in Consumer/Producer
>> specifics.  But I don't see what's confusing about the descriptors
>> that have Consumer/Producer bits.
>>
>> QWord, DWord, and Word descriptors don't seem to have a
>> Consumer/Producer bit, but they do contain _TRA, so they must be
>> intended for bridge windows.  Can they also be used for device
>> registers?  I don't know.
>>
>> The Extended Address descriptor has a Consumer/Producer bit, and I
>> would interpret the spec to mean that if the flag is clear (the device
>> produces and consumes this resource), the resource is available on the
>> bus below the bridge, i.e., the bridge consumes the resource on its
>> upstream side and produces it on its downstream side.
>
> OK, that makes sense for bridges.
>
>> If the bit were
>> set (the device only consumes the resource), I would expect that to
>> mean the descriptor is for bridge registers like 0xcf8/0xcfc that
>> never appear on the downstream side.
>
> That part is clear.  What is not clear is whether or not we can *always*
> expect the resources with Consumer/Producer *clear* to be produced on the
> downstram side.  That appears to be the case for host bridges if my
> understanding of things is correct, but is it the case in general?
>
>> Maybe I'm reading the spec too naively, but this doesn't seem a matter
>> of experience.
>
> Well, the specification is not clear enough in that respect, at least as
> far as I can say, or maybe it is, but then does firmware always follow that
> interpretation?

So I guess I'd like to propose to go back to the 3.19 behavior for PCI host
bridges and then to handle the IOAPIC as a separate case.

We can think about consolidating the two later.

Any objections to doing that?

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

Powered by blists - more mailing lists