On 11/02/2017 09:56 AM, Andrew Lunn wrote:

quoted

OK, now I think I understand.  Yes, the MAC can be hardwired to a switch.
In fact, there are system designs that do exactly that.

We try to handle this case by not having a "phy-handle" property in the
device tree.  The link to the remote device (switch IC in this case) is
brought up on ndo_open()

O.K, so you totally ignore the Linux way of doing this and hack
together your own proprietary solution.

I am going to add handling of the "phy-mode" property, but other than 
that I don't know what the "Linux way" of specifying a hard MAC-to-MAC 
connection with no intervening phy devices is.  Wether the remote MAC is 
a switch, or something else, would seem to be irrelevant.  All we are 
concerned about in this code is putting the thing into a state where 
data flows in both directions through the MAC.

A pointer to an existing device tree binding for an Ethernet device that 
has no (or an optional) phy device would be useful, we can try to do the 
same.

quoted

There may be opportunities to improve how this works in the future, but the
current code is serviceable.

It might be serviceable, but it will never get into mainline. For
mainline, you need to use DSA.

http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt

I am truly at a loss here.  That DSA document states:

      Master network devices are regular, unmodified Linux
      network device drivers for the CPU/management Ethernet
      interface.

What modification do you suggest I make?

Getting back to my original point, having these platform devices can
cause issues for DSA. Freescale FMAN has a similar architecture, and
it took a while to restructure it to make DSA work.

https://www.spinics.net/lists/netdev/msg459394.html

	Andrew