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.0On 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
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
----- 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
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.
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
----- 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
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
----- 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
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
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
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
© 2016 - 2025 Red Hat, Inc.