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 DC942C433DF for ; Thu, 28 May 2020 16:08:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BD2B72071A for ; Thu, 28 May 2020 16:08:58 +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="Jd6iDpEQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404881AbgE1QI6 (ORCPT ); Thu, 28 May 2020 12:08:58 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:54856 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404666AbgE1QI4 (ORCPT ); Thu, 28 May 2020 12:08:56 -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=g7+apd5iHU977x2lEJZNWTIWFaiZlqB3L4cjMfiaFus=; b=Jd6iDpEQBLUDuOqaWacjCVx/2B pKIy/DvQhu5S7s1CtK2HrpqAjbQXs/VUjDxTUI8XMRAo8kbHZH11jxz9W3Gn0KqYLkBZRPh5SMC4s NwuCBb18aDQwUAxKexPuHsZY/XSUDGT+X9pW6cGaNJUjuAmTLUDY4y5fMuXBzZ0m/Dwg=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jeL5D-003YEr-B5; Thu, 28 May 2020 18:08:39 +0200 Date: Thu, 28 May 2020 18:08:39 +0200 From: Andrew Lunn To: Geert Uytterhoeven Cc: Oleksij Rempel , Philippe Schenker , "sergei.shtylyov@cogentembedded.com" , "kernel@pengutronix.de" , "davem@davemloft.net" , "hkallweit1@gmail.com" , "linux@armlinux.org.uk" , "linux-kernel@vger.kernel.org" , "david@protonic.nl" , "netdev@vger.kernel.org" , "f.fainelli@gmail.com" , "linux-renesas-soc@vger.kernel.org" , Kazuya Mizuguchi , Grygorii Strashko Subject: Re: [PATCH net-next v3] net: phy: micrel: add phy-mode support for the KSZ9031 PHY Message-ID: <20200528160839.GE840827@lunn.ch> References: <20200422072137.8517-1-o.rempel@pengutronix.de> <20200428154718.GA24923@lunn.ch> <6791722391359fce92b39e3a21eef89495ccf156.camel@toradex.com> <20200429092616.7ug4kdgdltxowkcs@pengutronix.de> <20200527205221.GA818296@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2020 at 03:10:06PM +0200, Geert Uytterhoeven wrote: > Hi Andrew, > > On Wed, May 27, 2020 at 10:52 PM Andrew Lunn wrote: > > > You may wonder what's the difference between 3 and 4? It's not just the > > > PHY driver that looks at phy-mode! > > > drivers/net/ethernet/renesas/ravb_main.c:ravb_set_delay_mode() also > > > does, and configures an additional TX clock delay of 1.8 ns if TXID is > > > enabled. > > > > That sounds like a MAC bug. Either the MAC insert the delay, or the > > PHY does. If the MAC decides it is going to insert the delay, it > > should be masking what it passes to phylib so that the PHY does not > > add a second delay. > > And so I gave this a try, and modified the ravb driver to pass "rgmii" > to the PHY if it has inserted a delay. > That fixes the speed issue on R-Car M3-W! > And gets rid of the "*-skew-ps values should be used only with..." > message. > > I also tried if I can get rid of "rxc-skew-ps = <1500>". After dropping > the property, DHCP failed. Compensating by changing the PHY mode in DT > from "rgmii-txid" to "rgmii-id" makes it work again. In general, i suggest that the PHY implements the delay, not the MAC. Most PHYs support it, where as most MACs don't. It keeps maintenance and understanding easier, if everything is the same. But there are cases where the PHY does not have the needed support, and the MAC does the delays. > However, given Philippe's comment that the rgmi-*id apply to the PHY > only, I think we need new DT properties for enabling MAC internal delays. Do you actually need MAC internal delays? > That description is not quite correct: the driver expects skews for > plain RGMII only. For RGMII-*ID, it prints a warning, but still applies > the supplied skew values. O.K. so not so bad. > > To fix the issue, I came up with the following problem statement and > plan: > > A. Old behavior: > > 1. ravb acts upon "rgmii-*id" (on SoCs that support it[1]), > 2. ksz9031 ignored "rgmii-*id", using hardware defaults for skew > values. So two bugs which cancelled each other out :-) > B. New behavior (broken): > > 1. ravb acts upon "rgmii-*id", > 2. ksz9031 acts upon "rgmii-*id". > > C. Quick fix for v5.8 (workaround, backwards-compatible with old DTB): > > 1. ravb acts upon "rgmii-*id", but passes "rgmii" to phy, > 2. ksz9031 acts upon "rgmi", using new "rgmii" skew values. > > D. Long-term fix: I don't know if it is possible, but i would prefer that ravb does nothing and the PHY does the delay. The question is, can you get to this state without more things breaking? Andrew