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=-5.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT 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 1D0AFC43381 for ; Wed, 20 Feb 2019 15:02:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E5FF221902 for ; Wed, 20 Feb 2019 15:02:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="OA4pz+MK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726311AbfBTPCg (ORCPT ); Wed, 20 Feb 2019 10:02:36 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:59809 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725881AbfBTPCe (ORCPT ); Wed, 20 Feb 2019 10:02:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=S4cbb8ND+j0vo8LvgB3kKypLhVMH7LLvRf76LKljaTs=; b=OA4pz+MKQFj2MjQIG354fdwEBz 1rgNg/bnksa9WleHWoajSH8E0JledA//QyTaKlnqh9fF1tFwl/8N7PpbIC+cKR3DtRsw63r/RhVVv 4daJ6bnu98g8AIDwFFm9uIoOHs5/HfkdqJxgCFWCSVvxlbLfG87XLWl3kQ2V6jlBQ8Cw=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1gwTOB-0006nN-46; Wed, 20 Feb 2019 16:02:23 +0100 Date: Wed, 20 Feb 2019 16:02:23 +0100 From: Andrew Lunn To: Rodolfo Giometti Cc: Florian Fainelli , Vivien Didelot , "David S. Miller" , netdev@vger.kernel.org Subject: Re: Possible bug into DSA2 code. Message-ID: <20190220150223.GH13075@lunn.ch> References: <528f797d-445b-a314-d8ef-db15a3b6a8ce@enneenne.com> <20190209193409.GI30856@lunn.ch> <084b3973-88b9-8c71-50d5-9d773999ad04@enneenne.com> <49728829-49cc-6d6a-04b1-ccfc1e5266dd@enneenne.com> <2651a882-c5ab-ba3b-ef4c-731dca90147d@gmail.com> <24527f56-41dd-f257-0f5e-c568cb80881e@gmail.com> <20190219000340.GJ14879@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Feb 20, 2019 at 08:54:01AM +0100, Rodolfo Giometti wrote: > On 19/02/2019 01:03, Andrew Lunn wrote: > >>diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c > >>index 54a5b660640a..bb46ebbb2bb8 100644 > >>--- a/drivers/net/dsa/mv88e6xxx/chip.c > >>+++ b/drivers/net/dsa/mv88e6xxx/chip.c > >>@@ -2399,7 +2399,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds) > >> int i; > >> > >> chip->ds = ds; > >>- ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip); > >>+ ds->slave_mii_bus = NULL; > >> > >> mutex_lock(&chip->reg_lock); > >> > >>Is that right? > > > >Hi Rodolfo > > > >Humm, that needs testing. There are two used combinations you need to > >test: > > > >No MDIO node in device tree, e.g. > >arch/arm/boot/dts/kirkwood-dir665.dts > > > >MDIO node in device tree, e.g: > >arch/arm/boot/dts/vf610-zii-dev-rev-b.dts > > I'm sorry but I haven't such boards... :'( Hi Rodolfo I know. But you should be able to modify the device tree of the boards you are using to follow these patterns, and test them. > > >There is a third combination which will appear soon. There is only the > >external mdio bus in device tree: > > > > port@9 { > > reg = <9>; > > label = "eth_cu_1000_2"; > > phy-handle = <&phy9>; > > phy-mode = "sgmii"; > > managed = "in-band-status"; > > }; > > }; > > > > mdio1 { > > compatible = "marvell,mv88e6xxx-mdio-external"; > > #address-cells = <1>; > > #size-cells = <0>; > > > > phy9: phy9@0 { > > compatible = "ethernet-phy-ieee802.3-c45"; > > pinctrl-0 = <&pinctrl_gpio_phy9>; > > pinctrl-names = "default"; > > interrupt-parent = <&gpio2>; > > interrupts = <30 IRQ_TYPE_LEVEL_LOW>; > > reg = <0>; > > }; > > }; > > > >Here port 9 uses the external MDIO bus and all the other ports > >implicitly make use of the internal MDIO bus. > > Mmm... maybe should code into drivers/net/dsa/mv88e6xxx use private data to > hold used mdio busses instead of ds->slave_mii_bus pointer? I suspend that might break some of these different use cases. Either there needs to be a well argued analysis, or some testing of these setups. Andrew