Re: [PATCH] PCI: Remove not needed check in disable aspm link

["Jiang Liu (Gerry)" <jiang.liu@huawei.com>]

Hi Bjorn,
     I'm working on several acpiphp related bugfixes, and feel some
are materials for 3.10 too. Actually we have identified four bugs
related to dock station support on Sony VAIO VPCZ23A4R laptop.
I will try to send out patchset to address these bugs tonight.
Seems we really need to rethink about acpiphp and pciehp now.
Regards!
Gerry
On 2013/6/13 11:50, Bjorn Helgaas wrote:
> On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>> current code from acpi_pci_root_add we have
>>>>    1. pci_acpi_scan_root
>>>>           ==> pci devices enumeration and bus scanning.
>>>>               ==> pci_alloc_child_bus
>>>>                   ==> pcibios_add_bus
>>>>                       ==> acpi_pci_add_bus
>>>>                           ==> acpiphp_enumerate_slots
>>>>                               ==> ...==> register_slot
>>>>                                    ==> device_is_managed_by_native_pciehp
>>>>                                          ==> check osc_set with
>>>> OSC_PCI_EXPRESS_NATIVE_HP_CONTROL
>>>>     2. _OSC set request
>>>>
>>>> so we always have acpiphp hotplug slot registered at first.
>>>>
>>>> so either we need to
>>>> A. revert reverting about _OSC
>>>> B. move pcibios_add_bus down to pci_bus_add_devices()
>>>>      as acpiphp and apci pci slot driver are some kind of drivers for pci_bus
>>>> C. A+B
>>>
>>> It doesn't surprise me at all that there are problems in the _OSC code
>>> and the acpiphp/pciehp interaction.  That whole area is a complete
>>> disaster.  It'd really be nice if somebody stepped up and reworked it
>>> so it makes sense.
>>>
>>> But this report is useless to me.  I don't have time to work out what
>>> the problem is and how it affects users and come up with a fix.
>>
>> effects: without fix the problem, user can not use pcie native hotplug
>> if their system's firmware support acpihp and pciehp.
>> And make it worse, that acpiphp have to be built-in, so they have no
>> way to blacklist acpiphp in config.
>>
>>>
>>> My advice is to simplify the path first, and worry about fixing the
>>> bug afterwards.  We've already done several iterations of fiddling
>>> with things, and I think all we're doing is playing "whack-a-mole" and
>>> pushing the bugs around from one place to another.
>>
>> We need to address regression at first.
>> my suggestion is : revert the reverting and apply my -v3 version that will fix
>> regression that Roman Yepishev met.
>>
>> please check attached two patches, hope it could save your some time.
>
> OK, you're right.  It's not reasonable to do anything more than a
> minimal fix when we're at -rc5.
>
> Sigh.  I'll spend tomorrow trying to understand your patches and write
> changelogs for you.
>
> I think you're saying that in systems that support both acpiphp and
> pciehp, we should be using pciehp, but we currently use acpiphp.  If
> so, that's certainly a bug.  How serious is it?  Is it a disaster if
> we use acpiphp until we can resolve this cleanly?  Are there a lot of
> systems that claim to support acpiphp but it doesn't actually work?
>
> Bjorn
>
> .
>