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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0F3EC433EF for ; Fri, 15 Apr 2022 14:40:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354616AbiDOOnJ (ORCPT ); Fri, 15 Apr 2022 10:43:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354712AbiDOOm6 (ORCPT ); Fri, 15 Apr 2022 10:42:58 -0400 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7EF213700F; Fri, 15 Apr 2022 07:40:24 -0700 (PDT) Received: (Authenticated sender: clement.leger@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 974ECE000B; Fri, 15 Apr 2022 14:40:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1650033622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zanZazVS+F6yO9Vb+0jek4QpQxEnTAcQmwRfYFhBd+k=; b=XvjgWF12omvcB0S9wdZocsVRAM1fWYoHiR3MF0fsHo3P2MRQFyfstVNy00SFVoUnaYfNn5 DHTXUF6jawn9JnEU+1oqAbtBVncahboURiQbPA8my6MYgJfBtZa7dJYGANrQGdr2VlYBUO h6jCzl9nA6Oc98wTw2G+Nthu3s1C5LycIA7OUXethKZt4aeXqiQzdpThwIS3Giy5cuXfJW 7fgNfwBtv3eQ3VWNQqBJe43/w+CMLSJuooTGyXCGiaStd+/42BLmNRw5wWflmuNrJUnDS7 IXLGtSXkRqiUo9FnvBUtdVr8XG8qvaPy51ebNxVCCOqaHDI+dbpqhktihqA2oA== Date: Fri, 15 Apr 2022 16:38:53 +0200 From: =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= To: Andrew Lunn Cc: Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Geert Uytterhoeven , Magnus Damm , Heiner Kallweit , Russell King , Thomas Petazzoni , Herve Codina , =?UTF-8?B?TWlxdcOobA==?= 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 09/12] ARM: dts: r9a06g032: describe MII converter Message-ID: <20220415163853.683c0b6d@fixe.home> In-Reply-To: References: <20220414122250.158113-1-clement.leger@bootlin.com> <20220414122250.158113-10-clement.leger@bootlin.com> <20220415102453.1b5b3f77@fixe.home> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le Fri, 15 Apr 2022 16:16:46 +0200, Andrew Lunn a =C3=A9crit : > On Fri, Apr 15, 2022 at 10:24:53AM +0200, Cl=C3=A9ment L=C3=A9ger wrote: > > Le Fri, 15 Apr 2022 01:22:01 +0200, > > Andrew Lunn a =C3=A9crit : > > =20 > > > On Thu, Apr 14, 2022 at 02:22:47PM +0200, Cl=C3=A9ment L=C3=A9ger wro= te: =20 > > > > Add the MII converter node which describes the MII converter that is > > > > present on the RZ/N1 SoC. =20 > > >=20 > > > Do you have a board which actually uses this? I just noticed that > > > renesas,miic-cfg-mode is missing, it is a required property, but maybe > > > the board .dts file provides it? > > >=20 > > > Andrew =20 > >=20 > > Hi Andrew, yes, I have a board that defines and use that. =20 >=20 > Great. Do you plan to mainline it? It is always nice to see a user. Although we are working on a specific customer board, we will probably try to mailine this support for the RZ/N1D-DB. >=20 > > The > > renesas,miic-cfg-mode actually configures the muxes that are present on > > the SoC. They allows to mux the various ethernet components (Sercos > > Controller, HSR Controller, Ethercat, GMAC1, RTOS-GMAC). > > All these muxes are actually controller by a single register > > CONVCTRL_MODE. You can actually see the muxes that are present in the > > manual [1] at Section 8 and the CONVCTRL_MODE possible values are listed > > on page 180. > >=20 > > This seems to be something that is board dependent because the muxing > > controls the MII converter outputs which depends on the board layout. = =20 >=20 > Does it also mux the MDIO lines as well? Nope, the MDIO lines are muxed using the pinctrl driver. >=20 > We might want to consider the name 'mux'. Linux already has the > concept of a mux, e.g. an MDIO mux, and i2c mux etc. These muxes have > one master device, which with the aid of the mux you can connect to > multiple busses. And at runtime you flip the mux as needed to access > the devices on the multiple slave busses. For MDIO you typically see > this when you have multiple Ethernet switch, each has its own slave > MDIO bus, and you use the mux to connect the single SOC MDIO bus > master to the various slave busses as needed to perform a bus > transaction. I2C is similar, you can have multiple SFPs, either with > there own IC2 bus, connected via a mux to a single I2C bus controller > on the SoC. >=20 > I've not looked at the data sheet yet, but it sounds like it operates > in a different way, so we might want to avoid 'mux'. Indeed, Let's not refer to it as mux in the code at all. If using your proposal below, I guess we could avoid that. >=20 > > I'm open to any modification for this setup which does not really fit > > any abstraction that I may have seen. > >=20 > > [1] > > https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1= l-group-users-manual-system-introduction-multiplexing-electrical-and =20 >=20 > O.K, looking at figure 8.1. >=20 > What the user wants to express is something like: >=20 > Connect MI_CONV5 to SECOS PORTA > Connect MI_CONV4 to ETHCAT PORTB > Connect MI_CONV3 to SWITCH PORTC > Connect MI_CONV2 to SWITCH PORTD >=20 > plus maybe >=20 > Connect SWITCH PORTIN to RTOS Yes, that is correct. >=20 > So i guess i would express the DT bindings like this, 5 values, and > let the driver then try to figure out the value you need to put in the > register, or return -EINVAL. For DT bindings we try to avoid magic > values which get written into registers. We prefer a higher level > description, and then let the driver figure out how to actually > implement that. Ok, looks like a more flexible way to doing it. Let's go with something like this: renesas,miic-port-connection =3D , , , , ; --=20 Cl=C3=A9ment L=C3=A9ger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com