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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 43FBEC38A2A for ; Sat, 9 May 2020 00:11:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2A0B324954 for ; Sat, 9 May 2020 00:11:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727983AbgEIALe (ORCPT ); Fri, 8 May 2020 20:11:34 -0400 Received: from foss.arm.com ([217.140.110.172]:54032 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727890AbgEIALe (ORCPT ); Fri, 8 May 2020 20:11:34 -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 CCB73D6E; Fri, 8 May 2020 17:11:33 -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 A3D893F68F; Fri, 8 May 2020 17:11:32 -0700 (PDT) Subject: Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id() To: Andrew Lunn Cc: Calvin Johnson , Andy Shevchenko , "Rafael J . Wysocki" , Russell King - ARM Linux admin , linux.cj@gmail.com, Florian Fainelli , Cristi Sovaiala , Florin Laurentiu Chiculita , Ioana Ciornei , Madalin Bucur , Greg Kroah-Hartman , Heikki Krogerus , Varun Sethi , "Rajesh V . Bikkina" , ACPI Devel Maling List , Linux Kernel Mailing List , Diana Madalina Craciun , netdev , Marcin Wojtas , Laurentiu Tudor , Makarand Pawagi , linux-arm Mailing List , Pankaj Bansal , "David S. Miller" , Heiner Kallweit References: <20200505132905.10276-1-calvin.johnson@oss.nxp.com> <20200505132905.10276-5-calvin.johnson@oss.nxp.com> <67e263cf-5cd7-98d1-56ff-ebd9ac2265b6@arm.com> <83ab4ca4-9c34-4cdd-4413-3b4cdf96727d@arm.com> <20200508160755.GB10296@lsv03152.swis.in-blr01.nxp.com> <20200508181301.GF298574@lunn.ch> <1e33605e-42fd-baf8-7584-e8fcd5ca6fd3@arm.com> <20200508202722.GI298574@lunn.ch> <97a9e145-bbaa-efb8-6215-dc3109ee7290@arm.com> <20200508234257.GA338317@lunn.ch> From: Jeremy Linton Message-ID: <8e67dd6c-e83d-d366-9799-940708e6ae3d@arm.com> Date: Fri, 8 May 2020 19:11:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200508234257.GA338317@lunn.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 5/8/20 6:42 PM, Andrew Lunn wrote: > On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote: >> Hi, >> >> On 5/8/20 3:27 PM, Andrew Lunn wrote: >>>>> There is a very small number of devices where the vendor messed up, >>>>> and did not put valid contents in the ID registers. In such cases, we >>>>> can read the IDs from device tree. These are then used in exactly the >>>>> same way as if they were read from the device. >>>>> >>>> >>>> Is that the case here? >>> >>> Sorry, I don't understand the question? >> >> I was asking in general, does this machine report the ID's correctly. > > Very likely, it does. > >> The embedded single mac:mdio per nic case seems like the normal case, and >> most of the existing ACPI described devices are setup that way. > > Somebody in this thread pointed to ACPI patches for the > MACCHIATOBin. If i remember the hardware correctly, it has 4 Ethernet > interfaces, and two MDIO bus masters. One of the bus masters can only > do C22 and the other can only do C45. It is expected that the busses > are shared, not a nice one to one mapping. Thats whats going on with the NXP too AFAIK. But the mcbin is one of the ones with the "compatible" embedded in the DSD properties.. AKA, they buried the entire DT node there. > >> But at the same time, that shifts the c22/45 question to the nic >> driver, where use of a DSD property before instantiating/probing >> MDIO isn't really a problem if needed. > > This in fact does not help you. The MAC driver has no idea what PHY is > connected to it. The MAC does not know if it is C22 or C45. It uses Thats all I was trying to say (the mac side capability is implied by the HID/CID that instantiates it). > the phylib abstraction which hides all this. Even if you assume 1:1, > use phy_find_first(), it will not find a C45 PHY because without > knowing there is a C45 PHY, we don't scan for it. And we should expect > C45 PHYs to become more popular in the next few years. > >> In fact this embedded nic/mac/mdio/phy 1:1:1 case, is likely a requirement >> for passthrough into a generic VM, otherwise someone has to create a virtual >> mdio, and pass the phy in for the nic/mac. >> >> AFAIK, NXP's part avoids this despite having a shared MDIO, because the phy >> state never leaves the mgmt side of the picture. It monitors the state and >> then feeds that back into their nic mgmt complex rather than using it >> directly. > > That is the other model. Don't use Linux to drive the PHY, use > firmware in the MAC. A number of MACs do that, but it has the usual > problems of firmware. It limits you on your choice of PHYs, bugs in > the firmware cannot be fixed by the community, no sharing of drivers > because firmware is generally proprietary, no 'for free features' > because somebody else added features to the linux PHY driver etc. But > it will make ACPI support simple, this whole discussion goes away, no > ACPI needed at all. Open source firmware! :)