Messages in this thread | | | Subject | Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support. | From | David Daney <> | Date | Thu, 2 Nov 2017 11:31:45 -0700 |
| |
On 11/02/2017 09:56 AM, Andrew Lunn wrote: >> 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.
> >> 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 >
| |