Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp1417461ybs; Mon, 25 May 2020 15:51:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+zLYSBNW+9W0BOozs5NrVIEl+Zav8PfXMJ+t7u80UHC+S/iDljgRAMQzMF+261QK4SXUk X-Received: by 2002:a17:906:5a99:: with SMTP id l25mr21391678ejq.235.1590447102649; Mon, 25 May 2020 15:51:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590447102; cv=none; d=google.com; s=arc-20160816; b=OsOaJ+bbQq+8FfauEyUBZJHzvbstWSyoQ5Ej1B5GsvkeOAc9qxIie/jsCplkRPhd5f mHo5Q4iwgn3gZ7HthThtzSi8e+FS3gHSlJFBsVA3TuYjqZKM5Y0l8+uzbB6WkXiZBvIx TDlOkEb+s4RNPEiJf7O8GOc+C5EBZB6+efBvEKewSlvZnBlOvfVZ5PsE4CqCauy1TK5m //u3soM7scGfnjNEzO07p8RQuamftA56v4LbSntQRcsDip1yusWu4K8uRTsUWAmcJXX2 t+v3+JlhLeQXaBkCCqx1/G0f0Zuqxh+OwS6wzlqb/Sbh50P90Kza8dPmoppUBOdk8n5G BLQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=IpZUASbLMdqBsqE1kRZ5lAM97mbmtkb+H+6iseFy2a8=; b=oZOot+7sdRffF2xHgTIt8Oc/COjGpPkPuGtYdCPrXhWBaFUVOQB7z4bXDaGIxJWv1e Lr0kAw/uK0dqUFP5NWYlBZLP+iERC/tNPI0BtQC8lc/gVJXohDpTFQm6akxpwzR1wm5q HC5dxc4N5TJBUKiH5aIpN/uHw89IEPpEMI4yXo3cpMUOK1mEZ+IDvn9TylEUwrEHX7qG TLYsL8po2WNXpA5LF/wzVk9Tg2SPGiAgKkKgPEaHge9VxxcOigeXX1LC6Q7WETuavqt0 O8Ou2xlxxqvMKFY+JC4ya2Nq54344UIJ4PXJpmLCJIM6t4FWCTNywsJCS4h2vcJF/qo6 6QsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d20si9809337edx.529.2020.05.25.15.51.20; Mon, 25 May 2020 15:51:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389465AbgEYWR3 (ORCPT + 99 others); Mon, 25 May 2020 18:17:29 -0400 Received: from foss.arm.com ([217.140.110.172]:44840 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388615AbgEYWR3 (ORCPT ); Mon, 25 May 2020 18:17:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8C20F31B; Mon, 25 May 2020 15:17:28 -0700 (PDT) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F12E3F6C4; Mon, 25 May 2020 15:17:28 -0700 (PDT) Subject: Re: [RFC 04/11] net: phy: Handle c22 regs presence better To: Andrew Lunn Cc: Russell King - ARM Linux admin , netdev@vger.kernel.org, davem@davemloft.net, f.fainelli@gmail.com, hkallweit1@gmail.com, madalin.bucur@oss.nxp.com, calvin.johnson@oss.nxp.com, linux-kernel@vger.kernel.org References: <20200522213059.1535892-1-jeremy.linton@arm.com> <20200522213059.1535892-5-jeremy.linton@arm.com> <20200523183731.GZ1551@shell.armlinux.org.uk> <20200525100612.GM1551@shell.armlinux.org.uk> <63ca13e3-11ea-3ddf-e1c7-90597d4a5f8c@arm.com> <20200525220614.GC768009@lunn.ch> From: Jeremy Linton Message-ID: <8868af66-fc1a-8ec2-ab75-123bffe2d504@arm.com> Date: Mon, 25 May 2020 17:17:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200525220614.GC768009@lunn.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 5/25/20 5:06 PM, Andrew Lunn wrote: >> Yes, we know even for the NXP reference hardware, one of the phy's doesn't >> probe out correctly because it doesn't respond to the ieee defined >> registers. I think at this point, there really isn't anything we can do >> about that unless we involve the (ACPI) firmware in currently nonstandard >> behaviors. >> >> So, my goals here have been to first, not break anything, and then do a >> slightly better job finding phy's that are (mostly?) responding correctly to >> the 802.3 spec. So we can say "if you hardware is ACPI conformant, and you >> have IEEE conformant phy's you should be ok". So, for your example phy, I >> guess the immediate answer is "use DT" or "find a conformant phy", or even >> "abstract it in the firmware and use a mailbox interface". > > Hi Jeremy > > You need to be careful here, when you say "use DT". With a c45 PHY > of_mdiobus_register_phy() calls get_phy_device() to see if the device > exists on the bus. So your changes to get_phy_device() etc, needs to > continue to find devices it used to find, even if they are not fully > complient to 802.3. > Yes, that is my "don't break anything". But, in a number of cases I can't tell if something is an intentional "bug", or what exactly the intended side effect actually was. The c22 bit0 sanitation is in this bucket, because its basically disabling the MMD0 probe.. I know for sure we find phys that previously weren't found. OTOH, i'm not sure how many that were previously "found" are now getting kicked out by because they are doing something "bad" that looked like a bug.