On Mon, Nov 14, 2022 at 06:31:02PM +0300, Dmitry Baryshkov wrote: > On 14/11/2022 16:37, Johan Hovold wrote: > > On Sat, Nov 12, 2022 at 02:43:03PM +0300, Dmitry Baryshkov wrote: > >> On 11/11/2022 12:24, Johan Hovold wrote: > >>> + "#clock-cells": > >>> + const: 1 > >>> + > >>> + clock-output-names: > >>> + items: > >>> + - const: usb3_pipe > >>> + - const: dp_link > >>> + - const: dp_vco_div > >>> + > >>> + "#phy-cells": > >>> + const: 1 > >>> + description: | > >>> + PHY index > >>> + - PHY_TYPE_USB3 > >>> + - PHY_TYPE_DP > >> > >> I'm stepping on Rob's and Krzysztof's ground here, but it might be more > >> logical and future proof to use indices instead of phy types. > > > > Why would that be more future-proof? > > > > I initially added defines for these indexes to a QMP header, but noticed > > that we already have PHY drivers that use the PHY types for this. So > > there's already a precedent for this and I didn't see any real benefit > > to adding multiple per-SoC defines for the same thing. > > As you guessed from my question, I was thinking about USB4 (for which we > do not have a separate PHY_TYPE, but that probably shouldn't matter). Yeah, that's easy enough to add. > Would it be a separate PHY here, or would it be a combo UBS3+USB4 plus > separate DP phy? We don't know yet. > Yes, we have other PHYs, which use types as an index, however it's > slightly more common to have indices instead. If you look at (yaml) bindings using a single phy-cell, the majority simply ignores describing what the index is used for and which values are valid. Of the few that do describe it, the cell index is either used for something which does not allow itself for mapping to PHY_TYPE or PHY_TYPE is used. > Anyway, this is a minor issue. It might be just that I'm more common to > using indices everywhere (in other words, I have preference here, but > it's not a strong requirement from my side). I don't have a strong preference here either. Let's see what Krzysztof and Rob says. Johan
