On Fri, Apr 24, 2020 at 03:46:22PM +0300, Florinel Iordache wrote: > Add support for Ethernet Backplane KR generic driver using link training > (ieee802.3ap/ba standards), equalization algorithms (bee, fixed) and > enable qoriq family of devices. > This driver is dependent on uboot Backplane KR support: > patchwork.ozlabs.org/project/uboot/list/?series=164627&state=* > > v2 changes: > * phy.rst and ABI/testing/sysfs-class-net-phydev updates with new PHY > interface values according to Florian Fainelli feedback > * dt bindings updates according to Rob Herring feedback: fixed errors > occurred when running 'make dt_binding_check' > * bpdev log changes according to feedback from Joe Perches: use %pV > instead of an intermediate buffer and refactoring > * reverse christmas tree updates according to David Miller feedback > * use pr_info_once function in probe to display qoriq backplane driver > version according to Joe's feedback > * introduce helper function dt_serdes_type in qoriq backplane according > to Joe's feedback > * use standard linux defines to access AN control/status registers and > not indirect with internal variables according to Andrew's feedback > * dt bindings link training updates: pre-cursor, main-cursor, post-cursor > * change display format for tx equalization using C() standard notation > * add priv pointer in backplane_device and lane as device specific private > extension to be used by upper layer backplane drivers > * backplane refactoring: split backplane_phy_info struct in > backplane_device and backplane_driver, add backplane specific ops and > move amp_red as qoriq specific param > * lane refactoring: split kr_lane_info struct in lane_device and lane_kr > in order to separate lane kr specific data by generic device lane data, > lane kr parameters unification, extension params for custom device > specific > * equalization refactoring: replace eq_setup_info/equalizer_info with > equalizer_driver/equalizer_device data structures Hi Florinel > > Feedback not addressed yet: > * general solution for PCS representation: still working to find a > generic suitable solution, exploring alternatives, perhaps this > should be addressed in phy generic layer I actually think this is the most important point. It makes a big difference to the overall structure of this code, the APIs it needs to export. So don't expect too detailed a review until this is decided. Andrew
