Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp161143imm; Thu, 30 Aug 2018 10:45:13 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZio9wVbCkDzFTLIDcOVVNmVYnpFk9p5ZYNC+ZHObgHj17/8enHqpJf1LrNSgH2IWbe7y4h X-Received: by 2002:a62:2e02:: with SMTP id u2-v6mr11594647pfu.134.1535651113613; Thu, 30 Aug 2018 10:45:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535651113; cv=none; d=google.com; s=arc-20160816; b=GNbOqCTEcVme600aLFtl7PnDJWibKvIlrFhw5M1b52VhSqurR1mIGOCDtqvNEr1vym qyssp23JgljeLgieoiadxU0Z++6mQl0oBEpFzwb5hA0uX6+nVLnhTUu6xbdwbkgzmUgX MutQJ6k2wxC5lyba1vbu0EYt62Tf3s9M2ag9LbjDljie8wydxEXldrIxyZjq4Ni/e3Z8 1iBgeQP1Xj9Oqipnr2m/hjqCw3k/odCfPCeLjpcKq6xZBO2lCAGmNlzkat3Y0SMbiUzs 5yYDrGRBVZoW+fCc1fcFlNOi/LZywNyJfYJ+cA1iL9K55UW/ag90w+xPoI6EyY6nf+Xz lgcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=iPpgRrWsxDnPqjMElfLEWocL8UoqMVQCyvagPcW3hAE=; b=B6ztC2n39XElzybef7eBMy3IM+/XUgZnY/D/pDbe96JUCn26Bi1c02zJ0KA9HJPenw heRWf301JqYCgf0agMPbKy7AnMkJDZpZRie9WL/1eWIr7hlI46mfqwjjvWE8xDBII9Ln JaY2+EJrqlVnpNv3WAi/u1GAY3bOPUkLvpEz+yaq9yj4WJEieba4IUXE31iy/Iu/RIf2 vHz6v+69W3jm8wN6EtvHjANuke6Pt9OUdKUTw2le1KPY/ZDRwBdI48PBvIWl+7oaVwSs RILeqZ3Gpp2/JZjrYOvmiaQIUz/+ZW16hcDKou1DHbv6Lhv8g1Mq8mlhVtYf+WnbCItt EOhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=sP6xgVkz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q90-v6si7311670pfa.272.2018.08.30.10.44.58; Thu, 30 Aug 2018 10:45:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=sP6xgVkz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727642AbeH3VqR (ORCPT + 99 others); Thu, 30 Aug 2018 17:46:17 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:48003 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727582AbeH3VqQ (ORCPT ); Thu, 30 Aug 2018 17:46:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=iPpgRrWsxDnPqjMElfLEWocL8UoqMVQCyvagPcW3hAE=; b=sP6xgVkzHufsSZwKQlft6uj16D5c9savAUC8fpjdokO+EIl1nvjl/UhMJooT3IqIh8cGAsFgF3CIPJr87g+LkKyTqdikY3CxtFEtQ9phtCQYdvfhBJ7SfSXSSs1ne09bC2PQbmiLIaj+RyFfz4XwJStByEIZy59KJg66DsrIwqE=; Received: from andrew by vps0.lunn.ch with local (Exim 4.84_2) (envelope-from ) id 1fvQy8-0001Am-Ow; Thu, 30 Aug 2018 19:42:56 +0200 Date: Thu, 30 Aug 2018 19:42:56 +0200 From: Andrew Lunn To: Moritz Fischer Cc: "David S. Miller" , Kees Cook , Florian Fainelli , Linux Kernel Mailing List , netdev@vger.kernel.org, Alex Williams Subject: Re: [PATCH net-next 2/3] net: nixge: Add support for having nixge as subdevice Message-ID: <20180830174256.GC31581@lunn.ch> References: <20180830004046.9417-1-mdf@kernel.org> <20180830004046.9417-3-mdf@kernel.org> <20180830031110.GC16896@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 30, 2018 at 09:39:39AM -0700, Moritz Fischer wrote: > Hi Andrew, > > On Wed, Aug 29, 2018 at 8:11 PM, Andrew Lunn wrote: > > > Could you tell us more about the parent device. I'm guessing PCIe. Is > > it x86 so no device tree? Are there cases where it does not have a PHY > > connected? What is connected instead? SFP? A switch? Can there be > > multiple PHYs on the MDIO bus? > > The device is part of a larger FPGA design. One use case that I was trying > to support with this patch is PCIe with x86 (hopefully on it's own PF...) > Since the whole design isn't completely done, these are the use cases I > see upcoming and current: > > ARM(64): > a) DT: PHY over MDIO (current use case), fixed-link with GPIO (coming) > b) DT: SFP (potentially coming) > > x86: > a) no PHY (coming)-> fixed-link with GPIO > b) SFP (potentially), PHY over MDIO (potentially) Hi Mortiz For SFP, you need to convert this driver to use phylink. That will also help you with fixed-link, since phylink will handle probing that for you. But this brings its own problems. phylink and sfp currently has no support for platform devices. The SFP driver needs to know which i2c bus to use, and which GPIOs are connected to the SFP. phylink parses the device tree to find out if there is an SFP device, or a fixed link, etc. I don't know of any conceptual reason why platform data would not work, it just needs implementing. There also does not appear to be any in kernel users of the device tree binding. That gives you some flexibility in that you could think about making non-backwards compatible changes in the binding. I would definitely want to move PHYs into an mdio subnode. I'm not aware of any x86 drivers using fixed link. What they generally do is register the mdio bus using mdiobus_register() and then use phy_find_first() to get a PHY. This works O.K. for PCs, laptops, and PCIe cards where there is only one PHY on the bus. What you might be able to do is always register the MDIO bus, and if you fail to find a PHY, instantiate a fixed-link and use that instead. Reality is, all the core work in this area has been pushed by the embedded world, which is ARM and device tree. For Intel and Server style networking, drivers tend to either ignore the Linux core code and write there own PHY and MDIO bus drivers, or it is all done in firmware. Andrew