Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3544822ybb; Mon, 6 Apr 2020 10:45:11 -0700 (PDT) X-Google-Smtp-Source: APiQypI/xo+q2VYZyMp7+e01vknc449hSF2wn2BTr1N0M6+JTrC0Z9nq5mpwKE9CNqcO/nmqJAZd X-Received: by 2002:a05:6808:43:: with SMTP id v3mr272570oic.59.1586195111404; Mon, 06 Apr 2020 10:45:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586195111; cv=none; d=google.com; s=arc-20160816; b=0qpZGjQiqtzXM+XH5LRLlxplnJtgMSqLEcs7kHgg6YPUBDdPa7vLqf85QqPQsIO8FA lqj2RLAdh/s7SleVgpBtRqMyGdgRcZGNwpWEWP7VHYLebCJztuXlbcUGESCFfu/mARSF AKrwES154Dmbqr2q4SnVjnFMsBOiWBhCHG64jMPgl5T10+ecUO8tu2G5yEspsYZnccof f2cvtleoS76JJw0K+B24FROWrWOgHPGVep6ivoQc0G/ty9WLAGXcgX+K83P+9DnfCOvf mxLl06ovh6z1CRvkn6eYgdWqBoEEqXv1T0esXetPFHuyo9X4BavninaTTZL4wZfrh8Sh 7eqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=n/KK25l/wjjM7EmvcmldyNEQTQsrX/M3Rjl5nUkyui4=; b=Ec7hG5NMTN1t+Dyh1z8X/jCZDWMBf0wvjfVnGs/A1AiFMNcjKBUPbYVOnm/NOmB7yt QZfTM3dzSw0AuV5TmtEkfWvoSfCVq8MqAudkDROVjXPiQ0s0kq7zTQT6hacDWflohaZT DmSvO5OORuzbYYn8ipH59Mc+Z6eOg9Qv1lDkGj0E8OLOOctW5jYzjutFy9KHVU7+ErED 9C+5fl3EnJhZ+VzZVBkJ0npLpHtkWPrrD1ewNf+72oiGOK0Z2j7c4f7SEs4HIUCVndkm mVuTWBeb6QyaXuCDIvEeQ2bQLKQfYvK6n/CMcqgVbmZEnzAAD/6++zRvApzZo/++NMd6 BiiQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z10si117032oth.135.2020.04.06.10.44.59; Mon, 06 Apr 2020 10:45:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729786AbgDFRI3 (ORCPT + 99 others); Mon, 6 Apr 2020 13:08:29 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:57220 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727126AbgDFRI0 (ORCPT ); Mon, 6 Apr 2020 13:08:26 -0400 Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 6EC4415DA0AE6; Mon, 6 Apr 2020 10:08:25 -0700 (PDT) Date: Mon, 06 Apr 2020 10:08:23 -0700 (PDT) Message-Id: <20200406.100823.2156599779063686930.davem@davemloft.net> To: f.fainelli@gmail.com Cc: netdev@vger.kernel.org, kuba@kernel.org, andrew@lunn.ch, vivien.didelot@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: dsa: bcm_sf2: Do not register slave MDIO bus with OF From: David Miller In-Reply-To: <20200404213517.12783-1-f.fainelli@gmail.com> References: <20200404213517.12783-1-f.fainelli@gmail.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 06 Apr 2020 10:08:25 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Florian Fainelli Date: Sat, 4 Apr 2020 14:35:17 -0700 > We were registering our slave MDIO bus with OF and doing so with > assigning the newly created slave_mii_bus of_node to the master MDIO bus > controller node. This is a bad thing to do for a number of reasons: > > - we are completely lying about the slave MII bus is arranged and yet we > still want to control which MDIO devices it probes. It was attempted > before to play tricks with the bus_mask to perform that: > https://www.spinics.net/lists/netdev/msg429420.html but the approach > was rightfully rejected > > - the device_node reference counting is messed up and we are effectively > doing a double probe on the devices we already probed using the > master, this messes up all resources reference counts (such as clocks) > > The proper fix for this as indicated by David in his reply to the > thread above is to use a platform data style registration so as to > control exactly which devices we probe: > https://www.spinics.net/lists/netdev/msg430083.html > > By using mdiobus_register(), our slave_mii_bus->phy_mask value is used > as intended, and all the PHY addresses that must be redirected towards > our slave MDIO bus is happening while other addresses get redirected > towards the master MDIO bus. > > Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus") > Signed-off-by: Florian Fainelli Applied and queued up for -stable.