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.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 22D49C10F13 for ; Fri, 12 Apr 2019 00:26:11 +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 E3D2721850 for ; Fri, 12 Apr 2019 00:26:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sbxg/a5A"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="it1SUZQL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3D2721850 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:References: In-Reply-To:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=tXorh7ysou9quRNtA3+010oQRc40iCAy28Ub4wZbSk8=; b=sbxg/a5AVqxsnAJOz8AdAxW3SA 6QIitXCvhriMZuvT+sF8Jiri5PBlQDNkEZ3iWyxiCD5MRb393IsNnSZjGFdcBGQClpUrfIIwREhFb T5JbjSANVDLqUTjG2QG47QZWcXnohQvnHmd5ecO8ff19lKGcDrmJJ2QsrucK7t32BCrldND6p97V7 AXK9tMss8k4o5YN8z88AftI8Fj8wVnrjmpnw4X120lhBMgThnGz5TtMDKX8v3iYeJszj7S4MHPMLR o32seJFrU0juxHobEWi7zKZckoO1pZ00d8TR6ImZKVnDdY2Pv4/hay/a0Lh8IwDOoqefMofev7MUf w9sIjyfA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEk16-00019P-Ec; Fri, 12 Apr 2019 00:26:04 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEk12-00018v-Du for linux-arm-kernel@lists.infradead.org; Fri, 12 Apr 2019 00:26:02 +0000 Received: by mail-wm1-x344.google.com with SMTP id h18so8795334wml.1 for ; Thu, 11 Apr 2019 17:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=yf+MWTvV1m/3ufrq70QFsORkCI+URDSm1F4wdPRYD48=; b=it1SUZQLJAmozpByTaZ2KrqNzT6e1wEC0W3+n3tfqBLHN+tqQlHRJ/BeD441a+8iW4 vyuWxzVoph7iQ1xoiGQ9CKIbrbqMHxaGo8pbuiyYLH7cI5bz8Jt8HNOzvfk/H9FyjTP4 D2C881RO6x5JOxf/2uMrRc+kNo0MZH3CQCnLiqV6qDDOeR+OaHFqah8HjJAX3OhTKjXX NP2siwpgFEHD3v7brqqHjicz7wjHb4h3CoLL5OE0Lll2MVFclOJCw+gmcL9tFtTx11wH 07wJPjTa5lAFuebYY0xghgJuYBr1uaRXd4tT+98xIuqafESl6362hZAscnKyjeH40K2D A0jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=yf+MWTvV1m/3ufrq70QFsORkCI+URDSm1F4wdPRYD48=; b=a5FkO3nNcBJTYlBN6J3KYnkasXWFlUbEdpKaNxYkqYYHW6WiZSwTjUnbpAYVRt0H9w 3P9qBbUorMaYkEMc5OHSItmecAib4bz7V/fonqtdcZgrxpS1J92dOb1ItbvilSAA4Nmj AZ1nbl+9t+vyUgkep+QOOXMIdzSWwB33codoq1rnM6ehvFsOsXDf+ABzqeSbKlZ1KQok k7S4BKt61u7Pmo7ZkQSkAB6JYNUvDG+1sNFNPVjGEkp2sEjU3IFZpPFwhZ8wYjtk6eHV jpMU6m2wnJxmq+ca6GRJ+DtQi6GXhcgV2AosKJyyjy2LUZkDEEiLfGLb0Tg7YumKg08m PQ0A== X-Gm-Message-State: APjAAAU+l/kHpHTFzJWFnxp7buVzJCDOoDqFpxm2NILxcZw+wC0M/E3z UFpQU41z3VGGndGCwLfDA8A= X-Google-Smtp-Source: APXvYqy8kipHhUMR4+EQc1x5oFY0entJf3N4dtkG79LlR+tyJgkRWB+etZj3IkkEZs0ZRNDW6Ch8ww== X-Received: by 2002:a1c:4e04:: with SMTP id g4mr8911201wmh.127.1555028758826; Thu, 11 Apr 2019 17:25:58 -0700 (PDT) Received: from localhost.localdomain (5-12-225-227.residential.rdsnet.ro. [5.12.225.227]) by smtp.gmail.com with ESMTPSA id e16sm60489893wrs.0.2019.04.11.17.25.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 17:25:58 -0700 (PDT) From: Vladimir Oltean To: linux@armlinux.org.uk, ccaione@baylibre.com, f.fainelli@gmail.com, hkallweit1@gmail.com Subject: Re: [PATCH 0/3] at803x: Add quirk to disable SmartEEE Date: Fri, 12 Apr 2019 03:25:54 +0300 Message-Id: <20190412002554.8880-1-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190130104709.ganb2vuvzbxqkmxy@e5254000004ec.dyn.armlinux.org.uk> References: <20190130104709.ganb2vuvzbxqkmxy@e5254000004ec.dyn.armlinux.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190411_172600_497410_07B561C6 X-CRM114-Status: GOOD ( 30.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, andrew@lunn.ch, devicetree@vger.kernel.org, s.hauer@pengutronix.de, leoyang.li@nxp.com, robh+dt@kernel.org, linux-imx@nxp.com, kernel@pengutronix.de, fabio.estevam@nxp.com, olteanv@gmail.com, shawnguo@kernel.org, aisheng.dong@nxp.com, linux-arm-kernel@lists.infradead.org, abailon@baylibre.com MIME-Version: 1.0 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 Jan. 30, 2019, 10:47 a.m., Russell King - ARM Linux admin wrote: > On Wed, Jan 30, 2019 at 10:16:39AM +0000, Carlo Caione wrote: > > On 28/01/2019 19:04, Russell King - ARM Linux admin wrote: > > > > Hi Russell, > > > > > There is no "advertisement of SmartEEE" - it's just EEE. That is > > > because as far as the link partner is concerned, SmartEEE is just > > > EEE. > > > > > > Carlio posted a link to one of the datasheets for the family. In > > > there, it describes the EEE capability register, which describes > > > what is supported, and the EEE wake error counter register. > > > > > > It also describes the EEE advertisement and link parter advertisement > > > registers. > > > > > > All these registers correspond to the 802.3 section 45 defined MMD > > > and address offsets found in Clause 45 compliant PHYs, and these > > > registers control not only EEE but also SmartEEE. > > > > > > Please stop thinking that SmartEEE is different on the link partner > > > side from EEE - as far as the link partner is concerned, there is > > > no difference. The difference is all to do with the MAC side of > > > the local PHY. > > > > Thank you for clarifying how the SmartEEE is really working. > > > > Now, the problem is that the MMD registers controlling the EEE (7.3c and > > 7.3d, touched by the "eee-broken-*" property) are not the same as the ones > > for the SmartEEE (3.805b, 3.805c, 3.805d). So, is it worth to add a new DT > > property to deal also with the cases where we want to selectively disable > > the SmartEEE? > > That's because you're confusing what the registers are. Please take > the time to read the data sheet for the AR803x devices, and the 802.3 > specifications, and you will save yourself from asking a lot of > questions by email. > > 7.3c (or 7.60 in decimal) is the EEE advertisement register. This is > what gets sent _to_ the link partner. > > 7.3d (or 7.61 in decimal) is the EEE link partner ability register. > This is what the link partner sent to us _from_ its own EEE > advertisement register. > > The eee-broken-* properties allow the EEE advertisement to be altered, > thereby preventing EEE being negotiated for the various link modes. > Disabling EEE for a particular link mode means that EEE (in any form) > will not operate while the link is operating at that speed. > > 3.805b, 3.805c, 3.805d in the AR803x family are specifically to do > with the SmartEEE implementation. > > 3.805b controls how much time between the link waking up and buffered > data already received from the MAC being sent. > 3.805c controls the time from the last activity to entering low power > mode, additional bits in 3.805d. > 3.805d contains the SmartEEE enable bit, as well as the additional bits > from 3.805c. > > Most of these registers are only useful when you have a MAC that has no > EEE functionality - that is where SmartEEE can be enabled to provide the > power savings, and in order to implement EEE, there are various timeouts > required by the protocol. SmartEEE allows these timeouts to be > programmed via the above register. > > When using a MAC that has EEE functionality, SmartEEE should be disabled > via 3.805d to allow _full_ 802.3az EEE (from local MAC to link partner) > to operate, rather than SmartEEE (from local PHY to link partner.) > > Otherwise, using the existing "eee-broken-*" properties to disable the > link modes where EEE fails would be the correct way forward, and should > be used in preference to disabling SmartEEE. > > However, no one has mentioned what the problem that is trying to be > addressed. Is it data corruption? Is it that the link fails? Is it > lost packets? Is it that the MAC supports EEE? I think there needs to > be some better understanding of the problem at hand before trying to > address it. Hi Russell, Heiner, Carlo, Florian, You could have copied me when referencing the U-boot patch. It is indeed correct that disabling regular EEE advertisement does also disable SmartEEE. Somehow I hadn't taken this thought one step further to realize that the regular eee-broken-1000t DT binding is enough to take care of this. In my case it was indeed a situation of packet loss when the PHY should have buffered it, and nobody debugged it to find the root cause. While true that the Layerscape MACs in general need to disable EEE advertisement, in this particular case I can't rule out an electrical issue on the PHY's voltage rails. This is especially plausible since the MDIO interface of this PHY needed some rework anyway, whereas the RGMII side presented no more packet loss after disabling the PHY's low power mode. Thank you, -Vladimir _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel