From nobody Fri Sep 25 00:42:05 2026 Received: from mail-oa2-f10.google.com (mail-oa2-f10.google.com [74.125.231.74]) (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 7143B3F12C1 for ; Fri, 18 Sep 2026 04:58:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.231.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789707483; cv=none; b=a9Rx7BENW3UdakIK+h84o2N2RR4AAls2SCfSLjCBeZKLEjaKn1Io4inZozLCbRKNbPd8RuVHHA/QYo0Y9HNCbfkCMHNcRbihWNZt5mQTOM8k2v93ydJ5Cf1gfXLzJ/i/2pEOUC/QNbDv81UFrVu1zgI59tw3k2dHXEIM+Ir3Ucg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789707483; c=relaxed/simple; bh=QApoySis0Adh6uF/PzHVfhA1jkpjYHZNgPhek+gBJ7E=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=A8MZKpmBDs8ItObu3+VA72iOfacuMgm1Hxg6iSju1eKALZz8W+xbPshfo5vLfs0pz0yB4BDPPadv8CvmqT+/TmP7tmhgsqGIxkOxYT/pFTYRptpnsea5+CljUyrNIchqM3ukl0ruC6+nrdoWShR0FjqutKTg1nBJ3nc8isBVTkQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DNP2ARos; arc=none smtp.client-ip=74.125.231.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DNP2ARos" Received: by mail-oa2-f10.google.com with SMTP id 586e51a60fabf-46adea418f3so98108fac.1 for ; Thu, 17 Sep 2026 21:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789707480; x=1790312280; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=UqClDMZv+Qp3g2QhTysx0rBLnCkZVZnC/Rs9Rzbs0+0=; b=DNP2ARosjyKw+bY806+Xx3kEQMAbw/NYtfLsiI0AUZtDEjmQT84M/PR3YA2edJbNol GTx07XQgvJ0qpS4WDD9hzWHQQC916mzEzICsB+0tphLjUiLNsdeSGCOj3zX9yloIjg/8 SdrUPMEY0YPStVup277lMtnx5rUPNVrZ6jF5K9fJYVpqL8xYpogmW/qhBaEvzk8VunUS ts9AmAHd7jjKeeqEThDdFfN4g0E8MHbh8s1euwqVmdV7aAwD2UdjB0XGqbma/OPWSeKD 6Ga4wCa1LKHxqD6EvaxwUFKyvxOk4X7WKZwoKMVi58HJCyD9hUtOVZEIPcx1AGa72OYF Yddw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789707480; x=1790312280; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UqClDMZv+Qp3g2QhTysx0rBLnCkZVZnC/Rs9Rzbs0+0=; b=mn2+KV95hRCD6pBl6tCpPRIbgss4HjgUKeM/2LorRcYiPLR0RcNjJ7hzexnoIS0gQA h81ggGZzSdiORGZfaN9lKAu2ja9IS7kqtdQyVkSiqa6WTaF6hXDdapnwZE0dwi5P1NcN zMgivP3HhKD7RAqJdLN9Vz5zd63E8asgscNKK5yY2dM9z0bCL+AMUajK7UKx0PN++59z 0VGYbhwNXmRttlbdhS55XRDHORyKE/+XjgmyyOSoWSZtAYFyJtPQP6kDcKCrNYXZolm9 1dJ+MGld8vkbGIhN2VH/WZ7TkyKZBpFq8h9qIorZMgUVlT+TXqcRF30zLqaTgeC8eJlh kQ/Q== X-Forwarded-Encrypted: i=1; AKwUvBzplWs/ut6NCcKzNjVDPP0pB7u6rirSPbLZqilj3RG3OqT8PD9EcSuMiVT5GzStyPIKf2uuInb6rQ+w/yQ=@vger.kernel.org X-Gm-Message-State: AFuF++mhdIh2MYndUmDtQkrBAv2pWmM9NxG0qHXoTQRDK6//hLSkETEF MDlJZh+GR/OEe5zs6i7yoyPKKez/xsmlw6d4G2r5hjnNNtVJaATvQCOnRBq05NWY4hU= X-Gm-Gg: AYBFou34uRM6csYLIGx/HlG+FwwvgYU+5dujp80cNC2YlZvWJuKYntaivE6GZdIzovR JA8BymjRWX4nZhWkmJzmG6wrFdRMWG5BHHXADTDdlPL15fMp99yjSkCbi8VvMZBqqUzzhbg0gBJ HR8JOxMA4VBFXeLqaacb3Orb6UUn9C04THIzz0qe+cJCD79AYCW2wR9l+6CEc8J9EuZqQf9BHww /RILP0tC/s+bGCWCnWYyDpGnuHltIUeYmRIzPJ+XMI3K7n98zkp657fbviQOvv7cw/ni85Dwpur X2MZ7Zhpu1dV5wsfuz9BXOu0zsPefAuyyD12m+MUrKH4bGXl2an9dxYDiLMfo+0mp05HRw1lsSq K6lVrxzJ2Vwv/0uzaBEzfzMg8YGUH788s03YGhbKW/B4NSszusAZ1KCfyT3QorbN3xMd4uQzOak fLb+5V6Odmk8LHbwRppig0cBelLaXp/b+6+Y5ElMLqbaDzzVYerF6pdI9977YRwcfVqcShIhBDt 3X9 X-Received: by 2002:a05:6870:2419:b0:483:b498:9db0 with SMTP id 586e51a60fabf-486e5447154mr1433078fac.14.1789707480336; Thu, 17 Sep 2026 21:58:00 -0700 (PDT) Received: from [192.168.18.164] ([2600:8804:5716:d800::b712]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-48739da0d0dsm256318fac.12.2026.09.17.21.57.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2026 21:57:53 -0700 (PDT) From: Ryan Brue Date: Thu, 17 Sep 2026 23:57:46 -0500 Subject: [PATCH 1/2] dt-bindings: mfd: mediatek: mt6397: describe the RTC's nvmem layout 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: <20260917-rbrue-suez-upstreaming-mt6397-rtc-nvmem-v1-1-558b8f95cfbc@gmail.com> References: <20260917-rbrue-suez-upstreaming-mt6397-rtc-nvmem-v1-0-558b8f95cfbc@gmail.com> In-Reply-To: <20260917-rbrue-suez-upstreaming-mt6397-rtc-nvmem-v1-0-558b8f95cfbc@gmail.com> To: Sen Chu , Sean Wang , Macpaul Lin , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , AngeloGioacchino Del Regno , Eddie Huang , Alexandre Belloni Cc: linux-pm@vger.kernel.org, mfd@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-rtc@vger.kernel.org, Ryan Brue X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789707469; l=1572; i=ryanbrue.dev@gmail.com; s=20260906; h=from:subject:message-id; bh=QApoySis0Adh6uF/PzHVfhA1jkpjYHZNgPhek+gBJ7E=; b=mjeSErd6IUo2Z5QDXzSoT7MEYbyj3Na50gNAofJEh5wz/azQT61QJzOrgH1djAKYxTLLJUkYV wo88yBIlUloAzlG19N2bRJfn1YRBdEMkcgp1nZ1QQEMSYEmHHj+zw0v X-Developer-Key: i=ryanbrue.dev@gmail.com; a=ed25519; pk=KsUvVaP//v/2q+ZBuacc7cLbsyEYn+AD71Sn28oZWKo= Four of the MT6397 RTC's alarm registers use only their low bits; the high byte of each is storage the clock and the alarm don't touch. MediaTek's documentation names them RTC_NEW_SPARE0 to RTC_NEW_SPARE3 and assigns the first to a fuel gauge, which is what a battery driver reads at boot so that the reported capacity does not jump across a reboot. They sit in the RTC's always-on domain, so the driver can offer them as a battery-backed nvmem provider. Allow a board to lay cells out over them. Assisted-by: LLM Signed-off-by: Ryan Brue Reviewed-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/D= ocumentation/devicetree/bindings/mfd/mediatek,mt6397.yaml index 3cbc0dc12c31..5c89c589b53c 100644 --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml @@ -81,6 +81,15 @@ properties: =20 start-year: true =20 + nvmem-layout: + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml + description: + The RTC carries four bytes of storage that neither the clock nor= the + alarm uses, in the high half of four of the alarm registers, and + offers them as a battery-backed nvmem provider. MediaTek's + documentation names them RTC_NEW_SPARE0 to RTC_NEW_SPARE3 and gi= ves + the first to a fuel gauge. + required: - compatible =20 --=20 2.55.0 From nobody Fri Sep 25 00:42:05 2026 Received: from mail-oo2-f3.google.com (mail-oo2-f3.google.com [74.125.231.131]) (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 A391C43B3E3 for ; Fri, 18 Sep 2026 04:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.231.131 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789707486; cv=none; b=i1wS2pSglaG9zMlhYTNRXtgFwVaI98hUJdWGL1efDt3DSIEeF02aWBYX83faLjFEINkMP/ePeeOp9wJIvqwKHxtJ/g3b8RhIQukv6YbBlqjcdHEeuO4I9z+BnBkkV9vxjBC3aoUAHLZYYV2XEpwWLkoZd684TqiLNtOm/V7tmyw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789707486; c=relaxed/simple; bh=1ZbFpDNmPpKPUw8gavi59S7TugQ/2BR2pAG4PVbmBvQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=peT1oqnQd8BSZZ2w9LB3opCFe8FxKHlnJKU3FX07u3oCWtQCCpPVM65W0YNTW2CymXTAZGkcDNpjEWXAp1m7DEw1ESJveuH0yCx7lugefHN4cCDDP3T5he1NBlfkCufD7HQw6JmCWxG3eu6zxLjFZwdMJaWwiAQg5APmAtu802s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RKfTiUgp; arc=none smtp.client-ip=74.125.231.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RKfTiUgp" Received: by mail-oo2-f3.google.com with SMTP id 006d021491bc7-6b35c65f4cdso121461eaf.0 for ; Thu, 17 Sep 2026 21:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789707483; x=1790312283; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=O2vctS1HDPIT/X25n9pLYfCPg6VUQlM6OzxcQLhiTME=; b=RKfTiUgpbGI2O95h6oM/71226s4gw5TNrgZAf29hi7Z/cyF3vo9nkZOJRIrT3KL+EK A3r9Ied19wveBX3OaRta3F9acrNxg6VNw10rpD+4Fw2MRk5DqiJhwOrOlyNvSklWIAuZ 01mIBe1w6v9aTN68pTG7mjUT803swR+ZZbUxYkrprXUQeXJcj4aDRy4SdziFb/fEJ1l9 +ctEbtICOrH0id1U2UAKulvCH20YAaTqIdiIbnbbdUmo02k+rV7Sx/VkYHPG/bLWOrDc aIrs4YSJomC857wzzWAsXjEQ2O5A4zouplWaDWPHUCCn7TBI6Lh4hxeUFLQtX0tTO2V/ vn8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789707483; x=1790312283; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=O2vctS1HDPIT/X25n9pLYfCPg6VUQlM6OzxcQLhiTME=; b=JP2veDBClrl15n665Rh9mEAvdRcR/6emyyfCDvgAqrqkGoUC3cUfo2B/4ks5S7zMVA PetECjXsIKQgNRnp5wu+8AjFaZ9gnyLC2623jmjebUt86aUx6KXcYxQiS+IRFEH0EEAH Y7+b6FZ0Qo9CxA5lolEtB78qI5v24WgEz5UFnaFKkqKRwj64NPf17r6LPdm5K86UXWem 7XMiwHr8v6NlYzLzX1rhxWKIg/4uyGAWpxo58p9r4AdLpLjt8SY55QQDfNs2z9wSEpro /bNJJUrzVOEaLJCHr5J+vHOyfT6y7LngNHlzg+QncbGvpst5xCj9cJ91Ka05VZ8q/XHg misw== X-Forwarded-Encrypted: i=1; AKwUvBymJjrsJoIJyji8NZ++n2JkVXXIf16C5tVsVMz77UTHERTKbjc4YOQIjiBrIp/26t9FgRO1+IXaeC//QgI=@vger.kernel.org X-Gm-Message-State: AFuF++lFUz6jk+NnmQB3UQ/fT8i0BiLtRpR7u/d8CaIoalKgb74npuqT TXVrMtJl1bb77srAsBFcMQmt3qcwNK8YFbVRk8DzfDgQY0ubE0ZgFaI2+UP2MEyusMA= X-Gm-Gg: AYBFou006YXbaFIFPMCdxrsw8DykIA8/21zp1WQEeH2wHZPL2DhQGtBQk7HfZ9kCxXi JsyUts/iAv4VnZnUrovqUBfvfTs/0uPOBT91tflOmV5VcipZ7rJqrJdzqZ+J3f0Lg8Slj/W8Apm qkB2vhBfSIm0SYgatvFnNmXiOuenEnqDVYoUSWTQqSbqulSfPGFvt5CVFW+n53gooMvpjqrUhgz 3B9Vq4Vt7512OopPFJhd86xxq8x71/syeQRnOnPoPq1kWIoY49Y6q4lIP3CaWi+BBLZ6zkH0+Ul +HqkORSuwT1+xLnf94uVrDwMkbebK0ty+SedknM0MT2sGnDpcZPs+8N99lsNX9EdZmROCwiDWEp iDaoLHveYaQVClovQxtIc0goTJwjPyfhmbsYTcEVcuPxPuCsZ6qjmE3BENglQjx8RqhQMGoWLrT CNhQohdPgDnNbkRrZzjpERqzG56tgdgf8KkXt71e7gBy3DhYsUGCsCXPniEQCcjD9nQQ== X-Received: by 2002:a05:6820:198e:b0:6ba:1356:2038 with SMTP id 006d021491bc7-6ca9dc81d82mr1247500eaf.65.1789707483400; Thu, 17 Sep 2026 21:58:03 -0700 (PDT) Received: from [192.168.18.164] ([2600:8804:5716:d800::b712]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-48739da0d0dsm256318fac.12.2026.09.17.21.58.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2026 21:58:02 -0700 (PDT) From: Ryan Brue Date: Thu, 17 Sep 2026 23:57:47 -0500 Subject: [PATCH 2/2] rtc: mt6397: expose the spare bytes of the alarm registers as nvmem 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: <20260917-rbrue-suez-upstreaming-mt6397-rtc-nvmem-v1-2-558b8f95cfbc@gmail.com> References: <20260917-rbrue-suez-upstreaming-mt6397-rtc-nvmem-v1-0-558b8f95cfbc@gmail.com> In-Reply-To: <20260917-rbrue-suez-upstreaming-mt6397-rtc-nvmem-v1-0-558b8f95cfbc@gmail.com> To: Sen Chu , Sean Wang , Macpaul Lin , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , AngeloGioacchino Del Regno , Eddie Huang , Alexandre Belloni Cc: linux-pm@vger.kernel.org, mfd@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-rtc@vger.kernel.org, Ryan Brue X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789707469; l=5079; i=ryanbrue.dev@gmail.com; s=20260906; h=from:subject:message-id; bh=1ZbFpDNmPpKPUw8gavi59S7TugQ/2BR2pAG4PVbmBvQ=; b=kj88aZa+h4fhuHQwM8Bk8GTy18OwBUHg5C5G/Eakbrvp92M6E9GMdVV5SYpbTN1UoeBxPc9GB pvRQ/rrqw2PDudl5VHFcBTBuqsjCkWZg2xKtUjEWDMv3azffj7wA3JR X-Developer-Key: i=ryanbrue.dev@gmail.com; a=ed25519; pk=KsUvVaP//v/2q+ZBuacc7cLbsyEYn+AD71Sn28oZWKo= Each alarm field lives in the low bits of its register and the driver masks its writes accordingly, so the high byte of four of them is storage the RTC never touches. MediaTek names these RTC_NEW_SPARE0 to RTC_NEW_SPARE3 and gives the first to a fuel gauge, which is how its PMIC battery drivers carry a state of charge over a reboot. Offer all four as a battery-backed nvmem provider, so that a consumer does not have to reach into this block behind the driver's back. Doing it here is what makes it safe: a write lands under the same lock the alarm paths take, so it can neither be lost inside mtk_rtc_set_alarm()'s read-modify-write nor fire the write trigger in the middle of one. The nvmem core does not range check a cell against the provider size, so the callbacks check the offset themselves. Tested on an MT6397; MediaTek's spare map for mt6323 matches, and the alarm field masks are common to every compatible this driver binds. Assisted-by: LLM Signed-off-by: Ryan Brue Reviewed-by: AngeloGioacchino Del Regno --- drivers/rtc/rtc-mt6397.c | 91 ++++++++++++++++++++++++++++++++++++++= +++- include/linux/mfd/mt6397/rtc.h | 7 ++++ 2 files changed, 97 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c index 3d857681f760..d6e156516aa6 100644 --- a/drivers/rtc/rtc-mt6397.c +++ b/drivers/rtc/rtc-mt6397.c @@ -4,6 +4,8 @@ * Author: Tianping.Fang */ =20 +#include +#include #include #include #include @@ -243,10 +245,91 @@ static const struct rtc_class_ops mtk_rtc_ops =3D { .set_alarm =3D mtk_rtc_set_alarm, }; =20 +/* + * The spare byte of each of these registers, in the order a board address= es + * them as RTC_NEW_SPARE0 to RTC_NEW_SPARE3. + */ +static const u32 mtk_rtc_spare_reg[] =3D { + RTC_AL_HOU, RTC_AL_DOM, RTC_AL_DOW, RTC_AL_MTH, +}; + +static int mtk_rtc_nvram_read(void *priv, unsigned int offset, void *val, + size_t bytes) +{ + struct mt6397_rtc *rtc =3D priv; + u8 *buf =3D val; + u32 data; + int ret =3D 0; + + if (offset >=3D ARRAY_SIZE(mtk_rtc_spare_reg) || + bytes > ARRAY_SIZE(mtk_rtc_spare_reg) - offset) + return -EINVAL; + + mutex_lock(&rtc->lock); + + while (bytes--) { + ret =3D regmap_read(rtc->regmap, + rtc->addr_base + mtk_rtc_spare_reg[offset++], + &data); + if (ret) + break; + + *buf++ =3D FIELD_GET(RTC_SPARE_MASK, data); + } + + mutex_unlock(&rtc->lock); + + return ret; +} + +static int mtk_rtc_nvram_write(void *priv, unsigned int offset, void *val, + size_t bytes) +{ + struct mt6397_rtc *rtc =3D priv; + u8 *buf =3D val; + int ret =3D 0; + + if (offset >=3D ARRAY_SIZE(mtk_rtc_spare_reg) || + bytes > ARRAY_SIZE(mtk_rtc_spare_reg) - offset) + return -EINVAL; + + mutex_lock(&rtc->lock); + + while (bytes--) { + ret =3D regmap_update_bits(rtc->regmap, + rtc->addr_base + mtk_rtc_spare_reg[offset++], + RTC_SPARE_MASK, + FIELD_PREP(RTC_SPARE_MASK, *buf++)); + if (ret) + goto out; + } + + /* + * None of it reaches the always-on domain until the write trigger, + * which commits every pending alarm register at once -- so this runs + * under the same lock the alarm paths take, rather than landing in + * the middle of one of them. + */ + ret =3D mtk_rtc_write_trigger(rtc); +out: + mutex_unlock(&rtc->lock); + + return ret; +} + static int mtk_rtc_probe(struct platform_device *pdev) { struct resource *res; struct mt6397_chip *mt6397_chip =3D dev_get_drvdata(pdev->dev.parent); + struct nvmem_config nvmem_cfg =3D { + .name =3D "mt6397_rtc_spare", + .word_size =3D 1, + .stride =3D 1, + .size =3D ARRAY_SIZE(mtk_rtc_spare_reg), + .type =3D NVMEM_TYPE_BATTERY_BACKED, + .reg_read =3D mtk_rtc_nvram_read, + .reg_write =3D mtk_rtc_nvram_write, + }; struct mt6397_rtc *rtc; int ret; =20 @@ -293,7 +376,13 @@ static int mtk_rtc_probe(struct platform_device *pdev) rtc->rtc_dev->start_secs =3D mktime64(1968, 1, 2, 0, 0, 0); rtc->rtc_dev->set_start_time =3D true; =20 - return devm_rtc_register_device(rtc->rtc_dev); + ret =3D devm_rtc_register_device(rtc->rtc_dev); + if (ret) + return ret; + + nvmem_cfg.priv =3D rtc; + + return devm_rtc_nvmem_register(rtc->rtc_dev, &nvmem_cfg); } =20 #ifdef CONFIG_PM_SLEEP diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h index 27883af44f87..f4da579ec638 100644 --- a/include/linux/mfd/mt6397/rtc.h +++ b/include/linux/mfd/mt6397/rtc.h @@ -49,6 +49,13 @@ =20 #define RTC_AL_SEC 0x0018 =20 +/* The high byte of four of the alarms is spare, always-on storage */ +#define RTC_AL_HOU 0x001c +#define RTC_AL_DOM 0x001e +#define RTC_AL_DOW 0x0020 +#define RTC_AL_MTH 0x0022 +#define RTC_SPARE_MASK GENMASK(15, 8) + #define RTC_AL_SEC_MASK 0x003f #define RTC_AL_MIN_MASK 0x003f #define RTC_AL_HOU_MASK 0x001f --=20 2.55.0