From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4593BC4360F for ; Thu, 28 Feb 2019 11:04:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 09D7121850 for ; Thu, 28 Feb 2019 11:04:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551351842; bh=6bRHgTEgv8vwIe/PfPN0wn3OEqBloKfzoEbKTe5GSpQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=Xum1T1l/Vabs5TbqX1u8NOccScFiWuNaAnPj7GdMMdaxnNHb+bntC4UEhC5sFdYOW lXJGMxGX2npIYBxcZRYLfNLK5YcLx4BRuWMMU4ol2eV5df/878OfWEesEvHupUgsDT v4UZdt0LPQ2qKMzKnINFEANZs0nk//BMX6wo7ZhY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732443AbfB1LDz (ORCPT ); Thu, 28 Feb 2019 06:03:55 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:33320 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731883AbfB1LDv (ORCPT ); Thu, 28 Feb 2019 06:03:51 -0500 Received: by mail-ot1-f66.google.com with SMTP id q24so17318950otk.0; Thu, 28 Feb 2019 03:03:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8iWWCNb5ROZNgxIfGX26VTbIpTUj9YLNwK+9gEJRspg=; b=cvtQkuKBh89p/+/xe7+a1AKtE6W2G1dzBP8AdV8f/0G7Q4j/+VPAOkmn8ADXCu/GBn VSc1xeRDTII1j/tjJurahDIqj3sCHshSDLlMDO5v4f2T31G/9pxuaGqcyx2THcWoJP15 J+aAPgGloRGKSW9hbo+2CYQZD95GWV4dapKYH+UjhohSg4dBmVzDs1/nhAAJ1WqHFVPs xmwbvr9nPLjE0+mk7xN4cquNkYE+dk/ba0j32Tj05dY8Ohdf4bHK0eQ5lJcNpRsg8sWU jO1C/Fi0PMNNv/fOQhIQd42s30bD/WilDp6i84dlqCp+kTkbtXnctel+JbRR0sG4ChJ5 PlHQ== X-Gm-Message-State: AHQUAuYRLyV6m2cHvEItGM9R48RhiKyJlxtTw6nxBEUqxT5dzrQSzGgz KIBkST5lMduUOb6QPWDxzEPGkiz2M5pPT+khj8E= X-Google-Smtp-Source: AHgI3IY6LMSLvVHee6CRbFFRRyFzxjrV5H+KF7Yh7G3pMnTGukPC2IvVz7x2Lb9zYJwQ9FwOsIpv94l4LoGTjTeHqeQ= X-Received: by 2002:a9d:4e08:: with SMTP id p8mr5018108otf.124.1551351829712; Thu, 28 Feb 2019 03:03:49 -0800 (PST) MIME-Version: 1.0 References: <20190224140426.3267-1-marc.zyngier@arm.com> <20190226232822.GA174696@google.com> <20190227205754.GF174696@google.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 28 Feb 2019 12:03:38 +0100 Message-ID: Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes To: Brian Norris Cc: "Rafael J. Wysocki" , Ard Biesheuvel , Marc Zyngier , Ganapathi Bhat , Jeffy Chen , Heiko Stuebner , Devicetree List , Xinming Hu , "" , linux-pm , "" , Linux Kernel Mailing List , Amitkumar Karwar , "open list:ARM/Rockchip SoC..." , Nishant Sarmukadam , Rob Herring , "Rafael J. Wysocki" , linux-arm-kernel , Enric Balletbo i Serra , Lorenzo Pieralisi , "David S. Miller" , Kalle Valo , Tony Lindgren , Mark Rutland Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Thu, Feb 28, 2019 at 3:29 AM Brian Norris wrote: > > Hi Rafael, > > On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki wrote: > > On Wed, Feb 27, 2019 at 9:58 PM Brian Norris wrote: > > > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote: > > > > So I'd argue that we should add an optional 'wake-gpio' DT property > > > > instead to the generic PCI device binding, and leave the interrupt > > > > binding and discovery alone. > > > > > > So I think Mark Rutland already shot that one down; it's conceptually an > > > interrupt from the device's perspective. > > Perhaps I shouldn't speak for Mark, but I am basically quoting him off IRC. > > > Which device are you talking about? The one that signals wakeup? If > > so, then I beg to differ. > > Yes, the endpoint device. > > > On ACPI platforms WAKE# is represented as an ACPI GPE that is signaled > > through SCI and handled at a different level (on HW-reduced ACPI it > > actually can be a GPIO interrupt, but it still is handled with the > > help of AML). The driver of the device signaling wakeup need not even > > be aware that WAKE# has been asserted. > > Frankly, ACPI is not relevant to how we represent WAKE# in DT, IMO. I mentioned ACPI as an example of how WAKE# can be handled. > Also, we're talking about the *device*, not the driver. When talking > about Device Tree, that distinction is relevant. I'm not sure what you mean, really. I guess we are talking about information in DT and some of it is consumed by the driver while some of it is consumed by some other pieces of code. > So while the driver need not be aware (and I agree! it only needs to > care about enabling/disabling wake), Not even that. Actually, PME enable is handled by the PCI bus type code. > *something* should be aware, Right. > and the signal that "something" should be receiving is simply "did WAKE > happen"? Right. But it may not be clear which device signaled it, because WAKE# may be shared in general. > That sounds basically like the device is signalling an interrupt to me. Well, consider the native PME here. In there, the device sends an in-band message over the PCIe hierarchy to a root port and the interrupt is signaled from there. There is a PME driver in the kernel that requests that IRQ and handles it (for all ports that can trigger it), but for each port it binds to a separate device (or "service" if you will) that takes care of all PME messages coming from all devices under that port. At an abstract level, WAKE# is expected to be similar AFAICS except that there is a physical signal going from the device(s) (in low-power states) that have detected external activity (wakeup) to an entity that can trigger an interrupt. The original idea in the PCI PM spec regarding WAKE# seems to be to wire up WAKE# from all devices on the bus to one input that will cause an interrupt to trigger when one of them drives WAKE# and whatever handled that interrupt was expected to walk the bus, find the device(s) with PME Status set and put it (or them) into D0 (clearing PME Status in the process). That still is a valid case to consider IMO. However, designers of some boards decided to provide dedicated per-device interrupts for WAKE# and you may regard them as "wakeup IRQs" except that the handling of each of them is the same as for the "global WAKE#" above: if the PME Status of the device is set, put it into D0 etc. That part belongs to the PCI bus type layer IMO. Of course, because nothing is easy and simple, there is a third case in which one WAKE# line (and interrupt) can be shared by a subset of devices on the bus and there are multiple (say two or three) subsets. > Maybe this goes back to some confusion we had elsewhere: what is the > meaning of "interrupt" in device tree? Maybe. > > > We just need to figure out a good way of representing it that doesn't stomp on the existing INTx > > > definitions. > > > > WAKE# is a signal that is converted into an interrupt, but that > > interrupt may arrive at some place your driver has nothing to do with. > > I could agree with that, perhaps. But that's also what Device Tree is > all about, really. We describe the relation between devices. So some > other handles events that are triggered by , so we use a > phandle to relate to . So you have a PCI endpoint on the one hand and the "wakeup serivce" device on the other. > > It generally doesn't make sense to represent it as an interrupt for > > the target device. > > What would you suggest then? I'm not clearly understanding how you > think we should (a) describe (in DT) and (b) implement this WAKE# > handling. I would introduce a "wakeup service" concept (along the lines of the native PME) and make it request all interrupts associated with WAKE#. In the case when the WAKE# interrupts are dedicated per-device, it would be good to avoid walking the bus and use some "wakeup-IRQ-to-device" mapping if available. But as I said above, IMO the *handling* of all WAKE# interrupts belongs to the PCI bus type as it is the same for all PCI devices. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes Date: Thu, 28 Feb 2019 12:03:38 +0100 Message-ID: References: <20190224140426.3267-1-marc.zyngier@arm.com> <20190226232822.GA174696@google.com> <20190227205754.GF174696@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Brian Norris Cc: "Rafael J. Wysocki" , Ard Biesheuvel , Marc Zyngier , Ganapathi Bhat , Jeffy Chen , Heiko Stuebner , Devicetree List , Xinming Hu , "" , linux-pm , "" , Linux Kernel Mailing List , Amitkumar Karwar , "open list:ARM/Rockchip SoC..." , Nishant Sarmukadam , Rob Herring , "Rafael J. Wysocki" List-Id: devicetree@vger.kernel.org On Thu, Feb 28, 2019 at 3:29 AM Brian Norris wrote: > > Hi Rafael, > > On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki wrote: > > On Wed, Feb 27, 2019 at 9:58 PM Brian Norris wrote: > > > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote: > > > > So I'd argue that we should add an optional 'wake-gpio' DT property > > > > instead to the generic PCI device binding, and leave the interrupt > > > > binding and discovery alone. > > > > > > So I think Mark Rutland already shot that one down; it's conceptually an > > > interrupt from the device's perspective. > > Perhaps I shouldn't speak for Mark, but I am basically quoting him off IRC. > > > Which device are you talking about? The one that signals wakeup? If > > so, then I beg to differ. > > Yes, the endpoint device. > > > On ACPI platforms WAKE# is represented as an ACPI GPE that is signaled > > through SCI and handled at a different level (on HW-reduced ACPI it > > actually can be a GPIO interrupt, but it still is handled with the > > help of AML). The driver of the device signaling wakeup need not even > > be aware that WAKE# has been asserted. > > Frankly, ACPI is not relevant to how we represent WAKE# in DT, IMO. I mentioned ACPI as an example of how WAKE# can be handled. > Also, we're talking about the *device*, not the driver. When talking > about Device Tree, that distinction is relevant. I'm not sure what you mean, really. I guess we are talking about information in DT and some of it is consumed by the driver while some of it is consumed by some other pieces of code. > So while the driver need not be aware (and I agree! it only needs to > care about enabling/disabling wake), Not even that. Actually, PME enable is handled by the PCI bus type code. > *something* should be aware, Right. > and the signal that "something" should be receiving is simply "did WAKE > happen"? Right. But it may not be clear which device signaled it, because WAKE# may be shared in general. > That sounds basically like the device is signalling an interrupt to me. Well, consider the native PME here. In there, the device sends an in-band message over the PCIe hierarchy to a root port and the interrupt is signaled from there. There is a PME driver in the kernel that requests that IRQ and handles it (for all ports that can trigger it), but for each port it binds to a separate device (or "service" if you will) that takes care of all PME messages coming from all devices under that port. At an abstract level, WAKE# is expected to be similar AFAICS except that there is a physical signal going from the device(s) (in low-power states) that have detected external activity (wakeup) to an entity that can trigger an interrupt. The original idea in the PCI PM spec regarding WAKE# seems to be to wire up WAKE# from all devices on the bus to one input that will cause an interrupt to trigger when one of them drives WAKE# and whatever handled that interrupt was expected to walk the bus, find the device(s) with PME Status set and put it (or them) into D0 (clearing PME Status in the process). That still is a valid case to consider IMO. However, designers of some boards decided to provide dedicated per-device interrupts for WAKE# and you may regard them as "wakeup IRQs" except that the handling of each of them is the same as for the "global WAKE#" above: if the PME Status of the device is set, put it into D0 etc. That part belongs to the PCI bus type layer IMO. Of course, because nothing is easy and simple, there is a third case in which one WAKE# line (and interrupt) can be shared by a subset of devices on the bus and there are multiple (say two or three) subsets. > Maybe this goes back to some confusion we had elsewhere: what is the > meaning of "interrupt" in device tree? Maybe. > > > We just need to figure out a good way of representing it that doesn't stomp on the existing INTx > > > definitions. > > > > WAKE# is a signal that is converted into an interrupt, but that > > interrupt may arrive at some place your driver has nothing to do with. > > I could agree with that, perhaps. But that's also what Device Tree is > all about, really. We describe the relation between devices. So some > other handles events that are triggered by , so we use a > phandle to relate to . So you have a PCI endpoint on the one hand and the "wakeup serivce" device on the other. > > It generally doesn't make sense to represent it as an interrupt for > > the target device. > > What would you suggest then? I'm not clearly understanding how you > think we should (a) describe (in DT) and (b) implement this WAKE# > handling. I would introduce a "wakeup service" concept (along the lines of the native PME) and make it request all interrupts associated with WAKE#. In the case when the WAKE# interrupts are dedicated per-device, it would be good to avoid walking the bus and use some "wakeup-IRQ-to-device" mapping if available. But as I said above, IMO the *handling* of all WAKE# interrupts belongs to the PCI bus type as it is the same for all PCI devices. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE8B8C43381 for ; Thu, 28 Feb 2019 11:04:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C14A21850 for ; Thu, 28 Feb 2019 11:04:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lewQX12t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C14A21850 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6ltPfFrfyTDLF2N+NrP8Ibtw5HRcam2OuIBGqp/xOhc=; b=lewQX12tUhrYfj pFU+4UUH66mkQ6Rv5QItt9e8DGbEslAXJycRkqQMz134k4ebMfQtLJ9GgV0X3tk/cJHsyvSZoxEIN 3A6GqAww0+RTm+VN/5W6my8QPDSFUpJHzZhBkKUcaNacgthojQQISCuUDnzgxSRNOR3jfBilrYZjQ khSnH+Nt6Q1CUDlM6qKbhDz46QtxfbRhScyY0Vr/Gbkapt3gGATggxTY3fb9o9pNdoTDFGPWmIxBj iTdIU6Xoaxc0hQ8xQNOrLUAD+4D/EMxss+jKVU2G0D8F6MzPApYjZ1w8VtlneX/jQINEYg3/fxygd Kf1M68UaMtgzWSTJW2Hg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzJTn-00033a-VP; Thu, 28 Feb 2019 11:03:55 +0000 Received: from mail-ot1-f68.google.com ([209.85.210.68]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzJTj-00032D-2z; Thu, 28 Feb 2019 11:03:53 +0000 Received: by mail-ot1-f68.google.com with SMTP id w26so3936130otp.12; Thu, 28 Feb 2019 03:03:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8iWWCNb5ROZNgxIfGX26VTbIpTUj9YLNwK+9gEJRspg=; b=erDZZqEd2gKZpPzF9JxrrybFiGY+G4Z12ZI6qNres3PnM9ojiT6QSa31BOBlJXe8Gl MZCyONzM3jWVH/SCvl3umYL6+mHV7K14Pk9XJlD57zIJvMo2DgIIRNxk1t6gtg7CH6WH ASezat9NY/pz0sK7bhJ/R4WUazGOEu0rj20mb6ym5dXBNM4+1naix/rYVtsywGjyT2qU FyWMbOJaDlibMwozqOKKP/2P2xqN084kfwJvoA2jLjDJTMGrVpV2xYsR/FSPp7p67arh TLv8RKXBh3M3CqRFu5+mgh4xFzo4Ywp8RC1b6yLoyPVX17mzd4Ib8LEorOCSo4BhNa/C vntA== X-Gm-Message-State: AHQUAubfT0lnRM+oTlxafyE5M6hgG1ASxkWx7n+YnCVa8Oxl3zqqUHw2 tGCNS7qZDE9BO8ZMnmnaidtrtX+roaV3CQFMPRk= X-Google-Smtp-Source: AHgI3IY6LMSLvVHee6CRbFFRRyFzxjrV5H+KF7Yh7G3pMnTGukPC2IvVz7x2Lb9zYJwQ9FwOsIpv94l4LoGTjTeHqeQ= X-Received: by 2002:a9d:4e08:: with SMTP id p8mr5018108otf.124.1551351829712; Thu, 28 Feb 2019 03:03:49 -0800 (PST) MIME-Version: 1.0 References: <20190224140426.3267-1-marc.zyngier@arm.com> <20190226232822.GA174696@google.com> <20190227205754.GF174696@google.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 28 Feb 2019 12:03:38 +0100 Message-ID: Subject: Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes To: Brian Norris X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190228_030351_128922_BEA52185 X-CRM114-Status: GOOD ( 30.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Heiko Stuebner , "Rafael J. Wysocki" , Tony Lindgren , "Rafael J. Wysocki" , Amitkumar Karwar , Lorenzo Pieralisi , "open list:ARM/Rockchip SoC..." , linux-arm-kernel , Devicetree List , linux-pm , Marc Zyngier , Jeffy Chen , Nishant Sarmukadam , Rob Herring , Kalle Valo , Ganapathi Bhat , Ard Biesheuvel , Xinming Hu , "" , "" , Linux Kernel Mailing List , Enric Balletbo i Serra , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 28, 2019 at 3:29 AM Brian Norris wrote: > > Hi Rafael, > > On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki wrote: > > On Wed, Feb 27, 2019 at 9:58 PM Brian Norris wrote: > > > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote: > > > > So I'd argue that we should add an optional 'wake-gpio' DT property > > > > instead to the generic PCI device binding, and leave the interrupt > > > > binding and discovery alone. > > > > > > So I think Mark Rutland already shot that one down; it's conceptually an > > > interrupt from the device's perspective. > > Perhaps I shouldn't speak for Mark, but I am basically quoting him off IRC. > > > Which device are you talking about? The one that signals wakeup? If > > so, then I beg to differ. > > Yes, the endpoint device. > > > On ACPI platforms WAKE# is represented as an ACPI GPE that is signaled > > through SCI and handled at a different level (on HW-reduced ACPI it > > actually can be a GPIO interrupt, but it still is handled with the > > help of AML). The driver of the device signaling wakeup need not even > > be aware that WAKE# has been asserted. > > Frankly, ACPI is not relevant to how we represent WAKE# in DT, IMO. I mentioned ACPI as an example of how WAKE# can be handled. > Also, we're talking about the *device*, not the driver. When talking > about Device Tree, that distinction is relevant. I'm not sure what you mean, really. I guess we are talking about information in DT and some of it is consumed by the driver while some of it is consumed by some other pieces of code. > So while the driver need not be aware (and I agree! it only needs to > care about enabling/disabling wake), Not even that. Actually, PME enable is handled by the PCI bus type code. > *something* should be aware, Right. > and the signal that "something" should be receiving is simply "did WAKE > happen"? Right. But it may not be clear which device signaled it, because WAKE# may be shared in general. > That sounds basically like the device is signalling an interrupt to me. Well, consider the native PME here. In there, the device sends an in-band message over the PCIe hierarchy to a root port and the interrupt is signaled from there. There is a PME driver in the kernel that requests that IRQ and handles it (for all ports that can trigger it), but for each port it binds to a separate device (or "service" if you will) that takes care of all PME messages coming from all devices under that port. At an abstract level, WAKE# is expected to be similar AFAICS except that there is a physical signal going from the device(s) (in low-power states) that have detected external activity (wakeup) to an entity that can trigger an interrupt. The original idea in the PCI PM spec regarding WAKE# seems to be to wire up WAKE# from all devices on the bus to one input that will cause an interrupt to trigger when one of them drives WAKE# and whatever handled that interrupt was expected to walk the bus, find the device(s) with PME Status set and put it (or them) into D0 (clearing PME Status in the process). That still is a valid case to consider IMO. However, designers of some boards decided to provide dedicated per-device interrupts for WAKE# and you may regard them as "wakeup IRQs" except that the handling of each of them is the same as for the "global WAKE#" above: if the PME Status of the device is set, put it into D0 etc. That part belongs to the PCI bus type layer IMO. Of course, because nothing is easy and simple, there is a third case in which one WAKE# line (and interrupt) can be shared by a subset of devices on the bus and there are multiple (say two or three) subsets. > Maybe this goes back to some confusion we had elsewhere: what is the > meaning of "interrupt" in device tree? Maybe. > > > We just need to figure out a good way of representing it that doesn't stomp on the existing INTx > > > definitions. > > > > WAKE# is a signal that is converted into an interrupt, but that > > interrupt may arrive at some place your driver has nothing to do with. > > I could agree with that, perhaps. But that's also what Device Tree is > all about, really. We describe the relation between devices. So some > other handles events that are triggered by , so we use a > phandle to relate to . So you have a PCI endpoint on the one hand and the "wakeup serivce" device on the other. > > It generally doesn't make sense to represent it as an interrupt for > > the target device. > > What would you suggest then? I'm not clearly understanding how you > think we should (a) describe (in DT) and (b) implement this WAKE# > handling. I would introduce a "wakeup service" concept (along the lines of the native PME) and make it request all interrupts associated with WAKE#. In the case when the WAKE# interrupts are dedicated per-device, it would be good to avoid walking the bus and use some "wakeup-IRQ-to-device" mapping if available. But as I said above, IMO the *handling* of all WAKE# interrupts belongs to the PCI bus type as it is the same for all PCI devices. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel