Received: by 10.213.65.68 with SMTP id h4csp2361528imn; Thu, 5 Apr 2018 13:37:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx48xhwE5PL6gn2i72mla9ooqNqyUp1WVL6fFl1/tM+JveAmTEn1GYPhLrItwaKpdArPOXu4f X-Received: by 10.99.175.6 with SMTP id w6mr15410610pge.186.1522960671006; Thu, 05 Apr 2018 13:37:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522960670; cv=none; d=google.com; s=arc-20160816; b=x/CcfjTMYcixXhSGGWjtXDogtfDJevh0fQsOntCkgWgZfr0c1HXkpQz/dfJOcy+Xwa +GsFfBLXb2aAM1k7XKyimJuMHVDzfmk4tIX73ttnfPTlYLiaaUm1di3zuLkI2DnrZ4V9 9vGLiXhqe59PJ1i8bBwzwoNXW+xW/HxE7nF5GUKI/Mpb+B/8JudlcvmqZ8IR8b6z+jik vPg9ChAtl+oZanyGvqzV6xdmTj28VGo3N9VHXVBGPZiiVL6cGLRAlDdT/FQasgLwEn3O VtkfuZCdTTfOYvJNVhULO8yE9SmaZTLa98+mr6PMft3APIr6xJUAHsOO3RHudZJ9xWTd to4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=jXZGmCrkP1/u85i8aLWS/MDAOyOaJMm6Ij34rZaBi0A=; b=G2uMPeXkGfM908VbAedH8bCOi4AodqMVtcdF5GbVS2k931UIUJU9PRmIMWDI9+aQKg OxEVFP3fgZHG9P2hvexmNwoqb8pQ4OF1AS63efDCL+zl9PrTm4mNJtGBZ7ADC1KY464b /VY5Qf3VHnB3+925a9yCDG/17tX2ZZd0+M3mkeaFec2oB7MmAuGT0SD/svij15Xe2tWa JweuK/APFLrx8q8dhtCYhsLrlwiO3uMF9J1KfPDbdl7n0IuF6x8hNrg3LLWhURRl+Wb9 4ySyeYha7QMoLCv0sxhUXTcxOh81YEgeb0tcEihZzQErPq8iTs+exJqVUezItEA+vIkU qJ4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@haabendal.dk header.s=20140924 header.b=Rf27mX/B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a23si4610153pfn.161.2018.04.05.13.37.37; Thu, 05 Apr 2018 13:37:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@haabendal.dk header.s=20140924 header.b=Rf27mX/B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752752AbeDEUav (ORCPT + 99 others); Thu, 5 Apr 2018 16:30:51 -0400 Received: from mailrelay4-3.pub.mailoutpod1-cph3.one.com ([46.30.212.13]:14876 "EHLO mailrelay4-3.pub.mailoutpod1-cph3.one.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752563AbeDEUas (ORCPT ); Thu, 5 Apr 2018 16:30:48 -0400 X-Greylist: delayed 709 seconds by postgrey-1.27 at vger.kernel.org; Thu, 05 Apr 2018 16:30:47 EDT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haabendal.dk; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=/WNuDeZgmNB2vnkZFH+RNpUHeK0neKqlw0BT0OtWxgI=; b=Rf27mX/BL4sNhvIkrtojqGnfUApRZQjc60KOxkcZRmMGvzxfUeP1xgLwurcT9po+khexTsO9I5fil lOjTVFNkFYHcbawOPJhki6g4i6OHQbK/dvLagDdjMWzuFfwEVusenrrc1P8T67God7WJ+OXyEIQpaP q8PRVqvEMNS486OI= X-HalOne-Cookie: 4db38157c1cf223991c8c2b68ca0562b4ec6932e X-HalOne-ID: 37d424cd-3910-11e8-a248-d0431ea8bb10 Received: from localhost (unknown [87.57.30.174]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 37d424cd-3910-11e8-a248-d0431ea8bb10; Thu, 05 Apr 2018 20:30:45 +0000 (UTC) From: Esben Haabendal To: Florian Fainelli Cc: Richard Cochran , Andrew Lunn , "open list\:PTP HARDWARE CLOCK SUPPORT" , open list , Rasmus Villemoes Subject: Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings References: <20180405114424.8519-1-esben.haabendal@gmail.com> <20180405114424.8519-2-esben.haabendal@gmail.com> <95678797-bd17-ba3f-8a70-a00b4792a258@gmail.com> Date: Thu, 05 Apr 2018 22:30:45 +0200 In-Reply-To: <95678797-bd17-ba3f-8a70-a00b4792a258@gmail.com> (Florian Fainelli's message of "Thu, 5 Apr 2018 09:02:38 -0700") Message-ID: <87d0zdjszu.fsf@haabendal.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Florian Fainelli writes: > On 04/05/2018 04:44 AM, esben.haabendal@gmail.com wrote: >> From: Esben Haabendal >> >> Read configration settings, to allow automatic forced speed/duplex setup >> by hardware strapping. > > OK but why? What problem is this solving for you? It is ensuring that the PHY is configured according to the HW design. If the HW design has set the strap configuration to fx. fixed 100 Mbit full-duplex, this avoids Linux configuring it for auto-negotiation. > In general, we do not really want to preserve too much of what the PHY > has been previously configured with, Even when this "previous" configuration is the configuration selected by the board configuration? > provided that the PHY driver can re-instate these configuration > values. This is sort of what I try to do here. The PHY driver needs to check the BMCR register to figure out what the strapped configuration was. Without that, it is necessary for software configuration to duplicate the exact same configuration as is encoded in the strap configuration in order for the PHY to be configured as it is supposed to. > I just wonder how this can be robust when you connect this PHY with > auto-negotiation disabled to a peer that expects a set of link > parameters not covered by the default advertisement values? I assume it will fail just as it will if you use ethtool to configure the PHY wrongly. > This really looks like a recipe for disaster when you could just > disable auto-negotiation with ethtool. The current PHY driver approach to always default to enable auto-negotation, and then allow user-space to configure it differently with ethtool. With this patch, the default configuration is chosen based on the strap configuration, but user-space can still change the configuration with ethtool if needed / desired. I don't think it is such a big change. Bringing up the PHY with a default configuration according to HW strapping instead of an in-kernel SW hard-coded value sounds like a good idea to me. /Esben