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=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 EE3B5C49361 for ; Sat, 19 Jun 2021 20:35:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFACD60FE3 for ; Sat, 19 Jun 2021 20:35:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230175AbhFSUhp (ORCPT ); Sat, 19 Jun 2021 16:37:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:47988 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229475AbhFSUhp (ORCPT ); Sat, 19 Jun 2021 16:37:45 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 98E22610A7; Sat, 19 Jun 2021 20:35:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624134933; bh=lER0y7Z4cnY2Oauv/bbe+khn3ZDuybDepS871EY7/oc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KLrc/oEyPql2ZMfLtdBlF89tQMTs0USOuhYcZkJLVQIRRmLHE0Ne4GWx2mVgmZFYv STnESKfAwfC3jQCOjw+SO6dN7RhAGtKtJZ7WxiCSMkUMYWkmqi/bIuRepJobtc17o5 kmHKnFum0+UQQDUiKqFVjLy2KPlf1igSOVC/gbzEnDX6QxHgi8wlWQjbGq9xj9ahpL Tun6uy82t2YjFMhnrdfBHHIpdbsNo0Lkww5ZUP3+TIW4Ss1LAFRG4l5OTcmDBUdybU MGrT3sv9XAzkMJpSxl0GPzh1lglrwoSHUu2OO95MyBS6Y3KijWxUaXe0KsdPjY30kN IKtKFh07orfKg== Received: by pali.im (Postfix) id 41EA71404; Sat, 19 Jun 2021 22:35:31 +0200 (CEST) Date: Sat, 19 Jun 2021 22:35:31 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Madalin Bucur Cc: Andrew Lunn , Russell King , Igal Liberman , Shruti Kanetkar , Emil Medve , Scott Wood , Rob Herring , Michael Ellerman , Benjamin Herrenschmidt , "netdev@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Camelia Alexandra Groza (OSS)" Subject: Re: Unsupported phy-connection-type sgmii-2500 in arch/powerpc/boot/dts/fsl/t1023rdb.dts Message-ID: <20210619203531.nmhpcux5hwwve47e@pali> References: <20210603143453.if7hgifupx5k433b@pali> <20210603194853.ngz4jdso3kfncnj4@pali> <20210604192732.GW30436@shell.armlinux.org.uk> <20210604233455.fwcu2chlsed2gwmu@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210604233455.fwcu2chlsed2gwmu@pali> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Saturday 05 June 2021 01:34:55 Pali Rohár wrote: > On Friday 04 June 2021 21:47:26 Madalin Bucur wrote: > > > -----Original Message----- > > > From: Andrew Lunn > > > Sent: 04 June 2021 23:24 > > > To: Madalin Bucur > > > Cc: Russell King ; Pali Rohár ; > > > Igal Liberman ; Shruti Kanetkar > > > ; Emil Medve ; Scott > > > Wood ; Rob Herring ; Michael > > > Ellerman ; Benjamin Herrenschmidt > > > ; netdev@vger.kernel.org; > > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Camelia > > > Alexandra Groza (OSS) > > > Subject: Re: Unsupported phy-connection-type sgmii-2500 in > > > arch/powerpc/boot/dts/fsl/t1023rdb.dts > > > > > > > The "sgmii-2500" compatible in that device tree describes an SGMII HW > > > > block, overclocked at 2.5G. Without that overclocking, it's a plain > > > > Cisco (like) SGMII HW block. That's the reason you need to disable it's > > > > AN setting when overclocked. With the proper Reset Configuration Word, > > > > you could remove the overclocking and transform that into a plain > > > "sgmii". > > > > Thus, the dts compatible describes the HW, as it is. > > > > > > It sounds like the hardware is capable of swapping between SGMII and > > > 2500BaseX. > > > > > > What we have in DT in this case is not describing the hardware, but > > > how we configure the hardware. It is one of the few places we abuse DT > > > for configuration. > > > > > > Andrew > > > > The actual selection of this mode of operation is performed by the so called > > Reset Configuration Word from the boot media, that aligned with the HW and > > board design. The need to name it something other than plain "sgmii" comes > > from the HW special need for AN to be disabled to operate. > > > > Actually, the weird/non-standard hardware is described by the device tree > > with a value that puts it in a class of its own. Instead of the overclocked > > SGMII denomination "sgmii-2500" it could have been named just as well > > "overclocked-nonstandard-2.5G-ethernet-no-autoneg-SGMII-hw-ip". > > > > One could try to change device trees to slip configuration details, but the > > backwards compatibility aspect renders this futile. Is there any option to > > say "sgmii" then "autoneg disabled"? > > > > Madalin > > Madalin, my understanding is that "sgmii-2500" mode is unknown and > unsupported by kernel. > > List of known modes which can be specified in DTS file are defined in > YAML schema for 'phy-connection-type' in file: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/ethernet-controller.yaml?h=v5.12#n55 > > And there is none "sgmii-2500", so some DTS schema validator could throw > validation error for that DTS file. I'm not sure if somebody has written > DTS schema validator with all those things (like there are JSON schema > or OpenAPI validators in JavaScript / HTTP world). > > Plus also in linux/phy.h header file contains list of known Linux modes: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/phy.h?h=v5.12#n169 > > And based on all information in this email discussion, in my opinion the > mode which HW supports matches Linux meaning of "2500base-x" key/string. > So I would suggest to rename "sgmii-2500" in that DTS file to > "2500base-x". Does it make sense? Any opinion? Or should I send a patch?