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 11788C2D0EE for ; Tue, 31 Mar 2020 12:54:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8ED920848 for ; Tue, 31 Mar 2020 12:54:44 +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 S1730732AbgCaMym (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: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@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