From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support. Date: Thu, 2 Nov 2017 11:31:45 -0700 Message-ID: <0168761e-cb18-e489-4689-8c9062aa316b@caviumnetworks.com> References: <20171102003606.19913-1-david.daney@cavium.com> <20171102003606.19913-7-david.daney@cavium.com> <20171102124339.GF4772@lunn.ch> <521d6b21-b7f0-66e0-4b49-cf95d83452d1@caviumnetworks.com> <20171102161016.GH24320@lunn.ch> <0f39046d-dc99-5c05-d918-10952cd20e1b@caviumnetworks.com> <20171102165605.GJ24320@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Daney , linux-mips@linux-mips.org, ralf@linux-mips.org, James Hogan , netdev@vger.kernel.org, "David S. Miller" , Rob Herring , Mark Rutland , linux-kernel@vger.kernel.org, "Steven J. Hill" , devicetree@vger.kernel.org, Carlos Munoz To: Andrew Lunn Return-path: Received: from mail-dm3nam03on0071.outbound.protection.outlook.com ([104.47.41.71]:7072 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933393AbdKBSbv (ORCPT ); Thu, 2 Nov 2017 14:31:51 -0400 In-Reply-To: <20171102165605.GJ24320@lunn.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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 >