[U-Boot] DM ethernet driver with multiple interfaces per device

[Simon Glass]

+Marek

Hi Stefan,

On 1 February 2016 at 06:27, Stefan Roese <sr at denx.de> wrote:
> Hi!
>
> I'm currently porting the Marvell mvpp2 driver for the Armada 375
> to U-Boot. This controller is a bit different, as it exposes
> multiple interfaces per controller. In this specific case its
> 2 interfaces. Here the current dts node:
>
>         /* Network controller */
>         ethernet at f0000 {
>                 compatible = "marvell,armada-375-pp2";
>                 reg = <0xf0000 0xa000>, /* Packet Processor regs */
>                       <0xc0000 0x3060>, /* LMS regs */
>                       <0xc4000 0x100>,  /* eth0 regs */
>                       <0xc5000 0x100>;  /* eth1 regs */
>                 clocks = <&gateclk 3>, <&gateclk 19>;
>                 clock-names = "pp_clk", "gop_clk";
>                 status = "disabled";
>
>                 eth0: eth0 at c4000 {
>                         interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>                         port-id = <0>;
>                         status = "disabled";
>                 };
>
>                 eth1: eth1 at c5000 {
>                         interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>                         port-id = <1>;
>                         status = "disabled";
>                 };
>         };
>
> Now I'm unsure, how to support those multiple network interfaces
> with DM. As the driver will only get called once. And I can't
> instantiate 2 network interfaces from the one probe function
> call.
>
> I could work around this problem, by restructuring the DT node
> into 2 separate DT nodes, each referencing the shared resources.
> But this would be a ugly, since it results in a different DT
> source between Linux and U-Boot.
>
> So my question is, is this something that is supported by the
> current DM networking infrastructure? And if not, if you have
> some hints on how to best support such a constellation with
> multiple network interfaces via one ethernet controller.

My suggestion would be to make this device a UCLASS_MISC or something
like that, then in its bind() method, bind two new child devices in
UCLASS_ETH.

Marek was talking about something similar on IRC and I pointed him to
the way the USB PHYs work, but clearly the device tree binding you
have anticipates having two devices.

Regards,
Simon