From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Andrew Davis <afd@ti.com>, Peter Rosin <peda@axentia.se>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mux: mmio: use reg property when parent device is not a syscon
Date: Tue, 16 May 2023 18:19:36 +0200 [thread overview]
Message-ID: <7d73a37f-80b7-b623-1b71-fa19bf379713@linaro.org> (raw)
In-Reply-To: <895c84f5-4a3c-fd2c-2b43-1a1996862e15@ti.com>
On 16/05/2023 17:18, Andrew Davis wrote:
> On 5/15/23 4:14 PM, Peter Rosin wrote:
>> Hi!
>>
>> 2023-05-15 at 21:19, Andrew Davis wrote:
>>> The DT binding for the reg-mux compatible states it can be used when the
>>> "parent device of mux controller is not syscon device". It also allows
>>> for a reg property. When the parent device is indeed not a syscon device,
>>> nor is it a regmap provider, we should fallback to using that reg
>>> property to identify the address space to use for this mux.
>>
>> We should? Says who?
>>
>> Don't get me wrong, I'm not saying the change is bad or wrong, I would just
>> like to see an example where it matters. Or, at least some rationale for why
>> the code needs to change other than covering some case that looks like it
>> could/should be possible based on the binding. I.e., why is it not better to
>> "close the hole" in the binding instead?
>>
>
> Sure, so this all stated when I was building a checker to make sure that drivers
> are not mapping overlapping register spaces. I noticed syscon nodes are a source
> of that so I'm trying to look into their usage.
>
> To start, IHMO there is only one valid use for syscon and that is when more than
> one driver needs to access shared bits in a single register. DT has no way to
It has... what about all existing efuse/nvmem devices?
> describe down to the bit granular level, so one must give that register to
> a "syscon node", then have the device node use a phandle to the syscon node:
>
> common_reg: syscon@10000 {
> compatible = "syscon";
> reg = <0x10000 0x4>;
> };
>
> consumer@1 {
> syscon-efuse = <&common_reg 0x1>;
> };
>
> consumer@2 {
> syscon-efuse = <&common_reg 0x2>;
> };
>
> Something like that, then regmap will take care of synchronizing access.
Syscon is not for this.
>
...
>
> Ideally DT nodes all describe their register space in a "reg"
> property and all the "large collection of devices" spaces become
> "simple-bus" nodes. "syscon" nodes can then be limited to only the
> rare case when multiple devices share bits in a single register.
>
> If Rob and Krzysztof agree I can send a patch with the above
> guidance to the Devicetree Specification repo also.
Agree on what?
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-05-16 16:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 19:19 Andrew Davis
2023-05-15 21:14 ` Peter Rosin
2023-05-16 15:18 ` Andrew Davis
2023-05-16 16:19 ` Krzysztof Kozlowski [this message]
2023-05-16 16:29 ` Andrew Davis
2023-05-16 16:49 ` Krzysztof Kozlowski
2023-05-16 17:47 ` Andrew Davis
2023-05-16 18:33 ` Krzysztof Kozlowski
2023-05-16 18:59 ` Andrew Davis
2023-05-16 18:37 ` Krzysztof Kozlowski
2023-05-16 18:44 ` Krzysztof Kozlowski
2023-05-16 20:37 ` Andrew Davis
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=7d73a37f-80b7-b623-1b71-fa19bf379713@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=afd@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=peda@axentia.se \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.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
all inboxes | Powered by JetHome®