devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-omap@vger.kernel.org,
	 devicetree <devicetree@vger.kernel.org>,
	 Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee@kernel.org>,
	 dakr@kernel.org, "Rafael J. Wysocki" <rafael@kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Mark Brown <broonie@kernel.org>,
	tony@atomide.com, rogerq@kernel.org,  khilman@baylibre.com,
	aaro koskinen <aaro.koskinen@iki.fi>,
	 Conor Dooley <conor+dt@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>, robh <robh@kernel.org>
Subject: Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems
Date: Sat, 29 Nov 2025 16:18:35 +0100 (CET)	[thread overview]
Message-ID: <253085958.4428.1764429515315.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20251129153644.333498f1@kemnade.info>

----- 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

  reply	other threads:[~2025-11-29 15:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-29 14:20 [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems Richard Weinberger
2025-11-29 14:20 ` [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs Richard Weinberger
2025-11-29 15:23   ` Krzysztof Kozlowski
2025-11-29 15:33     ` Richard Weinberger
2025-11-29 15:44       ` Krzysztof Kozlowski
2025-11-29 15:49         ` Krzysztof Kozlowski
2025-11-29 23:02           ` Andreas Kemnade
2025-11-29 15:56         ` Richard Weinberger
2025-11-30  8:17           ` Krzysztof Kozlowski
2025-12-01 21:34             ` Richard Weinberger
2025-12-01 21:41               ` Krzysztof Kozlowski
2025-12-01 22:40                 ` Richard Weinberger
2025-12-01 12:19       ` Mark Brown
2025-12-01 13:13   ` Rob Herring
2025-11-29 14:20 ` [PATCH 2/4] regmap: Allow disabling debugfs via regmap_config Richard Weinberger
2025-12-01 12:03   ` Mark Brown
2025-11-29 14:20 ` [PATCH 3/4] syscon: Wire up has-inaccessible-regs Richard Weinberger
2025-11-29 15:25   ` Krzysztof Kozlowski
2025-11-29 14:20 ` [PATCH 4/4] arm: dts: omap: Mark various register maps as dangerous Richard Weinberger
2025-11-29 15:26   ` Krzysztof Kozlowski
2025-11-29 15:35     ` Richard Weinberger
2025-11-29 15:54       ` Krzysztof Kozlowski
2025-11-29 16:02         ` Richard Weinberger
2025-11-29 16:48       ` Andreas Kemnade
2025-11-29 14:36 ` [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems Andreas Kemnade
2025-11-29 15:18   ` Richard Weinberger [this message]
2025-12-01 12:27   ` Mark Brown
2025-12-01 12:26 ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=253085958.4428.1764429515315.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=aaro.koskinen@iki.fi \
    --cc=andreas@kemnade.info \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=khilman@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rogerq@kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).