From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 AA0B42FC037 for ; Fri, 17 Apr 2026 17:30:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776447051; cv=none; b=VLKVJYrTsx3VBxtBj5p/M90bSEvNNC3VYHGL0+ExUtVT6JIgg8VJobhgCiMJOfcDfYphNwAIBYqbLXxrPri+kLmdl9i6ta0fGV8s7uFBxzJ3ij8OLs4EObvwz4XgcJAvCKZmHfNe89c3lhyjkVuatKorEKAZrXLewlXyFINGuCA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776447051; c=relaxed/simple; bh=ycybKBC08oXR9ME0KHALVkiM6mQfe8XZvDSZtlzc91U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EwXFoMMz7+L8J8RQexUztv1cTCOemK89xdCMAj4VgMb9iYq6MR47J5LZ2wvo6HS3enLrjJYb+5FBnJJmGYBkANtyo5yS6qw9TE6tKUjrRkXaqm2eowHb+QSMtUv8o/QIIj8LlAN7NlABTjxGs+CExqCgP1cF7g+F9U9eYugDVuU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=y73whGyi; arc=none smtp.client-ip=156.67.10.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="y73whGyi" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=TGZoyyU5mHFyfI81hgTycgiqWkmpexYhWMgVjzucmMY=; b=y73whGyibXvyVYNDNyPFnQAyMd eNY9QgXr6vi7KyuFwRNlaDo8k5tV+c+1/UEylcCLSaqrJP2gNkA8zSOSyey5havYeGQa4Vsy8QmX4 0918cQy7oZdGrMy6KAypTjdiQtI9bC4T2/zcsWEp1a5TKgSl7pjvvLfFUEkvcrpA2yNM=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1wDn1R-00GRAd-By; Fri, 17 Apr 2026 19:30:29 +0200 Date: Fri, 17 Apr 2026 19:30:29 +0200 From: Andrew Lunn To: Alexander Stein Cc: "Russell King (Oracle)" , Maxime Chevallier , Heiner Kallweit , Alexandre Torgue , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, Maxime Coquelin , netdev@vger.kernel.org, Paolo Abeni Subject: Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release() Message-ID: <01f5e05f-31ab-4051-bc2a-9c331fcd9a95@lunn.ch> References: <680c384c-135f-44cd-a2cd-7e4fd0ec4bf7@bootlin.com> <13939918.O9o76ZdvQC@steina-w> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13939918.O9o76ZdvQC@steina-w> > Thanks for conforming this for another PHY. What I'm wondering right now: > Why is the PHY stopped in the first place? We are just changing the MTU, no? It is not too uncommon to see an MTU change destroying everything and rebuilding it, especially when it was retrofitted into an older driver which had fixed MTU. > I have a proof of concept running, but it needs more cleanup due > to code duplication. You probably also want to take a look at the ethtool code for configuring rings. Oh, it is even worse: int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size) { struct stmmac_priv *priv = netdev_priv(dev); int ret = 0; if (netif_running(dev)) stmmac_release(dev); priv->dma_conf.dma_rx_size = rx_size; priv->dma_conf.dma_tx_size = tx_size; if (netif_running(dev)) ret = stmmac_open(dev); return ret; } So not even using __stmmac_release() or __stmmac_open(), and leaving you with a dead interface if there is not enough memory to allocate the rings. These paths should really share the same code. Andrew