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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 0C157C43381 for ; Fri, 22 Mar 2019 00:05:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BDB9A21902 for ; Fri, 22 Mar 2019 00:05:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QfPY6tWt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727151AbfCVAFD (ORCPT ); Thu, 21 Mar 2019 20:05:03 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:39097 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbfCVAFD (ORCPT ); Thu, 21 Mar 2019 20:05:03 -0400 Received: by mail-wr1-f66.google.com with SMTP id j9so450403wrn.6 for ; Thu, 21 Mar 2019 17:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9PZJbH42bdh/2W6/mCYkYNgVKuvNkdXc9H7Z82kWdv4=; b=QfPY6tWtZET6Lw4RnheLxU8p6nhuLTsr70NziO4BTu3JuO8RVgNGcON7BGP3/fS71n +N8iiCsUM5FaPkTZbjjnfH+H7jpGt0D7L8xoaZG83t2ikibrLDv3IEytO/tyDpEcPZ/z 5FhupRxpskDyadsA4MySCm+Dm/bhJPLHdxfLp4nx4jZywTMkLgSkk62kFr7THA5e3fHj pX3zrEbhgrS6ENWxYbRkBh5b1I9q1vkK2um+n2SkiweHWE5qi83pTv7QWpTcnqPzAJ4B Bf1rjWkEXleQfo3IKrLbuYSneCRET2HowA5J60Y8OD1kYl0y9cUX44qkGcnpCmC5cYlJ /oHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9PZJbH42bdh/2W6/mCYkYNgVKuvNkdXc9H7Z82kWdv4=; b=m1p9hq8SgmBA8n7mKMyB4wg4nkuGebNKCtK91oYS6bAJQzlxQO5ooaj3Uql/gMbfQr tn7Ttt6BxQRZyY2B99/U4E0JrXgNefuXWjSi0P/3URS1+9508JkiMH9EGEdgYNpWVun4 IEMx/uQiF+L3t/Q48ANcV0Pu5be6r5ciV144uV7JyxlX9YxCyuNYZ5RlTAQ1O74xtCMZ EC7ypjXGYGDPbt1BRbH0mAvHS/Vfri0YMmgvST8ZQb6P7wPraG40UJyI/3VTQWhMGqkf Aku2ETH+U5205CYKrIQTpUsnsxzVPXJ3F3FR34YCGHmvG0zK39rghErR6ueGUux+LnYo KiDw== X-Gm-Message-State: APjAAAVe+JeuCsPoQ2UssmAKhwodgSgNCPId3ax0m2/jBJC0Vj4O2WJG QlycnVQeMh/HJTQDGKcnLzs= X-Google-Smtp-Source: APXvYqyI29+hisBvHH9WUjNdZtTJZoyUDd0TA+V5n1iu2TikO/94FCyF9NZ8MrlhQf6f+GKrR4fC0Q== X-Received: by 2002:a5d:494c:: with SMTP id r12mr4170778wrs.56.1553213101724; Thu, 21 Mar 2019 17:05:01 -0700 (PDT) Received: from debian64.daheim (p4FD091E7.dip0.t-ipconnect.de. [79.208.145.231]) by smtp.gmail.com with ESMTPSA id b10sm11560951wrt.86.2019.03.21.17.05.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Mar 2019 17:05:00 -0700 (PDT) Received: from localhost.daheim ([127.0.0.1] helo=debian64.localnet) by debian64.daheim with esmtp (Exim 4.92) (envelope-from ) id 1h77gC-0005pf-54; Fri, 22 Mar 2019 01:05:00 +0100 From: Christian Lamparter To: Marek Behun Cc: Florian Fainelli , netdev@vger.kernel.org, Andrew Lunn , Michal =?utf-8?B?Vm9rw6HEjQ==?= , John Crispin , Wei Yongjun Subject: Re: [PATCH net-next 1/1] net: dsa: qca8k: Fix internal PHY MDIO address Date: Fri, 22 Mar 2019 01:05:00 +0100 Message-ID: <1658622.mF2cRKpH9t@debian64> In-Reply-To: <20190322000120.7a87fde5@nic.cz> References: <20190321182319.10664-1-marek.behun@nic.cz> <2275278.j5OWp99DLc@debian64> <20190322000120.7a87fde5@nic.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Friday, March 22, 2019 12:01:20 AM CET Marek Behun wrote: > > Hm, it's not really a "external mode". But let's try one more time. > > The idea is that if an external mdio-bus (from the SoC) has already > > registered the PHY 0x0 - 0x4 from the QCA8337, the qca8k should not > > expose the same PHYs as it's own mdio-bus because then the PHYs end > > up being registered twice. > > Hi, > yes, I understand this bit. What I was talking about was that the MDIO > addresses of internal PHYs are 0 to 4, it does not matter if you access > them via switch or directly. But the current code for direct access is > using addresses 1 to 5, which does not work at all. It should also > substract 1 from the port number. > I think you clipped the part that explained what's wrong the code: |If you look at the mdio-bus communications during boot you can definitly see |the funkyness: every PHY gets initialized twice. You can also see this |"duplication" in /sys/class/mdio_bus. In this directory you'll have a mdio-bus |from the SoC and another one dsa-0:0 from the qca8k. If you look into those |you'll notice that their both the same. | |As for why this happend. I think I found the culprit in a "missed" |requirement from one of Andrew Lunn's reponses to the initial qca8k patch: | | |In this post, he described the Device-Tree dts configuration we use today. |But at the end he requests: |"and remove the phy_read() and phy_write() functions." TL;DR: the current qca8k_phy_(read|write) are wrong and need to be removed. But you should be able to test this in V4 easily (CC'd you there). You only need Patch 3/4 (and keep your dts the way it is). Anyway, that's it for now until tomorrow. Cheers, Christian