From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D57AF1C8639 for ; Tue, 13 May 2025 07:49:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747122551; cv=none; b=A6TlDWVnvsISKso49xKpVHssYxBs40Sk8oCPuRvsJOSb8wAltLooULkcLhZZrN2WHy2a4Br8I4+3SFA2J7dwKxicXey04Td7MEoQutnaojj++zWTM5hA5GIdnQIuTX3Zbh+3G3jCwAXUwVXcP94ZmIwpU/BKwOx52i4s29tgya0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747122551; c=relaxed/simple; bh=LzBEXxG0UH9im5Vw6DtrXQGXE4QZla4EC0690wwQdIs=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=LFBjWDOVQk7S+BnXf7dMd+p18IJ8pOv+KgvhwV3+f58iTNLO7+HV5uKJLsQbNnNctzelOsylmWTexVv3+ke+gIMCnJxs3DRjHcj1WUwkQdKG3qbohhOS+dwD9pcyZxGKhZU1TGg2Oh+GgWsIMZixzgNij0Uc8sQIkS2IJ0crgZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lS9wbMPD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lS9wbMPD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 472C4C4CEE4; Tue, 13 May 2025 07:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747122550; bh=LzBEXxG0UH9im5Vw6DtrXQGXE4QZla4EC0690wwQdIs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lS9wbMPDWO4ZduhtMnc+PJ0oYngctgjQ1Rm27HFMGyzAP/3oux3Mp2Oi4rwYsrlxX /ct1JqOv7bfPGoHWHAh2AcfNzYmxTP9HFkW1qkiUZvtU6d/FOy5j2+4IaKBlb3dIpD ayBx/2TigCxoGUTLCY6Yq5iBhVZvKtZCGFgo7F/Msmc0KP5D3UUh5ajrdsU9y5AM2E /UUmYKab1W79fKaYfPihkeS8F4qAmuEXzEu0TpyS0hysfRZSIk6xqmvN8rfk+psKO3 97g/PPGAR49yxgycTtJ2kb4kq5lO0tm8LFhLqXrWRu1hee+PrQfZTjjOONScB/Zadv 7SjrmNg2fwPlQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uEkNv-00EQRk-Q1; Tue, 13 May 2025 08:49:07 +0100 Date: Tue, 13 May 2025 08:49:06 +0100 Message-ID: <86plgdeyrx.wl-maz@kernel.org> From: Marc Zyngier To: Douglas Anderson Cc: Thomas Gleixner , chintanpandya@google.com, Maulik Shah , linux-kernel@vger.kernel.org Subject: Re: [PATCH] genirq/PM: Fix IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND if depth > 1 In-Reply-To: <20250512173250.1.If5c00cf9f08732f4af5f104ae59b8785c7f69536@changeid> References: <20250512173250.1.If5c00cf9f08732f4af5f104ae59b8785c7f69536@changeid> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: dianders@chromium.org, tglx@linutronix.de, chintanpandya@google.com, quic_mkshah@quicinc.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hey Doug, On Tue, 13 May 2025 01:32:52 +0100, Douglas Anderson wrote: > > The IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag doesn't work properly if the > IRQ disable depth is not 0 or 1 at suspend time. In this case, the > IRQ's depth will be decremented but the IRQ won't be enabled to wake > the system up. Add a special case for when we're suspending and always > enable the IRQ in that case. For my own edification, can you explain why you end-up in this situation? Because I think I can see a use case for the current behaviour, where a driver controls whether it wants to use this interrupt as a wake-up source or not dynamically, irrespective of the underlying chip's capabilities (which I suspect is pinctrl-msm). This is also consistent with the way disable_irq() nests, making IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND the equivalent of an enable_irq() call. I have the feeling this outlines an issue in the endpoint driver, more than a core code deficiency. Thanks, M. -- Without deviation from the norm, progress is not possible.