From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DC512F2914 for ; Mon, 22 Sep 2025 07:11:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758525103; cv=none; b=I4mW5wJ1xq21TBSbq8NL/CeJWMV4QoLAXij3sD7EzYANAerua0lgspxLFvU7GorAp1Yv6lg9jRMFwgoBc/1HfDXxdHwLYlTVw+Zy11ywJEbwVNihBGmrqExfxkXZxTa9OWFAYPyvZwGufMxtOlmxQfcOS5+1SGVQiuaty8LI4OQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758525103; c=relaxed/simple; bh=T7Z0FIstTb2WSj8YtIHnDt3lr50hwBNXU0a3XU0hZ6A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iaZe+JZmLpliBLUTBhiRXcG3lE38tknb2VFeoD0HNPJA1Bmh6GTDpWbVYGbnHBNtFAAEDEKfW2N/2InZG0pHNc0yTsZms2Et7Zo4E/wQJ5uLavKXq33whM7m4PcUEW1fsTShk6M56WjmKe4WXYiPfbJsLeuDuPdGkfVG4Imu1N4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1v0ahc-0000Ae-EZ; Mon, 22 Sep 2025 09:11:12 +0200 Received: from pty.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::c5]) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v0ahZ-002YKq-2Z; Mon, 22 Sep 2025 09:11:09 +0200 Received: from ore by pty.whiteo.stw.pengutronix.de with local (Exim 4.96) (envelope-from ) id 1v0ahZ-006mzY-25; Mon, 22 Sep 2025 09:11:09 +0200 Date: Mon, 22 Sep 2025 09:11:09 +0200 From: Oleksij Rempel To: Lukas Wunner Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Hubert Wi??niewski , Marek Szyprowski , stable@vger.kernel.org, kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Russell King , Xu Yang , linux-usb@vger.kernel.org Subject: Re: [PATCH net v1 1/1] net: usb: asix: forbid runtime PM to avoid PM/MDIO + RTNL deadlock Message-ID: References: <20250917095457.2103318-1-o.rempel@pengutronix.de> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-usb@vger.kernel.org Hi Lukas, On Wed, Sep 17, 2025 at 08:58:17PM +0200, Lukas Wunner wrote: > On Wed, Sep 17, 2025 at 11:54:57AM +0200, Oleksij Rempel wrote: > > Forbid USB runtime PM (autosuspend) for AX88772* in bind. > [...] > > With autosuspend active, resume paths may require calling phylink/phylib > > (caller must hold RTNL) and doing MDIO I/O. Taking RTNL from a USB PM > > resume can deadlock (RTNL may already be held), and MDIO can attempt a > > runtime-wake while the USB PM lock is held. > > FWIW, for smsc95xx.c, the MDIO deadlock issue was resolved by commit > 7b960c967f2a ("usbnet: smsc95xx: Fix deadlock on runtime resume"). > I would assume that something similar would be possible for > asix_devices.c as well. thanks for the recommendation. Right now I’m juggling two goals: - Stable: provide a simple and robust fix with minimal risk. - net-next: design a clean and reliable solution that keeps autosuspend working. For -stable, keeping autosuspend disabled per AX88772* seems to be the most straightforward and low-risk way to avoid the problematic autoresume path. Autosuspend isn’t on by default in most distros anyway, so the behavioral impact is minimal. If we keep autosuspend enabled, the driver has to be careful about multiple contexts: - Runtime PM callbacks: asix_{suspend,resume,reset_resume} running under the USB PM lock. - System sleep/resume: asix_resume() via dpm_run_callback() workqueues (no pm_runtime involved). - ndo_open() path (RTNL held): usbnet_open() -> usb_autopm_get_interface() -> synchronous autoresume into asix_resume(). - ethtool / netlink control paths: often under RTNL, may trigger autoresume and/or MDIO via phylib. - phylink/MAC ops: may touch MDIO; caller is expected to hold RTNL. - status URB / NAPI: atomic/BH context (no sleeping, no RTNL). If maintainers prefer attempting the smsc95xx-style change right away, I can draft it; my preference for -stable is still the minimal forbid to limit churn. Best Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |