Hi everyone, > > The first question which pops up in my mind is related to the meaning > > of each item. The option which I envision based on your proposal is: > > > > * minItems: 1 > > * maxItems: 2 > > * Item[0]: Presumably equivalent to the current > > "fixed-emmc-driver-type", i.e. the strength value applied in both > > HS200 and HS400 modes. > > * Item[1] (optional): Presumably equivalent to > > "fixed-emmc-driver-type-hs400" proposed in this series. If this > > element is provided, the first one should likely change its role > > and become an equivalent of "fixed-emmc-driver-type-hs200" from > > this series. > > + Pro: Full backward compatibility. No need to touch the existing > > users of "fixed-emmc-driver-type". > > - Con: Not sure we have such DT bindings which dynamically change > > their semantics based on the usage pattern. > > - Con: Can't easily achieve the same flexibility as accomplished in > > this series. For example, current implementation allows users to > > define each of the three parameters (i.e. HSx00-agnostic drive > > strength, HS200 and HS400 specific drive strengths) individually, > > as well as in all possible combinations. This might be needed if, > > in certain HSx00 mode, users still need to rely on the > > RAW/unmodified drive strength. I am unsure if/how this can be > > achieved with an array OF property with a constant or variable > > number of elements (I try to sketch one solution below). > > > > One option to achieve a similar degree of flexibility by using an array > > OF property (instead of several u32 properties) would be to agree on a > > convention based on magic values, i.e. below DT one-liner could be an > > example of providing solely the "fixed-emmc-driver-type-hs200" value > > (based on the agreement that 0xFF values are discarded by the driver): > > > > fixed-emmc-driver-type = <0xFF 0x1 0xFF>; > > I don't understand why you have 3 values instead of 2. Because he sketches maximum flexibility here. Have a non-HS (default) value, one for HS200, and one for HS400: fixed-emmc-driver-type = <[default] [HS200] [HS400]>; > I would just use -1 if you want to ignore an entry. If that's the common '-1' sounds good to me, too. > case, then I'd stick with what you originally proposed. If rare, then I > think an array is the better route. What I have seen so far: setting drive strength alone is more on the rare side. Setting specific values for default and HS200/400 seems even more rare to me. With this patchset, it is the first time I hear about it. Yet, my experience might be a bit limited, maybe others (Hi Ulf! ;)) can add their views, too? Regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
