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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 EF34EC433E2 for ; Tue, 21 Jul 2020 01:59:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE9B8206E9 for ; Tue, 21 Jul 2020 01:59:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595296777; bh=A2FDwNSyDpauYN840UREHbh62qgAGtvRaDcTfH064/w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=KwP7GFCVz/7CoUqQ7SJR2xbhDNI7Wd4FWYSLk1UV2Uw3M9t5/mJf8XdSx0VUiipdz xUa55HQMifo+4cnXVrz7dz81dZQ5EU5fUO8Vy2OA74iMx0RB4KioutMxOoBbDXYw1O hTzoWH3Y5cRyfSshU2U3gkrz1W0sg3pTpuaAjKh8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727971AbgGUB7e (ORCPT ); Mon, 20 Jul 2020 21:59:34 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:43740 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726962AbgGUB7e (ORCPT ); Mon, 20 Jul 2020 21:59:34 -0400 Received: by mail-io1-f65.google.com with SMTP id k23so19710424iom.10; Mon, 20 Jul 2020 18:59:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wnc7YVfPETMY6OwZSSKyjxvpm6CL442HL8Evb64Bao0=; b=ObDkZUCkUiIaGolGkqSsZKx1s5D0ohTz62PZZc+i+3bawVSOMebEEsJahX91MQgjxn Lw7PdCN5bQlUXBYBvAxQpEqMSdZOtTbR5CNhnj1+ZXZbo5l42xj5Od+9zxKd0R3Mmp9y RiJNsY4SzrVFPOOyjmoqIf3AThrrlG9XvsbnD/4EhpaFJ4evjbfd1c9Uo+9YVsBADCyh e5lBAp7dIwqFjm4hcsUMHZdgJR+ImPC7onVQaj1bya0EMg4DkRiBCO2lHj43LfglzXHn /ZBJPlbaYS4KT7LCHnYROP6jzVYYBBvxDXNPzgvdHGcI8jD3wE8ZYvpqNwiUE1LE0XX0 yDSA== X-Gm-Message-State: AOAM530dz9Th/EoAHozCdFh1sMTM5+exb38Ga6g+Hgb48wDPBZmYNBmd yazyqVDWhxDhgsTp0o0oow== X-Google-Smtp-Source: ABdhPJy8KThvkeccvCI926AXDyWSugNKjKyrlGQkm9NW9P/FwLo9C9MOvQMwCMAcBFH6teHRisqXRg== X-Received: by 2002:a02:2401:: with SMTP id f1mr29054327jaa.66.1595296772813; Mon, 20 Jul 2020 18:59:32 -0700 (PDT) Received: from xps15 ([64.188.179.252]) by smtp.gmail.com with ESMTPSA id p124sm9810465iod.32.2020.07.20.18.59.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2020 18:59:32 -0700 (PDT) Received: (nullmailer pid 3370741 invoked by uid 1000); Tue, 21 Jul 2020 01:59:30 -0000 Date: Mon, 20 Jul 2020 19:59:30 -0600 From: Rob Herring To: Matthew Hagan Cc: Andrew Lunn , Jakub Kicinski , Vivien Didelot , Florian Fainelli , "David S. Miller" , linux@armlinux.org.uk, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, John Crispin , Jonathan McDowell , devicetree@vger.kernel.org Subject: Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD_CTRL properties Message-ID: <20200721015930.GA3363310@bogus> References: <2e1776f997441792a44cd35a16f1e69f848816ce.1594668793.git.mnhagan88@gmail.com> <20200716150925.0f3e01b8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200716223236.GA1314837@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jul 17, 2020 at 08:26:02PM +0100, Matthew Hagan wrote: > > > On 16/07/2020 23:32, Andrew Lunn wrote: > > On Thu, Jul 16, 2020 at 03:09:25PM -0700, Jakub Kicinski wrote: > >> On Mon, 13 Jul 2020 21:50:26 +0100 Matthew Hagan wrote: > >>> Add names and decriptions of additional PORT0_PAD_CTRL properties. > >>> > >>> Signed-off-by: Matthew Hagan > >>> --- > >>> Documentation/devicetree/bindings/net/dsa/qca8k.txt | 8 ++++++++ > >>> 1 file changed, 8 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt > >>> index ccbc6d89325d..3d34c4f2e891 100644 > >>> --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt > >>> +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt > >>> @@ -13,6 +13,14 @@ Optional properties: > >>> > >>> - reset-gpios: GPIO to be used to reset the whole device > >>> > >>> +Optional MAC configuration properties: > >>> + > >>> +- qca,exchange-mac0-mac6: If present, internally swaps MAC0 and MAC6. > >> > >> Perhaps we can say a little more here? > >> > >>> +- qca,sgmii-rxclk-falling-edge: If present, sets receive clock phase to > >>> + falling edge. > >>> +- qca,sgmii-txclk-falling-edge: If present, sets transmit clock phase to > >>> + falling edge. > >> > >> These are not something that other vendors may implement and therefore > >> something we may want to make generic? Andrew? > > > > I've never seen any other vendor implement this. Which to me makes me > > think this is a vendor extension, to Ciscos vendor extension of > > 1000BaseX. > > > > Matthew, do you have a real use cases of these? I don't see a DT patch > > making use of them. And if you do, what is the PHY on the other end > > which also allows you to invert the clocks? > > > The use case I am working on is the Cisco Meraki MX65 which requires bit > 18 set (qca,sgmii-txclk-falling-edge). On the other side is a BCM58625 > SRAB with ports 4 and 5 in SGMII mode. There is no special polarity > configuration set on this side though I do have very limited info on > what is available. The settings I have replicate the vendor > configuration extracted from the device. > > The qca,sgmii-rxclk-falling-edge option (bit 19) is commonly used > according to the device trees found in the OpenWrt, which is still using > the ar8216 driver. With a count through the ar8327-initvals I see bit 19 > set on 18 of 22 devices using SGMII on MAC0. Can't you identify the device and configure the setting based on that? After all, MDIO devices are discoverable. Or there's no MDIO here? Rob