Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1796830pxp; Mon, 7 Mar 2022 02:33:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8r9Vdr+QHDVDqmMg5uelAkAeJ2h0GKG8oSanw5iRVTGzURSATEtd5D1o588UeIxD5Hbfh X-Received: by 2002:a17:902:d705:b0:14e:e5a2:1b34 with SMTP id w5-20020a170902d70500b0014ee5a21b34mr10930218ply.88.1646649197492; Mon, 07 Mar 2022 02:33:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646649197; cv=none; d=google.com; s=arc-20160816; b=fy1ndYEGP6POQIA/HKRx5NkIQSwcMPY5t8/DjuXrQa+bxhV0OO8I0sUWe5WDneUE/d 5XYwRPQeaEiIpc9RyFe5k7KyxjHTQArZ7+rVJaD7Eudc/sY3PqIEv201HY25gFQgAx7W t3wnDze3WVEQFk8ir3MVFn7yUDqYRwcU84oH+24nuHGK9F0V0NtACV4Rlzxfiyj0RmdS lErKTKqDycqOyUHw5r2ONuBUQJvXAbpWhiMwPEm7pNZ+gH6LJrCluoLsQfQS2BmT0vcD Spfzy415mB9fk1ry+4b+YalVsieXBLKbpkiUznowGUobdDmVK47tdJu2lUAhDLaBp74G LICg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=17Yws4IQs4DBSBhdwZBv49fzrKTF5NHaPlD3z8AiAZo=; b=kucHKqo8tVTWudCFhMJwJDXB7EfczwanebcxyeFyNgPbg7pwieSc4sH3c6389lP6hp oQB8Gua1P7/2XKDQgnhFJ8y5PdmbJWPE4tvPLK4qckJxBRTR3fkGQgxeFvkhv2KZPu2i Amy5EjGQJe/hvkZV7QGWP85CVamQMqeNHbTtnKi/htMsQODtM/wnZk2VyxMkLUZWrGBH fDDghvAZVmVn1rddiT+syF1XvNMheK780INltdNeibIOteOjVBsjBRPWFIIAEkzzbGhd 8EmoMuDI+vWqItRVM0WGikoMatzywqVUcv6+Qh2Kvt0iYceSh6aqx1Z+7GOzVNn40FzD yJ8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eRSO8yPN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g71-20020a636b4a000000b0037c6bb03a6asi10624099pgc.533.2022.03.07.02.33.03; Mon, 07 Mar 2022 02:33:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eRSO8yPN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240138AbiCGKFG (ORCPT + 99 others); Mon, 7 Mar 2022 05:05:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234934AbiCGJmH (ORCPT ); Mon, 7 Mar 2022 04:42:07 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CCEEDED7; Mon, 7 Mar 2022 01:41:12 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1C6CF61354; Mon, 7 Mar 2022 09:41:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 108EDC340FF; Mon, 7 Mar 2022 09:41:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646646071; bh=kRf2+Neh77iSMJt5sEjQ41gXstfFY7Iu39R7lcfHym4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eRSO8yPNB8e5XTqrtWExOIShYPSl/8PN1tOuo/kqrqIiLymL5p6pIsIWeSw5ZiT0q eGiu2eyaTGbDFexQiclnwfG0t5cUcXFnhgTuu2nYS+mBoS0Qa4Zz0nj8SPy+5o6lui zbUjrHyHz7c/f6RVvNQJEPqSvntW/W7T5bEC1VVQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vladimir Oltean , Florian Fainelli , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.15 123/262] net: dsa: seville: register the mdiobus under devres Date: Mon, 7 Mar 2022 10:17:47 +0100 Message-Id: <20220307091705.932468911@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091702.378509770@linuxfoundation.org> References: <20220307091702.378509770@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vladimir Oltean [ Upstream commit bd488afc3b39e045ba71aab472233f2a78726e7b ] As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Seville VSC9959 switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the seville switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The seville driver has a code structure that could accommodate both the mdiobus_unregister and mdiobus_free calls, but it has an external dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls devm_mdiobus_alloc_size() on its behalf. So rather than restructuring that, and exporting yet one more symbol mscc_miim_teardown(), let's work with devres and replace of_mdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn't free a still-registered bus (it either runs both callbacks, or none). Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/dsa/ocelot/seville_vsc9953.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c index ca8c003b99bc5..05e4e75c01076 100644 --- a/drivers/net/dsa/ocelot/seville_vsc9953.c +++ b/drivers/net/dsa/ocelot/seville_vsc9953.c @@ -1111,7 +1111,7 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot) snprintf(bus->id, MII_BUS_ID_SIZE, "%s-imdio", dev_name(dev)); /* Needed in order to initialize the bus mutex lock */ - rc = of_mdiobus_register(bus, NULL); + rc = devm_of_mdiobus_register(dev, bus, NULL); if (rc < 0) { dev_err(dev, "failed to register MDIO bus\n"); return rc; @@ -1163,7 +1163,8 @@ static void vsc9953_mdio_bus_free(struct ocelot *ocelot) mdio_device_free(pcs->mdio); lynx_pcs_destroy(pcs); } - mdiobus_unregister(felix->imdio); + + /* mdiobus_unregister and mdiobus_free handled by devres */ } static const struct felix_info seville_info_vsc9953 = { -- 2.34.1