| Message ID | 20140211104237.GE18029@intel.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Tuesday, February 11, 2014 12:42:37 PM Mika Westerberg wrote: > On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in > > > the ACPI hotplug code that overlooks this and removes the device on resume? > > > > That is possible. Actually even quite likely, but let's wait for the response > > from Peter. > > Here's a hack that should take the 0xa return value into consideration. It > turned out that this case is even mentioned in the ACPI spec. Looks reasonable. Peter, please check if this one makes a difference for you. > diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c > index e2a783fdb98f..014381b42d86 100644 > --- a/drivers/pci/hotplug/acpiphp_glue.c > +++ b/drivers/pci/hotplug/acpiphp_glue.c > @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot *slot) > return (unsigned int)sta; > } > > +static inline bool device_sta_valid(unsigned long long sta) > +{ > + /* > + * ACPI spec says that _STA may return bit 0 clear with bit 8 set > + * if the device is valid but does not require device driver to be > + * loaded (chapter 6.3.7). > + */ > + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING; > + return (sta & mask) == mask; > +} > + > /** > * trim_stale_devices - remove PCI devices that are not responding. > * @dev: PCI device to start walking the hierarchy from. > @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev) > unsigned long long sta; > > status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); > - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL) > + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta)) > || acpiphp_no_hotplug(handle); > } > if (!alive) { > @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) > mutex_lock(&slot->crit_sect); > if (slot_no_hotplug(slot)) { > ; /* do nothing */ > - } else if (get_slot_status(slot) == ACPI_STA_ALL) { > + } else if (device_sta_valid(get_slot_status(slot))) { > /* remove stale devices if any */ > list_for_each_entry_safe_reverse(dev, tmp, > &bus->devices, bus_list) > >
On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: > On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in > > > the ACPI hotplug code that overlooks this and removes the device on > > > resume? > > > > That is possible. Actually even quite likely, but let's wait for the > > response from Peter. > > Here's a hack that should take the 0xa return value into consideration. It > turned out that this case is even mentioned in the ACPI spec. Tested-by: Peter Wu <lekensteyn@gmail.com> This works, the devices are not lost anymore after resume. dmesg mentions the 04:00.* devices at resume compared to the unpatched kernel: [ 42.650721] PM: Finishing wakeup. [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 42.650874] iwlwifi 0000:05:00.0: no hotplug settings from platform [ 42.650722] Restarting tasks ... done. [ 42.650985] video LNXVIDEO:00: Restoring backlight state [ 42.650988] video LNXVIDEO:01: Restoring backlight state [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported [ 43.128401] jme 0000:04:00.5: irq 50 for MSI/MSI-X [ 43.153005] jme 0000:04:00.5 eth0: Link is down [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 43.154364] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S [ 43.162307] iwlwifi 0000:05:00.0: Radio type=0x1-0x3-0x1 [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 [ 43.276257] xhci_hcd 0000:02:00.0: no hotplug settings from platform [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 [ 43.276355] sdhci-pci 0000:04:00.0: no hotplug settings from platform [ 43.276368] pci 0000:04:00.2: no hotplug settings from platform [ 43.276381] jmb38x_ms 0000:04:00.3: no hotplug settings from platform [ 43.276393] jme 0000:04:00.5: no hotplug settings from platform [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 43.276491] iwlwifi 0000:05:00.0: no hotplug settings from platform [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Rafael, do you want me to test the other patch as well? Peter > diff --git a/drivers/pci/hotplug/acpiphp_glue.c > b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86 > 100644 > --- a/drivers/pci/hotplug/acpiphp_glue.c > +++ b/drivers/pci/hotplug/acpiphp_glue.c > @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot > *slot) return (unsigned int)sta; > } > > +static inline bool device_sta_valid(unsigned long long sta) > +{ > + /* > + * ACPI spec says that _STA may return bit 0 clear with bit 8 set > + * if the device is valid but does not require device driver to be > + * loaded (chapter 6.3.7). > + */ > + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING; > + return (sta & mask) == mask; > +} > + > /** > * trim_stale_devices - remove PCI devices that are not responding. > * @dev: PCI device to start walking the hierarchy from. > @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev) > unsigned long long sta; > > status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); > - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL) > + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta)) > > || acpiphp_no_hotplug(handle); > > } > if (!alive) { > @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge > *bridge) mutex_lock(&slot->crit_sect); > if (slot_no_hotplug(slot)) { > ; /* do nothing */ > - } else if (get_slot_status(slot) == ACPI_STA_ALL) { > + } else if (device_sta_valid(get_slot_status(slot))) { > /* remove stale devices if any */ > list_for_each_entry_safe_reverse(dev, tmp, > &bus->devices, bus_list) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: > On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: > > On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > > > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in > > > > the ACPI hotplug code that overlooks this and removes the device on > > > > resume? > > > > > > That is possible. Actually even quite likely, but let's wait for the > > > response from Peter. > > > > Here's a hack that should take the 0xa return value into consideration. It > > turned out that this case is even mentioned in the ACPI spec. > > Tested-by: Peter Wu <lekensteyn@gmail.com> > > This works, the devices are not lost anymore after resume. dmesg > mentions the 04:00.* devices at resume compared to the unpatched kernel: > > [ 42.650721] PM: Finishing wakeup. > [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 > [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 > [ 42.650874] iwlwifi 0000:05:00.0: no hotplug settings from platform > [ 42.650722] Restarting tasks ... done. > [ 42.650985] video LNXVIDEO:00: Restoring backlight state > [ 42.650988] video LNXVIDEO:01: Restoring backlight state > [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported > [ 43.128401] jme 0000:04:00.5: irq 50 for MSI/MSI-X > [ 43.153005] jme 0000:04:00.5 eth0: Link is down > [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 43.154364] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S > [ 43.162307] iwlwifi 0000:05:00.0: Radio type=0x1-0x3-0x1 > [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 > [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 > [ 43.276257] xhci_hcd 0000:02:00.0: no hotplug settings from platform > [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 > [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 > [ 43.276355] sdhci-pci 0000:04:00.0: no hotplug settings from platform > [ 43.276368] pci 0000:04:00.2: no hotplug settings from platform > [ 43.276381] jmb38x_ms 0000:04:00.3: no hotplug settings from platform > [ 43.276393] jme 0000:04:00.5: no hotplug settings from platform > [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 > [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 > [ 43.276491] iwlwifi 0000:05:00.0: no hotplug settings from platform > [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > > Rafael, do you want me to test the other patch as well? No, thanks! Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. Thanks! > > diff --git a/drivers/pci/hotplug/acpiphp_glue.c > > b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86 > > 100644 > > --- a/drivers/pci/hotplug/acpiphp_glue.c > > +++ b/drivers/pci/hotplug/acpiphp_glue.c > > @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot > > *slot) return (unsigned int)sta; > > } > > > > +static inline bool device_sta_valid(unsigned long long sta) > > +{ > > + /* > > + * ACPI spec says that _STA may return bit 0 clear with bit 8 set > > + * if the device is valid but does not require device driver to be > > + * loaded (chapter 6.3.7). > > + */ > > + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING; > > + return (sta & mask) == mask; > > +} > > + > > /** > > * trim_stale_devices - remove PCI devices that are not responding. > > * @dev: PCI device to start walking the hierarchy from. > > @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev) > > unsigned long long sta; > > > > status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); > > - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL) > > + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta)) > > > > || acpiphp_no_hotplug(handle); > > > > } > > if (!alive) { > > @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge > > *bridge) mutex_lock(&slot->crit_sect); > > if (slot_no_hotplug(slot)) { > > ; /* do nothing */ > > - } else if (get_slot_status(slot) == ACPI_STA_ALL) { > > + } else if (device_sta_valid(get_slot_status(slot))) { > > /* remove stale devices if any */ > > list_for_each_entry_safe_reverse(dev, tmp, > > &bus->devices, bus_list) >
On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: > On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: >> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: >>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: >>>>> _STA() returns 0x0A instead of 0x0F. Could there be something missing in >>>>> the ACPI hotplug code that overlooks this and removes the device on >>>>> resume? >>>> >>>> That is possible. Actually even quite likely, but let's wait for the >>>> response from Peter. >>> >>> Here's a hack that should take the 0xa return value into consideration. It >>> turned out that this case is even mentioned in the ACPI spec. >> >> Tested-by: Peter Wu <lekensteyn@gmail.com> >> >> This works, the devices are not lost anymore after resume. dmesg >> mentions the 04:00.* devices at resume compared to the unpatched kernel: >> >> [ 42.650721] PM: Finishing wakeup. >> [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 >> [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 >> [ 42.650874] iwlwifi 0000:05:00.0: no hotplug settings from platform >> [ 42.650722] Restarting tasks ... done. >> [ 42.650985] video LNXVIDEO:00: Restoring backlight state >> [ 42.650988] video LNXVIDEO:01: Restoring backlight state >> [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported >> [ 43.128401] jme 0000:04:00.5: irq 50 for MSI/MSI-X >> [ 43.153005] jme 0000:04:00.5 eth0: Link is down >> [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready >> [ 43.154364] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S >> [ 43.162307] iwlwifi 0000:05:00.0: Radio type=0x1-0x3-0x1 >> [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 >> [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 >> [ 43.276257] xhci_hcd 0000:02:00.0: no hotplug settings from platform >> [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 >> [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 >> [ 43.276355] sdhci-pci 0000:04:00.0: no hotplug settings from platform >> [ 43.276368] pci 0000:04:00.2: no hotplug settings from platform >> [ 43.276381] jmb38x_ms 0000:04:00.3: no hotplug settings from platform >> [ 43.276393] jme 0000:04:00.5: no hotplug settings from platform >> [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 >> [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 >> [ 43.276491] iwlwifi 0000:05:00.0: no hotplug settings from platform >> [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready >> >> Rafael, do you want me to test the other patch as well? > > No, thanks! > > Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. > Thanks guys for solving this issue ! Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as well ? -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 12, 2014 at 12:58:07AM +0100, Rafael J. Wysocki wrote:
> Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14.
Thanks Rafael.
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, February 12, 2014 08:44:13 AM Francis Moreau wrote: > On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: > > On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: > >> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: > >>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > >>>>> _STA() returns 0x0A instead of 0x0F. Could there be something missing in > >>>>> the ACPI hotplug code that overlooks this and removes the device on > >>>>> resume? > >>>> > >>>> That is possible. Actually even quite likely, but let's wait for the > >>>> response from Peter. > >>> > >>> Here's a hack that should take the 0xa return value into consideration. It > >>> turned out that this case is even mentioned in the ACPI spec. > >> > >> Tested-by: Peter Wu <lekensteyn@gmail.com> > >> > >> This works, the devices are not lost anymore after resume. dmesg > >> mentions the 04:00.* devices at resume compared to the unpatched kernel: > >> > >> [ 42.650721] PM: Finishing wakeup. > >> [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 > >> [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 > >> [ 42.650874] iwlwifi 0000:05:00.0: no hotplug settings from platform > >> [ 42.650722] Restarting tasks ... done. > >> [ 42.650985] video LNXVIDEO:00: Restoring backlight state > >> [ 42.650988] video LNXVIDEO:01: Restoring backlight state > >> [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported > >> [ 43.128401] jme 0000:04:00.5: irq 50 for MSI/MSI-X > >> [ 43.153005] jme 0000:04:00.5 eth0: Link is down > >> [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > >> [ 43.154364] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S > >> [ 43.162307] iwlwifi 0000:05:00.0: Radio type=0x1-0x3-0x1 > >> [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 > >> [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 > >> [ 43.276257] xhci_hcd 0000:02:00.0: no hotplug settings from platform > >> [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 > >> [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 > >> [ 43.276355] sdhci-pci 0000:04:00.0: no hotplug settings from platform > >> [ 43.276368] pci 0000:04:00.2: no hotplug settings from platform > >> [ 43.276381] jmb38x_ms 0000:04:00.3: no hotplug settings from platform > >> [ 43.276393] jme 0000:04:00.5: no hotplug settings from platform > >> [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 > >> [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 > >> [ 43.276491] iwlwifi 0000:05:00.0: no hotplug settings from platform > >> [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > >> > >> Rafael, do you want me to test the other patch as well? > > > > No, thanks! > > > > Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. > > > > Thanks guys for solving this issue ! > > Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as > well ? Yes, I have marked it for stable. Thanks!
Le mer. 12 févr. 2014 15:04:28 CET, Rafael J. Wysocki a écrit : >>> Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. >>> >> >> Thanks guys for solving this issue ! >> >> Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as >> well ? > > Yes, I have marked it for stable. Thanks a lot for dealing with this! Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot *slot) return (unsigned int)sta; } +static inline bool device_sta_valid(unsigned long long sta) +{ + /* + * ACPI spec says that _STA may return bit 0 clear with bit 8 set + * if the device is valid but does not require device driver to be + * loaded (chapter 6.3.7). + */ + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING; + return (sta & mask) == mask; +} + /** * trim_stale_devices - remove PCI devices that are not responding. * @dev: PCI device to start walking the hierarchy from. @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev) unsigned long long sta; status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL) + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta)) || acpiphp_no_hotplug(handle); } if (!alive) { @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) mutex_lock(&slot->crit_sect); if (slot_no_hotplug(slot)) { ; /* do nothing */ - } else if (get_slot_status(slot) == ACPI_STA_ALL) { + } else if (device_sta_valid(get_slot_status(slot))) { /* remove stale devices if any */ list_for_each_entry_safe_reverse(dev, tmp, &bus->devices, bus_list)