From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932139AbcF2Owz (ORCPT ); Wed, 29 Jun 2016 10:52:55 -0400 Received: from gloria.sntech.de ([95.129.55.99]:60091 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752417AbcF2Owm convert rfc822-to-8bit (ORCPT ); Wed, 29 Jun 2016 10:52:42 -0400 From: Heiko Stuebner To: Kishon Vijay Abraham I Cc: Frank Wang , dianders@chromium.org, linux@roeck-us.net, groeck@chromium.org, jwerner@chromium.org, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, linux-rockchip@lists.infradead.org, xzy.xu@rock-chips.com, kever.yang@rock-chips.com, huangtao@rock-chips.com, william.wu@rock-chips.com Subject: Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy Date: Wed, 29 Jun 2016 16:27:19 +0200 Message-ID: <2624359.mbyKrcyvqy@phil> User-Agent: KMail/4.14.10 (Linux/4.3.0-1-amd64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <5773D7DC.9050902@ti.com> References: <1465783810-18756-1-git-send-email-frank.wang@rock-chips.com> <1653733.7f4MgdqfFf@diego> <5773D7DC.9050902@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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