Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 15 Dec 2023 20:03:23 +0800 | Subject | Re: [PATCH v3 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332 platform | From | Jie Luo <> |
| |
On 12/15/2023 6:21 PM, Krzysztof Kozlowski wrote: > On 15/12/2023 11:03, Jie Luo wrote: >>>>>> + cmn-reference-clock: >>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> >>>>> Nothing improved here >>>> >>>> With this change, the warning is not reported when i run >>>> dt_binding_check, looks the new added property needs >>>> the type ref to avoid the warning reported. >>> >>> Nothing improved in the property name, nor its style, nor in the actual >>> contents/values. >> >> This property is for CMN PLL block reference clock configuration, >> so i use this property name. >> >> it will be appreciated if you can suggest a suitable name, thanks. > > See example-schema about naming. Read writing-bindings. You need vendor > prefix for custom properties.
Ok, thanks.
> >> >>> >>> ... >>> >>>>>> + reset-gpios: >>>>>> + maxItems: 1 >>>>>> + >>>>>> + reset-assert-us: >>>>>> + maxItems: 1 >>>>> >>>>> This does not look related to ipq5332. >>>> >>>> The reset gpio properties are needed on ipq5332, since qca8084 phy is >>>> connected, which uses the MDIO bus level gpio reset. >>> >>> I am talking about this property, not these properties. >> >> ok. >> >>> >>>> >>>> Without declaring these gpio properties, the warning will be reported >>>> by dt_binding_check. >>> >>> How is it even possible to have warnings if there is no such node in >>> DTS? We do not care about warnings in your downstream code. >>> >>> >>> Best regards, >>> Krzysztof >>> >> >> If i do not declare the property "reset-assert-us" and >> "reset-deassert-us", the warning will be reported by "make >> dt_binding_check" since i >> add a example in this file. > > This argument does not make sense, sorry. Obviously if property is not > allowed, it should be removed. > > Provide rationale, in terms of hardware, why this property must be added > and why it cannot be deduced from the compatible. > > Best regards, > Krzysztof >
So i can remove "reset-assert-us" and "reset-deassert-us" from the added example to avoid the dt check warning? even these two properties are needed to be defined in the device tree to make this driver working correctly.
| ![\](/images/icornerr.gif) |