>-----Original Message----- >From: David Miller <da...@davemloft.net> >Sent: Tuesday, July 30, 2019 7:54 PM >To: Claudiu Manoil <claudiu.man...@nxp.com> >Cc: and...@lunn.ch; robh...@kernel.org; Leo Li <leoyang...@nxp.com>; >Alexandru Marginean <alexandru.margin...@nxp.com>; >netdev@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- >ker...@lists.infradead.org; linux-ker...@vger.kernel.org >Subject: Re: [PATCH net-next v4 0/4] enetc: Add mdio bus driver for the PCIe >MDIO endpoint > >From: David Miller <da...@davemloft.net> >Date: Tue, 30 Jul 2019 09:44:36 -0700 (PDT) > >> From: Claudiu Manoil <claudiu.man...@nxp.com> >> Date: Tue, 30 Jul 2019 12:45:15 +0300 >> >>> First patch fixes a sparse issue and cleans up accessors to avoid >>> casting to __iomem. >>> Second patch just registers the PCIe endpoint device containing >>> the MDIO registers as a standalone MDIO bus driver, to allow >>> an alternative way to control the MDIO bus. The same code used >>> by the ENETC ports (eth controllers) to manage MDIO via local >>> registers applies and is reused. >>> >>> Bindings are provided for the new MDIO node, similarly to ENETC >>> port nodes bindings. >>> >>> Last patch enables the ENETC port 1 and its RGMII PHY on the >>> LS1028A QDS board, where the MDIO muxing configuration relies >>> on the MDIO support provided in the first patch. >> ... >> >> Series applied, thank you. > >Actually this doesn't compile, I had to revert: >
Sorry, I overlooked the module part. Turns out I have to define a separate module for this driver (mdio), refactor common code between the mdio module and the enetc-pf module, clean up the Makefile... and do more checks.