Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0ab2f6c1-4f48-592e-1123-d89d5eb0d164@linaro.org>
Date:   Sat, 5 Aug 2023 21:09:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.14.0
Subject: Re: [PATCH 2/2] dt-bindings: clock: intel,cgu-lgm: add
 mxl,control-gate option
Content-Language: en-US
To:     Florian Eckert <fe@dev.tdt.de>
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
References: <20230731100349.184553-1-fe@dev.tdt.de>
 <20230731100349.184553-3-fe@dev.tdt.de>
 <780aa090-3a97-abab-271f-59790df29cc4@linaro.org>
 <11386dd27487075a9a0b1a2aa7794951@dev.tdt.de>
 <75cbeeed-84c9-7637-b2a7-b37d87f5872e@linaro.org>
 <2053f32f262911061e3e56540e4b51d4@dev.tdt.de>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <2053f32f262911061e3e56540e4b51d4@dev.tdt.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 01/08/2023 10:09, Florian Eckert wrote:
> 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!

Then unfortunately this is not a correct change.

Best regards,
Krzysztof