Re: [RFC PATCH 01/18] dt-bindings: net: wireless: describe the ath12k AHB module

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/09/2024 13:28, Raj Kumar Bhagat wrote:
> On 9/4/2024 1:08 PM, Krzysztof Kozlowski wrote:
>> On 04/09/2024 09:23, Raj Kumar Bhagat wrote:
>>>>> +  qcom,board_id:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>> +    description:
>>>>> +      Board id value, it identifies the variant of ath12k WiFi device.
>>>>
>>>> Please do not upstream whatever you have in your vendor tree... You even
>>>> copied its style! There is no such property in upstream.
>>>>
>>>> NAK, you are duplicating compatibles.
>>>>
>>>>
>>>
>>> qcom,board_id is a new parameter introduced to distinguish between different variants
>>> of ath12k devices that share the same compatible value. This differentiation is crucial
>>> as these variants have different qcom,board_id values (with the same compatible) based
>>
>> You must explain why compatible cannot be used for that.
>>
> 
> The compatible property is used to define the variant of the Ath12k device. However, the
> Ath12k device variant does not change with different capabilities or configurations
> (e.g., operating band). The qcom,board_id parameter is introduced to define these
> configurations, not the device variant itself.

operating aspects are run-time, so not suitable here. It's all still
vague for me.

> 
>>> on WiFi frequency bands capability. For example, 2 GHz, 5 GHz, 6 GHz, or multi-band
>>> variants of ath12k devices have different qcom,board_id values.
>>>
>>> In the next version, I will include the above information in the qcom,board_id
>>> description.
>>
>> Please follow DTS coding style. And style of existing properties like
>> this. Did you look for them? I claim you just sent whatever you had in
>> downstream.
>>
> 
> Checked "Devicetree Specification, Release v0.4", section 4.1.1,
> seems "_" to be avoided for property name and hyphen "-" to be used. Also, qcom,board-id
> is already taken in "Documentation/devicetree/bindings/arm/qcom.yaml". In the next
> version will change this property name.

Look at existing bindings and see how they are doing it. Sorry, you
still did not give any good rationale why compatibles cannot be used. If
this is board specific implementation, then the board compatible defines
differences.

You need to be specific, not so vague, about problem you are solving.
Don't answer with half-baked explanations just to get rid of reviewer.

Best regards,
Krzysztof