On 11/02/2017 11:31 AM, David Daney wrote: > 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. The canonical way to support that type of connections is to use use a fixed-link property describing the link between the two MACs, ideally putting the same fixed-link property on both sides. > > 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? If you support normal phy_device and fixed-link devices, you should be good as far as using PHYLIB and interfacing with Ethernet switchses using DSA for instance. What Andrew is asking you though is to make sure that the platform device dance between the bgx drivers and the other modules preserves the Device Tree parenting, of_node pointers such that a DSA switch, which needs to reference a CPU/management port, has a chance to successfully look up that node via of_find_net_device_by_node(). > > >> >> 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 >> > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
