Re: [PATCH 1/1] dt-bindings: clock: meson: Convert axg-audio-clkc to YAML format

[Rob Herring <robh@kernel.org>]

On Thu, Aug 10, 2023 at 09:51:05AM +0200, Jerome Brunet wrote:
> 
> On Thu 10 Aug 2023 at 09:46, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> 
> > On 10/08/2023 09:32, Jerome Brunet wrote:
> >>>>> Then why do you have this huge, apparently unnecessary, oneOf? If it's
> >>>>> the same, then drop the oneOf and make number of clocks fixed.
> >>>>
> >>>> But as far as I understand the number of clocks is not fixed. As Jerome pointed 
> >>>> out in the other post, it can have any combination of clocks and range from 1 
> >>>> up to 11, where 'pclk' is always 1st clock.
> >>>> I currently have no idea how to constraint that, despite limiting the number 
> >>>> of clock-names.
> >>>
> >>> The same as in all other clock controllers (was also present on my list
> >>> of useful patterns - Variable length arrays (per variant)):
> >>> https://elixir.bootlin.com/linux/v5.19-rc6/source/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml#L57
> >> 
> >> In the example provided, the number and list of clocks required by each
> >> controller variant is fixed, if I'm reading it correctly
> >> 
> >> Here the controller (regardless of the variant) accepts a maximum 29
> >> clock inputs. Only pclk is required. It is valid to have any of 28
> >> optional clocks at index 2, 3, etc ...
> >
> > I actually doubt that it is optional. These are valid clock inputs. I
> > could imagine they are optional depending on the use-case, like some
> > block being turned off or on... but then still the clock is there, just
> > not actively used.
> >
> > Aren't you now describing existing Linux driver?
> 
> They are valid inputs but not required. It is valid (and expected) to
> have a fair share of them not connected. The slave clocks just don't exist
> most of the time, and the IP can totally accept unwired master clock
> inputs on SoC variant. Nothing is going to break down if some are
> missing.
> 
> >From the controller perspective, the description given here is correct
> and the inputs are optional.
> 
> The more generic question is how do we deal with multiple,
> independent and optional ressources ? Because then, the order in which
> they appear cannot be predicted.

phandle values of 0 or -1 are treated as "NULL" entries.

Rob