On Wednesday, June 12, 2013 10:47:08 PM Yinghai Lu wrote: > On Wed, Jun 12, 2013 at 8:50 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > > On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > > > > 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? > > No sure. To make acpiphp would need more expertise in bios. > Normally BIOS vendor would have half done work there, and will need > OEM or system vendor have someone to make it work .... > You would not want to read asl code in DSDT to help them out. > That is not something that we can control. However, pciehp may simply not work by itself on those systems. It's pretty much like saying "Oh, _CRS may be screwed up, so let's just ignore it", which isn't overly smart. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
