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: <75cbeeed-84c9-7637-b2a7-b37d87f5872e@linaro.org>
Date:   Mon, 31 Jul 2023 15:01:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.1
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>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <11386dd27487075a9a0b1a2aa7794951@dev.tdt.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 31/07/2023 14:59, Florian Eckert wrote:
> Thanks for your reply,
> 
>> 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.

> 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.

Best regards,
Krzysztof