On 14/11/2022 18:08, Johan Hovold wrote: >> >> Which is also fine. I don't understand still why it is a problem - even >> if you have multiple files, one for each SoC/phy. If USB4 brings here 10 >> more clocks and other SoCs/phys might bring many more options, then what >> else can you do? Grow the binding file with big text-based mapping of >> IDs? It's not a viable solution. Header or headers is the only >> maintainable way for such cases. > > So then we must add per-SoC (and PHY type) headers even if we can > possibly reuse defines from one platform for another as long as they > appear to be similar enough? No, you don't have to. I just got impression that future devices will bring so many changes that anyway you will end up with per-SoC defines. > For example, using a "SC7180_USB3_DP" infix > for the current platforms and add a new series of indexes for SC8280XP: > > QMP_SC7180_USB3_DP_USB3_PIPE 0 > QMP_SC7180_USB3_DP_DP_LINK 1 > QMP_SC7180_USB3_DP_DP_VCO_DIV 2 > > QMP_SC8280XP_USB4_USB3_DP_USB3_PIPE 0 > QMP_SC8280XP_USB4_USB3_DP_DP_LINK 1 > QMP_SC8280XP_USB4_USB3_DP_DP_VCO_DIV 2 > QMP_SC8280XP_USB4_USB3_DP_USB4_PCIE_PIPE 3 > ... > QMP_SC8280XP_USB4_USB3_DP_USB4_RX1 9 The names are just a names, you can even use QMP_SC7180_* on SC8280XP. You can skip the SoC part and have something shared. We already have such patterns - although maybe more often for outside components (like PMICs). The differences are: 1. For per-SoC name it's quite obvious which clock is supported on fiven SoC, 2. With shared names, you should document somewhere mapping between supported clocks and SoCs. Also what to do if new device comes with 10 new clocks entirely different - re-use/map existing defines or add completely new set of 10 of them? Best regards, Krzysztof
