aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorMaxime Ripard <[email protected]>2021-09-24 09:27:53 +0200
committerRob Herring <[email protected]>2021-10-12 09:05:34 -0500
commit88ffadce9d4cc14b04e7c21961a6ea9ceb9077e4 (patch)
tree95c3598ffbe45fff26f1a52305ed77ff3578c55c /tools/perf/scripts/python
parent5278e4a181ff53c297a74f5403984ac403e6800c (diff)
dt-bindings: bluetooth: broadcom: Fix clocks check
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" <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: [email protected] Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions