>-----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.

Reply via email to