linux-kernel - [PATCH V2] mfd: syscon: Use regmap max_register_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240903184710.1552067-1-nm@ti.com>
Date: Tue, 3 Sep 2024 13:47:10 -0500
From: Nishanth Menon <nm@...com>
To: Lee Jones <lee@...nel.org>
CC: Arnd Bergmann <arnd@...db.de>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, Nishanth Menon <nm@...com>,
        Mark Brown
	<broonie@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        <linux-arm-msm@...r.kernel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        <bcm-kernel-feedback-list@...adcom.com>,
        Florian Fainelli
	<florian.fainelli@...adcom.com>,
        <linux-stm32@...md-mailman.stormreply.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>
Subject: [PATCH V2] mfd: syscon: Use regmap max_register_is_0 as needed

syscon has always set the optional max_register configuration of
regmap to ensure the correct checks are in place. However, a recent
commit 0ec74ad3c157 ("regmap: rework ->max_register handling")
introduced explicit configuration in regmap framework for register
maps that is exactly 1 register, when max_register is pointing to a
valid register 0. This commit solved a previous limitation of regmap
framework.

Update syscon driver to consistent in regmap configuration for
all sizes of syscons by using this new capability by setting
max_register_is_0, when the max_register is valid and 0.

Signed-off-by: Nishanth Menon <nm@...com>
---

Based on my search
https://gist.github.com/nmenon/d537096d041fa553565fba7577d2cd24, the
pattern of syscon registers that may potentially be impacted by this
patch (that are exactly 1 register wide) is probably limited, though
this patch in itself was inspired by a buggy driver code fixed in
https://lore.kernel.org/linux-pm/20240828131915.3198081-1-nm@ti.com/
I have tried to Cc lists that may be interested in looking closer to
avoid un-intended side-effects.

Changes since V1:
* Incorporate review comments by rewording commit message and $subject
  and dropped Fixes.
* No functional change to the patch.
* Expand the CC list to notify potential users.

V1: https://lore.kernel.org/all/20240828121008.3066002-1-nm@ti.com/

Cc: Mark Brown <broonie@...nel.org>
Cc: Shawn Guo <shawnguo@...nel.org>
Cc: linux-arm-msm@...r.kernel.org
Cc: Bjorn Andersson <andersson@...nel.org>
Cc: bcm-kernel-feedback-list@...adcom.com
Cc: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: linux-stm32@...md-mailman.stormreply.com
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>

 drivers/mfd/syscon.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 2ce15f60eb10..3e1d699ba934 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -108,6 +108,8 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_res)
 	syscon_config.reg_stride = reg_io_width;
 	syscon_config.val_bits = reg_io_width * 8;
 	syscon_config.max_register = resource_size(&res) - reg_io_width;
+	if (!syscon_config.max_register)
+		syscon_config.max_register_is_0 = true;

 	regmap = regmap_init_mmio(NULL, base, &syscon_config);
 	kfree(syscon_config.name);
@@ -357,6 +359,9 @@ static int syscon_probe(struct platform_device *pdev)
 		return -ENOMEM;

 	syscon_config.max_register = resource_size(res) - 4;
+	if (!syscon_config.max_register)
+		syscon_config.max_register_is_0 = true;
+
 	if (pdata)
 		syscon_config.name = pdata->label;
 	syscon->regmap = devm_regmap_init_mmio(dev, base, &syscon_config);

-- 
2.46.0