From patchwork Fri Mar 4 07:30:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chen Yu X-Patchwork-Id: 8499691 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 2D4D0C0553 for ; Fri, 4 Mar 2016 07:30:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2CFA0201F2 for ; Fri, 4 Mar 2016 07:30:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4B287201BC for ; Fri, 4 Mar 2016 07:30:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751090AbcCDHaX (ORCPT ); Fri, 4 Mar 2016 02:30:23 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:33938 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751486AbcCDHaW (ORCPT ); Fri, 4 Mar 2016 02:30:22 -0500 Received: by mail-wm0-f50.google.com with SMTP id p65so8303727wmp.1 for ; Thu, 03 Mar 2016 23:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jS+8BMuB2nLor6q7viSG6I69SUkD0qPfyLM5nR3OELk=; b=tZuMbQPLDy25esxnXGW//oG7hYAIVPQaPatHbprsNJkRfODnX7VIWXP74OsX6B+q1r Ez0cxqiosY1S/swVVSMvbBI5qBJ0xTgd5qM/vSQ35BcN04sQNWEbERsBDYd8GuQ5wWnQ mlDpGlwwA0NHWSuy5njR0KGk9OxUBnYYo3f29ziKpGOeqNE7OHF7Wh1DbFHQjSVHgo+T pJtFKrtStTnY+fdy7zljSivAmjHw5DyYYh9OTBX7csf7SHfDTuF2RmwUzU70F3+wux6C 3YaCgb5M2ji/+Zq30TPdotjq7WYBSyHDd+T4HbTxyPMXAzT1jcX0tpQlQQDoySRNQQPF Jkhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jS+8BMuB2nLor6q7viSG6I69SUkD0qPfyLM5nR3OELk=; b=DuEK2MAOUTZtKqK1Bz1fdi+FtY09W0Lh3sJEdrBxuN8UY6+Og9T+Gr4vvzxl1/nUGs 7xsaQ+kgrEVAF8VafLebmhJXLVNqECcBBZuKDfEkzzhs1Q0rfn11TGn+BvxQZyAen5Yk elDWqVngJLkOxObaDrQHM3uMrhzkgBzxEp08s91nBkDSj9Ynsuv4DibL4AGIm6wIyglc sb7QP787ju/Ml5Eg1ktYvWz59KKLglDLAsNq1sp5jozqsmLR4EyJ9e86229/Oj9OnV/D m1WdMmlx9dtklcdZY37J0n09U/l81om9S8OsMwMUQsP1jwXg/wc/nHFQW3Ce9L4VtZMq 7gOw== X-Gm-Message-State: AD7BkJL0jl2rZUXHIUU8HoS+xQeNn6aO8oz19+ShXJ/cSxUjqh1KSXhEUeOyJeQBr1OE+NaNjAYXc0b1ih6Kpw== MIME-Version: 1.0 X-Received: by 10.28.132.17 with SMTP id g17mr3512542wmd.63.1457076620782; Thu, 03 Mar 2016 23:30:20 -0800 (PST) Received: by 10.194.235.129 with HTTP; Thu, 3 Mar 2016 23:30:20 -0800 (PST) In-Reply-To: References: <87h9gpp5rt.fsf@gmail.com> <87a8mhotmk.fsf@gmail.com> <8737s8uj49.fsf@gmail.com> Date: Fri, 4 Mar 2016 15:30:20 +0800 Message-ID: Subject: Re: STI problem and workaround for Dell XPS 13 (Skylake, 2016) / Broadcom BCM4350 From: yu chen To: Tamas Papp Cc: linux-pm@vger.kernel.org Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Mar 4, 2016 at 9:41 AM, yu chen wrote: > On Thu, Mar 3, 2016 at 3:16 PM, Tamas Papp 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 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 */