On 29/04/16 18:31, Tony Lindgren wrote: > * Roger Quadros <rogerq@xxxxxx> [160429 03:10]: >> On 26/04/16 18:10, Tony Lindgren wrote: >>> I guess for now if no runtime detection is possible in the kernel. >> >> There are 2 ways to detect them mode >> 1) Enabe GPIO rising edge detect interrupt and reset the Ethernet PHY >> 2) read a PHY register over MDIO bus >> >> I'm not very sure where this can be done in the kernel. > > We already have some PHY detection over MDIO detection in place, > so that's probably the most generic solution. Sorry, I didn't get you. Based on the PHY node we need to switch the MAC driver. i.e. either CPSW or PRUeth. The PHY driver remains the same in both modes. > >> Even if there is some place to do the detection, how do we go about reconfiguring the >> device tree? > > You may not need to, you can have several named pin states: > > pinctrl-names = "default", "phy-foo", "phy-bar"; > pinctrl-0 = <&cpsw_default>; > pinctrl-1 = <&cpsw_phy_foo>; > pinctrl-2 = <&cpsw_phy_bar>; > ... > > Then have the common pins in cpsw_default, and manually enable > the other pinctrl groups based on the detection. We already > have that going on in am335x-bone-common.dtsi with the &mac > entry for cpsw. Probably I'm looking at the wrong place but in am353x-bone-common.dtsi I only see "default" and "sleep" pins. > > But maybe you have other detection issues too beyond setting > the pins? It is not only about the pinmux but using an entirely different MAC driver. So we need to enable/disable different MAC drivers. It gets even trickier if one port is assigned to one MAC driver and the other one to another MAC driver. The pinmux now has to be port specific and the cpsw driver has to be updated to support port specific pinmux. As of now it handles only one pinmux group for both its ports. cheers, -roger -- 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
