From mboxrd@z Thu Jan 1 00:00:00 1970 From: arno-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org (Arnaud Ebalard) Subject: Re: [PATCH] ARM: mvebu: Add Netgear ReadyNAS 2120 board Date: Mon, 11 Nov 2013 01:32:43 +0100 Message-ID: <87fvr393ro.fsf@natisbad.org> References: <87bo1tmibv.fsf@natisbad.org> <527ECBDD.7050607@gmail.com> <87hablulxu.fsf@natisbad.org> <527ED9E5.80800@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <527ED9E5.80800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Sebastian Hesselbarth's message of "Sun, 10 Nov 2013 01:57:09 +0100") Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sebastian Hesselbarth Cc: Jason Cooper , Andrew Lunn , Gregory Clement , Ezequiel Garcia , Thomas Petazzoni , Russell King , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Guenter Roeck List-Id: devicetree@vger.kernel.org Hi, I thought it would be a simple update but one of your comment gave me a run for my money ;-) Sebastian Hesselbarth writes: >>>> + status = "okay"; >>>> + }; >>>> + >>>> + mdio { >>>> + phy0: ethernet-phy@0 { >>>> + reg = <0>; >>> >>> Can you evaluate PHYs compatible from u-boot or post vendor:prodid >>> from MDIO registers? >> >> Looking at the PCB, 88E1318-NNB2. I will dig into Documentation/ the >> associated compatible. Out of curiosity, how do you get the PHY model >> from u-boot or userland? > > If it is 88e1318 the compatible is "marvell,88e1318" then. I usually > look at u-boot messages which sometimes reveal the PHY used. If that > is not sufficient, you can read PHY ID 1/2 (SMI address 2 and 3) > registers and go looking for model numbers. For the records, another solution is to look under /sys/: root@thin:/sys/bus/mdio_bus/drivers# find -name '*mdio*' ./Marvell 88E1318S/d0072004.mdio-mi:00 ./Marvell 88E1318S/d0072004.mdio-mi:01 I guess the driver just looks at the PHY ID to detect the flavour. Now regarding the compatible string you propose, did some grep calls and was unable to find a reference to marvell,88e1318 or even 88e138 and was unable to find any. How does the kernel do something with it to somehow inflect the selection of the right driver/flavour? >>> Both properties above are not required, so please remove them. >>> >>>> + g762_clk: fixedclk { >>> >>> s/fixedclk/oscillator/ ? In fact, if I change 'fixedclk' for 'oscillator', then I am unable to boot: my SATA disk get unrecognized in a storm of insane messages. Obviously, because I had modified the whole .dts to handle all the points in your revieuw, I spent some time finding the root cause. But that was interesting on many aspects and the continuation of a debugging week end ;-) Can you confirm the following: g762_clk is a *label for the node*, which is referenced via specific properties of g762@xx nodes, so that they get a clock frequency (a property of g762_clk). And fixedclk is *the name of the node*. In that specific case, fixedclk is ok because it does not collide w/ any existing node. But 'oscillator' is already defined in armada-xp.dtsi (included via armada-370-xp.dtsi): clocks { /* 25 MHz reference crystal */ refclk: oscillator { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <25000000>; }; }; So I guess the renaming I did from 'fixedclk' to 'oscillator' just somehow overloaded the armada-xp.dtsi 25Mhz clock for a 32KHz one, hence the inability to boot. If I am correct, I guess it would be nice to have some checks from dtc when compiling the .dts to verify the uniqueness of nodes in order to avoid such things. Comments welcome. Cheers, a+ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html