From: Florian Eckert <fe@dev.tdt.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: mturquette@baylibre.com, sboyd@kernel.org, yzhu@maxlinear.com,
rtanwar@maxlinear.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Eckert.Florian@googlemail.com
Subject: Re: [PATCH 2/2] dt-bindings: clock: intel,cgu-lgm: add mxl,control-gate option
Date: Tue, 01 Aug 2023 10:09:50 +0200 [thread overview]
Message-ID: <2053f32f262911061e3e56540e4b51d4@dev.tdt.de> (raw)
In-Reply-To: <75cbeeed-84c9-7637-b2a7-b37d87f5872e@linaro.org>
Hello Krzysztof,
>>> You described the desired Linux feature or behavior, not the actual
>>> hardware. The bindings are about the latter, so instead you need to
>>> rephrase the property and its description to match actual hardware
>>> capabilities/features/configuration etc.
>>
>> You have correctly identified that this is not a hardware
>> configuration,
>> but a driver configuration. Currently, the driver is configured so
>> that
>> the gates cannot be switched via the clk subsystem callbacks. When
>> registering the data structures from the driver, I have to pass a flag
>> GATE_CLK_HW so that the gate is managed by the driver.
>>
>> I didn't want to always change the source of the driver when it has to
>> take
>> care of the GATE, so I wanted to map this via the dts.
>>
>> I have a board support package from Maxlinear for the Lightning
>> Mountain
>> Soc
>> with other drivers that are not upstream now. Some of them use the
>> clock framework some of them does not.
>>
>> Due to missing documents it is not possible to send these drivers
>> upstream.
>
> So when you upstream them, the binding becomes wrong or not needed?
> Sorry, bindings are entirely independent of OS, so using this as an
> argument is clear no-go.
Yes, that would probably be the case, as the maxlinear drivers are at
an early stage and are not yet upstreamable in my opinion. If I had the
documents, I would take a closer look. But they are developing behind
closed doors. Nothing can be contributed. Not until the drivers are
hopefully upstream at some point as the cgu-lgm.
>> Strictly speaking, this is about the gptc and the watchdog.
>>
>> Since it is a buildin_platform driver, it can also not work via
>> module parameters.
>
> None of this explains any hardware related part of this binding. You
> created now policy for one specific OS. Devicetree, which is OS
> independent, is not for such purposes.
Yes this would be the case. Maybe I need to patch the cgu-lgm.c [1]
and send it upstream to restore the old behavior.
Because the following commit has changed the behaviour [2].
Unfortunately, it is also included in 5.15 stable branch.
Which in my opinion should not have happened!
Best regards,
Florian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/x86/clk-lgm.c?h=v6.5-rc4
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/clk/x86/clk-cgu.c?h=v5.15.123&id=a0583edea4fdb7b5b87a077263dddab476e9f138
next prev parent reply other threads:[~2023-08-01 8:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 10:03 [PATCH 0/2] clk: mxl: add mxl,control-gate dts property Florian Eckert
2023-07-31 10:03 ` [PATCH 1/2] " Florian Eckert
2023-07-31 10:03 ` [PATCH 2/2] dt-bindings: clock: intel,cgu-lgm: add mxl,control-gate option Florian Eckert
2023-07-31 11:11 ` Rob Herring
2023-07-31 12:03 ` Krzysztof Kozlowski
2023-07-31 12:59 ` Florian Eckert
2023-07-31 13:01 ` Krzysztof Kozlowski
2023-08-01 8:09 ` Florian Eckert [this message]
2023-08-05 19:09 ` Krzysztof Kozlowski
2023-08-08 7:53 ` Yi xin Zhu
2023-08-09 8:56 ` Florian Eckert
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=2053f32f262911061e3e56540e4b51d4@dev.tdt.de \
--to=fe@dev.tdt.de \
--cc=Eckert.Florian@googlemail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=rtanwar@maxlinear.com \
--cc=sboyd@kernel.org \
--cc=yzhu@maxlinear.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).