Quoting Bjorn Andersson (2021-12-11 10:13:17)

On Thu 09 Dec 02:25 CST 2021, Stephen Boyd wrote:

quoted

Maybe you want to drop these strings and use the dt index directly? That
may actually be faster because we don't do as many string comparisons
and the code may be smaller if we don't have to store bi_tcxo. I suppose
to make it more readable we could have #defines for each DT index like

 #define DT_BI_TCXO   0
 #define DT_SLEEP_CLK 1

Blaze a new trail!

I like the idea, and iiuc it's just a matter of replacing .fw_name with
.index?

Yes.

I am however worried that people will get the order wrong as they are
hacking on their dts/drivers, because (at least in my view) the order of
clocks & clock-names has been seen as "a dt binding requirement" up
until such change. But if we replace the names with indices such enum
would have to be kept in sync with the DT binding and there's no way to
validate it.

That's lame, but I see your point. The order is definitely part of the
binding but I'm not sure what we can do about folks deciding to reorder
the clocks property. The checker has a blind spot here.

If we do this we should force the driver and dts-writers to rely on the
binding document by omitting clock-names from the binding (and hence
dts). Otherwise people will (I will) assume that the clock-names are
still what matters...

I guess so. It still leaves everything exposed to the clocks property
getting jumbled and then everything falling apart. Sigh.

I'm not sure how much worse this is than today where the clock-names
property could be wrong and doesn't match the order of the clocks
property. We don't catch that either with the checker, so it's about the
same risk from my perspective. Why not take the risk and save on image
size?