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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 19ACDC48BDF for ; Thu, 10 Jun 2021 18:05:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC0D7613F5 for ; Thu, 10 Jun 2021 18:05:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229963AbhFJSHt (ORCPT ); Thu, 10 Jun 2021 14:07:49 -0400 Received: from mail-oi1-f169.google.com ([209.85.167.169]:37669 "EHLO mail-oi1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229941AbhFJSHs (ORCPT ); Thu, 10 Jun 2021 14:07:48 -0400 Received: by mail-oi1-f169.google.com with SMTP id h9so3050584oih.4; Thu, 10 Jun 2021 11:05:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6tFMdKF66GtiGCGuvjiXKRo9ePOn5bxziMQAgLo1RwQ=; b=tXifdLjtt7Hj0WOCAAbhwvnB7W4trRIs5WTgpiu7nAEYY2x4q5r+tnEp9a6s9zbcZ5 2f+npVuIKn+YLGMSjrGjYQ6yWus/T80JEvB05w7XM+SucEIoj83W3NuTlR6HGCyLpK/+ 9XLfKL40uj72VdSnTu7NRnjHuMvQWnRRakj1SB1shWT9kxrF7rpj3gXfOM5ma+0oH6Nf OM4Pq1Q3KqxQqkpdNOP5vrfldzgRM+eTMuqHjQhHl4bqOefV61lx2KdNyUGiYQ2AKPj/ 0oN/AXPl3zlkrVOUPzVbN2iU1SFinw8qIxBLdrHxzDaDZx1uKzsU7sGf9mcLUgXDpXjM h32A== X-Gm-Message-State: AOAM5334/7ecQbXz7/MDI97TjHo0oJW5kz0/WkX7Ed9IiTsGHhV00AGQ s0i5qDRhIUmnijrzvhzH+KfPkH/0J2+2N6os1OE= X-Google-Smtp-Source: ABdhPJye8bhCZ3nvbsoG/AWSQExSaZgQ+UgWztP4soqwRMwdfz+Yf6AgchrvP9rp8nrhLcVOg1JZ7oftyXUEbxzdG7w= X-Received: by 2002:a05:6808:f08:: with SMTP id m8mr1212972oiw.69.1623348342904; Thu, 10 Jun 2021 11:05:42 -0700 (PDT) MIME-Version: 1.0 References: <20210610163917.4138412-1-ciorneiioana@gmail.com> <20210610163917.4138412-2-ciorneiioana@gmail.com> In-Reply-To: <20210610163917.4138412-2-ciorneiioana@gmail.com> From: "Rafael J. Wysocki" Date: Thu, 10 Jun 2021 20:05:31 +0200 Message-ID: Subject: Re: [PATCH net-next v8 01/15] Documentation: ACPI: DSD: Document MDIO PHY To: Ioana Ciornei Cc: Grant Likely , "Rafael J . Wysocki" , Jeremy Linton , Andrew Lunn , Andy Shevchenko , Florian Fainelli , Russell King - ARM Linux admin , Heikki Krogerus , Marcin Wojtas , Pieter Jansen Van Vuuren , Jon , Saravana Kannan , Randy Dunlap , calvin.johnson@nxp.com, Cristi Sovaiala , Florin Laurentiu Chiculita , Madalin Bucur , Linux ARM , Diana Madalina Craciun , ACPI Devel Maling List , Linux Kernel Mailing List , "linux.cj" , netdev , Laurentiu Tudor , Len Brown , "Rafael J . Wysocki" , Calvin Johnson , Ioana Ciornei Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Jun 10, 2021 at 6:40 PM Ioana Ciornei wrote: > > From: Calvin Johnson > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > provide them to be connected to MAC. This is not an "ACPI mechanism", because it is not part of the ACPI specification or support documentation thereof. I would call it "a mechanism based on generic ACPI _DSD device properties definition []1]". And provide a reference to the _DSD properties definition document. With that changed, you can add Acked-by: Rafael J. Wysocki to this patch. Note, however, that within the traditional ACPI framework, the _DSD properties are consumed by the driver that binds to the device represented by the ACPI device object containing the _DSD in question in its scope, while in this case IIUC the properties are expected to be consumed by the general networking code in the kernel. That is not wrong in principle, but it means that operating systems other than Linux are not likely to be using them. > Describe properties "phy-handle" and "phy-mode". > > Signed-off-by: Calvin Johnson > Signed-off-by: Ioana Ciornei > --- > > Changes in v8: None > Changes in v7: None > Changes in v6: > - Minor cleanup > > Changes in v5: > - More cleanup > > Changes in v4: > - More cleanup > > Changes in v3: None > Changes in v2: > - Updated with more description in document > > Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst > new file mode 100644 > index 000000000000..7d01ae8b3cc6 > --- /dev/null > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > @@ -0,0 +1,133 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +========================= > +MDIO bus and PHYs in ACPI > +========================= > + > +The PHYs on an MDIO bus [1] are probed and registered using > +fwnode_mdiobus_register_phy(). > + > +Later, for connecting these PHYs to their respective MACs, the PHYs registered > +on the MDIO bus have to be referenced. > + > +This document introduces two _DSD properties that are to be used > +for connecting PHYs on the MDIO bus [3] to the MAC layer. > + > +These properties are defined in accordance with the "Device > +Properties UUID For _DSD" [2] document and the > +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > +Data Descriptors containing them. > + > +phy-handle > +---------- > +For each MAC node, a device property "phy-handle" is used to reference > +the PHY that is registered on an MDIO bus. This is mandatory for > +network interfaces that have PHYs connected to MAC via MDIO bus. > + > +During the MDIO bus driver initialization, PHYs on this bus are probed > +using the _ADR object as shown below and are registered on the MDIO bus. > + > +:: > + Scope(\_SB.MDI0) > + { > + Device(PHY1) { > + Name (_ADR, 0x1) > + } // end of PHY1 > + > + Device(PHY2) { > + Name (_ADR, 0x2) > + } // end of PHY2 > + } > + > +Later, during the MAC driver initialization, the registered PHY devices > +have to be retrieved from the MDIO bus. For this, the MAC driver needs > +references to the previously registered PHYs which are provided > +as device object references (e.g. \_SB.MDI0.PHY1). > + > +phy-mode > +-------- > +The "phy-mode" _DSD property is used to describe the connection to > +the PHY. The valid values for "phy-mode" are defined in [4]. > + > +The following ASL example illustrates the usage of these properties. > + > +DSDT entry for MDIO node > +------------------------ > + > +The MDIO bus has an SoC component (MDIO controller) and a platform > +component (PHYs on the MDIO bus). > + > +a) Silicon Component > +This node describes the MDIO controller, MDI0 > +--------------------------------------------- > +:: > + Scope(_SB) > + { > + Device(MDI0) { > + Name(_HID, "NXP0006") > + Name(_CCA, 1) > + Name(_UID, 0) > + Name(_CRS, ResourceTemplate() { > + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN) > + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) > + { > + MDI0_IT > + } > + }) // end of _CRS for MDI0 > + } // end of MDI0 > + } > + > +b) Platform Component > +The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 > +--------------------------------------------------------------------- > +:: > + Scope(\_SB.MDI0) > + { > + Device(PHY1) { > + Name (_ADR, 0x1) > + } // end of PHY1 > + > + Device(PHY2) { > + Name (_ADR, 0x2) > + } // end of PHY2 > + } > + > +DSDT entries representing MAC nodes > +----------------------------------- > + > +Below are the MAC nodes where PHY nodes are referenced. > +phy-mode and phy-handle are used as explained earlier. > +------------------------------------------------------ > +:: > + Scope(\_SB.MCE0.PR17) > + { > + Name (_DSD, Package () { > + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), > + Package () { > + Package (2) {"phy-mode", "rgmii-id"}, > + Package (2) {"phy-handle", \_SB.MDI0.PHY1} > + } > + }) > + } > + > + Scope(\_SB.MCE0.PR18) > + { > + Name (_DSD, Package () { > + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), > + Package () { > + Package (2) {"phy-mode", "rgmii-id"}, > + Package (2) {"phy-handle", \_SB.MDI0.PHY2}} > + } > + }) > + } > + > +References > +========== > + > +[1] Documentation/networking/phy.rst > + > +[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > + > +[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst > + > +[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml > -- > 2.31.1 > 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=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 AE251C48BDF for ; Thu, 10 Jun 2021 18:07:26 +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 68C2D613E7 for ; Thu, 10 Jun 2021 18:07:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68C2D613E7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=c28CtBtverQjUPVZhfHImZ0iy0dNPML09nl69arVopc=; b=y1HvEDo3m4UPvc D1Shv74biXW496NCbydj1u9oJZKFdO7HFWCx8eWTBRujM06h7ouhbSXse9P55OxhG4ft4lDNkj9wP EQpitUPdlfsoI/Go+NxN/IthF8pcoWx6/JT0fHgdqfp1iWG2AN1Wx352kP/iYQ8l9oLMYRg+BBXpK EVt8Z/759S1d29AkEMYZWI3TbOJPTA/zwoZ8c/8rV5kpQwgLdXa39dBGggUmeX8bSiJJYoIGm1296 SId+PIH1GbjcRJI85oR/Y9+hfi01Pizqoy8XO6hGzyXb/p9lRdsPUk5d0TZEzqp9qjc5tIZfWoTSa rs7mADPXsNL1c0FhkUhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrP3s-00233P-AM; Thu, 10 Jun 2021 18:05:48 +0000 Received: from mail-oi1-f174.google.com ([209.85.167.174]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrP3o-00232Z-8h for linux-arm-kernel@lists.infradead.org; Thu, 10 Jun 2021 18:05:46 +0000 Received: by mail-oi1-f174.google.com with SMTP id x196so3037788oif.10 for ; Thu, 10 Jun 2021 11:05:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6tFMdKF66GtiGCGuvjiXKRo9ePOn5bxziMQAgLo1RwQ=; b=eGduWncOM2Hh/tg0F1tjSMgL/RzjgLDLtwvgfukzs6KQ2Rx1PrQbYbiKOkHvkJE9iS ufhkPN1fl3mKzlzWxvre8wihHFXzRJ5AD+K+YIWaB+cPf0Bo9FC2gdTIcEtOW2DWYLqd mFCZZtIha8Dfkuj2uu7IbfBDRlQzzsk8/Nm6B9Vg3j8lah8jp7zbKfUgfXe2M5TIr5Wn sfIRNSJJqyBtyjP/3HDzww75IKD31mY2fdclvPUyZfsKB0ytE0H2dkB7QdNlA4dq9C6e 2w1yFTE62WApkFfP2xuaBmn0btbxqZcAPsQTNLiQU0ld+GBYljKBEtzGogVAvGnUfsU9 CPBg== X-Gm-Message-State: AOAM533OL5aacZ7vpg6dnBDXGhH8Hx/by8XS3BKIiqqJvwR470ILp1Co bCB1VqkD1VylDtPfU/yABw9R2orv9TS7JeN68b8= X-Google-Smtp-Source: ABdhPJye8bhCZ3nvbsoG/AWSQExSaZgQ+UgWztP4soqwRMwdfz+Yf6AgchrvP9rp8nrhLcVOg1JZ7oftyXUEbxzdG7w= X-Received: by 2002:a05:6808:f08:: with SMTP id m8mr1212972oiw.69.1623348342904; Thu, 10 Jun 2021 11:05:42 -0700 (PDT) MIME-Version: 1.0 References: <20210610163917.4138412-1-ciorneiioana@gmail.com> <20210610163917.4138412-2-ciorneiioana@gmail.com> In-Reply-To: <20210610163917.4138412-2-ciorneiioana@gmail.com> From: "Rafael J. Wysocki" Date: Thu, 10 Jun 2021 20:05:31 +0200 Message-ID: Subject: Re: [PATCH net-next v8 01/15] Documentation: ACPI: DSD: Document MDIO PHY To: Ioana Ciornei Cc: Grant Likely , "Rafael J . Wysocki" , Jeremy Linton , Andrew Lunn , Andy Shevchenko , Florian Fainelli , Russell King - ARM Linux admin , Heikki Krogerus , Marcin Wojtas , Pieter Jansen Van Vuuren , Jon , Saravana Kannan , Randy Dunlap , calvin.johnson@nxp.com, Cristi Sovaiala , Florin Laurentiu Chiculita , Madalin Bucur , Linux ARM , Diana Madalina Craciun , ACPI Devel Maling List , Linux Kernel Mailing List , "linux.cj" , netdev , Laurentiu Tudor , Len Brown , "Rafael J . Wysocki" , Calvin Johnson , Ioana Ciornei X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210610_110544_348309_E4AB865D X-CRM114-Status: GOOD ( 31.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 10, 2021 at 6:40 PM Ioana Ciornei wrote: > > From: Calvin Johnson > > Introduce ACPI mechanism to get PHYs registered on a MDIO bus and > provide them to be connected to MAC. This is not an "ACPI mechanism", because it is not part of the ACPI specification or support documentation thereof. I would call it "a mechanism based on generic ACPI _DSD device properties definition []1]". And provide a reference to the _DSD properties definition document. With that changed, you can add Acked-by: Rafael J. Wysocki to this patch. Note, however, that within the traditional ACPI framework, the _DSD properties are consumed by the driver that binds to the device represented by the ACPI device object containing the _DSD in question in its scope, while in this case IIUC the properties are expected to be consumed by the general networking code in the kernel. That is not wrong in principle, but it means that operating systems other than Linux are not likely to be using them. > Describe properties "phy-handle" and "phy-mode". > > Signed-off-by: Calvin Johnson > Signed-off-by: Ioana Ciornei > --- > > Changes in v8: None > Changes in v7: None > Changes in v6: > - Minor cleanup > > Changes in v5: > - More cleanup > > Changes in v4: > - More cleanup > > Changes in v3: None > Changes in v2: > - Updated with more description in document > > Documentation/firmware-guide/acpi/dsd/phy.rst | 133 ++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst > > diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst > new file mode 100644 > index 000000000000..7d01ae8b3cc6 > --- /dev/null > +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst > @@ -0,0 +1,133 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +========================= > +MDIO bus and PHYs in ACPI > +========================= > + > +The PHYs on an MDIO bus [1] are probed and registered using > +fwnode_mdiobus_register_phy(). > + > +Later, for connecting these PHYs to their respective MACs, the PHYs registered > +on the MDIO bus have to be referenced. > + > +This document introduces two _DSD properties that are to be used > +for connecting PHYs on the MDIO bus [3] to the MAC layer. > + > +These properties are defined in accordance with the "Device > +Properties UUID For _DSD" [2] document and the > +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device > +Data Descriptors containing them. > + > +phy-handle > +---------- > +For each MAC node, a device property "phy-handle" is used to reference > +the PHY that is registered on an MDIO bus. This is mandatory for > +network interfaces that have PHYs connected to MAC via MDIO bus. > + > +During the MDIO bus driver initialization, PHYs on this bus are probed > +using the _ADR object as shown below and are registered on the MDIO bus. > + > +:: > + Scope(\_SB.MDI0) > + { > + Device(PHY1) { > + Name (_ADR, 0x1) > + } // end of PHY1 > + > + Device(PHY2) { > + Name (_ADR, 0x2) > + } // end of PHY2 > + } > + > +Later, during the MAC driver initialization, the registered PHY devices > +have to be retrieved from the MDIO bus. For this, the MAC driver needs > +references to the previously registered PHYs which are provided > +as device object references (e.g. \_SB.MDI0.PHY1). > + > +phy-mode > +-------- > +The "phy-mode" _DSD property is used to describe the connection to > +the PHY. The valid values for "phy-mode" are defined in [4]. > + > +The following ASL example illustrates the usage of these properties. > + > +DSDT entry for MDIO node > +------------------------ > + > +The MDIO bus has an SoC component (MDIO controller) and a platform > +component (PHYs on the MDIO bus). > + > +a) Silicon Component > +This node describes the MDIO controller, MDI0 > +--------------------------------------------- > +:: > + Scope(_SB) > + { > + Device(MDI0) { > + Name(_HID, "NXP0006") > + Name(_CCA, 1) > + Name(_UID, 0) > + Name(_CRS, ResourceTemplate() { > + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN) > + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) > + { > + MDI0_IT > + } > + }) // end of _CRS for MDI0 > + } // end of MDI0 > + } > + > +b) Platform Component > +The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 > +--------------------------------------------------------------------- > +:: > + Scope(\_SB.MDI0) > + { > + Device(PHY1) { > + Name (_ADR, 0x1) > + } // end of PHY1 > + > + Device(PHY2) { > + Name (_ADR, 0x2) > + } // end of PHY2 > + } > + > +DSDT entries representing MAC nodes > +----------------------------------- > + > +Below are the MAC nodes where PHY nodes are referenced. > +phy-mode and phy-handle are used as explained earlier. > +------------------------------------------------------ > +:: > + Scope(\_SB.MCE0.PR17) > + { > + Name (_DSD, Package () { > + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), > + Package () { > + Package (2) {"phy-mode", "rgmii-id"}, > + Package (2) {"phy-handle", \_SB.MDI0.PHY1} > + } > + }) > + } > + > + Scope(\_SB.MCE0.PR18) > + { > + Name (_DSD, Package () { > + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), > + Package () { > + Package (2) {"phy-mode", "rgmii-id"}, > + Package (2) {"phy-handle", \_SB.MDI0.PHY2}} > + } > + }) > + } > + > +References > +========== > + > +[1] Documentation/networking/phy.rst > + > +[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > + > +[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst > + > +[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml > -- > 2.31.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel