Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp239331pxb; Thu, 21 Apr 2022 22:50:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynCWK3g8EJsY72+sbxdRQjKBH8lc3nVimyoVinc9/7VSa0qzMkg6OyJIjSUrV2Ae+vjyuR X-Received: by 2002:a17:902:f690:b0:158:d6ee:b1f9 with SMTP id l16-20020a170902f69000b00158d6eeb1f9mr2855456plg.80.1650606654193; Thu, 21 Apr 2022 22:50:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650606654; cv=none; d=google.com; s=arc-20160816; b=Fsd7GcO4Q/m9jtg0qyVydhCAoFvD06Kfdhg9c6Ku0PP3vxssWkVra2IrYhq38dk/iY Yi1QnDMoRAJauwbiYsHif4gQrTYuDG8JU/RWdv+3LkCHDB0L/pId1wAgNjykGOWxWw8z pL7drDPHXlxAMTk8XyyHacigUxstUMEeuSy/eXoQSld3j+uNdlu8JGKq7+32QNHdLdgc mK07U9MrhRqIFYYSDrgMWJlh0goWzQDH0wiWK6qhrb7qRIUObnDaOyvxwm7OM9CgcSDV DidB6NPAYBXtbXRsvDI/dRXpOeFB3JVPbKasO8ZdOaHr+lY5AWtAz8jyECEobMPxz2R2 Pvcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=yg1QMdJD0jJidIacTdvCTSB235cSU+8ZTTNRkM2ZhJM=; b=t86/xqLss3UZ0XCF0+WI6H31T0vS5alX88l9QVV76Dq69JfSbRTrlHL3JqTvCOKqUV 1wvdglm1o0qob8Ht4ErpVddv0Uust2r5MZGt59axlpGaOUcgS7iAUoJT+M2Knd4Swmo2 mdnHzoggUwmpSwOPpfgjZVj6OvOv1H1iFPVoPQ3Q7xFczM/xtkETjNh00cEL0sdnnGpO cR64j65/OeOdR7+dq2oKT+hVxhNX0n/pIrQmcGHey3DsmFGmuwYkMaLxkWsdeE5AESSK nbub4w+2linGHyfA+ALbJqxgCRWoh4TGqC5hBBtGxZ+hg+igL2TbdUoOAq9u9xk6xWty anNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t71-20020a63814a000000b003aa9b5fc288si2791996pgd.695.2022.04.21.22.50.38; Thu, 21 Apr 2022 22:50:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350865AbiDTUOU (ORCPT + 99 others); Wed, 20 Apr 2022 16:14:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233033AbiDTUOP (ORCPT ); Wed, 20 Apr 2022 16:14:15 -0400 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC06337BFE; Wed, 20 Apr 2022 13:11:28 -0700 (PDT) Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-e2afb80550so3196660fac.1; Wed, 20 Apr 2022 13:11:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=yg1QMdJD0jJidIacTdvCTSB235cSU+8ZTTNRkM2ZhJM=; b=c4pIxYy1XlZmICyjmUlFECXjMtsTtDdB+SOS0fPzI41ybSOyINq5r38bIuBYfQ+ziv IgkYJFjB1EcAnAJxdLfJmoKSbyhhEV8o4l/6v3V506iJHTwQINViNnElCLzo6uiuQmJ8 sycqnJDi5WN7tqt0sei8zTpeacaQo+0ey+ORuwXZjQg0t56k04N+pbGkSvnTQLdtKQVF dAxVNwMg7cFRGy/urYDCYlq7SpGbGDYE7oejLzd0lSDCnsBq1/238uqcswXHZOV2l/f1 wZLXX1tP/eY9xek5ui3xOCgpjnqEbZkViN1TBn5O/B4a5sCvELv29pawvxAqJcMBhZ32 iuLQ== X-Gm-Message-State: AOAM532mzbjlZf1c43nwqiIdawSvldirDCTjyZ4q2E5TwIpR6UFwkFAT L+wTZA3l6ij+S2+2LBgZSA== X-Received: by 2002:a05:6870:4252:b0:e6:3ad5:cff6 with SMTP id v18-20020a056870425200b000e63ad5cff6mr2290495oac.196.1650485488205; Wed, 20 Apr 2022 13:11:28 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id g5-20020a9d5f85000000b006057056774esm380928oti.33.2022.04.20.13.11.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 13:11:27 -0700 (PDT) Received: (nullmailer pid 1770236 invoked by uid 1000); Wed, 20 Apr 2022 20:11:26 -0000 Date: Wed, 20 Apr 2022 15:11:26 -0500 From: Rob Herring To: =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= Cc: Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , Geert Uytterhoeven , Magnus Damm , Heiner Kallweit , Russell King , Thomas Petazzoni , Herve Codina , =?iso-8859-1?Q?Miqu=E8l?= Raynal , Milan Stevanovic , Jimmy Lalande , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH net-next 03/12] dt-bindings: net: pcs: add bindings for Renesas RZ/N1 MII converter Message-ID: References: <20220414122250.158113-1-clement.leger@bootlin.com> <20220414122250.158113-4-clement.leger@bootlin.com> <20220419170044.450050ca@fixe.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220419170044.450050ca@fixe.home> X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 19, 2022 at 05:00:44PM +0200, Cl?ment L?ger wrote: > Le Tue, 19 Apr 2022 08:43:47 -0500, > Rob Herring a ?crit : > > > > + clocks: > > > + items: > > > + - description: MII reference clock > > > + - description: RGMII reference clock > > > + - description: RMII reference clock > > > + - description: AHB clock used for the MII converter register interface > > > + > > > + renesas,miic-cfg-mode: > > > + description: MII mux configuration mode. This value should use one of the > > > + value defined in dt-bindings/net/pcs-rzn1-miic.h. > > > > Describe possible values here as constraints. At present, I don't see > > the point of this property if there is only 1 possible value and it is > > required. > > The ethernet subsystem contains a number of internal muxes that allows > to configure ethernet routing. This configuration option allows to set > the register that configure these muxes. > > After talking with Andrew, I considered moving to something like this: > > eth-miic@44030000 { > compatible = "renesas,rzn1-miic"; > > mii_conv1: mii-conv-1 { > renesas,miic-input = ; > port = <1>; 'port' is already used, find another name. Maybe 'reg' here. Don't know. What do 1 and 2 represent? > }; > mii_conv2: mii-conv-2 { > renesas,miic-input = ; > port = <2>; > }; > ... > }; > > Which would allow embedding the configuration inside the port > sub-nodes. Moreover, it allows a better validation of the values using > the schema validation directly since only a limited number of values > are allowed for each port. > > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + > > > +patternProperties: > > > + "^mii-conv@[0-4]$": > > > + type: object > > > > additionalProperties: false > > > > > + description: MII converter port > > > + > > > + properties: > > > + reg: > > > + maxItems: 1 > > > > Why do you need sub-nodes? They don't have any properties. A simple mask > > property could tell you which ports are present/active/enabled if that's > > what you are tracking. Or the SoC specific compatibles you need to add > > can imply the ports if they are SoC specific. > > The MACs are using phandles to these sub-nodes to query a specific MII > converter port PCS: > > switch@44050000 { > compatible = "renesas,rzn1-a5psw"; > > ports { > port@0 { ethernet-ports and ethernet-port so we don't collide with the graph binding. > reg = <0>; > label = "lan0"; > phy-handle = <&switch0phy3>; > pcs-handle = <&mii_conv4>; > }; > }; > }; > > According to Andrew, this is not a good idea to represent the PCS as a > bus since it is indeed not a bus. I could also switch to something like > pcs-handle = <ð_mii 4> but i'm not sure what you'd prefer. We could > also remove this from the device-tree and consider each driver to > request the MII ouput to be configured using something like this for > instance: I'm pretty sure we already defined pcs-handle as only a phandle. If you want variable cells, then it's got to be extended like all the other properties using that pattern. > > miic_request_pcs(pcs_np, miic_port_nr, MIIC_SWITCHD_PORT); > > But I'm not really fan of this because it requires the drivers to > assume some specificities of the MII converter (port number are not in > the same order of the switch for instance) and thus I would prefer this > to be in the device-tree. > > Let me know if you can think of something that would suit you > better but keep in mind that I need to correctly match a switch/MAC > port with a PCS port and that I also need to configure MII internal > muxes. > > For more information, you can look at section 8 of the manual at [1]. I can't really. Other people want their bindings reviewed too. Rob