* Grygorii Strashko <grygorii.strashko@xxxxxx> [180830 00:12]: > Hi Tony, > > On 08/29/2018 10:00 AM, Tony Lindgren wrote: > > The current cpsw usage for cpsw-phy-sel is undocumented but is used for > > all the boards using cpsw. And cpsw-phy-sel is not really a child of > > the cpsw device, it lives in the system control module instead. > > > > Let's document the existing usage, and improve it a bit where we prefer > > to use a phandle instead of a child device for it. That way we can > > properly describe the hardware in dts files for things like genpd. > > I'm ok with this series, but I really don't like cpsw-phy-sel in general. Yeah this binding predates any standards. This series only fixes the nasty issue of cpsw claiming a module as a child that's outside it's IO range. > It was introduced long time back and now I'm thinking about possibility to replace it with > one of current generic interfaces - for example mux-controller. > Each port will control up to 3 muxes (port mode, idmode and rmii_ext_clk) and > transform phy-mode => mux states. > What do you think? Sure a mux-controller here makes sense. > Another option is to use phy, but it'd be complicated. For the port muxes, how about a phy driver just using a pinctrl driver? In general, it seems cpsw is just an interconnect instance (L4_FAST) with a control module (CPSW_WR) and a pile of independent other modules. That's described nicely in am437x TRM chapter "2.1.4 L4 Fast Peripheral Memory Map". So from that point of view the binding reg entries right now are all wrong :) In the long run cpsw should be really treated as an interconnect instance with it's control module providing standard Linux framework services such as clock / regulator / phy / pinctrl / iio whatever for the other modules. Just my 2c based on looking at the interconnect, I'm not too familiar with cpsw otherwise. Regards, Tony
