From: Richard Weinberger <richard@nod.at>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
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>
Subject: Re: [PATCH 1/4] dt-bindings: Document new common property: has-inaccessible-regs
Date: Mon, 1 Dec 2025 22:34:46 +0100 (CET) [thread overview]
Message-ID: <2010740416.11902.1764624886863.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <c303a5f3-4283-445e-9e0e-053fab32a468@kernel.org>
----- 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
next prev parent reply other threads:[~2025-12-01 21:34 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 [this message]
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
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=2010740416.11902.1764624886863.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=krzk@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).