From nobody Tue Sep 29 06:08:35 2026 Received: from mail-vk1-f228.google.com (mail-vk1-f228.google.com [209.85.221.228]) (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 9AFA33B8BDA for ; Tue, 11 Aug 2026 16:38:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.228 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786466300; cv=none; b=jpW/b2JXv+TlHnmeLSZph65j+LDn7OSUn09L3EuS9MWeT0AjSRcZ+X6XSltIq7J55N//dUZQEnqWMolu6i8yNsn8bb+HvPyRgo1FMhhcpX6A/bFwDIrhez3Xa7bFOPd/AWsc2VdYIngEACf/cW0j7M6jEx+Yon46Xxp5MH5Cp6s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786466300; c=relaxed/simple; bh=Pn1CRRczXoaCNuEg3/gTPS8bvh9jftQiMH9lZRLES8c=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Zhwz9N9zmeI/wPdHPCVCnan5srxwsHHZ/5UFvQ095+AzjXA81R34U3+efZdihC/tjYNYF6tN/OF8cUdmksVbX59LGbqQSzQZ2roeGYKNv3MKTwUnqWw4qm+9DdNUOlMxi5E/k/lU9ZJ98hapqxVN7qDowbqPNrDvotxdtXug2g0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=fMWN3bac; arc=none smtp.client-ip=209.85.221.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="fMWN3bac" Received: by mail-vk1-f228.google.com with SMTP id 71dfb90a1353d-5bfc5b77c02so2489812e0c.0 for ; Tue, 11 Aug 2026 09:38:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786466297; x=1787071097; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=CSmcaixicWN0/teuSYgIhYRtdBpb1IrPNrZX6fZUyRA=; b=lQOGhBahnpiMCp3z4EmUXUDGXE9iJZ8loySK314f1tx5kQEmOc8UHndMqh6i1XujTm gS0IoEE4gEAmu20dnpFv26SU/HqXwVubuzKIw0XFEtWwnj++vphLZ/nRedIisgvdDjcN s25euTIs0Qw5N0m108VkMJ2iG9JJfA3l2FS+UMmszNh2Bu58w6l+SH6hai/aU93xMB5A PYXdEDj2s06HIRz1Qh7xzK9erpV3jidSFGcw1kOmqU3kJZ/Q3woGSp6SLk6zxJ0JUM7R qhAjUjL8kn9ICTfkR0xqG0hPx5ck7owVAc/bcE9wKJTODtMaTtG2zXNeDpw/6rTOUbba dbjQ== X-Forwarded-Encrypted: i=1; AHgh+RrZwjmicTcElXnXO+dbFvq8Y5qEm0Ts4UY3GkQSWid090XV3ubtDO051KQUWHjbVvQue1Y+FBz1hx4qcqY=@vger.kernel.org X-Gm-Message-State: AOJu0YxrpsjHmR/SA9sG0MVIUKQkzSgVKh8FtAU/rzHoUvxvhUAlu/Bn t8PtgsGtbmOM8tOlIj3dXnGSBJgLHduN7hJvQcLjEo/1lmaIU1M5CV3aW8KttmFP2RhsX4pnR6B 3COB7wJVrJQQoOkdhP7J5/hVwDTcLc5x7hJR+z0LUOEPuPWeg8nX56IeNJyfVgJDPHSyYAl2vxq XeON/6qAy7qT2ysxG8ziwbyxmSZ4GkgVG9jXbEC7lfQC2U820raO0FScIzYuuyUzBwYZgNRm1cI el4mOwNoVDTF4R6 X-Gm-Gg: AR+sD121BmriuLbDU4qwtOkd4mWjY6/xDA6C9sCii2LllrJT8GvnuTSW8DpxUQx5tQC ICHSsJ8giDtv5lgzGzd8XXG9Iqu7OqEbaspcYNaAdo7tyLsvOwgMKzmsXmob6dH8Q1tDK337wFo usCgifImTLWv5hYOwYjzyI2ipcGvdnKbhEv/eouBxJpnO1bcO4UQ5oraW5EF/THBS0XIC0oyYlx PlZX5ccm9rE2UaArQhsnuc1yEOIPctFkV8lEQbVB/sVmUpS+Yu6I5MQgihl6rA3M3NOcumtmYra 64gbZp7Zyq4Ki30ZpSrMs136JUGmwVJWTI/i3buuq76NtZ3Bt/jYYbVZsI1MsN9hZfDzNEcCfBx TXteUzoEEZufvVjMcWJkHmL975jea5l3B24ao1qDhy1AlQkV9MjudIdvO0ZqeMnDNMbxebgc+kT N9jTaoA9uJwP9oMD7Aej5+TACh5EJGpzneDZk= X-Received: by 2002:a05:6102:5245:b0:744:a3fd:410a with SMTP id ada2fe7eead31-76b578d3d0fmr1310925137.14.1786466297372; Tue, 11 Aug 2026 09:38:17 -0700 (PDT) Received: from smtp-us-east1-p01-i01-si01.dlp.protect.broadcom.com (address-144-49-247-120.dlp.protect.broadcom.com. [144.49.247.120]) by smtp-relay.gmail.com with ESMTPS id a1e0cc1a2514c-97a3c20e746sm9806241.8.2026.08.11.09.38.17 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2026 09:38:17 -0700 (PDT) X-Relaying-Domain: broadcom.com X-CFilter-Loop: Reflected Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-92ec3146553so19271785a.1 for ; Tue, 11 Aug 2026 09:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1786466296; x=1787071096; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=CSmcaixicWN0/teuSYgIhYRtdBpb1IrPNrZX6fZUyRA=; b=fMWN3backj+66pLPUqSWLZG8Z4xnDqJqzOZpRy8TMD+r4OluV7CvZmFQ88jPXwAjQr 3frRF4Nga9B5gCB4sc40i5WbU2WjTXaboccqZkltjPvfhUrTGrM/H2vmUtrLtXa4wEFO D2AIn8vWT4MaHT+2eis0Dsjcv/kIXv9QsQAxc= X-Forwarded-Encrypted: i=1; AHgh+Rq7CJ48hLVYQS7oFdM0/ee8IndfxRKmuLQ5Ld52xXWavxtgUWjiVp2dLYH8VHpWQ/DPK/DDqHTnDQy+QFg=@vger.kernel.org X-Received: by 2002:a05:622a:c3:b0:519:f884:b587 with SMTP id d75a77b69052e-52d585e7f3bmr41299051cf.27.1786466296511; Tue, 11 Aug 2026 09:38:16 -0700 (PDT) X-Received: by 2002:a05:622a:c3:b0:519:f884:b587 with SMTP id d75a77b69052e-52d585e7f3bmr41298471cf.27.1786466295898; Tue, 11 Aug 2026 09:38:15 -0700 (PDT) Received: from mail.broadcom.net ([192.19.144.250]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-52d57c3c09bsm14427981cf.25.2026.08.11.09.38.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 09:38:15 -0700 (PDT) From: Kamal Dasu To: Ulf Hansson Cc: Kamal Dasu , Florian Fainelli , Wolfram Sang , Oleksij Rempel , Avri Altman , Pedro Demarchi Gomes , Erick Shepherd , Adrian Hunter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski Subject: [PATCH v9 1/3] dt-bindings: mmc: Extend keep-power-in-suspend beyond SDIO Date: Tue, 11 Aug 2026 12:38:08 -0400 Message-Id: <20260811163810.1599747-2-kamal.dasu@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260811163810.1599747-1-kamal.dasu@broadcom.com> References: <20260811163810.1599747-1-kamal.dasu@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-DetectorID-Processed: b00c1d49-9d2e-4205-b15f-d015386d3d5e Content-Type: text/plain; charset="utf-8" keep-power-in-suspend is currently documented as SDIO-only, but the requirement it describes -- preserving card power across a suspend/resume cycle -- applies just as well to any card type. Drop the SDIO-only restriction so eMMC and SD platforms can use it too. Signed-off-by: Kamal Dasu Reviewed-by: Krzysztof Kozlowski --- Changes in v9: - No change. Changes in v8: - No change. Changes in v7: - Added Krzysztof's Reviewed-by. Changes in v6: - Split into a separate, minimal patch per Ulf: just extend keep-power-in-suspend's scope, with no brcmstb/firmware-specific rationale in its description. That rationale now lives in the new reset-card-at-resume property instead (patch 2/3), and the two are set together on brcmstb rather than folded into one property. - Also per Ulf (applies to v4 and v5 alike): dropped the mention of sdio_set_host_pm_flags() and how Linux's SDIO stack happens to expose this at runtime -- that's a software implementation detail, not a hardware/platform description. Changes in v5: - Added Krzysztof's Reviewed-by. Changes in v4: - Dropped no-mmc-poweroff-suspend entirely and extended keep-power-in-suspend instead, per Krzysztof: the two properties described the same "don't power off across suspend/resume" contract. Changes in v3: - Renamed from no-mmc-sleep; dropped S_A_TIMEOUT framing per Ulf. Changes in v2: - New patch, replacing v1's card-level quirk, per Ulf. Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.ya= ml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml index 3d7195e9461c..c18bf0d6a56e 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml @@ -291,7 +291,7 @@ properties: keep-power-in-suspend: $ref: /schemas/types.yaml#/definitions/flag description: - SDIO only. Preserves card power during a suspend/resume cycle. + Preserves card power during a suspend/resume cycle. =20 wakeup-source: $ref: /schemas/types.yaml#/definitions/flag --=20 2.34.1 From nobody Tue Sep 29 06:08:35 2026 Received: from mail-pj1-f100.google.com (mail-pj1-f100.google.com [209.85.216.100]) (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 7DB143C09F3 for ; Tue, 11 Aug 2026 16:38:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.100 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786466302; cv=none; b=dzIwX3Xx6LmfctJ87cMkQrt/gevI/0zHRkACAHgF4wpDpHUG3M1BpzSAuUqP/qccUDbaPjj7TCS1ox4EjcPjeubS4/T2Ptovr52kDawH3Sr1hPEYLMjR1y/ASts+sRNdFDSrTsdBtfcV+3+5k6gcyvIKsdkX63b1OHEBTQRdzv4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786466302; c=relaxed/simple; bh=VjAm/G+XBV3wqAMJf/jE90KbOirqngl4/9uUrm3AKo8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ku6ZRZQBmJoS1pUfOZwx5uFBhYzsRnlNUqMF7db9cX9CDwDg997iM1UaoUWK3wXHPnvL2YnNIP1LxpdMIu/fSNKqd/WCBRJn+6VaVGtxjclffPWCPHhPlNtDJJyxnWOJdQzPnal//Hq+r52x63z9qPBeWRCk7GvJpmB9EUBDQJM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=BRAkb/dQ; arc=none smtp.client-ip=209.85.216.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="BRAkb/dQ" Received: by mail-pj1-f100.google.com with SMTP id 98e67ed59e1d1-38d489b6b71so106164a91.0 for ; Tue, 11 Aug 2026 09:38:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786466300; x=1787071100; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=IP0oJG7AWLjJjpPY4ZmVTg/sHwIBv1HYr/k2mhlodnU=; b=a5Kqjzmb0Dwi9FMtlP4CR4HqPHpNnKsyi4HFb229lcFVDZjkWhIsotPnSEWf1/BKld daIeEEh3/O5whGaiin2+7F13qkGfh4Wnbry0MTgnQ+4U07dH5lbZjpaMJgVkVA8gz/7u kPkHEeXwxuT6kD9T4dbdo6yyh9k/hjYjviEDS1D4fid7sfYvit6ZzI3AUutGeL6gS1NT uRZ0utfIB0mnSZ7wY56eiggzn/5WCGQx2R04/xKT34YvnW/g9IEwW7qvw/oWk/LXfzRp IW1ERiFye/Zubyn/M6ytsXiCvdUcRtKZW2X+Fpksw/i2Ux8RiY8IxsQItsl3lry9I9Xc Kbzw== X-Forwarded-Encrypted: i=1; AHgh+RrewhYT35z0MwMlJWervNoyZL7LU0gEsnjROo+W3z8FdVEj+0JYxGDkwkzaU+gBYRh8KTgCpe167rNeGJc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5y5PHPacnh4HPgj/IuFHu2F0P1Vwni8MxKFUbS4ZxGCjokwqE C726ifB8Yk23qVMacbef0QASk3hArrkYu0db0L/HeCUK+YahzHAW7OFcY2mKwDOtPlbOfW3fymY f4IswdezZcdf0UZOz4FQYbZenCrIXdW7mSCyClXiAFdtWL74Q9HX5WV9NLLBCvB/hP0Pn6J1R4i LAiIHLSTqP+aJCnXeuoCW0CQ5LtLcmkxJ69ZrxJJcci8p7Qw/u54Ump5MWYR5Y5sdSaa8grmWBX 7513omq+k+a23ni X-Gm-Gg: AR+sD106u8/Yt/ybvlmeojzOf3x4tDme3QfkFW34Xk50gk+3iSE25uPusO3GUDQ+hh+ AecryZgbEDSuF4sYnpUFG3hs2zoLHaHtyhD1wUjO01UwhzGRlhy6oJ9PpFpwSqMhDU/kBp+vubS y6dcuJIIy8dsxnYYgq3Xwy1uCCBlJG45bkk2bYJWRmeJls7otSqIn+QXRNiS0Bjf9yCZ+GX9tUp eDj/e/XCKsvGd9UHPNSjjIRM9wjXnIJtsxvSRKOgwha/k5TGjylTmOfAga+Vjh9b6IeAo5prTIf PCsFJO+1ujhS++tdXvMSbHkogzKj2a1+BicHVoqRzYMhi8BFK2yc3PxTsvQKAJKK1hYg0fvf0zu 7REXxlsV0Jia+oAJmWIjAn5cR6y1uK9uWXTQqSKzt/3ViWARraf57vDlnAX7gLzcPPUClY2aafV Bc1JGgxyh8wb0OHSgcdlSovY5e2n54cQ== X-Received: by 2002:a17:90b:4d10:b0:381:6c5:3f63 with SMTP id 98e67ed59e1d1-392f469ab53mr1299645a91.6.1786466299626; Tue, 11 Aug 2026 09:38:19 -0700 (PDT) Received: from smtp-us-east1-p01-i01-si01.dlp.protect.broadcom.com (address-144-49-247-0.dlp.protect.broadcom.com. [144.49.247.0]) by smtp-relay.gmail.com with ESMTPS id 98e67ed59e1d1-392f9514986sm28526a91.12.2026.08.11.09.38.19 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2026 09:38:19 -0700 (PDT) X-Relaying-Domain: broadcom.com X-CFilter-Loop: Reflected Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-51c12e43b98so1208391cf.1 for ; Tue, 11 Aug 2026 09:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1786466298; x=1787071098; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=IP0oJG7AWLjJjpPY4ZmVTg/sHwIBv1HYr/k2mhlodnU=; b=BRAkb/dQhOBssXaWTntCJIG7KtHtikt2iq1aXuUsa7YYoOywPlrxiAn8luv3YrSBO4 lIk0mU0HZkZ2V/vRy795+3kAQjRRcrDtBAUSrFL2up7204weT+pEZORRi7NH966lc/6h S0b3VtvUxHgOHhO6XpGMWTRa8T5aacjokMglE= X-Forwarded-Encrypted: i=1; AHgh+RrcZJ4DkJrmQX/nlvNNp6/gMbdHIGukvupiLQh4GjzpfyEbwh21jhe30TWWnf1EuQTK44BCy+T+NW5LxGM=@vger.kernel.org X-Received: by 2002:a05:622a:4185:b0:51c:1c2c:a8bf with SMTP id d75a77b69052e-52d60284dabmr16892381cf.43.1786466298514; Tue, 11 Aug 2026 09:38:18 -0700 (PDT) X-Received: by 2002:a05:622a:4185:b0:51c:1c2c:a8bf with SMTP id d75a77b69052e-52d60284dabmr16891771cf.43.1786466297946; Tue, 11 Aug 2026 09:38:17 -0700 (PDT) Received: from mail.broadcom.net ([192.19.144.250]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-52d57c3c09bsm14427981cf.25.2026.08.11.09.38.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 09:38:17 -0700 (PDT) From: Kamal Dasu To: Ulf Hansson Cc: Kamal Dasu , Florian Fainelli , Wolfram Sang , Oleksij Rempel , Avri Altman , Pedro Demarchi Gomes , Erick Shepherd , Adrian Hunter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski Subject: [PATCH v9 2/3] dt-bindings: mmc: Add reset-card-at-resume property Date: Tue, 11 Aug 2026 12:38:09 -0400 Message-Id: <20260811163810.1599747-3-kamal.dasu@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260811163810.1599747-1-kamal.dasu@broadcom.com> References: <20260811163810.1599747-1-kamal.dasu@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-DetectorID-Processed: b00c1d49-9d2e-4205-b15f-d015386d3d5e Content-Type: text/plain; charset="utf-8" On some platforms, firmware or other hardware accesses the card during suspend/resume, before the kernel's own resume path has run, leaving the card in a state the kernel can no longer assume it knows. Add a flag property so such boards can tell the mmc core the card needs to be reset before it can be used again. This is expected to be paired with keep-power-in-suspend on boards whose firmware needs the card to stay powered and live throughout suspend: since the card is never power-cycled, nothing else would force it back to a known state on resume. Signed-off-by: Kamal Dasu Reviewed-by: Krzysztof Kozlowski --- Changes in v9: - No change. Changes in v8: - Sashiko's AI review of v7 pointed out this property's own description says it's "expected to be paired with keep-power-in-suspend", and patch 3/3 now enforces exactly that pairing in the driver, but nothing enforced it in the schema -- a DT could set reset-card-at-resume alone and still pass dt_binding_check. Rob Herring asked for this to be addressed on the list. Added a dependencies entry requiring keep-power-in-suspend whenever reset-card-at-resume is present. Changes in v7: - No other change here; patch 3/3 now requires this property alongside keep-power-in-suspend for (e)MMC rather than treating them as fully independent in the driver -- see that patch's changelog. Changes in v6: - New patch, per Ulf's suggestion: rather than fold "needs a reset at resume" into keep-power-in-suspend's own meaning, describe it as its own independent property, so the two can be combined only where actually needed (brcmstb sets both; SDIO's existing keep-power-in-suspend users are unaffected and set neither this nor a reset). Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml | 8 +++++= +++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.ya= ml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml index c18bf0d6a56e..c51e9184384d 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml @@ -293,6 +293,13 @@ properties: description: Preserves card power during a suspend/resume cycle. =20 + reset-card-at-resume: + $ref: /schemas/types.yaml#/definitions/flag + description: + The HW/FW may have accessed the card during suspend/resume, + leaving it in an unknown state. Hence, before the card can be + used, it must be reset. + wakeup-source: $ref: /schemas/types.yaml#/definitions/flag description: @@ -361,5 +368,6 @@ patternProperties: dependencies: cd-debounce-delay-ms: [ cd-gpios ] fixed-emmc-driver-type: [ non-removable ] + reset-card-at-resume: [ keep-power-in-suspend ] =20 additionalProperties: true --=20 2.34.1 From nobody Tue Sep 29 06:08:35 2026 Received: from mail-qv1-f98.google.com (mail-qv1-f98.google.com [209.85.219.98]) (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 90D1C3BE155 for ; Tue, 11 Aug 2026 16:38:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.98 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786466310; cv=none; b=bKP7iZ9CRLRidH2UHZolugyfoEmxHF+QLZiszv5F+iEvgPSeyZpiG/mMqJnnca0HUS40IsgXqXDi4UeACjHOZwJeuw5CcMpIOcjO3iMxquWLMLxH25lKf792Cy1OQUuT3RZgZjl2GnriaiNMtwbBkjWV+f1oHWUQC7e3yMa3Kxg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786466310; c=relaxed/simple; bh=qDIPVpVxEpcy+zvTLK84r8RGodocHdhfgyJCOWwDWL4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=bXBXrz/Wb+vL8CZEsWPhq6Dx3aygfZJ1/9Zb/Re7m/DbGmSwqYXJ4WCbH39qF99NmNOmes8A/xDQfAMbktRKV0W8m27KpSMC/TgJaU3CiGLw+Ag2Oh9rCPAm4YUrVeuTXq1NcxwK1pxitSjkTJ/aWjL6sIAwPW5yX+U+qsLR2KM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=EagPx92G; arc=none smtp.client-ip=209.85.219.98 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="EagPx92G" Received: by mail-qv1-f98.google.com with SMTP id 6a1803df08f44-8f23e851626so32976d6.3 for ; Tue, 11 Aug 2026 09:38:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786466302; x=1787071102; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=K2PGjge9uHRNeS69RnlDH3bcMcQ9lvmh6M0bI5U6ZnQ=; b=mXXDrf2vTz3BecGbYL5Aa9OX6gKLgDIQshd+Wx/2jY6kO7DRKzXMHY4mkt9yGUiceP 1EwPUXl23Za9lrfIFXJXg8XopjXsE6rWktm1LjKnGcie0pLBYocwHJjx+oDQreYfjcKX 1sTn/gOIpLYiFSMSLPwe1R4WvvfI41fg3jHwD+YyoyX+bs2U6l/aVauaqSEi8oyg9bVH 2/fR8esui2HzkcgkUSuG/7ZCN5ExPitesiCo7HKJ93gHGoNjK6PrUMFT5xART4xXNWvi +RJV1uF7LuSHQa4tTCs6xAreR2PitrTsVkXKFLv4Xeh+1GwRAKyPP0gSr5nlpq4xuh7k j4eg== X-Forwarded-Encrypted: i=1; AHgh+RrhwFQNw3Lcz87gHVoXYYifdxlc/3HeqaoYo8TkdZJEMieJ6VCmYvjRltpx33svOBCoae3s42US9mcJzcc=@vger.kernel.org X-Gm-Message-State: AOJu0YwyX2nzSMsQbR5ot1OROXi6+Fowt46qNPJTjEeDQYsnra1+LkSb j8cM5G8Bbll+H3NFJdMj4xoM8AGm40rDxSXZzLEJbn4FDFt3ITmobOykZUhXbftk3lrq/MLSOpJ 0rseOvJiHrdE/nqHJRIfoVcNFuEfep8kNWE1g7Au2vi8eygPWBJqfhGkYEM9kwYsU4UCxN6aUas uwyntXpZico9FUFW+QjyUv7P6LtSkjPZdZvZK0IImwRBkvYiZF29GSnEEpW0bsu8+SWdgfC2Pa/ YaymzMPfMWVPCGL X-Gm-Gg: AR+sD130QP2DoYRbygVFbWXHAtaFYDHnNrPOSEQbZUwXtsrrZlr1skK65Y6NnxH3jpO rXYJQ0E/B8fe3yw7vLyWiveoq34OfuyeHeoHcY6lsV+qwh4cU9MZABOv6fgc9OEDSux1+LlmDfM NxsicXLM+55PNf9qLwtEnDrqbAqp+8UFVcDKAEjTPoFdmcmz8D+B5nMDotSwRIH2Dgrwy4wLvtS eHNDcbPHGqp6VW9G59GONt0WHW8zw6OwDHgkITiTnE+zD5DYYfbumOmJhYNFfS9kbZUm1qP3uLh 7qyo1Tfqmkxv6mbDG28BHiRNGuQt9ahpYK4dwZL1JlCVuG39DJqRmJ+ZMjuCGsVRGmz/5E1KAQU ljhtHCdeakrtEmxKa18ZFFmU2mLa5j2q/OnT2t0FqS4MvJBqVu8ZLjiOBH1dJ1Yf5xMuTNK3W9/ rR/KTytBDAD90+wwRJY9suK8OFUcHpqio8 X-Received: by 2002:ad4:5ca5:0:b0:8ee:7c26:8bb8 with SMTP id 6a1803df08f44-90a6c0dbc6dmr13106506d6.9.1786466301864; Tue, 11 Aug 2026 09:38:21 -0700 (PDT) Received: from smtp-us-east1-p01-i01-si01.dlp.protect.broadcom.com (address-144-49-247-20.dlp.protect.broadcom.com. [144.49.247.20]) by smtp-relay.gmail.com with ESMTPS id 6a1803df08f44-90a6ce498f5sm40326d6.8.2026.08.11.09.38.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2026 09:38:21 -0700 (PDT) X-Relaying-Domain: broadcom.com X-CFilter-Loop: Reflected Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-90410c668adso247656d6.1 for ; Tue, 11 Aug 2026 09:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1786466301; x=1787071101; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=K2PGjge9uHRNeS69RnlDH3bcMcQ9lvmh6M0bI5U6ZnQ=; b=EagPx92GGJzuWnX5xycj2/LovP6jWbre2OeO1Wh5OdjrPwutBU5uxs0KO+KkVqFFbq tKl0MAvl6HQgRB9BGPaRD/9PSG9GnQBFVR+NHYZdIvml1/zMgCU4ObxkjZ7/MLaFxIAk VuK4+1xC/3Z+/X9aktvFvCTbAdu1xvlWKv/Xs= X-Forwarded-Encrypted: i=1; AHgh+RqZqmTFLNDclY/3qF/DqoaWwgpZmz+0g8MEUFrqqL9oPoFY2/HyxAk0Y3L5E3UJ0BuJVQzmIYaVBBCoCGA=@vger.kernel.org X-Received: by 2002:ac8:5d13:0:b0:52d:28f8:578c with SMTP id d75a77b69052e-52d60232d28mr14082211cf.31.1786466300768; Tue, 11 Aug 2026 09:38:20 -0700 (PDT) X-Received: by 2002:ac8:5d13:0:b0:52d:28f8:578c with SMTP id d75a77b69052e-52d60232d28mr14081381cf.31.1786466300075; Tue, 11 Aug 2026 09:38:20 -0700 (PDT) Received: from mail.broadcom.net ([192.19.144.250]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-52d57c3c09bsm14427981cf.25.2026.08.11.09.38.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 09:38:19 -0700 (PDT) From: Kamal Dasu To: Ulf Hansson Cc: Kamal Dasu , Florian Fainelli , Wolfram Sang , Oleksij Rempel , Avri Altman , Pedro Demarchi Gomes , Erick Shepherd , Adrian Hunter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v9 3/3] mmc: core: Honor keep-power-in-suspend and reset-card-at-resume for (e)MMC Date: Tue, 11 Aug 2026 12:38:10 -0400 Message-Id: <20260811163810.1599747-4-kamal.dasu@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260811163810.1599747-1-kamal.dasu@broadcom.com> References: <20260811163810.1599747-1-kamal.dasu@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-DetectorID-Processed: b00c1d49-9d2e-4205-b15f-d015386d3d5e Content-Type: text/plain; charset="utf-8" On some platforms, firmware accesses the (e)MMC card directly during resume from Suspend-to-DRAM, before the kernel's own resume path has run, in order to load boot code. This requires the card to remain powered and responsive throughout suspend: putting it to sleep, sending it a power-off notification, or removing its supply is not safe, since firmware needs to talk to a live card. Since the card is never power-cycled, nothing else resets it back to a known state before the kernel reuses it after resume. keep-power-in-suspend / MMC_PM_KEEP_POWER already exist for the first part, but are only consumed in the SDIO suspend/resume path (mmc_sdio_suspend()/mmc_sdio_resume()), gated on a per-function runtime request via sdio_set_host_pm_flags(). (e)MMC has no equivalent function-driver layer to make that request, and the requirement here is a fixed platform characteristic rather than a per-cycle one, so _mmc_suspend() checks host->pm_caps directly instead of pm_flags. reset-card-at-resume covers the second part: when set, _mmc_resume() resets the host to its initial bus state the same way _mmc_hw_reset() does for a non-power-cycle reset, before mmc_power_up() and mmc_init_card() re-identify the card. _mmc_suspend()'s fast path requires both MMC_PM_KEEP_POWER and MMC_CAP2_RESET_AT_RESUME to be set. Keeping the card powered without also resetting it at resume is not safe for this driver: skipping mmc_power_off() leaves power_mode at MMC_POWER_ON, so mmc_power_up() no-ops in _mmc_resume(), and without an explicit reset first, mmc_init_card() runs against whatever bus speed/width was active before suspend instead of the initial state it expects. Conversely, _mmc_resume()'s reset checks pm_flags rather than the MMC_CAP2_RESET_AT_RESUME capability directly, since pm_flags is only set when the fast path actually ran -- the only time power_mode is guaranteed to still be MMC_POWER_ON, and so the only time resetting the bus before mmc_power_up() is both necessary and safe. Without that check, MMC_CAP2_RESET_AT_RESUME set on its own would drive the clock and bus lines while the card's supply is still off following a normal mmc_power_off(). The fast path also leaves the card marked suspended without powering it off, so _mmc_suspend()'s pre-existing early exit for an already-suspended card can no longer assume there is nothing left to do: a shutdown, unbind or undervoltage event can still arrive before the card's next real access lazily triggers _mmc_resume() via runtime PM, and those events need the normal power-off sequence regardless. Reselect the card and continue into that sequence in that case, instead of returning early and silently skipping mmc_poweroff_notify() and mmc_power_off(). Reset the host to its initial bus state first, the same way _mmc_resume() does, since firmware may have left the card in a state that doesn't decode reliably at whatever clock/timing was negotiated before suspend -- otherwise mmc_select_card() itself can fail and abort into that same early exit, before ever reaching the sequence it was supposed to fall through to. If mmc_select_card() still fails after that reset -- the card may genuinely be gone -- fall through to mmc_power_off() directly rather than aborting again: unlike the other steps here, powering off doesn't need a responsive card, and shutdown/undervoltage need the supply actually removed regardless. host->pm_flags is set alongside marking the card suspended, and cleared in _mmc_resume(), so host controller resume handlers can tell power was preserved if they need to. Reported-by: Florian Fainelli Closes: https://lore.kernel.org/r/20260413180551.3683969-1-florian.fainelli= @broadcom.com/ Signed-off-by: Kamal Dasu --- Changes in v9: - Sashiko's AI review found two more High severity issues in the same shutdown/undervoltage fallback added in v8: * Calling mmc_select_card() straight after finding the card still marked suspended assumed the card would respond to CMD7 as-is, but that's exactly the assumption reset-card-at-resume exists to distrust -- firmware may have left the card unable to decode commands at whatever clock/timing was negotiated before suspend. A CMD7 timeout there hit "goto out" and skipped the power-off sequence entirely, the same failure mode this fallback was added to close in v8. Fixed by resetting the host to its initial bus state before mmc_select_card(), the same way _mmc_resume() already does before touching the card. * Even with that reset, mmc_select_card() can still legitimately fail (card genuinely gone). The code still unconditionally "goto out" in that case, skipping mmc_power_off() entirely -- but mmc_power_off() is host/regulator-side only and doesn't need a responsive card, so there's no reason a select failure should leave the supply on indefinitely for a shutdown or undervoltage event, or leave pm_flags/suspended state stuck retrying the same failing select on every later call. Fixed by falling through to mmc_power_off() directly on select failure instead of aborting. - Patches 1/3 and 2/3 are unchanged from v8. Changes in v8: - Sashiko's AI review of v7 found a High severity issue: the keep-power fast path marks the card suspended without powering it off, but the pre-existing early exit at the top of _mmc_suspend() (for an already-suspended card) doesn't know that -- it just returns immediately regardless of pm_type. Since the system-resume path only re-enables runtime PM rather than calling _mmc_resume() directly (that happens lazily, via runtime PM, on the card's next real access), a shutdown, unbind or undervoltage event landing before that next access would hit the early exit and silently skip mmc_poweroff_notify()/mmc_power_off() entirely. Fixed by reselecting the card and continuing into the normal power-off sequence whenever the card is suspended via our fast path but pm_type isn't a plain suspend, instead of a bare early exit. Calling _mmc_resume() itself from here isn't an option, since _mmc_suspend() already holds the host claim. Changes in v7: - Sashiko's AI review of v6 found two real, complementary bugs in treating MMC_PM_KEEP_POWER and MMC_CAP2_RESET_AT_RESUME as fully independent in this driver: * keep-power-in-suspend without reset-card-at-resume: confirmed on hardware to hang -- _mmc_resume()'s mmc_power_up() no-ops since power_mode never left MMC_POWER_ON, so mmc_init_card() runs at the pre-suspend bus speed and CMD1 times out. * reset-card-at-resume without keep-power-in-suspend: the reset block ran mmc_set_clock()/mmc_set_initial_state() ahead of mmc_power_up(), while power_mode was still MMC_POWER_OFF from a normal suspend-time mmc_power_off() -- driving the clock and bus lines before the card's supply is enabled. Fixed by requiring both capabilities together for the suspend fast path, and checking pm_flags (not the raw capability) for the resume-side reset, so it only ever runs when power was actually kept this cycle. Verified on hardware: the keep-power-in-suspend- without-reset-card-at-resume case now correctly falls through to a normal power-off/power-on cycle instead of hanging, and the paired-capability case is unaffected (still hardware-verified, now with an extra confirmation run after this fix). Changes in v6: - Reworked around Ulf's two-property split: dropped the unconditional mmc_set_clock()/mmc_set_initial_state() reset from the suspend-side fast path, and instead perform it in _mmc_resume(), gated on the new MMC_CAP2_RESET_AT_RESUME (from reset-card-at-resume), matching the property's name and description ("before the card can be used, it must be reset"). - No longer touches MMC_CAP2_NO_POWEROFF_SUSPEND/no-mmc-poweroff- suspend at all -- that capability and property are gone, per the v4 rework; this patch only adds MMC_CAP2_RESET_AT_RESUME. Changes in v5: - Only set host->pm_flags |=3D MMC_PM_KEEP_POWER after mmc_deselect_cards() succeeds, instead of unconditionally before it. Otherwise, if the deselect fails, the card is never marked suspended, _mmc_resume() takes its early exit, and the flag never gets cleared -- leaking it for the rest of uptime. Changes in v4: - Gated the fast path on pm_type =3D=3D MMC_POWEROFF_SUSPEND; it was previously unconditional, so it wrongly skipped the required power-off/notify handling during shutdown, unbind and undervoltage as well. - Set/clear host->pm_flags |=3D MMC_PM_KEEP_POWER around the suspend/ resume, mirroring the SDIO convention, so host controller resume handlers can tell power was preserved and perform a soft resume sequence instead of assuming power was lost. - Dropped MMC_CAP2_NO_POWEROFF_SUSPEND and the no-mmc-poweroff- suspend DT property entirely. Reuse keep-power-in-suspend / MMC_PM_KEEP_POWER instead, per Krzysztof's point that the new property described the same contract as the existing one. _mmc_suspend() now checks host->pm_caps directly rather than pm_flags, since (e)MMC has no per-function driver to make the dynamic sdio_set_host_pm_flags()-style request SDIO uses. Changes in v3: - Reworked _mmc_suspend() to skip poweroff-notify/sleep/power-off entirely, not just SLEEP, per Ulf. - Renamed to MMC_CAP2_NO_POWEROFF_SUSPEND/no-mmc-poweroff-suspend. Changes in v2: - Replaced the card-level MMC_QUIRK_BROKEN_SLEEP quirk with a host capability, per Ulf. - Added Reported-by/Closes crediting Florian. drivers/mmc/core/host.c | 2 + drivers/mmc/core/mmc.c | 98 +++++++++++++++++++++++++++++++++++++++- include/linux/mmc/host.h | 1 + 3 files changed, 99 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index b7ce3137d452..1622f7846441 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -400,6 +400,8 @@ int mmc_of_parse(struct mmc_host *host) if (device_property_read_bool(dev, "no-mmc-hs400")) host->caps2 &=3D ~(MMC_CAP2_HS400_1_8V | MMC_CAP2_HS400_1_2V | MMC_CAP2_HS400_ES); + if (device_property_read_bool(dev, "reset-card-at-resume")) + host->caps2 |=3D MMC_CAP2_RESET_AT_RESUME; =20 /* Must be after "non-removable" check */ if (device_property_read_u32(dev, "fixed-emmc-driver-type", &drv_type) = =3D=3D 0) { diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 05444ecf3909..3a0855a4ca44 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -2144,8 +2144,55 @@ static int _mmc_suspend(struct mmc_host *host, enum = mmc_poweroff_type pm_type) =20 mmc_claim_host(host); =20 - if (mmc_card_suspended(host->card)) - goto out; + if (mmc_card_suspended(host->card)) { + /* + * Nothing to do for a redundant suspend call. Otherwise, the + * card can only still be marked suspended here because the + * keep-power fast path below left it powered and merely + * deselected -- reselect it and continue into the normal + * power-off sequence below, since shutdown, unbind and + * undervoltage need mmc_power_off() regardless of how the + * card got here. + */ + if (pm_type =3D=3D MMC_POWEROFF_SUSPEND || + !(host->pm_flags & MMC_PM_KEEP_POWER)) + goto out; + + /* + * Firmware may have accessed the card while it stayed + * powered through suspend, leaving it in a state the kernel + * can no longer assume it knows. Reset the host to its + * initial bus state first, same as _mmc_resume() does before + * touching the card, so mmc_select_card() below is talking + * at a clock/timing every card is guaranteed to decode + * rather than whatever mode was negotiated before suspend. + */ + mmc_set_clock(host, host->f_init); + mmc_set_initial_state(host); + + if (!mmc_host_is_spi(host)) + err =3D mmc_select_card(host->card); + + if (err) { + /* + * The card still isn't responding even after the + * reset above -- it may genuinely be gone. Nothing + * else below needs a responsive card except + * mmc_power_off() itself, which is host/regulator + * side only, so cut power directly instead of + * leaving the card's supply on indefinitely (and + * pm_flags/suspended state stuck retrying this same + * failing select on every later call). + */ + mmc_power_off(host); + host->pm_flags &=3D ~MMC_PM_KEEP_POWER; + mmc_card_set_suspended(host->card); + goto out; + } + + mmc_card_clr_suspended(host->card); + host->pm_flags &=3D ~MMC_PM_KEEP_POWER; + } =20 /* * For the undervoltage case, we care more about device integrity. @@ -2157,6 +2204,33 @@ static int _mmc_suspend(struct mmc_host *host, enum = mmc_poweroff_type pm_type) goto out; } =20 + /* + * Keep the card powered across an actual suspend; shutdown, unbind + * and undervoltage still need the normal power-off path below, + * since they aren't guaranteed a subsequent _mmc_resume(). + * + * Check pm_caps, not pm_flags: unlike SDIO, (e)MMC has no + * per-function driver to request this via + * sdio_set_host_pm_flags(), so it's a fixed platform trait here. + * + * Require MMC_CAP2_RESET_AT_RESUME too: without it, _mmc_resume() + * has no way to bring the host back to a state mmc_init_card() can + * use, since mmc_power_up() no-ops when power_mode is already + * MMC_POWER_ON. Keeping power without also resetting at resume is + * not a safe combination for this driver. + */ + if (pm_type =3D=3D MMC_POWEROFF_SUSPEND && + (host->pm_caps & MMC_PM_KEEP_POWER) && + (host->caps2 & MMC_CAP2_RESET_AT_RESUME)) { + if (!mmc_host_is_spi(host)) + err =3D mmc_deselect_cards(host); + if (!err) { + host->pm_flags |=3D MMC_PM_KEEP_POWER; + mmc_card_set_suspended(host->card); + } + goto out; + } + if (mmc_card_can_poweroff_notify(host->card) && mmc_host_can_poweroff_notify(host, pm_type)) err =3D mmc_poweroff_notify(host->card, notify_type); @@ -2217,9 +2291,29 @@ static int _mmc_resume(struct mmc_host *host) if (!mmc_card_suspended(host->card)) goto out; =20 + /* + * Firmware or other hardware may have accessed the card while it + * stayed powered through suspend, leaving it in a state the kernel + * can no longer assume it knows. Reset the host to its initial bus + * state like _mmc_hw_reset() does for a non-power-cycle reset, + * before mmc_init_card() re-identifies the card. + * + * Check pm_flags, not the MMC_CAP2_RESET_AT_RESUME capability + * directly: pm_flags only ends up set here when _mmc_suspend() + * actually took the keep-power fast path this cycle, which is the + * only time power_mode is guaranteed to still be MMC_POWER_ON (and + * so the only time this reset is both necessary and safe to do + * before mmc_power_up() touches the bus). + */ + if (host->pm_flags & MMC_PM_KEEP_POWER) { + mmc_set_clock(host, host->f_init); + mmc_set_initial_state(host); + } + mmc_power_up(host, host->card->ocr); err =3D mmc_init_card(host, host->card->ocr, host->card); mmc_card_clr_suspended(host->card); + host->pm_flags &=3D ~MMC_PM_KEEP_POWER; =20 out: mmc_release_host(host); diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h index ba84f02c2a10..14a407a9f9b7 100644 --- a/include/linux/mmc/host.h +++ b/include/linux/mmc/host.h @@ -463,6 +463,7 @@ struct mmc_host { #define MMC_CAP2_CRYPTO 0 #endif #define MMC_CAP2_ALT_GPT_TEGRA (1 << 28) /* Host with eMMC that has GPT en= try at a non-standard location */ +#define MMC_CAP2_RESET_AT_RESUME (1 << 29) /* Card must be reset before us= e at resume */ =20 bool uhs2_sd_tran; /* UHS-II flag for SD_TRAN state */ bool uhs2_app_cmd; /* UHS-II flag for APP command */ --=20 2.34.1