Re: [PATCH v2 2/2] dt-bindings: clock: add QCOM SM8350 display clock bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Jonathan Marek (2021-06-04 10:25:41)
> On 6/2/21 5:27 PM, Stephen Boyd wrote:
> > Quoting Jonathan Marek (2021-05-18 17:18:02)
> >> Add sm8350 DISPCC bindings, which are simply a symlink to the sm8250
> >> bindings. Update the documentation with the new compatible.
> >>
> >> Signed-off-by: Jonathan Marek <jonathan@xxxxxxxx>
> >> Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
> >> ---
> >>   .../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml       | 6 ++++--
> >>   include/dt-bindings/clock/qcom,dispcc-sm8350.h              | 1 +
> > 
> >>   2 files changed, 5 insertions(+), 2 deletions(-)
> >>   create mode 120000 include/dt-bindings/clock/qcom,dispcc-sm8350.h
> > 
> > Why the symlink? Can we have the dt authors use the existing header file
> > instead?
> > 
> 
> It would be strange to include bindings with the name of a different 
> SoC. I guess it is a matter a preference, is there any good reason to 
> *not* do it like this?

 $ find include/dt-bindings -type l
 include/dt-bindings/input/linux-event-codes.h
 include/dt-bindings/clock/qcom,dispcc-sm8150.h

It seems to not be common at all.

> 
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> >> index 0cdf53f41f84..8f414642445e 100644
> >> --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> >> @@ -4,24 +4,26 @@
> >>   $id: http://devicetree.org/schemas/clock/qcom,dispcc-sm8x50.yaml#
> >>   $schema: http://devicetree.org/meta-schemas/core.yaml#
> >>   
> >> -title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250
> >> +title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250/SM8350
> > 
> > Maybe just "Binding for SM8x50 SoCs"
> > 
> 
> Its likely these bindings won't be compatible with future "SM8x50" SoCs, 
> listing supported SoCs explicitly will avoid confusion in the future.

The yaml file has sm8x50 in the name. What's the plan there?




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux