From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09216C54E8E for ; Mon, 11 May 2020 09:39:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D60862075E for ; Mon, 11 May 2020 09:39:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="06Nbqi6U" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728711AbgEKJjb (ORCPT ); Mon, 11 May 2020 05:39:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725790AbgEKJjb (ORCPT ); Mon, 11 May 2020 05:39:31 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D6EBC061A0C; Mon, 11 May 2020 02:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JXYKE2YvBIgyujZ6k0qik2Y4FBN5h7JmUD/1Z324Bzw=; b=06Nbqi6ULbmPZiLvQwzGzSEOH 4qSNuekc6jhgvszk86LXQc9whmYGJChSEd1O5sgtpwpWh6Xd080AZOG3ozpuwYWBGVmlb9AOjUKoa mIkk+CKcCB1Vily19TBX7nK8YXr3WIx1JKuZ6N6+GHchRRZGbMIMqFuvZVCBqQ9P3URDA6Zs3xIdL X0RnlxZEKBlbldWHHrcFUh2KYtSKkjAT7ieXMqodj/oxQ8qC2qDO312vIhA9LUz9xfvAIiKt2RATW kZNtT8TBHl9vl4aZld0Cteo2T/nk3oDPcRS2cUYo9ESDve7UO2wVrNBKJ+/WGyRQ/6DyOpKt1fS2x QB+Rdnt7A==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:59006) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY4tm-0005bR-H9; Mon, 11 May 2020 10:38:58 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jY4td-0005WV-Ml; Mon, 11 May 2020 10:38:49 +0100 Date: Mon, 11 May 2020 10:38:49 +0100 From: Russell King - ARM Linux admin To: Calvin Johnson Cc: Andrew Lunn , Jeremy Linton , Andy Shevchenko , "Rafael J . Wysocki" , linux.cj@gmail.com, Florian Fainelli , Cristi Sovaiala , Florin Laurentiu Chiculita , Ioana Ciornei , Madalin Bucur , Greg Kroah-Hartman , Heikki Krogerus , Varun Sethi , "Rajesh V . Bikkina" , ACPI Devel Maling List , Linux Kernel Mailing List , Diana Madalina Craciun , netdev , Marcin Wojtas , Laurentiu Tudor , Makarand Pawagi , linux-arm Mailing List , Pankaj Bansal , "David S. Miller" , Heiner Kallweit Subject: Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id() Message-ID: <20200511093849.GO1551@shell.armlinux.org.uk> References: <67e263cf-5cd7-98d1-56ff-ebd9ac2265b6@arm.com> <83ab4ca4-9c34-4cdd-4413-3b4cdf96727d@arm.com> <20200508160755.GB10296@lsv03152.swis.in-blr01.nxp.com> <20200508181301.GF298574@lunn.ch> <1e33605e-42fd-baf8-7584-e8fcd5ca6fd3@arm.com> <20200508202722.GI298574@lunn.ch> <97a9e145-bbaa-efb8-6215-dc3109ee7290@arm.com> <20200508234257.GA338317@lunn.ch> <20200511080040.GC12725@lsv03152.swis.in-blr01.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200511080040.GC12725@lsv03152.swis.in-blr01.nxp.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, May 11, 2020 at 01:30:40PM +0530, Calvin Johnson wrote: > On Sat, May 09, 2020 at 01:42:57AM +0200, Andrew Lunn wrote: > > On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote: > > > Hi, > > > > > > On 5/8/20 3:27 PM, Andrew Lunn wrote: > > > > > > There is a very small number of devices where the vendor messed up, > > > > > > and did not put valid contents in the ID registers. In such cases, we > > > > > > can read the IDs from device tree. These are then used in exactly the > > > > > > same way as if they were read from the device. > > > > > > > > > > > > > > > > Is that the case here? > > > > > > > > Sorry, I don't understand the question? > > > > > > I was asking in general, does this machine report the ID's correctly. > > > > Very likely, it does. > > > > > The embedded single mac:mdio per nic case seems like the normal case, and > > > most of the existing ACPI described devices are setup that way. > > > > Somebody in this thread pointed to ACPI patches for the > > MACCHIATOBin. If i remember the hardware correctly, it has 4 Ethernet > > interfaces, and two MDIO bus masters. One of the bus masters can only > > do C22 and the other can only do C45. It is expected that the busses > > are shared, not a nice one to one mapping. > > > > > But at the same time, that shifts the c22/45 question to the nic > > > driver, where use of a DSD property before instantiating/probing > > > MDIO isn't really a problem if needed. > > > > This in fact does not help you. The MAC driver has no idea what PHY is > > connected to it. The MAC does not know if it is C22 or C45. It uses > > the phylib abstraction which hides all this. Even if you assume 1:1, > > use phy_find_first(), it will not find a C45 PHY because without > > knowing there is a C45 PHY, we don't scan for it. And we should expect > > C45 PHYs to become more popular in the next few years. > > Agree. > > NXP's LX2160ARDB platform currently has the following MDIO-PHY connection. > > MDIO-1 ==> one 40G PHY, two 1G PHYs(C45), two 10G PHYs(C22) I'm not entirely sure you have that correct. The Clause 45 register set as defined by IEEE 802.3 does not define registers for 1G negotiation, unless the PHY either supports Clause 22 accesses, or implements some kind of vendor extension. For a 1G PHY, this would be wasteful, and likely incompatible with a lot of hardware/software. Conversely, Clause 22 does not define registers for 10G speeds, except accessing Clause 45 registers indirectly through clause 22 registers, which would also be wasteful. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0DAFC47255 for ; Mon, 11 May 2020 09:41:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9D7A62075E for ; Mon, 11 May 2020 09:41:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rZqeOGn0"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="06Nbqi6U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D7A62075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UVdmMavfwfDidK/a//Dc3A3v6BjFbFDuldOMSJRmrKA=; b=rZqeOGn0VPF+Oq 81doylQGOa9Xi78TsbC1xpT6/P0Vik8gEkOKD4LdATgTPn0mB4+9bvfuN/dTRIW96E1+1/yGm2pBF lLYTD4AALPnsJd+xG1GAN9497gUcpLohs+XLSFjdvRlxJ//p5CpXcicL7tdkJghidIbO/J5t6j3Op lIHjD5mPFbAghzDREXGkAbbAjq09awsxxKLDGtlzEyEe0SakmLmvGI92T/9wELVCVTYbx28Lv0dgp PizMwoj1IUZzwf2WXmlVgaPFQxrARr88JXxgqS47fsUIQuMLryfKOKtupRKb8LyBXu+GMQ4XaZUl0 i9Y4owwHYAM1JWH+s+Hg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jY4wL-0003f9-7V; Mon, 11 May 2020 09:41:37 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jY4wI-00019y-1L for linux-arm-kernel@lists.infradead.org; Mon, 11 May 2020 09:41:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JXYKE2YvBIgyujZ6k0qik2Y4FBN5h7JmUD/1Z324Bzw=; b=06Nbqi6ULbmPZiLvQwzGzSEOH 4qSNuekc6jhgvszk86LXQc9whmYGJChSEd1O5sgtpwpWh6Xd080AZOG3ozpuwYWBGVmlb9AOjUKoa mIkk+CKcCB1Vily19TBX7nK8YXr3WIx1JKuZ6N6+GHchRRZGbMIMqFuvZVCBqQ9P3URDA6Zs3xIdL X0RnlxZEKBlbldWHHrcFUh2KYtSKkjAT7ieXMqodj/oxQ8qC2qDO312vIhA9LUz9xfvAIiKt2RATW kZNtT8TBHl9vl4aZld0Cteo2T/nk3oDPcRS2cUYo9ESDve7UO2wVrNBKJ+/WGyRQ/6DyOpKt1fS2x QB+Rdnt7A==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:59006) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY4tm-0005bR-H9; Mon, 11 May 2020 10:38:58 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jY4td-0005WV-Ml; Mon, 11 May 2020 10:38:49 +0100 Date: Mon, 11 May 2020 10:38:49 +0100 From: Russell King - ARM Linux admin To: Calvin Johnson Subject: Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id() Message-ID: <20200511093849.GO1551@shell.armlinux.org.uk> References: <67e263cf-5cd7-98d1-56ff-ebd9ac2265b6@arm.com> <83ab4ca4-9c34-4cdd-4413-3b4cdf96727d@arm.com> <20200508160755.GB10296@lsv03152.swis.in-blr01.nxp.com> <20200508181301.GF298574@lunn.ch> <1e33605e-42fd-baf8-7584-e8fcd5ca6fd3@arm.com> <20200508202722.GI298574@lunn.ch> <97a9e145-bbaa-efb8-6215-dc3109ee7290@arm.com> <20200508234257.GA338317@lunn.ch> <20200511080040.GC12725@lsv03152.swis.in-blr01.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200511080040.GC12725@lsv03152.swis.in-blr01.nxp.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200511_024134_083473_114B3579 X-CRM114-Status: GOOD ( 24.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Heikki Krogerus , "Rafael J . Wysocki" , Cristi Sovaiala , Ioana Ciornei , Florian Fainelli , "Rajesh V . Bikkina" , Pankaj Bansal , Diana Madalina Craciun , ACPI Devel Maling List , Andy Shevchenko , Florin Laurentiu Chiculita , Madalin Bucur , Makarand Pawagi , Varun Sethi , Marcin Wojtas , linux-arm Mailing List , Laurentiu Tudor , Greg Kroah-Hartman , Linux Kernel Mailing List , Jeremy Linton , linux.cj@gmail.com, netdev , "David S. Miller" , Heiner Kallweit Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 11, 2020 at 01:30:40PM +0530, Calvin Johnson wrote: > On Sat, May 09, 2020 at 01:42:57AM +0200, Andrew Lunn wrote: > > On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote: > > > Hi, > > > > > > On 5/8/20 3:27 PM, Andrew Lunn wrote: > > > > > > There is a very small number of devices where the vendor messed up, > > > > > > and did not put valid contents in the ID registers. In such cases, we > > > > > > can read the IDs from device tree. These are then used in exactly the > > > > > > same way as if they were read from the device. > > > > > > > > > > > > > > > > Is that the case here? > > > > > > > > Sorry, I don't understand the question? > > > > > > I was asking in general, does this machine report the ID's correctly. > > > > Very likely, it does. > > > > > The embedded single mac:mdio per nic case seems like the normal case, and > > > most of the existing ACPI described devices are setup that way. > > > > Somebody in this thread pointed to ACPI patches for the > > MACCHIATOBin. If i remember the hardware correctly, it has 4 Ethernet > > interfaces, and two MDIO bus masters. One of the bus masters can only > > do C22 and the other can only do C45. It is expected that the busses > > are shared, not a nice one to one mapping. > > > > > But at the same time, that shifts the c22/45 question to the nic > > > driver, where use of a DSD property before instantiating/probing > > > MDIO isn't really a problem if needed. > > > > This in fact does not help you. The MAC driver has no idea what PHY is > > connected to it. The MAC does not know if it is C22 or C45. It uses > > the phylib abstraction which hides all this. Even if you assume 1:1, > > use phy_find_first(), it will not find a C45 PHY because without > > knowing there is a C45 PHY, we don't scan for it. And we should expect > > C45 PHYs to become more popular in the next few years. > > Agree. > > NXP's LX2160ARDB platform currently has the following MDIO-PHY connection. > > MDIO-1 ==> one 40G PHY, two 1G PHYs(C45), two 10G PHYs(C22) I'm not entirely sure you have that correct. The Clause 45 register set as defined by IEEE 802.3 does not define registers for 1G negotiation, unless the PHY either supports Clause 22 accesses, or implements some kind of vendor extension. For a 1G PHY, this would be wasteful, and likely incompatible with a lot of hardware/software. Conversely, Clause 22 does not define registers for 10G speeds, except accessing Clause 45 registers indirectly through clause 22 registers, which would also be wasteful. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel