* STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
@ 2016-03-02 9:51 Tamas Papp
2016-03-02 13:08 ` yu chen
0 siblings, 1 reply; 9+ messages in thread
From: Tamas Papp @ 2016-03-02 9:51 UTC (permalink / raw)
To: linux-pm
Hi,
I have a Dell XPS 13 (Skylake, 2016) and wanted to get STI working, so I
followed the instructions at [1]. I found that the Broadcom wireless
chip is waking the machine up from STI / freeze.
A workaround is
INTERFACE=wlp58s0
ifconfig $INTERFACE down
modprobe -r brcmfmac && echo freeze > /sys/power/state && modprobe brcmfmac
ifconfig $INTERFACE up
I thought I would ask whether I should report this as a bug, and if yes,
where.
Best,
Tamas
[1] https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
Hardware info (lspci -v):
3a:00.0 Network controller: Broadcom Corporation BCM4350 802.11ac Wireless Network Adapter (rev 08)
Subsystem: Dell BCM4350 802.11ac Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 283
Memory at dc400000 (64-bit, non-prefetchable) [size=32K]
Memory at dc000000 (64-bit, non-prefetchable) [size=4M]
Capabilities: [48] Power Management version 3
Capabilities: [58] MSI: Enable+ Count=1/16 Maskable- 64bit+
Capabilities: [68] Vendor Specific Information: Len=44 <?>
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-28-ff-ff-77-c8-ff
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Capabilities: [1b0] Latency Tolerance Reporting
Capabilities: [220] #15
Capabilities: [240] L1 PM Substates
Kernel driver in use: brcmfmac
Kernel modules: brcmfmac
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-02 9:51 STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350 Tamas Papp
@ 2016-03-02 13:08 ` yu chen
2016-03-02 14:13 ` Tamas Papp
0 siblings, 1 reply; 9+ messages in thread
From: yu chen @ 2016-03-02 13:08 UTC (permalink / raw)
To: Tamas Papp; +Cc: linux-pm
On Wed, Mar 2, 2016 at 5:51 PM, Tamas Papp <tkpapp@gmail.com> wrote:
> Hi,
>
> I have a Dell XPS 13 (Skylake, 2016) and wanted to get STI working, so I
> followed the instructions at [1]. I found that the Broadcom wireless
> chip is waking the machine up from STI / freeze.
>
> A workaround is
>
> INTERFACE=wlp58s0
> ifconfig $INTERFACE down
> modprobe -r brcmfmac && echo freeze > /sys/power/state && modprobe brcmfmac
> ifconfig $INTERFACE up
>
> I thought I would ask whether I should report this as a bug, and if yes,
> where.
>
Some device drivers such as brcmac has the ability to wake the system
up, you can
disable it by echo to /proc/acpi/wakeup IMO.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-02 13:08 ` yu chen
@ 2016-03-02 14:13 ` Tamas Papp
2016-03-02 14:44 ` yu chen
0 siblings, 1 reply; 9+ messages in thread
From: Tamas Papp @ 2016-03-02 14:13 UTC (permalink / raw)
To: yu chen; +Cc: linux-pm
On Wed, Mar 02 2016, yu chen wrote:
> On Wed, Mar 2, 2016 at 5:51 PM, Tamas Papp <tkpapp@gmail.com> wrote:
>> Hi,
>>
>> I have a Dell XPS 13 (Skylake, 2016) and wanted to get STI working, so I
>> followed the instructions at [1]. I found that the Broadcom wireless
>> chip is waking the machine up from STI / freeze.
>>
>> A workaround is
>>
>> INTERFACE=wlp58s0
>> ifconfig $INTERFACE down
>> modprobe -r brcmfmac && echo freeze > /sys/power/state && modprobe brcmfmac
>> ifconfig $INTERFACE up
>>
>> I thought I would ask whether I should report this as a bug, and if yes,
>> where.
>>
> Some device drivers such as brcmac has the ability to wake the system
> up, you can
> disable it by echo to /proc/acpi/wakeup IMO.
That's what I attempted first, but echo to /proc/acpi/wakeup just makes
the entry occur _twice_ -- what am I doing wrong?
root@tamas:~# cat /proc/acpi/wakeup | grep ena
PXSX S4 *enabled pci:0000:3a:00.0
PBTN S3 *enabled platform:PNP0C0C:00
root@tamas:~# echo PXSX > /proc/acpi/wakeup
root@tamas:~# cat /proc/acpi/wakeup | grep ena
PXSX S4 *enabled pci:0000:3c:00.0
PXSX S4 *enabled pci:0000:3a:00.0
PBTN S3 *enabled platform:PNP0C0C:00
root@tamas:~# uname -r
4.5.0-040500rc6-generic
Best,
Tamas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-02 14:13 ` Tamas Papp
@ 2016-03-02 14:44 ` yu chen
2016-03-03 7:16 ` Tamas Papp
0 siblings, 1 reply; 9+ messages in thread
From: yu chen @ 2016-03-02 14:44 UTC (permalink / raw)
To: Tamas Papp; +Cc: linux-pm
On Wed, Mar 2, 2016 at 10:13 PM, Tamas Papp <tkpapp@gmail.com> wrote:
> On Wed, Mar 02 2016, yu chen wrote:
>
>> On Wed, Mar 2, 2016 at 5:51 PM, Tamas Papp <tkpapp@gmail.com> wrote:
>>> Hi,
>>>
>>> I have a Dell XPS 13 (Skylake, 2016) and wanted to get STI working, so I
>>> followed the instructions at [1]. I found that the Broadcom wireless
>>> chip is waking the machine up from STI / freeze.
>>>
>>> A workaround is
>>>
>>> INTERFACE=wlp58s0
>>> ifconfig $INTERFACE down
>>> modprobe -r brcmfmac && echo freeze > /sys/power/state && modprobe brcmfmac
>>> ifconfig $INTERFACE up
>>>
>>> I thought I would ask whether I should report this as a bug, and if yes,
>>> where.
>>>
>> Some device drivers such as brcmac has the ability to wake the system
>> up, you can
>> disable it by echo to /proc/acpi/wakeup IMO.
>
> That's what I attempted first, but echo to /proc/acpi/wakeup just makes
> the entry occur _twice_ -- what am I doing wrong?
>
> root@tamas:~# cat /proc/acpi/wakeup | grep ena
> PXSX S4 *enabled pci:0000:3a:00.0
> PBTN S3 *enabled platform:PNP0C0C:00
> root@tamas:~# echo PXSX > /proc/acpi/wakeup
> root@tamas:~# cat /proc/acpi/wakeup | grep ena
> PXSX S4 *enabled pci:0000:3c:00.0
> PXSX S4 *enabled pci:0000:3a:00.0
> PBTN S3 *enabled platform:PNP0C0C:00
> root@tamas:~# uname -r
> 4.5.0-040500rc6-generic
>
Currently the 0000:3c and 0000:3a might have the same pnp object name PXSX,
unfortunately the 'echo' will find the first math device in the
wakable list, and maybe
0000:3c was probed before 0000:3a, so... maybe this is a weakness.
Maybe you can disabled the wakable feature directly in device sysfs,
for example,
echo 0 > /sys/devices/pci0000:00/0000:3a:00.0/power/wakeup,
you might need to find out where 0000:3a:00.0 is.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-02 14:44 ` yu chen
@ 2016-03-03 7:16 ` Tamas Papp
2016-03-04 1:41 ` yu chen
0 siblings, 1 reply; 9+ messages in thread
From: Tamas Papp @ 2016-03-03 7:16 UTC (permalink / raw)
To: yu chen; +Cc: linux-pm
On Wed, Mar 02 2016, yu chen wrote:
> Currently the 0000:3c and 0000:3a might have the same pnp object name PXSX,
> unfortunately the 'echo' will find the first math device in the
> wakable list, and maybe
> 0000:3c was probed before 0000:3a, so... maybe this is a weakness.
>
> Maybe you can disabled the wakable feature directly in device sysfs,
> for example,
> echo 0 > /sys/devices/pci0000:00/0000:3a:00.0/power/wakeup,
> you might need to find out where 0000:3a:00.0 is.
I tried that, but the module has problems after wakeup. I have to remove
and insert it again with modprobe.
Still, this is an OK workaround, thanks for the help. I still don't know
if I should file this as a bug, and if yes, where.
Best,
Tamas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-03 7:16 ` Tamas Papp
@ 2016-03-04 1:41 ` yu chen
2016-03-04 7:30 ` yu chen
2016-03-04 7:36 ` Tamas Papp
0 siblings, 2 replies; 9+ messages in thread
From: yu chen @ 2016-03-04 1:41 UTC (permalink / raw)
To: Tamas Papp; +Cc: linux-pm
On Thu, Mar 3, 2016 at 3:16 PM, Tamas Papp <tkpapp@gmail.com> wrote:
> On Wed, Mar 02 2016, yu chen wrote:
>
>> Currently the 0000:3c and 0000:3a might have the same pnp object name PXSX,
>> unfortunately the 'echo' will find the first math device in the
>> wakable list, and maybe
>> 0000:3c was probed before 0000:3a, so... maybe this is a weakness.
>>
>> Maybe you can disabled the wakable feature directly in device sysfs,
>> for example,
>> echo 0 > /sys/devices/pci0000:00/0000:3a:00.0/power/wakeup,
>> you might need to find out where 0000:3a:00.0 is.
>
> I tried that, but the module has problems after wakeup. I have to remove
> and insert it again with modprobe.
>
> Still, this is an OK workaround, thanks for the help. I still don't know
> if I should file this as a bug, and if yes, where.
>
Does the following fix make sense for you:
cat /proc/acpi/wakeup
PXSX:0 S4 *enabled pci:0000:3a:00.0
then you need to echo PXSX:0 to disable it,
and for 3c, it would be PXSX:1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-04 1:41 ` yu chen
@ 2016-03-04 7:30 ` yu chen
2016-03-04 7:36 ` Tamas Papp
1 sibling, 0 replies; 9+ messages in thread
From: yu chen @ 2016-03-04 7:30 UTC (permalink / raw)
To: Tamas Papp; +Cc: linux-pm
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On Fri, Mar 4, 2016 at 9:41 AM, yu chen <yu.chen.surf@gmail.com> wrote:
> On Thu, Mar 3, 2016 at 3:16 PM, Tamas Papp <tkpapp@gmail.com> wrote:
>> On Wed, Mar 02 2016, yu chen wrote:
>>
>>> Currently the 0000:3c and 0000:3a might have the same pnp object name PXSX,
>>> unfortunately the 'echo' will find the first math device in the
>>> wakable list, and maybe
>>> 0000:3c was probed before 0000:3a, so... maybe this is a weakness.
>>>
>>> Maybe you can disabled the wakable feature directly in device sysfs,
>>> for example,
>>> echo 0 > /sys/devices/pci0000:00/0000:3a:00.0/power/wakeup,
>>> you might need to find out where 0000:3a:00.0 is.
>>
>> I tried that, but the module has problems after wakeup. I have to remove
>> and insert it again with modprobe.
>>
>> Still, this is an OK workaround, thanks for the help. I still don't know
>> if I should file this as a bug, and if yes, where.
>>
> Does the following fix make sense for you:
>
> cat /proc/acpi/wakeup
> PXSX:0 S4 *enabled pci:0000:3a:00.0
> then you need to echo PXSX:0 to disable it,
> and for 3c, it would be PXSX:1
plz find attached the trival patch for it
[-- Attachment #2: fix_wakeup.diff --]
[-- Type: text/plain, Size: 3618 bytes --]
Index: linux_for_test/drivers/acpi/proc.c
===================================================================
--- linux_for_test.orig/drivers/acpi/proc.c 2016-03-04 10:59:04.576405039 +0800
+++ linux_for_test/drivers/acpi/proc.c 2016-03-04 12:06:24.368340465 +0800
@@ -33,10 +33,14 @@
if (!dev->wakeup.flags.valid)
continue;
-
- seq_printf(seq, "%s\t S%d\t",
- dev->pnp.bus_id,
- (u32) dev->wakeup.sleep_state);
+ if (dev->pnp.bus_sub_id >= 0)
+ seq_printf(seq, "%s:%d\t S%d\t",
+ dev->pnp.bus_id, dev->pnp.bus_sub_id,
+ (u32) dev->wakeup.sleep_state);
+ else
+ seq_printf(seq, "%s\t S%d\t",
+ dev->pnp.bus_id,
+ (u32) dev->wakeup.sleep_state);
mutex_lock(&dev->physical_node_lock);
@@ -96,15 +100,23 @@
size_t count, loff_t * ppos)
{
struct list_head *node, *next;
- char strbuf[5];
- char str[5] = "";
+ char strbuf[7];
+ char str[7] = "";
+ int sub_id = -1;
+ char *split;
- if (count > 4)
- count = 4;
+ if (count > 6)
+ count = 6;
if (copy_from_user(strbuf, buffer, count))
return -EFAULT;
strbuf[count] = '\0';
+ split = strstr(strbuf, ":");
+ if (split) {
+ *split = '\0';
+ split++;
+ sscanf(split, "%d", &sub_id);
+ }
sscanf(strbuf, "%s", str);
mutex_lock(&acpi_device_lock);
@@ -114,7 +126,8 @@
if (!dev->wakeup.flags.valid)
continue;
- if (!strncmp(dev->pnp.bus_id, str, 4)) {
+ if (!strncmp(dev->pnp.bus_id, str, 4) &&
+ (sub_id == -1 || sub_id == dev->pnp.bus_sub_id)) {
if (device_can_wakeup(&dev->dev)) {
bool enable = !device_may_wakeup(&dev->dev);
device_set_wakeup_enable(&dev->dev, enable);
Index: linux_for_test/drivers/acpi/scan.c
===================================================================
--- linux_for_test.orig/drivers/acpi/scan.c 2016-03-04 10:59:04.576405039 +0800
+++ linux_for_test/drivers/acpi/scan.c 2016-03-04 14:47:08.532186306 +0800
@@ -607,6 +607,34 @@
put_device(&adev->dev);
}
+#define MAX_SAME_NAME 100
+static void _wake_device_add(struct acpi_device *device)
+{
+ struct list_head *node, *next;
+ int max_idx = -1;
+
+ list_for_each_safe(node, next, &acpi_wakeup_device_list) {
+ struct acpi_device *dev =
+ container_of(node, struct acpi_device, wakeup_list);
+
+ if (!dev->wakeup.flags.valid)
+ continue;
+
+ if (!strncmp(dev->pnp.bus_id, device->pnp.bus_id, 4)) {
+ if (dev->pnp.bus_sub_id == -1)
+ dev->pnp.bus_sub_id = 0;
+ if (dev->pnp.bus_sub_id > max_idx)
+ max_idx = dev->pnp.bus_sub_id;
+ }
+ }
+
+ if (max_idx >= MAX_SAME_NAME)
+ pr_err("Too many devices of the same name.\n");
+
+ device->pnp.bus_sub_id = (max_idx >= 0) ? (max_idx + 1) : max_idx;
+ list_add_tail(&device->wakeup_list, &acpi_wakeup_device_list);
+}
+
int acpi_device_add(struct acpi_device *device,
void (*release)(struct device *))
{
@@ -671,7 +699,7 @@
list_add_tail(&device->node, &device->parent->children);
if (device->wakeup.flags.valid)
- list_add_tail(&device->wakeup_list, &acpi_wakeup_device_list);
+ _wake_device_add(device);
mutex_unlock(&acpi_device_lock);
if (device->parent)
Index: linux_for_test/include/acpi/acpi_bus.h
===================================================================
--- linux_for_test.orig/include/acpi/acpi_bus.h 2016-03-04 10:59:04.576405039 +0800
+++ linux_for_test/include/acpi/acpi_bus.h 2016-03-04 12:03:51.064342915 +0800
@@ -241,6 +241,7 @@
struct acpi_device_pnp {
acpi_bus_id bus_id; /* Object name */
+ int bus_sub_id; /* Sub object index */
struct acpi_pnp_type type; /* ID type */
acpi_bus_address bus_address; /* _ADR */
char *unique_id; /* _UID */
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-04 1:41 ` yu chen
2016-03-04 7:30 ` yu chen
@ 2016-03-04 7:36 ` Tamas Papp
2016-03-04 7:49 ` yu chen
1 sibling, 1 reply; 9+ messages in thread
From: Tamas Papp @ 2016-03-04 7:36 UTC (permalink / raw)
To: yu chen; +Cc: linux-pm
On Fri, Mar 04 2016, yu chen wrote:
> On Thu, Mar 3, 2016 at 3:16 PM, Tamas Papp <tkpapp@gmail.com> wrote:
>> On Wed, Mar 02 2016, yu chen wrote:
>>
>>> Currently the 0000:3c and 0000:3a might have the same pnp object name PXSX,
>>> unfortunately the 'echo' will find the first math device in the
>>> wakable list, and maybe
>>> 0000:3c was probed before 0000:3a, so... maybe this is a weakness.
>>>
>>> Maybe you can disabled the wakable feature directly in device sysfs,
>>> for example,
>>> echo 0 > /sys/devices/pci0000:00/0000:3a:00.0/power/wakeup,
>>> you might need to find out where 0000:3a:00.0 is.
>>
>> I tried that, but the module has problems after wakeup. I have to remove
>> and insert it again with modprobe.
>>
>> Still, this is an OK workaround, thanks for the help. I still don't know
>> if I should file this as a bug, and if yes, where.
>>
> Does the following fix make sense for you:
>
> cat /proc/acpi/wakeup
> PXSX:0 S4 *enabled pci:0000:3a:00.0
> then you need to echo PXSX:0 to disable it,
> and for 3c, it would be PXSX:1
Sorry, I am confused --- is this a proposed new syntax for
/proc/acpi/wakeup? I guess this could work. BTW, for kernel 4.4.3, I
don't need any fix (that's what I am using now), it works out of the
box, I just need to fiddle with the broadcom module in 4.5.0-rc6.
Best,
Tamas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350
2016-03-04 7:36 ` Tamas Papp
@ 2016-03-04 7:49 ` yu chen
0 siblings, 0 replies; 9+ messages in thread
From: yu chen @ 2016-03-04 7:49 UTC (permalink / raw)
To: Tamas Papp; +Cc: linux-pm
On Fri, Mar 4, 2016 at 3:36 PM, Tamas Papp <tkpapp@gmail.com> wrote:
> On Fri, Mar 04 2016, yu chen wrote:
>
>> On Thu, Mar 3, 2016 at 3:16 PM, Tamas Papp <tkpapp@gmail.com> wrote:
>>> On Wed, Mar 02 2016, yu chen wrote:
>>>
>>>> Currently the 0000:3c and 0000:3a might have the same pnp object name PXSX,
>>>> unfortunately the 'echo' will find the first math device in the
>>>> wakable list, and maybe
>>>> 0000:3c was probed before 0000:3a, so... maybe this is a weakness.
>>>>
>>>> Maybe you can disabled the wakable feature directly in device sysfs,
>>>> for example,
>>>> echo 0 > /sys/devices/pci0000:00/0000:3a:00.0/power/wakeup,
>>>> you might need to find out where 0000:3a:00.0 is.
>>>
>>> I tried that, but the module has problems after wakeup. I have to remove
>>> and insert it again with modprobe.
>>>
>>> Still, this is an OK workaround, thanks for the help. I still don't know
>>> if I should file this as a bug, and if yes, where.
>>>
>> Does the following fix make sense for you:
>>
>> cat /proc/acpi/wakeup
>> PXSX:0 S4 *enabled pci:0000:3a:00.0
>> then you need to echo PXSX:0 to disable it,
>> and for 3c, it would be PXSX:1
>
> Sorry, I am confused --- is this a proposed new syntax for
> /proc/acpi/wakeup? I guess this could work. BTW, for kernel 4.4.3, I
> don't need any fix (that's what I am using now), it works out of the
> box, I just need to fiddle with the broadcom module in 4.5.0-rc6.
It appends index suffix to their orinal name if there's a conflict.
Maybe in 4.4.3 broadcom is not a wakable by default, although the duplicate
naming problem should always be there.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-03-04 7:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-02 9:51 STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350 Tamas Papp
2016-03-02 13:08 ` yu chen
2016-03-02 14:13 ` Tamas Papp
2016-03-02 14:44 ` yu chen
2016-03-03 7:16 ` Tamas Papp
2016-03-04 1:41 ` yu chen
2016-03-04 7:30 ` yu chen
2016-03-04 7:36 ` Tamas Papp
2016-03-04 7:49 ` yu chen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).