From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: wens@csie.org
Cc: Andre Przywara <andre.przywara@arm.com>,
Vasily Khoruzhick <anarsoul@gmail.com>,
Yangtao Li <tiny.windzz@gmail.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Lukasz Luba <lukasz.luba@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Martin Botka <martin.botka@somainline.org>,
Bob McChesney <bob@electricworry.net>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v3 4/6] thermal: sun8i: add syscon register access code
Date: Tue, 28 Nov 2023 10:13:47 +0100 [thread overview]
Message-ID: <6356d9d1-2110-4195-805c-531bcdbeeb1f@linaro.org> (raw)
In-Reply-To: <CAGb2v64Om8xqpgacbXV9Qf0tbV5qDcSOs7gW-uqSh2HD3Hhu3A@mail.gmail.com>
On 28/11/2023 10:09, Chen-Yu Tsai wrote:
> On Tue, Nov 28, 2023 at 5:02 PM Chen-Yu Tsai <wens@csie.org> wrote:
>>
>> On Tue, Nov 28, 2023 at 4:59 PM Chen-Yu Tsai <wens@csie.org> wrote:
>>>
>>> On Tue, Nov 28, 2023 at 4:30 PM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 28/11/2023 08:50, Chen-Yu Tsai wrote:
>>>>> On Tue, Nov 28, 2023 at 3:43 PM Krzysztof Kozlowski
>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>>
>>>>>> On 28/11/2023 01:58, Andre Przywara wrote:
>>>>>>>
>>>>>>> +static struct regmap *sun8i_ths_get_syscon_regmap(struct device_node *node)
>>>>>>> +{
>>>>>>> + struct device_node *syscon_node;
>>>>>>> + struct platform_device *syscon_pdev;
>>>>>>> + struct regmap *regmap = NULL;
>>>>>>> +
>>>>>>> + syscon_node = of_parse_phandle(node, "syscon", 0);
>>>>>>
>>>>>> Nope. For the 100th time, this cannot be generic.
>>>>>>
>>>>>>> + if (!syscon_node)
>>>>>>> + return ERR_PTR(-ENODEV);
>>>>>>> +
>>>>>>> + syscon_pdev = of_find_device_by_node(syscon_node);
>>>>>>> + if (!syscon_pdev) {
>>>>>>> + /* platform device might not be probed yet */
>>>>>>> + regmap = ERR_PTR(-EPROBE_DEFER);
>>>>>>> + goto out_put_node;
>>>>>>> + }
>>>>>>> +
>>>>>>> + /* If no regmap is found then the other device driver is at fault */
>>>>>>> + regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
>>>>>>> + if (!regmap)
>>>>>>> + regmap = ERR_PTR(-EINVAL);
>>>>>>
>>>>>> Aren't you open-coding existing API to get regmap from syscon?
>>>>>
>>>>> Not really. This is to get a regmap exported by the device. Syscon's regmap
>>>>> is not tied to the device at all.
>>>>
>>>> I am talking about open-coding existing API. Look at syscon.h.
>>>
>>> The underlying implementation is different.
>>>
>>> syscon maintains its own mapping of device nodes to regmaps, and creates
>>> regmaps when none exist. The regmap is not tied to any struct device.
>>> syscon basically exists outside of the driver model and one has no control
>>> over what is exposed because it is meant for blocks that are a collection
>>> of random stuff.
>>
>> My bad. I failed to realize there is a platform device driver for syscon,
>> in addition to the existing "no struct device" implementation.
>
> Actually that doesn't do anything on DT platforms as of commit bdb0066df96e
> ("mfd: syscon: Decouple syscon interface from platform devices"). All the
> regmaps are, as I previously stated, not tied to any struct device.
Sorry, it's your third reply, so I don't know what exactly you want to
discuss.
This code open-codes existing API. Fix it.
>
>>> Here the provider device registers the (limited) regmap it wants to provide,
>>> tying the new regmap to itself. The consumer gets it via the dev_get_regmap()
>>> call. The provider has a main function and isn't exposing that part of its
>>> register map to the outside; only the random bits that were stuffed in are.
>>>
>>>>> With this scheme a device to could export just enough registers for the
>>>>> consumer to use, instead of the whole address range.
>>>>>
>>>>> We do this in the R40 clock controller as well, which has some bits that
>>>>> tweak the ethernet controllers RGMII delay...
>>>>
>>>> Not related.
>>>
>>> Related as in that is possibly what this code was based on, commit
>>> 49a06cae6e7c ("net: stmmac: dwmac-sun8i: Allow getting syscon regmap
>>> from external device").
How duplicating a code is related to R40 controller? Duplicating code is
generic problem, not specific and not related to your hardware.
Best regards,
Krzysztof
next prev parent reply other threads:[~2023-11-28 9:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 0:58 [PATCH v3 0/6] Add support for H616 Thermal system Andre Przywara
2023-11-28 0:58 ` [PATCH v3 1/6] soc: sunxi: sram: export register 0 for THS on H616 Andre Przywara
2023-11-28 0:58 ` [PATCH v3 2/6] dt-bindings: thermal: sun8i: Add H616 THS controller Andre Przywara
2023-11-28 7:41 ` Krzysztof Kozlowski
2023-11-28 0:58 ` [PATCH v3 3/6] thermal: sun8i: explain unknown H6 register value Andre Przywara
2023-11-28 0:58 ` [PATCH v3 4/6] thermal: sun8i: add syscon register access code Andre Przywara
2023-11-28 7:43 ` Krzysztof Kozlowski
2023-11-28 7:50 ` Chen-Yu Tsai
2023-11-28 8:29 ` Krzysztof Kozlowski
2023-11-28 8:59 ` Chen-Yu Tsai
2023-11-28 9:02 ` Chen-Yu Tsai
2023-11-28 9:09 ` Chen-Yu Tsai
2023-11-28 9:13 ` Krzysztof Kozlowski [this message]
2023-11-28 14:11 ` Krzysztof Kozlowski
2023-11-28 14:33 ` Andre Przywara
2023-11-28 14:48 ` Krzysztof Kozlowski
2023-11-28 16:10 ` Andre Przywara
2023-11-28 16:39 ` Chen-Yu Tsai
2023-11-28 16:50 ` Rob Herring
2023-11-29 17:03 ` Andre Przywara
2023-11-29 17:09 ` Chen-Yu Tsai
2023-11-28 0:58 ` [PATCH v3 5/6] thermal: sun8i: add support for H616 THS controller Andre Przywara
2023-12-09 10:44 ` Maksim Kiselev
2023-12-11 0:05 ` Andre Przywara
2023-12-12 18:09 ` Maxim Kiselev
2023-12-14 9:59 ` Andre Przywara
2023-12-17 14:16 ` Maxim Kiselev
2023-11-28 0:58 ` [PATCH v3 6/6] arm64: dts: allwinner: h616: Add thermal sensor and zones Andre Przywara
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=6356d9d1-2110-4195-805c-531bcdbeeb1f@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=anarsoul@gmail.com \
--cc=andre.przywara@arm.com \
--cc=bob@electricworry.net \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=lukasz.luba@arm.com \
--cc=martin.botka@somainline.org \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=rui.zhang@intel.com \
--cc=samuel@sholland.org \
--cc=tiny.windzz@gmail.com \
--cc=wens@csie.org \
/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).