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

[Jiang Liu (Gerry)]

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@xxxxxxxxxx> wrote:
> > On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> 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
>
> .


--
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/