Hi Kishon, Am Mittwoch, 29. Juni 2016, 19:44:52 schrieb Kishon Vijay Abraham I: > On Friday 17 June 2016 10:16 PM, Heiko Stübner wrote: > > Am Freitag, 17. Juni 2016, 17:24:46 schrieb Kishon Vijay Abraham I: > > [...] > > > >>> + /* find out a proper config which can be matched with dt. */ > >>> + index = 0; > >>> + while (phy_cfgs[index].reg) { > >>> + if (phy_cfgs[index].reg == reg) { > >> > >> Why not pass these config values from dt? Moreover finding the config > >> using register offset is bound to break. > > > > As you have probably seen, this phy block is no stand-alone > > (mmio-)device, but gets controlled through special register/bits in the > > so called "General Register Files" syscon. > > > > The values stored and accessed here, are the location and layout of > > those > > control registers. Bits in those phy control registers at times move > > between phy-versions in different socs (rk3036, rk3228, rk3366, rk3368, > > rk3399) and some are even missing. So I don't really see a nice way to > > describe that in dt without describing the register and offset of each > > of those 22 used bits individually. > > > > > > I'm also not sure where you expect it to break? The reg-offset is the > > offset of the phy inside the GRF and the Designware-phy also already > > does something similar to select some appropriate values. > > I'm concerned the phy can be placed in the different reg-offset within GRF > (like in the next silicon revision) and this driver can't be used. That is something that has not happened with all Rockchip SoCs I have had in my hands so far. While the GRF is some sort-of wild-west area with settings for vastly different blocks in there and always changes between different socs (rk3288 [4-core A17] <-> rk3366 <-> rk3368 [8-core A53] <-> rk3399 etc) there haven't been such changes (different register offsets) between soc-revisions of the same soc that I know off. The GRF also includes such important things like the whole pinctrl handling, so if there were such offset changes in the GRF a lot of drivers (and maintainers) would get very unhappy - me included :-) . Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html