Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4513901ybb; Tue, 14 Apr 2020 08:44:31 -0700 (PDT) X-Google-Smtp-Source: APiQypLwloReuohHGDK9v05/ONuT0YBKuSAkOVbQv1od15UrS9/SSoeYaZ6wjA8Y05NEf32dHNrE X-Received: by 2002:a17:906:e01:: with SMTP id l1mr775244eji.76.1586879071350; Tue, 14 Apr 2020 08:44:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586879071; cv=none; d=google.com; s=arc-20160816; b=eoVFkIp8nfM+e7E9jOqrqKp48g6U5iBJmrP3yHNE+decum27YBkszPOaCj3sumpupi C4ej87BRnPN9Jn94Lp/mfKiHOWR3goB3s/bKzWzLiXdh/e2q7lOTk1jEmKsFW+s7/PO/ qhazoVtY4cJkOaGYagFi80mAusvPKgiUCqs9+peaLAojpI7cb8BsFUASJ96sUbaVW1mP XY+pZlyPwGY7rYgyKuNQz56GDRQfNSKyW55fFPR31QmVkeGs9WwP3iT64GqZho8bl3MJ sM4CiKul60hGTGKvht02JzP6GjlJaxS1U9jD3T4KdOIZkeqqIPQByuk7NAkG/MbOGpgm /GDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=3HuLilv69rC7THF45aYrV+6luk1YKd/SKbIHAdtaS/I=; b=H2GtR9txDvT4HV9Y/C8ZWH29Ef5jMlHftgaRAIxg40odIsxKEuLD4C6r9zgwpixboH nExHrSuJSl/TofbjtzpZAgeM9gW+iZh30EEcrigm5MWoS4zIUe2F/h+EKX6UK+UGu5MC ODZKsdJEAnCzDnF4dSAJz6ItTVmy0CjM7SGiQxt+bBAOWaObSZFo01OaN7YRv1fpRATX QeOeXzjgUAW9mgzIO9TMVSJDkvSo7QvgaY0NZF5UgOwtrTdSTqKnhu6CQ5Aq5Ui56Qg/ ePnFnqgq8mjA27TBxR7xyPLvPp4o/edTvv1YzDQ1fPTkfezwrYDSI5mb/6qOZGGGZzta SR1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TbdltNJ8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e2si8585873edy.55.2020.04.14.08.44.07; Tue, 14 Apr 2020 08:44:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TbdltNJ8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731428AbgDNNWs (ORCPT + 99 others); Tue, 14 Apr 2020 09:22:48 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:40230 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731108AbgDNNUE (ORCPT ); Tue, 14 Apr 2020 09:20:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586870403; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=3HuLilv69rC7THF45aYrV+6luk1YKd/SKbIHAdtaS/I=; b=TbdltNJ8jZQXuJwsQZdr6sZi8I/S+6zwcgoPxr6JDDhUIb2uNfSjSVzudXMbYwWmv9/7tB iKol0fvSq0C6MYSILN7S/LY5sJMw06DmtRpoAUVLXCt4oN4UY1tgErNKfhce9sPD1aDlJQ SNZzhEgdUhaMXaG8nhmYuIxwjmDM7/g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-179-s7QuTE3nMBK2FMGTYY2epg-1; Tue, 14 Apr 2020 09:19:58 -0400 X-MC-Unique: s7QuTE3nMBK2FMGTYY2epg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E38B51B2C98A; Tue, 14 Apr 2020 13:19:56 +0000 (UTC) Received: from x1.localdomain.com (ovpn-114-21.ams2.redhat.com [10.36.114.21]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4DA489F9A4; Tue, 14 Apr 2020 13:19:55 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Darren Hart , Andy Shevchenko Cc: Hans de Goede , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Mikityanskiy , "5 . 3+" Subject: [PATCH v2] platform/x86: intel_int0002_vgpio: Only bind to the INT0002 dev when using s2idle Date: Tue, 14 Apr 2020 15:19:53 +0200 Message-Id: <20200414131953.131533-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") stopped passing irq_set_wake requests on to the parents IRQ because this was breaking suspend (causing immediate wakeups) on an Asus E202SA. This workaround for this issue is mostly fine, on most Cherry Trail devices where we need the INT0002 device for wakeups by e.g. USB kbds, the parent IRQ is shared with the ACPI SCI and that is marked as wakeup anyways. But not on all devices, specifically on a Medion Akoya E1239T there is no SCI at all, and because the irq_set_wake request is not passed on to the parent IRQ, wake up by the builtin USB kbd does not work here. So the workaround for the Asus E202SA immediate wake problem is causing problems elsewhere; and in hindsight it is not the correct fix, the Asus E202SA uses Airmont CPU cores, but this does not mean it is a Cherry Trail based device, Brasswell uses Airmont CPU cores too and this actually is a Braswell device. Most (all?) Braswell devices use classic S3 mode suspend rather then s2idle suspend and in this case directly dealing with PME events as the INT0002 driver does likely is not the best idea, so that this is causing issues is not surprising. Replace the workaround of not passing irq_set_wake requests on to the parents IRQ, by not binding to the INT0002 device when s2idle is not used= . This fixes USB kbd wakeups not working on some Cherry Trail devices, while still avoiding mucking with the wakeup flags on the Asus E202SA (and other Brasswell devices). Cc: Maxim Mikityanskiy Cc: 5.3+ # 5.3+ Fixes: 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement i= rq_set_wake on Bay Trail") Tested-by: Maxim Mikityanskiy Signed-off-by: Hans de Goede --- Changes in v2: - Rebase on top of 5.7-rc1 --- drivers/platform/x86/intel_int0002_vgpio.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/platform/x86/intel_int0002_vgpio.c b/drivers/platfor= m/x86/intel_int0002_vgpio.c index 289c6655d425..30806046b664 100644 --- a/drivers/platform/x86/intel_int0002_vgpio.c +++ b/drivers/platform/x86/intel_int0002_vgpio.c @@ -143,21 +143,9 @@ static struct irq_chip int0002_byt_irqchip =3D { .irq_set_wake =3D int0002_irq_set_wake, }; =20 -static struct irq_chip int0002_cht_irqchip =3D { - .name =3D DRV_NAME, - .irq_ack =3D int0002_irq_ack, - .irq_mask =3D int0002_irq_mask, - .irq_unmask =3D int0002_irq_unmask, - /* - * No set_wake, on CHT the IRQ is typically shared with the ACPI SCI - * and we don't want to mess with the ACPI SCI irq settings. - */ - .flags =3D IRQCHIP_SKIP_SET_WAKE, -}; - static const struct x86_cpu_id int0002_cpu_ids[] =3D { X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT, &int0002_byt_irqchip), - X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT, &int0002_cht_irqchip), + X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT, &int0002_byt_irqchip), {} }; =20 @@ -181,6 +169,10 @@ static int int0002_probe(struct platform_device *pde= v) if (!cpu_id) return -ENODEV; =20 + /* We only need to directly deal with PMEs when using s2idle */ + if (!pm_suspend_default_s2idle()) + return -ENODEV; + irq =3D platform_get_irq(pdev, 0); if (irq < 0) return irq; --=20 2.26.0