From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 102E6427A18 for ; Thu, 26 Feb 2026 16:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772123966; cv=none; b=ZK4cHdII2zXdy742vMzkzEZNIWvGNiUYzpQQS5pmUi90thaqBraOk/3b5l4FVDLoh5dNzHQKU28DjdLa5IFzZ1EhFhngOEtMMalZUP8QCwYUF468jnV0Q+/845XR2/wkOrjYR2euHjjeUMZLFoSZVyVaR9OkU5re0kiLFMCgXFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772123966; c=relaxed/simple; bh=RGWiSz0OZmp56vuOsH1lOEqi0n+JuVLSekK0RKtPb+k=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=mIKZgG4yRMOREc4miwQP0qnbUkh5IIq/jXUH6GSnV1yR7OLPEu3Qc5/IlvzObEyU7p0VZiU/WVRQbwwz+jt2O2b8Tdmw5/4wHh7b/4+QodNC2NEz6NxqDMJgEEcfIDUgIaHdOAloCTFuSlyAlETVomoMnZvm6w4vCj3BI6aacZs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=bwcGROu8; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="bwcGROu8" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-48374014a77so12017595e9.3 for ; Thu, 26 Feb 2026 08:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1772123961; x=1772728761; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T5B6phFCzYt+HE2CB08nF7/uTT/Fn+s/IX1ktent940=; b=bwcGROu8ySlq6V8VV5fUlZS2BAQO4EwVTN7MGR+EKIKA9rPR39Oa7nYhkrBFMhO/zs zeq5RZVMM7AVUr6fajkAMfZ164aRieMyR9GpGnoX+1jw5weALsVNKGDXhUVI0aqCENCS j42ZUEB1hVcluGyz+IchK4YEYq74c8bhKcqRrfSLYX76spjJeKUV60u3vHDl2taIffx0 ZnKfggnJFxP9iStsykERxVo71pvjbZvYtm3qSMyirzSDMoLxE6WZ30izQSUwkUGTYVQ0 OaYFJvuDOPRAtRY+RRY95dGY/gIh8vT95t53ud0azuXxtqWOgrF7GBphP2HT+D0n+0XA 2p4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772123961; x=1772728761; h=in-reply-to:references:subject:cc:to:from:message-id:date :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T5B6phFCzYt+HE2CB08nF7/uTT/Fn+s/IX1ktent940=; b=w/IenbLNML6x59GIZHHRJMPDzuxi9U4bR0nc0scsDOUyqf0unKVW0FOay/1srauYEv WkkVyVRNzaiyHCKXXEZJli2CsPPoy0Gehvv3RQtergwmYsqdwIitoa3MyUAZ9P21RdUN Tmi30kvEn29ErgDFd4IKxinTERMAc5ULsGMVCJJBiuaUprqAagJaA3x9GT+4hVe44tts u/GApCEXD1Qi4/ngZM4OEPyxnO5Xd9ItzH2JID0ZdEHfPhDN0hwJGrPnh73TnxI0Dtn4 E/ufzlyeQ9XxC+9P5ZY15lj1192fO6dDxAlnumWuM67IDxmMF0SXMIE+T03OqEhtxOG8 oDIA== X-Forwarded-Encrypted: i=1; AJvYcCUaWGGqT+qwOahOkPNlw+l1sNtDYJlmVPqpQCaKRaUe1vohMxsW2sR0FGOPREFHD+42d9qICksVuyLil6I=@vger.kernel.org X-Gm-Message-State: AOJu0YyqdH9EhkQZhsl/JqBBYEqkhyFW1GoEq2RWs65boCqbNhv4fmRy vPvE6lYVG7BZdf8zH7tB2V4w43jfewGUqBJVsUcv+2+y+aqDvnHKoMw/P5gc0aVx3h8= X-Gm-Gg: ATEYQzwb6EGoV+/5njG8OeTOiE3G+/qSNB8F9fVGA1YH3sLUP3pTFbjqfBd0yikzfGf d0ZmLpVqrdziPP9JXdu2hejFWwMgYqBGaZEumN/q0pbYDuNCNzFumRChQ9eMFxDcF4mAKCjeQFl EoCifL6EO/fTDvJCRHAWSai4aP2WoJO/uQqVt7n7hfCDmOI58QbLnMKv1l0nE6cbN+7NWKdrNMX GJFFwWaYZgGws4AnlyXTy23wWFHdvNu68R3+R4hWoFyxlwlwzKgcS8rCBOrC7GsN1iNcoEVllse GFKNSrT1In0kSgkxVGcE/LAY41tTc4aAZXlZZJpbqMv/kGqW+j1S9K/plVW3p29YMORpmSnM+tg 781MTohmB755uXa7yU/IvTk7l0xgjTQV/aNdPzyjioeKvafoE25hPJ+5Xi6XzbM+qK7GfS1ZST5 UlKKkhnOEZKNfhcTGzFScmGdd1Ww== X-Received: by 2002:a05:600c:37cc:b0:47e:e20e:bbbe with SMTP id 5b1f17b1804b1-483a95e9b65mr334329625e9.25.1772123961331; Thu, 26 Feb 2026 08:39:21 -0800 (PST) Received: from localhost ([195.52.25.213]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483c3b770c2sm51360545e9.10.2026.02.26.08.39.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 08:39:20 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: multipart/signed; boundary=e79d1022041faa676f36278d4e8685f754cef59bbd011f58fe85541a5fd0; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 26 Feb 2026 17:39:10 +0100 Message-Id: From: "Markus Schneider-Pargmann" To: "Kendall Willis" , "Markus Schneider-Pargmann" , "Marc Kleine-Budde" , "Vincent Mailhol" Cc: , , , , Subject: Re: [PATCH] can: m_can: set out-of-band wakeup if wakeup pinctrl exists X-Mailer: aerc 0.21.0 References: <20260213-mcan-out-of-band-v1-1-af68d4c570b3@ti.com> In-Reply-To: --e79d1022041faa676f36278d4e8685f754cef59bbd011f58fe85541a5fd0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi Kendall, On Thu Feb 19, 2026 at 9:31 PM CET, Kendall Willis wrote: > Hi Markus, > On 2/18/26 04:51, Markus Schneider-Pargmann wrote: >> Hi Kendall, >>=20 >> On Fri Feb 13, 2026 at 7:08 PM CET, Kendall Willis wrote: >>> In TI AM62X, AM62A, and AM62P SoCs, the m_can pins can act as a wakeup >>> source in the deepest low power states. However, the m_can pins are a p= art >>> of the MCU domain which is OFF in deeper low power states. Since the m_= can >>> pins continue to be ON even if the MCU domain is turned off, set >>> out-of-band wakeup for CAN device if `wakeup` pinctrl state exists and >>> device may wakeup. >>=20 >> Thank you for your patch. >>=20 >>> >>> Signed-off-by: Kendall Willis >>> --- >>> Tested on CAN IO wakeup from DeepSleep low power mode on AM62P EVM. >>> --- >>> drivers/net/can/m_can/m_can.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_ca= n.c >>> index eb856547ae7df27a844b236a0c1d4498cbb8b60f..8b277f5e208ffa634439b9e= a8495ed56f12cfccb 100644 >>> --- a/drivers/net/can/m_can/m_can.c >>> +++ b/drivers/net/can/m_can/m_can.c >>> @@ -2622,7 +2622,9 @@ int m_can_class_suspend(struct device *dev) >>> cdev->can.state =3D CAN_STATE_SLEEPING; >>> } >>> =20 >>> - if (!m_can_class_wakeup_pinctrl_enabled(cdev)) >>> + if (m_can_class_wakeup_pinctrl_enabled(cdev)) >>> + device_set_out_band_wakeup(dev); >>=20 >> This will set out of band wakeup for every m_can that has a >> wakeup-pinctrl set. am62* is currently probably the only platform that >> uses the wakeup pinctrl setting but that may change at some point in the >> future. Can we narrow down setting the out of band wakeup to the >> platforms that support it? >>=20 >> One idea could be to parse the supported system-idle-states from the >> list of wakeup-sources and see if deep states are supported that would >> require m_can to be off, e.g. mem-deep, off-wake. I think that would be >> a clear indicator that out of band wakeups are supported. >>=20 >> For the list of state names you can have a look in the dtschema >> repository: >> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schema= s/system-idle-states.yaml >>=20 >> What do you think? > > I agree that we should narrow down setting the out of band wakeup to the= =20 > platform, but I am unsure of parsing the supported system-idle-states as= =20 > the solution. Since we don't know how the power domains in other=20 > platforms are organized, it would be hard to say that if deeper idle=20 > states are supported mcan has out of band wakeup logic. It could be the= =20 > whole power domain was designed for the deeper power states. > > Additionally, without out of band wakeup for mcan on AM62 devices, mcan= =20 > can only wakeup from mem-mcu-active idle state, and adding out of band=20 > wakeup allows for wakeup from mem idle state and deeper. Checking for=20 > mem idle state doesn't seem deep enough to warrant setting out of band=20 > wakeup for all platforms since some platforms could have mcan in a power= =20 > domain that is ON during the mem idle state. > > Another idea would be to add some sort of property to the device tree to= =20 > denote the wakeup source is an out of band wakeup source. Sure, a generic DT property would be good as well. Do you already have something in mind? Best Markus --e79d1022041faa676f36278d4e8685f754cef59bbd011f58fe85541a5fd0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKMEABYKAEsWIQSJYVVm/x+5xmOiprOFwVZpkBVKUwUCaaB3MBsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMSwyLDIRHG1zcEBiYXlsaWJyZS5jb20ACgkQhcFWaZAVSlMe VgD9Gjh9TrBAM9VIzW+ZXCPWjq0RhP/Cq0x/tDWE6Yws6psA/3Ju/Es4ea9yQkhw H2mtiB3MXzHE76zIt4Qrn74QLm4M =tFV9 -----END PGP SIGNATURE----- --e79d1022041faa676f36278d4e8685f754cef59bbd011f58fe85541a5fd0--