On Fri, Sep 24, 2021 at 09:27:53AM +0200, Maxime Ripard wrote: > The original binding was mentioning that valid values for the clocks and > clock-names property were one or two clocks from extclk, txco and lpo, > with extclk being deprecated in favor of txco. > > However, the current binding lists a valid array as extclk, txco and > lpo, with either one or two items. > > While this looks similar, it actually enforces that all the device trees > use either ["extclk"], or ["extclk", "txco"]. That doesn't make much > sense, since the two clocks are said to be equivalent, with one > superseeding the other. > > lpo is also not a valid clock anymore, and would be as the third clock > of the list, while we could have only this clock in the previous binding > (and in DTs). > > Let's rework the clock clause to allow to have either: > > - extclk, and mark it a deprecated > - txco alone > - lpo alone > - txco, lpo > > While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device > tree so it's not an issue in practice. > > Similarly, ["lpo", "txco"] is still considered invalid, but it's > generally considered as a best practice to fix the order of clocks. > > Cc: "David S. Miller" <davem@xxxxxxxxxxxxx> > Cc: Jakub Kicinski <kuba@xxxxxxxxxx> > Cc: netdev@xxxxxxxxxxxxxxx > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx> > --- > .../bindings/net/broadcom-bluetooth.yaml | 17 +++++++++++++++-- > 1 file changed, 15 insertions(+), 2 deletions(-) I've applied this and the rest of the series. Rob
