Re: [PATCH net-next v2] dt-bindings: net: ath11k: document the inputs of the ath11k on WCN6855

[Kalle Valo <kvalo@kernel.org>]

Bartosz Golaszewski <brgl@bgdev.pl> writes:

> On Thu, 19 Sep 2024 09:48:41 +0200, Kalle Valo <kvalo@kernel.org> said:
>> Krzysztof Kozlowski <krzk@kernel.org> writes:
>>
>>> On 14/08/2024 10:23, Bartosz Golaszewski wrote:
>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> Describe the inputs from the PMU of the ath11k module on WCN6855.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>> ---
>>>> v1 -> v2:
>>>> - update the example
>>>
>>> I don't understand why this patch is no being picked up. The code
>>> correct represents the piece of hardware. The supplies should be
>>> required, because this one particular device - the one described in this
>>> binding - cannot work without them.
>>
>> I have already explained the situation. With supplies changed to
>> optional I'm happy take the patch.
>>
>
> No, silent NAKing and needless stalling is what you're doing. I responded to
> your last email with extensive clarifications. You're being told by the
> experts on the subject matter (Krzysztof and Conor) that the change is correct.
>
> The change has no functional impact on the driver code.

Until now it was possible to use qcom,ath11k-calibration-variant DT
property with M.2 devices. If your patch is applied that's not possible
anymore.

> It's also in line with commit 71839a929d9e ("dt-bindings: net:
> wireless: qcom,ath11k: describe the ath11k on QCA6390") under which we
> had literally the same discussion and that you ended up picking up
> after all.

I don't care about QCA6390 as it's not really used anywhere anymore. I
picked up 71839a929d9e, even though I considered it to be wrong, so that
your pwrseq subsystem is not delayed. But WCN6855 is a different matter
as it's more widely used.

> Arnd: I've added you here to bring this to your attention because it's somewhat
> related to what we discussed yesterday. It's a change that is very much
> SoC-specific, that has trouble getting upstream due to the driver's maintainer
> unwilingness to accept it. Is this a case where a change to DT bindings should
> go through the SoC rather than the driver tree?

Like I have said, I'm happy to take the patch if the supplies are
optional. Why can't we do that?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches