On Fri, 20 Sep 2024 08:22:16 +0200, Kalle Valo <kvalo@xxxxxxxxxx> said:
> Bartosz Golaszewski <brgl@xxxxxxxx> writes:
>
>> On Thu, 19 Sep 2024 09:48:41 +0200, Kalle Valo <kvalo@xxxxxxxxxx> said:
>>> Krzysztof Kozlowski <krzk@xxxxxxxxxx> writes:
>>>
>>>> On 14/08/2024 10:23, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
>>>>>
>>>>> Describe the inputs from the PMU of the ath11k module on WCN6855.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
>>>>> ---
>>>>> 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.
>
This is incorrect, why do you keep repeating it? What will be impossible is
upstreaming DT sources which don't take these supplies - which is what we want.
>> 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.
>
In upstream sources, it's only used in X13s and I added a node for it to
sc8280xp-crd but that's not upstream yet. Am I missing anything? As I said
several times: for out-of-tree DTS, this change does *not* matter.
>> 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?
>
Because this patch reflects the reality of the chipset. And device-tree is
supposed to model the reality. It's not there to configure your firmware
loader.
Bartosz
