Messages in this thread | | | Date | Mon, 25 Apr 2022 21:35:13 +0200 | Subject | Re: [PATCH 2/8] dt-bindings: clock: stm32mp1: describes clocks if "st,stm32mp1-rcc-secure" | From | Marek Vasut <> |
| |
On 4/25/22 21:11, Rob Herring wrote: > On Fri, Apr 22, 2022 at 06:31:25PM +0200, Marek Vasut wrote: >> On 4/22/22 17:09, Alexandre Torgue wrote: >>> In case of "st,stm32mp1-rcc-secure" (stm32mp1 clock driver with RCC >>> security support hardened), "clocks" and "clock-names" describe oscillators >>> and are required. >>> >>> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> >>> >>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml >>> index 7a251264582d..bb0e0b92e907 100644 >>> --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml >>> +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml >>> @@ -58,14 +58,8 @@ properties: >>> - st,stm32mp1-rcc-secure >>> - st,stm32mp1-rcc >>> - const: syscon >>> - >>> - clocks: >>> - description: >>> - Specifies the external RX clock for ethernet MAC. >>> - maxItems: 1 >>> - >>> - clock-names: >>> - const: ETH_RX_CLK/ETH_REF_CLK >>> + clocks: true >>> + clock-names: true >> >> It looks like this should rather be a property than a compatible string -- >> the compatible string is used by the OS to determine which hardware is >> represented by a node, but here it is the same hardware in either case, >> "st,stm32mp1-rcc" and "st,stm32mp1-rcc-secure", it is still the same >> STM32MP1 RCC block, just configured differently by some bootloader stage. >> >> So why not just add one-liner property of the RCC block like ? >> st,rcc-in-secure-configuration > > Because using compatible was already decided.
I see ... may I ask why compatible is OK in this case even though this is encoding a policy (secure/non-secure configuration of the same clock IP) into DT ?
| |