Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3B9CC636D3 for ; Fri, 10 Feb 2023 12:23:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231836AbjBJMX0 (ORCPT ); Fri, 10 Feb 2023 07:23:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231439AbjBJMXY (ORCPT ); Fri, 10 Feb 2023 07:23:24 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88C5F70CF2; Fri, 10 Feb 2023 04:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e9bOFTyg/R9p1/+tBwBFvmuDWAa2yaqkR6u3E/N1A/E=; b=v/jnMKqEH+8MxMTg1LSOuZlT5r 8p8lDTs3uBC3X/8daquwcHTpKTKlethqhl7FnLhTLWZb0EMmnWFVX8JNrb64F/KfIDLBPLhi7t0zG XCPfpa3WZXwuDRjIz7rSRPyWrqDUakuVBDBhkzHOC9du6lPypRcIk1Zi7KKdPrq94SC00AadW/l1G qNyhltA1js2JwQeRgdZ4kcGGBCzUmQn8yLpsy8p1bwONA/iqfpIkD+KzGeGQUTUAWwLcsZ9IShafK F4IvdFjPQN05neJsSIsVpfhIIRR4u7TdQV3MrXVoV9bHidk1lZz/psQnzNgJLRV3JRe/gr4POeh7j LVDpicUw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:36520) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pQSQu-0001Vw-FZ; Fri, 10 Feb 2023 12:23:16 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pQSQo-0005Zp-ED; Fri, 10 Feb 2023 12:23:10 +0000 Date: Fri, 10 Feb 2023 12:23:10 +0000 From: "Russell King (Oracle)" To: Krzysztof Kozlowski Cc: Daniel Golle , netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Heiner Kallweit , Lorenzo Bianconi , Mark Lee , John Crispin , Felix Fietkau , AngeloGioacchino Del Regno , Matthias Brugger , DENG Qingfang , Landen Chao , Sean Wang , Paolo Abeni , Jakub Kicinski , Eric Dumazet , "David S. Miller" , Vladimir Oltean , Florian Fainelli , Andrew Lunn , Jianhui Zhao , =?iso-8859-1?Q?Bj=F8rn?= Mork Subject: Re: [PATCH v2 03/11] dt-bindings: arm: mediatek: add 'mediatek,pn_swap' property Message-ID: References: <514ec4b8-ef78-35c1-2215-22884fca87d4@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 10, 2023 at 10:34:17AM +0000, Russell King (Oracle) wrote: > On Thu, Feb 09, 2023 at 12:30:27PM +0100, Krzysztof Kozlowski wrote: > > On 08/02/2023 23:30, Daniel Golle wrote: > > > Hm, none of the current PCS (or PHY) drivers are represented by a > > > syscon node... (and maybe that's the mistake in first place?) > > > > Yes. > > Nos, it isn't. To expand on this - I have no idea why you consider it a mistake that apparently all PCS aren't represented by a syscon node. PCS is a sub-block in an ethernet system, just the same as a MAC is a sub-block. PCS can appear in several locations of an ethernet system, but are generally found either side of a serial ethernet link such as 1000base-X, SGMII, USXGMII, 10Gbase-R etc. So, one can find PCS within an ethernet PHY - and there may be one facing the MAC connection, and there will be another facing the media. We generally do not need to separate these PCS from the PHY itself because we view the PHY as one whole device. The optional PCS on the MAC side of the link is something that we need to know about, because this has to be configured to talk to the PHY, or to configure and obtain negotiation results from in the case of fibre links. PCS on the MAC side are not a system level device, they are very much a specific piece of ethernet hardware in the same way that the MAC is, and we don't represent the MAC as a syscon node. There is no reason to do so with PCS. These PCS on the MAC side tend to be accessed via direct MMIO accesses, or over a MDIO bus. There's other blocks in the IEEE 802.3 ethernet layering, such as the PMA/PMD module (which for the MAC side we tend to model with the drivers/phy layer) - but again, these also appear in ethernet PHYs in order to produce the electrical signals for e.g. twisted pair ethernet. So, to effectively state that you consider that PCS should always be represented as a syscon node is rather naieve, and really as a DT reviewer you should not be making such decisions, but soliciting opinions from those who know this subject area in detail _whether_ they are some kind of system controller before making such a decision. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!