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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 7B97AC43331 for ; Tue, 31 Mar 2020 16:28:52 +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 F15B020786 for ; Tue, 31 Mar 2020 16:28:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ipHti3yp"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="R26I6KKB"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="CO3dujQg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F15B020786 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lunn.ch 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=jMa5W0sIO2XOwYzE+k8ziYu1dIQiZM8O8x/Z4CV+nAg=; b=ipHti3ypAKsOIz 3RCds1bNbi0qDjS3YD/6A66SEYpGF1Z/yXNEKlGE2v3wu9M0C+9XG/N4ImLLXTsaiaZAbwK4NpdA3 k/SeTh68I1siEDya/RY8ga47AhZaY0WLNJNr/mikpGBEP/d+2hvUCvbILyk5YAGYNCGirOEBzetzJ 1GnDB6mdR9H1i+Q29B2BVs0RuY52T0Q/MHqymYIoZdsjYV2LStG+/XTDrBRkl66oYrmrKkXjj/BG2 rjvpq84LzyyfVsMCLIcGpLNnagT4wMttpZ3OloK3zR45padZORFiYsC98BeRtP+SuZNA+V30bcRpY vDbY9743uqOBNQSIVqgA==; 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 1jJJkw-0000Kk-Ep; Tue, 31 Mar 2020 16:28:50 +0000 Received: from merlin.infradead.org ([205.233.59.134]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJJke-0008Vr-93 for linux-arm-kernel@bombadil.infradead.org; Tue, 31 Mar 2020 16:28:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=r0AJPSf8r8qp+BalfPA6Bpq2XK/td5V0wFPsnuZhIPc=; b=R26I6KKB8Xc2je8xFtV7oFswD8 VotNk059B0BTZ5875zIVzbdMBsqhLXPp2O3v4n1S7qekWbvbpo+jQs4hir70Ngu3WRIPi+Kn0Be4+ CoTNWpY6KtLTl2OZpC8uTG4sIqkG+tKjI/MFfZ46S3fjF2b1B1ynzfkddi3OshrLXH9ygIfgl6t3x +ylsI1x6L4IZ2pipX4G/SKwj8SojOI3mrB1buzMwi1klJzgauVknGhsIoo3s6b3D/upZSuQbTZnYU eYbi59FvHCqAtqP5HC745c9NZnr6uGOEBp3+8x/PrRbgwE5XxvuV76yWkQTfnNulbfIs7WAZpw/HB MwjBYamg==; Received: from vps0.lunn.ch ([185.16.172.187]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJGPz-0001FP-O1 for linux-arm-kernel@lists.infradead.org; Tue, 31 Mar 2020 12:55:00 +0000 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:Sender: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=r0AJPSf8r8qp+BalfPA6Bpq2XK/td5V0wFPsnuZhIPc=; b=CO3dujQgQCXxwkhIn1tgWxG/5d 5yb5cQsEgmfDWDTvLVAIhSXYZrINlwKCv6QQUStYlGGl36aTjI5p7Pj3HEctHNnD0vINgBPxPw4Pm rgHWDeDPB1Ym8HJOBiXNgrmayzL/bgE0zdWLDeLnMFuna0b5BrlhuvvCsTHky6bNOkPo=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jJGPZ-000Cws-3h; Tue, 31 Mar 2020 14:54:33 +0200 Date: Tue, 31 Mar 2020 14:54:33 +0200 From: Andrew Lunn To: David Jander Subject: Re: [PATCH v2] ARM: imx: allow to disable board specific PHY fixups Message-ID: <20200331125433.GA24486@lunn.ch> References: <20200329110457.4113-1-o.rempel@pengutronix.de> <20200329150854.GA31812@lunn.ch> <20200330052611.2bgu7x4nmimf7pru@pengutronix.de> <40209d08-4acb-75c5-1766-6d39bb826ff9@gmail.com> <20200330174114.GG25745@shell.armlinux.org.uk> <20200331104459.6857474e@erd988> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200331104459.6857474e@erd988> 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: Florian Fainelli , netdev@vger.kernel.org, Sascha Hauer , Russell King - ARM Linux admin , linux-kernel@vger.kernel.org, Oleksij Rempel , linux-imx@nxp.com, kernel@pengutronix.de, Shawn Guo , Fabio Estevam , linux-arm-kernel@lists.infradead.org, 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 > - Disable the SmartEEE feature of the phy. The comment in the code implies > that for some reason it doesn't work, but the reason itself is not given. > Anyway, disabling SmartEEE should IMHO opinion be controlled by a DT > setting. There is no reason to believe this problem is specific to the > i.MX6. Besides, it is a feature of the phy, so it seems logical to expose > that via the DT. Once that is done, it has no place here. The device tree properties are defined: bindings/net/ethernet-phy.yaml: eee-broken-100tx: bindings/net/ethernet-phy.yaml: eee-broken-1000t: bindings/net/ethernet-phy.yaml: eee-broken-10gt: bindings/net/ethernet-phy.yaml: eee-broken-1000kx: bindings/net/ethernet-phy.yaml: eee-broken-10gkx4: bindings/net/ethernet-phy.yaml: eee-broken-10gkr: And there is a helper: void of_set_phy_eee_broken(struct phy_device *phydev) > - Enable TXC delay. To clarify, the RGMII specification version 1 specified > that the RXC and TXC traces should be routed long enough to introduce a > certain delay to the clock signal, or the delay should be introduced via > other means. In a later version of the spec, a provision was given for MAC > or PHY devices to generate this delay internally. The i.MX6 MAC interface > is unable to generate the required delay internally, so it has to be taken > care of either by the board layout, or by the PHY device. This is the > crucial point: The amount of delay set by the PHY delay register depends on > the board layout. It should NEVER be hard-coded in SoC setup code. The > correct way is to specify it in the DT. Needless to say that this too, > isn't i.MX6-specific. Correct: # RX and TX delays are added by the MAC when required - rgmii # RGMII with internal RX and TX delays provided by the PHY, # the MAC should not add the RX or TX delays in this case - rgmii-id # RGMII with internal RX delay provided by the PHY, the MAC # should not add an RX delay in this case - rgmii-rxid # RGMII with internal TX delay provided by the PHY, the MAC # should not add an TX delay in this case - rgmii-txid The needed properties exist. I think part of the issue is that there are iMX6 board which are not device tree? Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 EB2B1C43331 for ; Tue, 31 Mar 2020 12:54:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B3FEC20658 for ; Tue, 31 Mar 2020 12:54:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="CO3dujQg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730772AbgCaMym (ORCPT ); Tue, 31 Mar 2020 08:54:42 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:40968 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730703AbgCaMym (ORCPT ); Tue, 31 Mar 2020 08:54:42 -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:Sender: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=r0AJPSf8r8qp+BalfPA6Bpq2XK/td5V0wFPsnuZhIPc=; b=CO3dujQgQCXxwkhIn1tgWxG/5d 5yb5cQsEgmfDWDTvLVAIhSXYZrINlwKCv6QQUStYlGGl36aTjI5p7Pj3HEctHNnD0vINgBPxPw4Pm rgHWDeDPB1Ym8HJOBiXNgrmayzL/bgE0zdWLDeLnMFuna0b5BrlhuvvCsTHky6bNOkPo=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jJGPZ-000Cws-3h; Tue, 31 Mar 2020 14:54:33 +0200 Date: Tue, 31 Mar 2020 14:54:33 +0200 From: Andrew Lunn To: David Jander Cc: Russell King - ARM Linux admin , Florian Fainelli , Oleksij Rempel , netdev@vger.kernel.org, Sascha Hauer , linux-kernel@vger.kernel.org, Fabio Estevam , linux-imx@nxp.com, kernel@pengutronix.de, Shawn Guo , linux-arm-kernel@lists.infradead.org, Heiner Kallweit Subject: Re: [PATCH v2] ARM: imx: allow to disable board specific PHY fixups Message-ID: <20200331125433.GA24486@lunn.ch> References: <20200329110457.4113-1-o.rempel@pengutronix.de> <20200329150854.GA31812@lunn.ch> <20200330052611.2bgu7x4nmimf7pru@pengutronix.de> <40209d08-4acb-75c5-1766-6d39bb826ff9@gmail.com> <20200330174114.GG25745@shell.armlinux.org.uk> <20200331104459.6857474e@erd988> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331104459.6857474e@erd988> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > - Disable the SmartEEE feature of the phy. The comment in the code implies > that for some reason it doesn't work, but the reason itself is not given. > Anyway, disabling SmartEEE should IMHO opinion be controlled by a DT > setting. There is no reason to believe this problem is specific to the > i.MX6. Besides, it is a feature of the phy, so it seems logical to expose > that via the DT. Once that is done, it has no place here. The device tree properties are defined: bindings/net/ethernet-phy.yaml: eee-broken-100tx: bindings/net/ethernet-phy.yaml: eee-broken-1000t: bindings/net/ethernet-phy.yaml: eee-broken-10gt: bindings/net/ethernet-phy.yaml: eee-broken-1000kx: bindings/net/ethernet-phy.yaml: eee-broken-10gkx4: bindings/net/ethernet-phy.yaml: eee-broken-10gkr: And there is a helper: void of_set_phy_eee_broken(struct phy_device *phydev) > - Enable TXC delay. To clarify, the RGMII specification version 1 specified > that the RXC and TXC traces should be routed long enough to introduce a > certain delay to the clock signal, or the delay should be introduced via > other means. In a later version of the spec, a provision was given for MAC > or PHY devices to generate this delay internally. The i.MX6 MAC interface > is unable to generate the required delay internally, so it has to be taken > care of either by the board layout, or by the PHY device. This is the > crucial point: The amount of delay set by the PHY delay register depends on > the board layout. It should NEVER be hard-coded in SoC setup code. The > correct way is to specify it in the DT. Needless to say that this too, > isn't i.MX6-specific. Correct: # RX and TX delays are added by the MAC when required - rgmii # RGMII with internal RX and TX delays provided by the PHY, # the MAC should not add the RX or TX delays in this case - rgmii-id # RGMII with internal RX delay provided by the PHY, the MAC # should not add an RX delay in this case - rgmii-rxid # RGMII with internal TX delay provided by the PHY, the MAC # should not add an TX delay in this case - rgmii-txid The needed properties exist. I think part of the issue is that there are iMX6 board which are not device tree? Andrew