Re: [PATCH net-next v2 0/9] net: ethernet backplane support

[Andrew Lunn <andrew@lunn.ch>]

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