[PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

[PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

[Richard Weinberger]

It came to my attention that commands such as `grep -r / -e ...` can cause
crashes on an AM572x based system.
An investigation found that reading from various files in /sys/kernel/debug/regmap
causes imprecise async data aborts.

One of these register maps is the CTRL_MODULE_CORE register map at 0x4A002000.
It contains various registers marked as reserved, but the manual indicates
that read access is still allowed.
On said system, reading from most registers seems to work, but for some
an async data abort happens. So it's not entirely clear what registers are safe
and which are not.

So, add tooling to allow disabling debugfs access to such dangerous registers.
Splitting the register map definitions in the device tree seemed less practical to
me since it would unnecessarily make the device trees more complicated.

Richard Weinberger (4):
  dt-bindings: Document new common property: has-inaccessible-regs
  regmap: Allow disabling debugfs via regmap_config
  syscon: Wire up has-inaccessible-regs
  arm: dts: omap: Mark various register maps as dangerous

 .../devicetree/bindings/common-properties.txt        | 12 ++++++++++++
 arch/arm/boot/dts/ti/omap/dra7-l4.dtsi               |  4 ++++
 arch/arm/boot/dts/ti/omap/dra7.dtsi                  |  1 +
 arch/arm/boot/dts/ti/omap/dra74x.dtsi                |  1 +
 drivers/base/regmap/regmap.c                         |  2 ++
 drivers/mfd/syscon.c                                 | 10 ++++++++++
 include/linux/regmap.h                               |  3 +++
 7 files changed, 33 insertions(+)

-- 
2.51.0

[PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Richard Weinberger]

This property is used to denote that a certain register map contains
registers that are inaccessible under conditions only a device driver
can know.
The purpose of this property is to disable register access through debug
facilities outside of the device driver.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 .../devicetree/bindings/common-properties.txt        | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/common-properties.txt b/Documentation/devicetree/bindings/common-properties.txt
index 98a28130e100f..edf6d0b8cf1b1 100644
--- a/Documentation/devicetree/bindings/common-properties.txt
+++ b/Documentation/devicetree/bindings/common-properties.txt
@@ -83,3 +83,15 @@ gpio@0 {
 	      #gpio-cells = <2>;
 	      #daisy-chained-devices = <3>;
 };
+
+Inaccessible registers
+----------------------
+
+If a register map as described by the 'reg' property contains registers
+that cannot be accessed for various reasons and splitting the register
+definition is not possible, use this property to denote that uncontrolled
+access outside of a device driver should be disabled.
+On Linux, for example, this disables regmap debugfs access
+
+Optional properties:
+- has-inaccessible-regs: Boolean
-- 
2.51.0

[PATCH 2/4] regmap: Allow disabling debugfs via regmap_config

[Richard Weinberger]

Regmap already disables register access via debugfs as soon as a register
map is used without taking locks.
Go a step further and allow disabling debugfs via regmap_config such that
device drivers can decide on their own whether uncontrolled register access
via debugfs is harmful.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 drivers/base/regmap/regmap.c | 2 ++
 include/linux/regmap.h       | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index ce9be3989a218..38d7a03aa7637 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -697,6 +697,8 @@ struct regmap *__regmap_init(struct device *dev,
 	if (ret)
 		goto err_map;
 
+	map->debugfs_disable = config->debugfs_disable;
+
 	ret = -EINVAL; /* Later error paths rely on this */
 
 	if (config->disable_locking) {
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 55343795644b9..646501a055eba 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -395,6 +395,7 @@ typedef void (*regmap_unlock)(void *);
  *
  * @ranges: Array of configuration entries for virtual address ranges.
  * @num_ranges: Number of range configuration entries.
+ * @debugfs_disable: Disable debugfs access to this register.
  */
 struct regmap_config {
 	const char *name;
@@ -467,6 +468,8 @@ struct regmap_config {
 
 	const struct regmap_range_cfg *ranges;
 	unsigned int num_ranges;
+
+	bool debugfs_disable;
 };
 
 /**
-- 
2.51.0

[PATCH 3/4] syscon: Wire up has-inaccessible-regs

[Richard Weinberger]

Evaluate the has-inaccessible-regs device tree property to disable
debugfs access if a register map contains dangerous/harmful registers.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 drivers/mfd/syscon.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ae71a2710bed8..73fff0df3f42f 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -70,6 +70,16 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_res)
 	else if (of_property_read_bool(np, "native-endian"))
 		syscon_config.val_format_endian = REGMAP_ENDIAN_NATIVE;
 
+
+	/*
+	 * Disable debugfs access if a register map has various inaccessible
+	 * registers.
+	 * In such a case the device driver has to know exactly how and when
+	 * access is allowed but general access via userspace can cause harm.
+	 */
+	if (of_property_read_bool(np, "has-inaccessible-regs"))
+		syscon_config.debugfs_disable = true;
+
 	/*
 	 * search for reg-io-width property in DT. If it is not provided,
 	 * default to 4 bytes. regmap_init_mmio will return an error if values
-- 
2.51.0

[PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

[Richard Weinberger]

These register maps contain registers where reads can cause an
imprecise async data abort.
Mark these register maps with has-inaccessible-regs to make sure
they cannot be accessed via debugfs and only by device drivers that
hopefully know exactly how and when access is allowed.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 ++++
 arch/arm/boot/dts/ti/omap/dra7.dtsi    | 1 +
 arch/arm/boot/dts/ti/omap/dra74x.dtsi  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index c9282f57ffa5e..bd037e199946e 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -69,6 +69,7 @@ scm_conf: scm_conf@0 {
 					#address-cells = <1>;
 					#size-cells = <1>;
 					ranges = <0 0x0 0x1400>;
+					has-inaccessible-regs;
 
 					pbias_regulator: pbias_regulator@e00 {
 						compatible = "ti,pbias-dra7", "ti,pbias-omap";
@@ -110,11 +111,13 @@ scm_conf1: scm_conf@1c04 {
 					compatible = "syscon";
 					reg = <0x1c04 0x0020>;
 					#syscon-cells = <2>;
+					has-inaccessible-regs;
 				};
 
 				scm_conf_pcie: scm_conf@1c24 {
 					compatible = "syscon";
 					reg = <0x1c24 0x0024>;
+					has-inaccessible-regs;
 				};
 
 				sdma_xbar: dma-router@b78 {
@@ -4306,6 +4309,7 @@ target-module@c000 {			/* 0x4ae0c000, ap 17 50.0 */
 			scm_wkup: scm_conf@0 {
 				compatible = "syscon";
 				reg = <0 0x1000>;
+				has-inaccessible-regs;
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi b/arch/arm/boot/dts/ti/omap/dra7.dtsi
index 711ce4c31bb1f..1b1f31608d37e 100644
--- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
@@ -359,6 +359,7 @@ bandgap: bandgap@4a0021e0 {
 		dsp1_system: dsp_system@40d00000 {
 			compatible = "syscon";
 			reg = <0x40d00000 0x100>;
+			has-inaccessible-regs;
 		};
 
 		dra7_iodelay_core: padconf@4844a000 {
diff --git a/arch/arm/boot/dts/ti/omap/dra74x.dtsi b/arch/arm/boot/dts/ti/omap/dra74x.dtsi
index cfb39dde49300..d814c31576797 100644
--- a/arch/arm/boot/dts/ti/omap/dra74x.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra74x.dtsi
@@ -47,6 +47,7 @@ ocp {
 		dsp2_system: dsp_system@41500000 {
 			compatible = "syscon";
 			reg = <0x41500000 0x100>;
+			has-inaccessible-regs;
 		};
 
 
-- 
2.51.0

Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

[Andreas Kemnade]

On Sat, 29 Nov 2025 15:20:38 +0100
Richard Weinberger <richard@nod.at> wrote:

> It came to my attention that commands such as `grep -r / -e ...` can cause
> crashes on an AM572x based system.
> An investigation found that reading from various files in /sys/kernel/debug/regmap
> causes imprecise async data aborts.
> 
> One of these register maps is the CTRL_MODULE_CORE register map at 0x4A002000.
> It contains various registers marked as reserved, but the manual indicates
> that read access is still allowed.
> On said system, reading from most registers seems to work, but for some
> an async data abort happens. So it's not entirely clear what registers are safe
> and which are not.
> 
it is usually not about individual registers, but about accessing 
unpowered devices/modules,

so it is probably more the logic like:

if (pm_runtime_is_suspended(regmap->device))
	-EACCESS;

Try to play around with on >power/control in sysfs.

> So, add tooling to allow disabling debugfs access to such dangerous registers.
> Splitting the register map definitions in the device tree seemed less practical to
> me since it would unnecessarily make the device trees more complicated.
> 
So is it really a description of the hardware? Maybe there are some special
cases, too.

Regards,
Andreas

Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Andreas Kemnade" <andreas@kemnade.info>
> it is usually not about individual registers, but about accessing
> unpowered devices/modules,
> 
> so it is probably more the logic like:
> 
> if (pm_runtime_is_suspended(regmap->device))
>	-EACCESS;
> 
> Try to play around with on >power/control in sysfs.

Well the that regmap is owned by the syscon mfd.
And in case of CTRL_MODULE_CORE only accessing some reserved registers causes
an abort.

For registers like dsp_system@40d00000 it's maybe indeed due to an unpowered module.
I'll double check that.
 
>> So, add tooling to allow disabling debugfs access to such dangerous registers.
>> Splitting the register map definitions in the device tree seemed less practical
>> to
>> me since it would unnecessarily make the device trees more complicated.
>> 
> So is it really a description of the hardware? Maybe there are some special
> cases, too.

IMHO, "There are problematic registers, don't blindly mess with them" is a description of the hardware.

Thanks,
//richard

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Krzysztof Kozlowski]

On 29/11/2025 15:20, Richard Weinberger wrote:
> This property is used to denote that a certain register map contains
> registers that are inaccessible under conditions only a device driver
> can know.

So device driver controls fully their exposure via sysfs.

Binding cannot help here at all.

> The purpose of this property is to disable register access through debug
> facilities outside of the device driver.

You described OS policy which is not suitable for bindings at all. Plus
commit msg really mixes up two separate points - buggy driver which
fails to properly set regmap (or other facility) with some DT-based
restrictions.



Best regards,
Krzysztof

Re: [PATCH 3/4] syscon: Wire up has-inaccessible-regs

[Krzysztof Kozlowski]

On 29/11/2025 15:20, Richard Weinberger wrote:
> Evaluate the has-inaccessible-regs device tree property to disable
> debugfs access if a register map contains dangerous/harmful registers.
> 
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  drivers/mfd/syscon.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index ae71a2710bed8..73fff0df3f42f 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -70,6 +70,16 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_res)
>  	else if (of_property_read_bool(np, "native-endian"))
>  		syscon_config.val_format_endian = REGMAP_ENDIAN_NATIVE;
>  
> +
> +	/*
> +	 * Disable debugfs access if a register map has various inaccessible
> +	 * registers.
> +	 * In such a case the device driver has to know exactly how and when
> +	 * access is allowed but general access via userspace can cause harm.
> +	 */
> +	if (of_property_read_bool(np, "has-inaccessible-regs"))
> +		syscon_config.debugfs_disable = true;

So you mark ENTIRE device like that? Then you don't need the property.
Your compatible already tells you that (IOW, this is fully deducible
from the compatible).

Best regards,
Krzysztof

Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

[Krzysztof Kozlowski]

On 29/11/2025 15:20, Richard Weinberger wrote:
> index 711ce4c31bb1f..1b1f31608d37e 100644
> --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
> +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
> @@ -359,6 +359,7 @@ bandgap: bandgap@4a0021e0 {
>  		dsp1_system: dsp_system@40d00000 {
>  			compatible = "syscon";

Oh, no no, sorry, but buggy/incomplete/legacy DT is not an excuse for
new properties. You cannot have such compatible alone in the first place.

>  			reg = <0x40d00000 0x100>;
> +			has-inaccessible-regs;
>  		};




Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
> On 29/11/2025 15:20, Richard Weinberger wrote:
>> This property is used to denote that a certain register map contains
>> registers that are inaccessible under conditions only a device driver
>> can know.
> 
> So device driver controls fully their exposure via sysfs.
> 
> Binding cannot help here at all.

The driver does not expose them via sysfs, it's the regmap framework via debugfs.
 
>> The purpose of this property is to disable register access through debug
>> facilities outside of the device driver.
> 
> You described OS policy which is not suitable for bindings at all. Plus
> commit msg really mixes up two separate points - buggy driver which
> fails to properly set regmap (or other facility) with some DT-based
> restrictions.

I kind of expected this answer. ;-)

Currently arch/arm/boot/dts/ti/omap/dra7-l4.dtsi binds CTRL_MODULE_CORE to the syscon mfd driver
and various child nodes bind to subranges.
e.g.
scm_conf: scm_conf@0 {
        compatible = "syscon", "simple-bus";
        reg = <0x0 0x1400>;
        #address-cells = <1>;
        #size-cells = <1>;
        ranges = <0 0x0 0x1400>;
        has-inaccessible-regs;

        pbias_regulator: pbias_regulator@e00 {
                compatible = "ti,pbias-dra7", "ti,pbias-omap";
                reg = <0xe00 0x4>;
                syscon = <&scm_conf>;
                pbias_mmc_reg: pbias_mmc_omap5 {
                        regulator-name = "pbias_mmc_omap5";
                        regulator-min-microvolt = <1800000>;
                        regulator-max-microvolt = <3300000>;
                };      
        };      

        phy_gmii_sel: phy-gmii-sel@554 {
                compatible = "ti,dra7xx-phy-gmii-sel";
                reg = <0x554 0x4>;
                #phy-cells = <1>;
        };      

        scm_conf_clocks: clocks {
                #address-cells = <1>;
                #size-cells = <0>;
        };      
};

So, drivers like ti,pbias-dra7 or ti,dra7xx-phy-gmii-sel touch only registers
they know about and this works well.
But syscon manages the whole register map via regmap, and regmap exposes it all
via debugfs.

What solution do you propose?
Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd anymore?

Thanks,
//richard

Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
> An: "richard" <richard@nod.at>, "linux-kernel" <linux-kernel@vger.kernel.org>
> CC: "linux-omap" <linux-omap@vger.kernel.org>, "devicetree" <devicetree@vger.kernel.org>, "Arnd Bergmann"
> <arnd@arndb.de>, "Lee Jones" <lee@kernel.org>, "dakr" <dakr@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, "Greg
> Kroah-Hartman" <gregkh@linuxfoundation.org>, "Mark Brown" <broonie@kernel.org>, "tony" <tony@atomide.com>, "rogerq"
> <rogerq@kernel.org>, "khilman" <khilman@baylibre.com>, "Andreas Kemnade" <andreas@kemnade.info>, "aaro koskinen"
> <aaro.koskinen@iki.fi>, "Conor Dooley" <conor+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "robh"
> <robh@kernel.org>
> Gesendet: Samstag, 29. November 2025 16:26:19
> Betreff: Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

> On 29/11/2025 15:20, Richard Weinberger wrote:
>> index 711ce4c31bb1f..1b1f31608d37e 100644
>> --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
>> +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
>> @@ -359,6 +359,7 @@ bandgap: bandgap@4a0021e0 {
>>  		dsp1_system: dsp_system@40d00000 {
>>  			compatible = "syscon";
> 
> Oh, no no, sorry, but buggy/incomplete/legacy DT is not an excuse for
> new properties. You cannot have such compatible alone in the first place.

Okay, I didn't know that the OMAP DT is in that bad shape.
Is somebody working on a solution?

Thanks,
//richard

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Krzysztof Kozlowski]

On 29/11/2025 16:33, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>> On 29/11/2025 15:20, Richard Weinberger wrote:
>>> This property is used to denote that a certain register map contains
>>> registers that are inaccessible under conditions only a device driver
>>> can know.
>>
>> So device driver controls fully their exposure via sysfs.
>>
>> Binding cannot help here at all.
> 
> The driver does not expose them via sysfs, it's the regmap framework via debugfs.

Driver always tells the regmap which registers are valid. This is not a
new problem, we had it in several devices and fixed drivers.

>  
>>> The purpose of this property is to disable register access through debug
>>> facilities outside of the device driver.
>>
>> You described OS policy which is not suitable for bindings at all. Plus
>> commit msg really mixes up two separate points - buggy driver which
>> fails to properly set regmap (or other facility) with some DT-based
>> restrictions.
> 
> I kind of expected this answer. ;-)
> 
> Currently arch/arm/boot/dts/ti/omap/dra7-l4.dtsi binds CTRL_MODULE_CORE to the syscon mfd driver
> and various child nodes bind to subranges.
> e.g.
> scm_conf: scm_conf@0 {
>         compatible = "syscon", "simple-bus";
>         reg = <0x0 0x1400>;
>         #address-cells = <1>;
>         #size-cells = <1>;
>         ranges = <0 0x0 0x1400>;
>         has-inaccessible-regs;
> 
>         pbias_regulator: pbias_regulator@e00 {
>                 compatible = "ti,pbias-dra7", "ti,pbias-omap";
>                 reg = <0xe00 0x4>;
>                 syscon = <&scm_conf>;
>                 pbias_mmc_reg: pbias_mmc_omap5 {
>                         regulator-name = "pbias_mmc_omap5";
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <3300000>;
>                 };      
>         };      
> 
>         phy_gmii_sel: phy-gmii-sel@554 {
>                 compatible = "ti,dra7xx-phy-gmii-sel";
>                 reg = <0x554 0x4>;
>                 #phy-cells = <1>;
>         };      
> 
>         scm_conf_clocks: clocks {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>         };      
> };
> 
> So, drivers like ti,pbias-dra7 or ti,dra7xx-phy-gmii-sel touch only registers
> they know about and this works well.
> But syscon manages the whole register map via regmap, and regmap exposes it all
> via debugfs.
> 
> What solution do you propose?
> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd anymore?

Fix the driver. In your case, the syscon driver.


Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Krzysztof Kozlowski]

On 29/11/2025 16:44, Krzysztof Kozlowski wrote:
>>         scm_conf_clocks: clocks {
>>                 #address-cells = <1>;
>>                 #size-cells = <0>;
>>         };      
>> };
>>
>> So, drivers like ti,pbias-dra7 or ti,dra7xx-phy-gmii-sel touch only registers
>> they know about and this works well.
>> But syscon manages the whole register map via regmap, and regmap exposes it all
>> via debugfs.
>>
>> What solution do you propose?
>> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd anymore?
> 
> Fix the driver. In your case, the syscon driver.

BTW, the state of existing TI DRA code is so poor that you don't have
many choices... or rather every choice has drawbacks. If this was proper
DTS, then I would say - define register map, used by regmap, for your
compatible either in syscon driver or dedicated driver (thus new driver
will be the syscon provider for you, just like Google GS101 syscon is
special).

Or maybe this is not syscon at all!

Remember that syscon is a collection of miscellaneous system controller
registers. You should not use syscon for other things, like devices with
incomplete hardware description.

Best regards,
Krzysztof

Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

[Krzysztof Kozlowski]

On 29/11/2025 16:35, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>> An: "richard" <richard@nod.at>, "linux-kernel" <linux-kernel@vger.kernel.org>
>> CC: "linux-omap" <linux-omap@vger.kernel.org>, "devicetree" <devicetree@vger.kernel.org>, "Arnd Bergmann"
>> <arnd@arndb.de>, "Lee Jones" <lee@kernel.org>, "dakr" <dakr@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, "Greg
>> Kroah-Hartman" <gregkh@linuxfoundation.org>, "Mark Brown" <broonie@kernel.org>, "tony" <tony@atomide.com>, "rogerq"
>> <rogerq@kernel.org>, "khilman" <khilman@baylibre.com>, "Andreas Kemnade" <andreas@kemnade.info>, "aaro koskinen"
>> <aaro.koskinen@iki.fi>, "Conor Dooley" <conor+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "robh"
>> <robh@kernel.org>
>> Gesendet: Samstag, 29. November 2025 16:26:19
>> Betreff: Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous
> 
>> On 29/11/2025 15:20, Richard Weinberger wrote:
>>> index 711ce4c31bb1f..1b1f31608d37e 100644
>>> --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
>>> +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
>>> @@ -359,6 +359,7 @@ bandgap: bandgap@4a0021e0 {
>>>  		dsp1_system: dsp_system@40d00000 {
>>>  			compatible = "syscon";
>>
>> Oh, no no, sorry, but buggy/incomplete/legacy DT is not an excuse for
>> new properties. You cannot have such compatible alone in the first place.
> 
> Okay, I didn't know that the OMAP DT is in that bad shape.

Heh, let me give you a piece of a spoiler of my OSS Japan talk in a
week: TI (entire TI, not individual sub-platforms) for arm32 is 0%
compliant, meaning EVERY board has issues, and TI has THE HIGHEST total
number of warnings of all active mainline arm32 platforms.

TI ARM32 status is absolutely terrible... TI ARM64 is on quite different
side. :)

More of hall-of-shame on 9th of December...

Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>> So, drivers like ti,pbias-dra7 or ti,dra7xx-phy-gmii-sel touch only registers
>> they know about and this works well.
>> But syscon manages the whole register map via regmap, and regmap exposes it all
>> via debugfs.
>> 
>> What solution do you propose?
>> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd
>> anymore?
> 
> Fix the driver. In your case, the syscon driver.

Please help me to understand what the desired behavior of the driver is.

Currently syscon creates one regmap for everything and passes this regmap
to the individual syscon users.
These users have to know what offset within the regmap is their playground.
If I understand correctly, it would be better if every syscon user would register their own regmap?

Lee, Arnd, what do you think?

Thanks,
//richard

Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>> Okay, I didn't know that the OMAP DT is in that bad shape.
> 
> Heh, let me give you a piece of a spoiler of my OSS Japan talk in a
> week: TI (entire TI, not individual sub-platforms) for arm32 is 0%
> compliant, meaning EVERY board has issues, and TI has THE HIGHEST total
> number of warnings of all active mainline arm32 platforms.

Oh dear. :-S
 
> TI ARM32 status is absolutely terrible... TI ARM64 is on quite different
> side. :)
> 
> More of hall-of-shame on 9th of December...

Let's hope this helps to motivate some TI guys.
I can help with TI platforms I have access to but I don't consider
myself an TI SoC expert to do massive refactoring of their device trees.

Thanks,
//richard

Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous

[Andreas Kemnade]

On Sat, 29 Nov 2025 16:35:31 +0100 (CET)
Richard Weinberger <richard@nod.at> wrote:

> ----- Ursprüngliche Mail -----
> > Von: "Krzysztof Kozlowski" <krzk@kernel.org>
> > An: "richard" <richard@nod.at>, "linux-kernel" <linux-kernel@vger.kernel.org>
> > CC: "linux-omap" <linux-omap@vger.kernel.org>, "devicetree" <devicetree@vger.kernel.org>, "Arnd Bergmann"
> > <arnd@arndb.de>, "Lee Jones" <lee@kernel.org>, "dakr" <dakr@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, "Greg
> > Kroah-Hartman" <gregkh@linuxfoundation.org>, "Mark Brown" <broonie@kernel.org>, "tony" <tony@atomide.com>, "rogerq"
> > <rogerq@kernel.org>, "khilman" <khilman@baylibre.com>, "Andreas Kemnade" <andreas@kemnade.info>, "aaro koskinen"
> > <aaro.koskinen@iki.fi>, "Conor Dooley" <conor+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "robh"
> > <robh@kernel.org>
> > Gesendet: Samstag, 29. November 2025 16:26:19
> > Betreff: Re: [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous  
> 
> > On 29/11/2025 15:20, Richard Weinberger wrote:  
> >> index 711ce4c31bb1f..1b1f31608d37e 100644
> >> --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
> >> +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
> >> @@ -359,6 +359,7 @@ bandgap: bandgap@4a0021e0 {
> >>  		dsp1_system: dsp_system@40d00000 {
> >>  			compatible = "syscon";  
> > 
> > Oh, no no, sorry, but buggy/incomplete/legacy DT is not an excuse for
> > new properties. You cannot have such compatible alone in the first place.  
> 
> Okay, I didn't know that the OMAP DT is in that bad shape.
> Is somebody working on a solution?
> 
well, it is an arduous work, piece by piece work. But things are getting better
slowly. I convert bindings from time to time, mostly the ones
needed by omap3-5 parts, not the active am3/5 parts.

compare
https://gitlab.com/robherring/linux-dt/-/jobs/5620809910#L5618

to the newer
https://gitlab.com/robherring/linux-dt/-/jobs/12112550529#L5156


Regards,
Andreas

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Andreas Kemnade]

On Sat, 29 Nov 2025 16:49:11 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 29/11/2025 16:44, Krzysztof Kozlowski wrote:
> >>         scm_conf_clocks: clocks {
> >>                 #address-cells = <1>;
> >>                 #size-cells = <0>;
> >>         };      
> >> };
> >>
> >> So, drivers like ti,pbias-dra7 or ti,dra7xx-phy-gmii-sel touch only registers
> >> they know about and this works well.
> >> But syscon manages the whole register map via regmap, and regmap exposes it all
> >> via debugfs.
> >>
> >> What solution do you propose?
> >> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd anymore?  
> > 
> > Fix the driver. In your case, the syscon driver.  
> 
> BTW, the state of existing TI DRA code is so poor that you don't have
> many choices... or rather every choice has drawbacks. If this was proper
> DTS, then I would say - define register map, used by regmap, for your
> compatible either in syscon driver or dedicated driver (thus new driver
> will be the syscon provider for you, just like Google GS101 syscon is
> special).
> 
> Or maybe this is not syscon at all!
> 
> Remember that syscon is a collection of miscellaneous system controller
> registers. You should not use syscon for other things, like devices with
> incomplete hardware description.
> 
It is referenced in mmu0_disp1, it looks like some syscon.
mmu0_dsp1:
...
   ti,syscon-mmuconfig = <&dsp1_system 0x0>;

So it looks valid. In code omap-iommu.c, aparrently only one register is
written.

But again, DRA7 is not my area, OMAP3-5: yes.

Regards,
Andreas

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Krzysztof Kozlowski]

On 29/11/2025 16:56, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>>> So, drivers like ti,pbias-dra7 or ti,dra7xx-phy-gmii-sel touch only registers
>>> they know about and this works well.
>>> But syscon manages the whole register map via regmap, and regmap exposes it all
>>> via debugfs.
>>>
>>> What solution do you propose?
>>> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd
>>> anymore?
>>
>> Fix the driver. In your case, the syscon driver.
> 
> Please help me to understand what the desired behavior of the driver is.
> 
> Currently syscon creates one regmap for everything and passes this regmap
> to the individual syscon users.
> These users have to know what offset within the regmap is their playground.
> If I understand correctly, it would be better if every syscon user would register their own regmap?

I don't think so. This device driver, so the syscon, creates the regmap
and knows EXACTLY which registers are valid or not. It is not
responsibility of the consumer to tell the syscon what this syscon is.
Syscon knows that...

Best regards,
Krzysztof

Re: [PATCH 2/4] regmap: Allow disabling debugfs via regmap_config

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Sat, Nov 29, 2025 at 03:20:40PM +0100, Richard Weinberger wrote:
> Regmap already disables register access via debugfs as soon as a register
> map is used without taking locks.
> Go a step further and allow disabling debugfs via regmap_config such that
> device drivers can decide on their own whether uncontrolled register access
> via debugfs is harmful.

What's the use case for this?  Drivers can already mark registers as
unreadable and precious to stop spurious reads.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Sat, Nov 29, 2025 at 04:33:38PM +0100, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----

> > Binding cannot help here at all.

> The driver does not expose them via sysfs, it's the regmap framework via debugfs.

regmap exposes the registers that the driver told it about, it won't
expose anything without the driver telling it about the register.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

[Rob Herring]

On Sat, 29 Nov 2025 15:20:38 +0100, Richard Weinberger wrote:
> It came to my attention that commands such as `grep -r / -e ...` can cause
> crashes on an AM572x based system.
> An investigation found that reading from various files in /sys/kernel/debug/regmap
> causes imprecise async data aborts.
> 
> One of these register maps is the CTRL_MODULE_CORE register map at 0x4A002000.
> It contains various registers marked as reserved, but the manual indicates
> that read access is still allowed.
> On said system, reading from most registers seems to work, but for some
> an async data abort happens. So it's not entirely clear what registers are safe
> and which are not.
> 
> So, add tooling to allow disabling debugfs access to such dangerous registers.
> Splitting the register map definitions in the device tree seemed less practical to
> me since it would unnecessarily make the device trees more complicated.
> 
> Richard Weinberger (4):
>   dt-bindings: Document new common property: has-inaccessible-regs
>   regmap: Allow disabling debugfs via regmap_config
>   syscon: Wire up has-inaccessible-regs
>   arm: dts: omap: Mark various register maps as dangerous
> 
>  .../devicetree/bindings/common-properties.txt        | 12 ++++++++++++
>  arch/arm/boot/dts/ti/omap/dra7-l4.dtsi               |  4 ++++
>  arch/arm/boot/dts/ti/omap/dra7.dtsi                  |  1 +
>  arch/arm/boot/dts/ti/omap/dra74x.dtsi                |  1 +
>  drivers/base/regmap/regmap.c                         |  2 ++
>  drivers/mfd/syscon.c                                 | 10 ++++++++++
>  include/linux/regmap.h                               |  3 +++
>  7 files changed, 33 insertions(+)
> 
> --
> 2.51.0
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: attempting to guess base-commit...
 Base: tags/v6.18-rc7-1539-gff736a286116 (exact match)
 Base: tags/v6.18-rc7-1539-gff736a286116 (use --merge-base to override)

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm/boot/dts/ti/' for 20251129142042.344359-1-richard@nod.at:

arch/arm/boot/dts/ti/omap/am571x-idk.dtb: clock@400 (ti,omap4-cm): '#clock-cells' is a dependency of 'clock-output-names'
	from schema $id: http://devicetree.org/schemas/clock/clock.yaml
arch/arm/boot/dts/ti/omap/am57xx-beagle-x15.dtb: clock@c00 (ti,omap4-cm): '#clock-cells' is a dependency of 'clock-output-names'
	from schema $id: http://devicetree.org/schemas/clock/clock.yaml
arch/arm/boot/dts/ti/omap/am57xx-beagle-x15-revc.dtb: clock@500 (ti,omap4-cm): '#clock-cells' is a dependency of 'clock-output-names'
	from schema $id: http://devicetree.org/schemas/clock/clock.yaml

Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Sat, Nov 29, 2025 at 03:36:44PM +0100, Andreas Kemnade wrote:

> it is usually not about individual registers, but about accessing 
> unpowered devices/modules,

If that's the case the regmap should be in cache only mode while the
device is unpowered.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Rob Herring]

On Sat, Nov 29, 2025 at 8:22 AM Richard Weinberger <richard@nod.at> wrote:
>
> This property is used to denote that a certain register map contains
> registers that are inaccessible under conditions only a device driver
> can know.
> The purpose of this property is to disable register access through debug
> facilities outside of the device driver.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  .../devicetree/bindings/common-properties.txt        | 12 ++++++++++++

This seems to be dead, but just so you are aware, new properties must
be in a schema. Something like this would probably go in dtschema, not
the kernel. (And this file needs to be removed)

Rob

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>>>> What solution do you propose?
>>>> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd
>>>> anymore?
>>>
>>> Fix the driver. In your case, the syscon driver.
>> 
>> Please help me to understand what the desired behavior of the driver is.
>> 
>> Currently syscon creates one regmap for everything and passes this regmap
>> to the individual syscon users.
>> These users have to know what offset within the regmap is their playground.
>> If I understand correctly, it would be better if every syscon user would
>> register their own regmap?
> 
> I don't think so. This device driver, so the syscon, creates the regmap
> and knows EXACTLY which registers are valid or not. It is not
> responsibility of the consumer to tell the syscon what this syscon is.
> Syscon knows that...

How to configure this in syscon?
AFAIK it takes only a single reg property.
Are you suggesting to add many more syscon nodes to the DT to skip the holes?

Currently the scm_conf@0 DT node defines the first 0x1400 bytes
of the CTRL_MODULE_CORE register[0].

Reading from register 0x180 triggers an async data abort here.
The manual describes it as "RESERVED" of type "R".
Lots of other offsets in CTRL_MODULE_CORE are reserved, but reading works.

Long story short, please tell me how to model it in DT and I'll do so.

Thanks,
//richard

[0] https://www.ti.com/lit/ug/spruhz6l/spruhz6l.pdf 18.5.2.1 CTRL_MODULE_CORE Register Summary

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Krzysztof Kozlowski]

On 01/12/2025 22:34, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>>>>> What solution do you propose?
>>>>> Splitting reg = <0x0 0x1400> into many tiny fractions and not using an mfd
>>>>> anymore?
>>>>
>>>> Fix the driver. In your case, the syscon driver.
>>>
>>> Please help me to understand what the desired behavior of the driver is.
>>>
>>> Currently syscon creates one regmap for everything and passes this regmap
>>> to the individual syscon users.
>>> These users have to know what offset within the regmap is their playground.
>>> If I understand correctly, it would be better if every syscon user would
>>> register their own regmap?
>>
>> I don't think so. This device driver, so the syscon, creates the regmap
>> and knows EXACTLY which registers are valid or not. It is not
>> responsibility of the consumer to tell the syscon what this syscon is.
>> Syscon knows that...
> 
> How to configure this in syscon?
> AFAIK it takes only a single reg property.
> Are you suggesting to add many more syscon nodes to the DT to skip the holes?
> 
> Currently the scm_conf@0 DT node defines the first 0x1400 bytes
> of the CTRL_MODULE_CORE register[0].
> 
> Reading from register 0x180 triggers an async data abort here.
> The manual describes it as "RESERVED" of type "R".
> Lots of other offsets in CTRL_MODULE_CORE are reserved, but reading works.
> 
> Long story short, please tell me how to model it in DT and I'll do so.

I already told you:

"...we had it in several devices and fixed drivers."

"Fix the driver. In your case, the syscon driver."

and finally:

"BTW, the state of existing TI DRA code is so poor that you don't have
many choices... or rather every choice has drawbacks. If this was proper
DTS, then I would say - define register map, used by regmap, for your
compatible either in syscon driver or dedicated driver (thus new driver
will be the syscon provider for you, just like Google GS101 syscon is
special)."

What to say more? This is the instruction/proposal.

Best regards,
Krzysztof

Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Krzysztof Kozlowski" <krzk@kernel.org>
>> Long story short, please tell me how to model it in DT and I'll do so.
> 
> I already told you:
> 
> "...we had it in several devices and fixed drivers."
> 
> "Fix the driver. In your case, the syscon driver."
> 
> and finally:
> 
> "BTW, the state of existing TI DRA code is so poor that you don't have
> many choices... or rather every choice has drawbacks. If this was proper
> DTS, then I would say - define register map, used by regmap, for your
> compatible either in syscon driver or dedicated driver (thus new driver
> will be the syscon provider for you, just like Google GS101 syscon is
> special)."
> 
> What to say more? This is the instruction/proposal.

I'm still chewing.
Let me do more research before I come back with more questions.

Thanks,
//richard

Re: [PATCH 2/4] regmap: Allow disabling debugfs via regmap_config

[kernel test robot]

Hi Richard,

kernel test robot noticed the following build errors:

[auto build test ERROR on robh/for-next]
[also build test ERROR on broonie-regmap/for-next lee-mfd/for-mfd-next lee-mfd/for-mfd-fixes linus/master v6.18 next-20251202]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Richard-Weinberger/dt-bindings-Document-new-common-property-has-inaccessible-regs/20251129-222517
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:    https://lore.kernel.org/r/20251129142042.344359-3-richard%40nod.at
patch subject: [PATCH 2/4] regmap: Allow disabling debugfs via regmap_config
config: arc-hsdk_defconfig (https://download.01.org/0day-ci/archive/20251203/202512030854.wgxWw5AH-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251203/202512030854.wgxWw5AH-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512030854.wgxWw5AH-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/base/regmap/regmap.c: In function '__regmap_init':
>> drivers/base/regmap/regmap.c:700:12: error: 'struct regmap' has no member named 'debugfs_disable'
     700 |         map->debugfs_disable = config->debugfs_disable;
         |            ^~


vim +700 drivers/base/regmap/regmap.c

   674	
   675	struct regmap *__regmap_init(struct device *dev,
   676				     const struct regmap_bus *bus,
   677				     void *bus_context,
   678				     const struct regmap_config *config,
   679				     struct lock_class_key *lock_key,
   680				     const char *lock_name)
   681	{
   682		struct regmap *map;
   683		int ret = -EINVAL;
   684		enum regmap_endian reg_endian, val_endian;
   685		int i, j;
   686	
   687		if (!config)
   688			goto err;
   689	
   690		map = kzalloc(sizeof(*map), GFP_KERNEL);
   691		if (map == NULL) {
   692			ret = -ENOMEM;
   693			goto err;
   694		}
   695	
   696		ret = regmap_set_name(map, config);
   697		if (ret)
   698			goto err_map;
   699	
 > 700		map->debugfs_disable = config->debugfs_disable;
   701	
   702		ret = -EINVAL; /* Later error paths rely on this */
   703	
   704		if (config->disable_locking) {
   705			map->lock = map->unlock = regmap_lock_unlock_none;
   706			map->can_sleep = config->can_sleep;
   707			regmap_debugfs_disable(map);
   708		} else if (config->lock && config->unlock) {
   709			map->lock = config->lock;
   710			map->unlock = config->unlock;
   711			map->lock_arg = config->lock_arg;
   712			map->can_sleep = config->can_sleep;
   713		} else if (config->use_hwlock) {
   714			map->hwlock = hwspin_lock_request_specific(config->hwlock_id);
   715			if (!map->hwlock) {
   716				ret = -ENXIO;
   717				goto err_name;
   718			}
   719	
   720			switch (config->hwlock_mode) {
   721			case HWLOCK_IRQSTATE:
   722				map->lock = regmap_lock_hwlock_irqsave;
   723				map->unlock = regmap_unlock_hwlock_irqrestore;
   724				break;
   725			case HWLOCK_IRQ:
   726				map->lock = regmap_lock_hwlock_irq;
   727				map->unlock = regmap_unlock_hwlock_irq;
   728				break;
   729			default:
   730				map->lock = regmap_lock_hwlock;
   731				map->unlock = regmap_unlock_hwlock;
   732				break;
   733			}
   734	
   735			map->lock_arg = map;
   736		} else {
   737			if ((bus && bus->fast_io) ||
   738			    config->fast_io) {
   739				if (config->use_raw_spinlock) {
   740					raw_spin_lock_init(&map->raw_spinlock);
   741					map->lock = regmap_lock_raw_spinlock;
   742					map->unlock = regmap_unlock_raw_spinlock;
   743					lockdep_set_class_and_name(&map->raw_spinlock,
   744								   lock_key, lock_name);
   745				} else {
   746					spin_lock_init(&map->spinlock);
   747					map->lock = regmap_lock_spinlock;
   748					map->unlock = regmap_unlock_spinlock;
   749					lockdep_set_class_and_name(&map->spinlock,
   750								   lock_key, lock_name);
   751				}
   752			} else {
   753				mutex_init(&map->mutex);
   754				map->lock = regmap_lock_mutex;
   755				map->unlock = regmap_unlock_mutex;
   756				map->can_sleep = true;
   757				lockdep_set_class_and_name(&map->mutex,
   758							   lock_key, lock_name);
   759			}
   760			map->lock_arg = map;
   761			map->lock_key = lock_key;
   762		}
   763	
   764		/*
   765		 * When we write in fast-paths with regmap_bulk_write() don't allocate
   766		 * scratch buffers with sleeping allocations.
   767		 */
   768		if ((bus && bus->fast_io) || config->fast_io)
   769			map->alloc_flags = GFP_ATOMIC;
   770		else
   771			map->alloc_flags = GFP_KERNEL;
   772	
   773		map->reg_base = config->reg_base;
   774		map->reg_shift = config->pad_bits % 8;
   775	
   776		map->format.pad_bytes = config->pad_bits / 8;
   777		map->format.reg_shift = config->reg_shift;
   778		map->format.reg_bytes = BITS_TO_BYTES(config->reg_bits);
   779		map->format.val_bytes = BITS_TO_BYTES(config->val_bits);
   780		map->format.buf_size = BITS_TO_BYTES(config->reg_bits + config->val_bits + config->pad_bits);
   781		if (config->reg_stride)
   782			map->reg_stride = config->reg_stride;
   783		else
   784			map->reg_stride = 1;
   785		if (is_power_of_2(map->reg_stride))
   786			map->reg_stride_order = ilog2(map->reg_stride);
   787		else
   788			map->reg_stride_order = -1;
   789		map->use_single_read = config->use_single_read || !(config->read || (bus && bus->read));
   790		map->use_single_write = config->use_single_write || !(config->write || (bus && bus->write));
   791		map->can_multi_write = config->can_multi_write && (config->write || (bus && bus->write));
   792		if (bus) {
   793			map->max_raw_read = bus->max_raw_read;
   794			map->max_raw_write = bus->max_raw_write;
   795		} else if (config->max_raw_read && config->max_raw_write) {
   796			map->max_raw_read = config->max_raw_read;
   797			map->max_raw_write = config->max_raw_write;
   798		}
   799		map->dev = dev;
   800		map->bus = bus;
   801		map->bus_context = bus_context;
   802		map->max_register = config->max_register;
   803		map->max_register_is_set = map->max_register ?: config->max_register_is_0;
   804		map->wr_table = config->wr_table;
   805		map->rd_table = config->rd_table;
   806		map->volatile_table = config->volatile_table;
   807		map->precious_table = config->precious_table;
   808		map->wr_noinc_table = config->wr_noinc_table;
   809		map->rd_noinc_table = config->rd_noinc_table;
   810		map->writeable_reg = config->writeable_reg;
   811		map->readable_reg = config->readable_reg;
   812		map->volatile_reg = config->volatile_reg;
   813		map->precious_reg = config->precious_reg;
   814		map->writeable_noinc_reg = config->writeable_noinc_reg;
   815		map->readable_noinc_reg = config->readable_noinc_reg;
   816		map->cache_type = config->cache_type;
   817	
   818		spin_lock_init(&map->async_lock);
   819		INIT_LIST_HEAD(&map->async_list);
   820		INIT_LIST_HEAD(&map->async_free);
   821		init_waitqueue_head(&map->async_waitq);
   822	
   823		if (config->read_flag_mask ||
   824		    config->write_flag_mask ||
   825		    config->zero_flag_mask) {
   826			map->read_flag_mask = config->read_flag_mask;
   827			map->write_flag_mask = config->write_flag_mask;
   828		} else if (bus) {
   829			map->read_flag_mask = bus->read_flag_mask;
   830		}
   831	
   832		if (config->read && config->write) {
   833			map->reg_read  = _regmap_bus_read;
   834			if (config->reg_update_bits)
   835				map->reg_update_bits = config->reg_update_bits;
   836	
   837			/* Bulk read/write */
   838			map->read = config->read;
   839			map->write = config->write;
   840	
   841			reg_endian = REGMAP_ENDIAN_NATIVE;
   842			val_endian = REGMAP_ENDIAN_NATIVE;
   843		} else if (!bus) {
   844			map->reg_read  = config->reg_read;
   845			map->reg_write = config->reg_write;
   846			map->reg_update_bits = config->reg_update_bits;
   847	
   848			map->defer_caching = false;
   849			goto skip_format_initialization;
   850		} else if (!bus->read || !bus->write) {
   851			map->reg_read = _regmap_bus_reg_read;
   852			map->reg_write = _regmap_bus_reg_write;
   853			map->reg_update_bits = bus->reg_update_bits;
   854	
   855			map->defer_caching = false;
   856			goto skip_format_initialization;
   857		} else {
   858			map->reg_read  = _regmap_bus_read;
   859			map->reg_update_bits = bus->reg_update_bits;
   860			/* Bulk read/write */
   861			map->read = bus->read;
   862			map->write = bus->write;
   863	
   864			reg_endian = regmap_get_reg_endian(bus, config);
   865			val_endian = regmap_get_val_endian(dev, bus, config);
   866		}
   867	
   868		switch (config->reg_bits + map->reg_shift) {
   869		case 2:
   870			switch (config->val_bits) {
   871			case 6:
   872				map->format.format_write = regmap_format_2_6_write;
   873				break;
   874			default:
   875				goto err_hwlock;
   876			}
   877			break;
   878	
   879		case 4:
   880			switch (config->val_bits) {
   881			case 12:
   882				map->format.format_write = regmap_format_4_12_write;
   883				break;
   884			default:
   885				goto err_hwlock;
   886			}
   887			break;
   888	
   889		case 7:
   890			switch (config->val_bits) {
   891			case 9:
   892				map->format.format_write = regmap_format_7_9_write;
   893				break;
   894			case 17:
   895				map->format.format_write = regmap_format_7_17_write;
   896				break;
   897			default:
   898				goto err_hwlock;
   899			}
   900			break;
   901	
   902		case 10:
   903			switch (config->val_bits) {
   904			case 14:
   905				map->format.format_write = regmap_format_10_14_write;
   906				break;
   907			default:
   908				goto err_hwlock;
   909			}
   910			break;
   911	
   912		case 12:
   913			switch (config->val_bits) {
   914			case 20:
   915				map->format.format_write = regmap_format_12_20_write;
   916				break;
   917			default:
   918				goto err_hwlock;
   919			}
   920			break;
   921	
   922		case 8:
   923			map->format.format_reg = regmap_format_8;
   924			break;
   925	
   926		case 16:
   927			switch (reg_endian) {
   928			case REGMAP_ENDIAN_BIG:
   929				map->format.format_reg = regmap_format_16_be;
   930				break;
   931			case REGMAP_ENDIAN_LITTLE:
   932				map->format.format_reg = regmap_format_16_le;
   933				break;
   934			case REGMAP_ENDIAN_NATIVE:
   935				map->format.format_reg = regmap_format_16_native;
   936				break;
   937			default:
   938				goto err_hwlock;
   939			}
   940			break;
   941	
   942		case 24:
   943			switch (reg_endian) {
   944			case REGMAP_ENDIAN_BIG:
   945				map->format.format_reg = regmap_format_24_be;
   946				break;
   947			default:
   948				goto err_hwlock;
   949			}
   950			break;
   951	
   952		case 32:
   953			switch (reg_endian) {
   954			case REGMAP_ENDIAN_BIG:
   955				map->format.format_reg = regmap_format_32_be;
   956				break;
   957			case REGMAP_ENDIAN_LITTLE:
   958				map->format.format_reg = regmap_format_32_le;
   959				break;
   960			case REGMAP_ENDIAN_NATIVE:
   961				map->format.format_reg = regmap_format_32_native;
   962				break;
   963			default:
   964				goto err_hwlock;
   965			}
   966			break;
   967	
   968		default:
   969			goto err_hwlock;
   970		}
   971	
   972		if (val_endian == REGMAP_ENDIAN_NATIVE)
   973			map->format.parse_inplace = regmap_parse_inplace_noop;
   974	
   975		switch (config->val_bits) {
   976		case 8:
   977			map->format.format_val = regmap_format_8;
   978			map->format.parse_val = regmap_parse_8;
   979			map->format.parse_inplace = regmap_parse_inplace_noop;
   980			break;
   981		case 16:
   982			switch (val_endian) {
   983			case REGMAP_ENDIAN_BIG:
   984				map->format.format_val = regmap_format_16_be;
   985				map->format.parse_val = regmap_parse_16_be;
   986				map->format.parse_inplace = regmap_parse_16_be_inplace;
   987				break;
   988			case REGMAP_ENDIAN_LITTLE:
   989				map->format.format_val = regmap_format_16_le;
   990				map->format.parse_val = regmap_parse_16_le;
   991				map->format.parse_inplace = regmap_parse_16_le_inplace;
   992				break;
   993			case REGMAP_ENDIAN_NATIVE:
   994				map->format.format_val = regmap_format_16_native;
   995				map->format.parse_val = regmap_parse_16_native;
   996				break;
   997			default:
   998				goto err_hwlock;
   999			}
  1000			break;
  1001		case 24:
  1002			switch (val_endian) {
  1003			case REGMAP_ENDIAN_BIG:
  1004				map->format.format_val = regmap_format_24_be;
  1005				map->format.parse_val = regmap_parse_24_be;
  1006				break;
  1007			default:
  1008				goto err_hwlock;
  1009			}
  1010			break;
  1011		case 32:
  1012			switch (val_endian) {
  1013			case REGMAP_ENDIAN_BIG:
  1014				map->format.format_val = regmap_format_32_be;
  1015				map->format.parse_val = regmap_parse_32_be;
  1016				map->format.parse_inplace = regmap_parse_32_be_inplace;
  1017				break;
  1018			case REGMAP_ENDIAN_LITTLE:
  1019				map->format.format_val = regmap_format_32_le;
  1020				map->format.parse_val = regmap_parse_32_le;
  1021				map->format.parse_inplace = regmap_parse_32_le_inplace;
  1022				break;
  1023			case REGMAP_ENDIAN_NATIVE:
  1024				map->format.format_val = regmap_format_32_native;
  1025				map->format.parse_val = regmap_parse_32_native;
  1026				break;
  1027			default:
  1028				goto err_hwlock;
  1029			}
  1030			break;
  1031		}
  1032	
  1033		if (map->format.format_write) {
  1034			if ((reg_endian != REGMAP_ENDIAN_BIG) ||
  1035			    (val_endian != REGMAP_ENDIAN_BIG))
  1036				goto err_hwlock;
  1037			map->use_single_write = true;
  1038		}
  1039	
  1040		if (!map->format.format_write &&
  1041		    !(map->format.format_reg && map->format.format_val))
  1042			goto err_hwlock;
  1043	
  1044		map->work_buf = kzalloc(map->format.buf_size, GFP_KERNEL);
  1045		if (map->work_buf == NULL) {
  1046			ret = -ENOMEM;
  1047			goto err_hwlock;
  1048		}
  1049	
  1050		if (map->format.format_write) {
  1051			map->defer_caching = false;
  1052			map->reg_write = _regmap_bus_formatted_write;
  1053		} else if (map->format.format_val) {
  1054			map->defer_caching = true;
  1055			map->reg_write = _regmap_bus_raw_write;
  1056		}
  1057	
  1058	skip_format_initialization:
  1059	
  1060		map->range_tree = RB_ROOT;
  1061		for (i = 0; i < config->num_ranges; i++) {
  1062			const struct regmap_range_cfg *range_cfg = &config->ranges[i];
  1063			struct regmap_range_node *new;
  1064	
  1065			/* Sanity check */
  1066			if (range_cfg->range_max < range_cfg->range_min) {
  1067				dev_err(map->dev, "Invalid range %d: %u < %u\n", i,
  1068					range_cfg->range_max, range_cfg->range_min);
  1069				goto err_range;
  1070			}
  1071	
  1072			if (range_cfg->range_max > map->max_register) {
  1073				dev_err(map->dev, "Invalid range %d: %u > %u\n", i,
  1074					range_cfg->range_max, map->max_register);
  1075				goto err_range;
  1076			}
  1077	
  1078			if (range_cfg->selector_reg > map->max_register) {
  1079				dev_err(map->dev,
  1080					"Invalid range %d: selector out of map\n", i);
  1081				goto err_range;
  1082			}
  1083	
  1084			if (range_cfg->window_len == 0) {
  1085				dev_err(map->dev, "Invalid range %d: window_len 0\n",
  1086					i);
  1087				goto err_range;
  1088			}
  1089	
  1090			/* Make sure, that this register range has no selector
  1091			   or data window within its boundary */
  1092			for (j = 0; j < config->num_ranges; j++) {
  1093				unsigned int sel_reg = config->ranges[j].selector_reg;
  1094				unsigned int win_min = config->ranges[j].window_start;
  1095				unsigned int win_max = win_min +
  1096						       config->ranges[j].window_len - 1;
  1097	
  1098				/* Allow data window inside its own virtual range */
  1099				if (j == i)
  1100					continue;
  1101	
  1102				if (range_cfg->range_min <= sel_reg &&
  1103				    sel_reg <= range_cfg->range_max) {
  1104					dev_err(map->dev,
  1105						"Range %d: selector for %d in window\n",
  1106						i, j);
  1107					goto err_range;
  1108				}
  1109	
  1110				if (!(win_max < range_cfg->range_min ||
  1111				      win_min > range_cfg->range_max)) {
  1112					dev_err(map->dev,
  1113						"Range %d: window for %d in window\n",
  1114						i, j);
  1115					goto err_range;
  1116				}
  1117			}
  1118	
  1119			new = kzalloc(sizeof(*new), GFP_KERNEL);
  1120			if (new == NULL) {
  1121				ret = -ENOMEM;
  1122				goto err_range;
  1123			}
  1124	
  1125			new->map = map;
  1126			new->name = range_cfg->name;
  1127			new->range_min = range_cfg->range_min;
  1128			new->range_max = range_cfg->range_max;
  1129			new->selector_reg = range_cfg->selector_reg;
  1130			new->selector_mask = range_cfg->selector_mask;
  1131			new->selector_shift = range_cfg->selector_shift;
  1132			new->window_start = range_cfg->window_start;
  1133			new->window_len = range_cfg->window_len;
  1134	
  1135			if (!_regmap_range_add(map, new)) {
  1136				dev_err(map->dev, "Failed to add range %d\n", i);
  1137				kfree(new);
  1138				goto err_range;
  1139			}
  1140	
  1141			if (map->selector_work_buf == NULL) {
  1142				map->selector_work_buf =
  1143					kzalloc(map->format.buf_size, GFP_KERNEL);
  1144				if (map->selector_work_buf == NULL) {
  1145					ret = -ENOMEM;
  1146					goto err_range;
  1147				}
  1148			}
  1149		}
  1150	
  1151		ret = regcache_init(map, config);
  1152		if (ret != 0)
  1153			goto err_range;
  1154	
  1155		if (dev) {
  1156			ret = regmap_attach_dev(dev, map, config);
  1157			if (ret != 0)
  1158				goto err_regcache;
  1159		} else {
  1160			regmap_debugfs_init(map);
  1161		}
  1162	
  1163		return map;
  1164	
  1165	err_regcache:
  1166		regcache_exit(map);
  1167	err_range:
  1168		regmap_range_exit(map);
  1169		kfree(map->work_buf);
  1170	err_hwlock:
  1171		if (map->hwlock)
  1172			hwspin_lock_free(map->hwlock);
  1173	err_name:
  1174		kfree_const(map->name);
  1175	err_map:
  1176		kfree(map);
  1177	err:
  1178		if (bus && bus->free_on_exit)
  1179			kfree(bus);
  1180		return ERR_PTR(ret);
  1181	}
  1182	EXPORT_SYMBOL_GPL(__regmap_init);
  1183	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki