From nobody Fri Dec 19 00:16:46 2025 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (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 CE99826136F for ; Mon, 24 Mar 2025 15:34:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742830457; cv=none; b=KnSI68WAuXuDuhufgAFt00XwcMwp6fX4tYVg0fUsBwemviOGY7hcbV23fcEqt5GvrzF63jSqbgHpXdd6jd/StSzO7a38MWopMnjD3OGOCSntRXJJgPuQJiPAGh7RvGkjQS4ItqxiP1yYKPNihZ3ZLHzMcrucKki90imri0GkIg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742830457; c=relaxed/simple; bh=BbaRiEVNhHM1RZ2ZnJzY8WLo+QoHvZrXazGZXzvdN9M=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=tU0Aza/RZjqVAJQGc9LnCrWnxaxYxKzuR0XvWDb2qkdIHEc5dDNmu6RAJA7lgw1NPD/7YPg+ZpLsL6W3p/N+0oidlYe1vNC5mmg3uk4LDcXegGbZdiR1MObadLl8V9hM6pC2VybPUK/3rOER/HirpsZ8k9ZcKzo2I6HdpOuvHCE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=fqV/Y7gl; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="fqV/Y7gl" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-ac3eb3fdd2eso706792466b.0 for ; Mon, 24 Mar 2025 08:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1742830454; x=1743435254; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=xRWYwpfb+Qm0/LZ29AYhcqtDsg2o5q/MxVz554Yo+yk=; b=fqV/Y7gl3A+nzJWgWVFe+IEhaRydBSbnkZJDpGei4Pey4zmcC6pUD02drg8L7T22ex Y0mMrBGgvwpbPz/Wmcrz00DrIuzyNBIUN6IEcorfwV2wqi+pd0k2pq14BxnEtS/8FKow PcZonkZPmIYwtwnrousKhUnZuseHLfPjvUXsqZHsEoNjYbhli087vTcZHRIoFJ578G2T PtRZSuinelSo8F+nQ+iS9hXI5K/vcnUf0zhXMF3k1uM4odr0at2iwOoEvAPZwGZvVLHp RACi+X9twz72VX2vud3sP+OeEmEtH9p82HCoJSzhnKzpN24ogQS9ymcWjvqqVR+B9KKQ xMTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742830454; x=1743435254; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xRWYwpfb+Qm0/LZ29AYhcqtDsg2o5q/MxVz554Yo+yk=; b=QYme1sC1He4kZcKVutRWlCQ9ctHUSqgH5Q99ZCNt6wj4l46zwSy1He8wYTmbUHSbdy JT4klEdbGIMHR3HSCXYTLBVoadYgPpxVGzYZHPfUL698DgjNdFRetAXWFNEVSpMAMjD4 W3nyGB3sesukSYTtlfUYgBnstxrFMa0Hl/RbWlwvEoNqyxUVCTqnCKXcZ566idAtcOM7 qDU8l2l9w3PCmdk4KSquUtmTiX/bYyTwuEep0sDmjR8HeVNxrJfTf5xKmWYu4Jft7LNX 5iB0nJCtWBxCq1zJlTdy8SWvzqaj3UkX+wSeuBCAuLrKwnXexG3elJufG1yMNCUU7apF 8ppg== X-Forwarded-Encrypted: i=1; AJvYcCV6j/4VWpS0MwA6tTsmKKX6szc4O0dKzFkOkQJ5jEfCcorQySczzvM7n56rxgdtzm5/cmED8IHH2wp/IaA=@vger.kernel.org X-Gm-Message-State: AOJu0YzmvKCoVZ0fvR86tv6jGxKiVsrawg8nEoiqc0nOH4eStz0lgBdx R1hT9L1lL45rjkecuMieITD94M85qy0zJqsLSiN7Fn4SFbxrj8GXmx17+3zbs54= X-Gm-Gg: ASbGncu/UrfnehRwPbYHDC0aANZpEiQb1xHwwNdWt4zkcnuVgHsCqQj4Pjp38ondF3T QtwdB5mzbp5o3xqNA4JdnsxLAidNQEXhWuxE+KFgTz00hXfUuXj8ud7of3fjYvyTF4TqfKdD3hd L0BaREFZQPJBqIpXX7xqEj8ZuPEUqfbhcMaMjLN6UEi2n6Z5GCRApnczJg0eh+pBHtamYXDAH2a sbL6DkHY6VdYv2DOAUJ4wSw7eXb5EnE2pa+fhjWusNeu00qRo6ptV/SrTkMy+OvAOHVixtDyR5A voUViK7foWS2OOHYwd5aidUB0sABWE4jIDy35Q8r5aLAGLMnO1vfoZQTEoHLLFhwFrngktIY427 dbZKRSQjSgEjU/DxG7m48M5E92XEp X-Google-Smtp-Source: AGHT+IFWUzpGuHqazl0dpTOmipY8A50S66wW8ZDj1rQKEydjpZVDbROVxeCvHwm+5oYARuqtOVEg6A== X-Received: by 2002:a17:907:3f9b:b0:ac2:63a9:df0b with SMTP id a640c23a62f3a-ac3f251f206mr1143189666b.35.1742830453945; Mon, 24 Mar 2025 08:34:13 -0700 (PDT) Received: from puffmais.c.googlers.com (8.239.204.35.bc.googleusercontent.com. [35.204.239.8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac3ef86e44dsm690219466b.31.2025.03.24.08.34.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Mar 2025 08:34:13 -0700 (PDT) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Mon, 24 Mar 2025 15:34:10 +0000 Subject: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250324-acpm-atomic-v2-2-7d87746e1765@linaro.org> References: <20250324-acpm-atomic-v2-0-7d87746e1765@linaro.org> In-Reply-To: <20250324-acpm-atomic-v2-0-7d87746e1765@linaro.org> To: Tudor Ambarus , Krzysztof Kozlowski , Alim Akhtar Cc: Peter Griffin , Will McVicker , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, =?utf-8?q?Andr=C3=A9_Draszik?= X-Mailer: b4 0.14.2 We need to access the PMIC during late system shutdown and at that time we are not allowed to sleep anymore. To make this case work, detect this condition and use busy waiting via udelay() instead of usleep_range() in that situation. The code isn't switched over to udelay() unconditionally so as to not waste resources during normal operation. acpm_may_sleep() was heavily inspired by the I2C subsystem's i2c_in_atomic_xfer_mode(). Reviewed-by: Tudor Ambarus Signed-off-by: Andr=C3=A9 Draszik --- udelay(10) causes a checkpatch warning (it suggests to use usleep_range() instead for usec >=3D 10), but that's exactly what we can not do. Reducing the udelay to be smaller will generally cause the loop to be iterated more than once, which I wanted to avoid. I could reflow the code to hide the actual value from checkpatch, e.g. with the help of a local variable if that is preferred to ignoring the checkpatch warning. --- drivers/firmware/samsung/exynos-acpm.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/sams= ung/exynos-acpm.c index 542eaff03f9e39422a8c5345ca75e05c1710a9ee..4f65f7ef39b5fdbf5bb10f6ee9f= fb78c5e34d8b2 100644 --- a/drivers/firmware/samsung/exynos-acpm.c +++ b/drivers/firmware/samsung/exynos-acpm.c @@ -15,6 +15,8 @@ #include #include #include +#include +#include #include #include #include @@ -25,6 +27,7 @@ #include #include #include +#include #include #include =20 @@ -273,6 +276,17 @@ static int acpm_get_rx(struct acpm_chan *achan, const = struct acpm_xfer *xfer) return 0; } =20 +/* + * When ACPM transfers happen very late, e.g. to access a PMIC when poweri= ng + * down, we can not sleep. We do want to sleep in the normal case, though,= to + * avoid wasting CPU cycles! + */ +static bool acpm_may_sleep(void) +{ + return system_state <=3D SYSTEM_RUNNING || + (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? preemptible() : !irqs_disabled()); +} + /** * acpm_dequeue_by_polling() - RX dequeue by polling. * @achan: ACPM channel info. @@ -300,7 +314,10 @@ static int acpm_dequeue_by_polling(struct acpm_chan *a= chan, return 0; =20 /* Determined experimentally. */ - usleep_range(20, 30); + if (!acpm_may_sleep()) + udelay(10); + else + usleep_range(20, 30); } while (ktime_before(ktime_get(), timeout)); =20 dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx.\n", --=20 2.49.0.395.g12beb8f557-goog