From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f12.google.com (mail-wr2-f12.google.com [74.125.225.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 711D63C8700 for ; Fri, 18 Sep 2026 01:50:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789696248; cv=none; b=aXtT5XHqw0KKjnhhBZ6NCP/WUpri/0c2wPmtodMPDZkvUHM8hWmi5gehS+hfn/SL5yOa6RCgoXru4RZYxaMklsZno0ofZxtndE+LdAusiHUfdTQaj1gSu3Y+I6Bc13kPdzEVZEPrziuD0xzIx0LnzpNbv8xYPyfOgltoPrEWvqA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789696248; c=relaxed/simple; bh=ie+Fks8qvoH2s91CTwbbOujmR4Ipol0/ojc69WvScig=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PWo1af0lPQCADpxykpEEUSox4cNkfuY6NfXgqz6tmFZRAsVrPPYxl4nKyZFfs1H+YXdQwyMffmh1Jj5YDLcKNLpplZ0x01jpZsILN32yaUnwMKVxSDnVy7H3BvQ+1RMGHGaEUzxRQBwM4UNaWjGnOCuuer8zAz7Lp1+7qLfB2+0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la; spf=pass smtp.mailfrom=lex.la; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b=JUA9YVX0; arc=none smtp.client-ip=74.125.225.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lex.la Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b="JUA9YVX0" Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f633cd78so71286f8f.1 for ; Thu, 17 Sep 2026 18:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1789696233; x=1790301033; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=R3EdtN6qtnpTbUr6qyK3WOaZ6BRajWizEp8fE4gWzmw=; b=JUA9YVX0ffaOhhQIZVaEAVfFRKBtZ25S6uN5vhPH+sqxcWIWvkANdlYmLEPjXqAK0T dNcwODf4aZKX7ntsiXVEgvvhP30pA49uSw3CKPZynNXD8CGjxp2nVyRWV8FU9554IKr4 TH9/W3dyy0WMG0GRObiS4Kqgm8r2QBiZ5fZ57j/oLJT3qg92PpjgeZ/5JhWNkWRXKsAe H1EEma+IJeeChISGc9Y2zgqmdqYi8AINgVJkBp2GB0+33qS84A4ccxtdWcpN/J3XHy4p HbIjwyyNG/C460Md8itX/ELDN9ehRotAyeUL+ayp+9hXUxu5kIqI9RmQBypW/64kk+/o gBjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789696233; x=1790301033; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=R3EdtN6qtnpTbUr6qyK3WOaZ6BRajWizEp8fE4gWzmw=; b=MK0crh0XN7kV0Olf7TAFlNblQcBfqXZvnGvXwtMu93WOUCgMMTsa2nk92RHYWk2EMo pjEz9G+POC97HhZZRj82oFBM6fdW5p+xW9FXtZwIMn/C3ghORS+FOc5jzNWgWastSbp8 JGjmfLRXgUegkU7M1amT9hL7Yjr7yxO91l4AZzJfKiXL7vViA5a7gZYMiaLn7ttfPymI Dt8RGc3wNvn8BiSIfvohcVRcOSAkGul1eNVJbRZE6eqWb+kWuU0F2pvxkclLNyNddNE+ Q4adeQ3bc89oAzFuZj9L6ENdRd+evuSN/bVxgA7QY3N1tGNDEXo+yISgdd3DM4YzOv+P E6Lg== X-Forwarded-Encrypted: i=1; AKwUvBxW+gvm/aYcjrKH6cRAAwYFb3BH9YYDpRTgiCVI0MKrwP8ssIhUjRWEq9JvAjGhCoQ+tQa9OfBtgMGmbuY=@vger.kernel.org X-Gm-Message-State: AFuF++mj0jrfT9ET2SQdy5yDWHmlWG1hmIn0oMoVRKCIAba3Uu3ozwn8 59WBV6D9hm8fs0QKx9VeX2JhAEWJtbphJujB774qsNI7zg0uXpd8A9WvT0tGbRf1LZQ= X-Gm-Gg: AYBFou1Iv222LRR0UC3q7Yw0KJqZOX/dr7sEZ4BHWAJHZdgbfFYCMs7KaoKTJ4Jy3B+ 2SBRXHeL2saMHP/TkWvZdVCM8EdLFAc58GRb8UKz/ioDnakc0KoKkD/LE2fJD36LN1KOlUcRTze 1xsbS8QChRb6vWY+bQ/9VOGCKrYoFCYn8WXRdDgLjgjh1UjhXHqXeMRns0ZKWJmvkkRBrcOssdT X7oX2+lAbR8WnDWETIjGvTdUfaoXnfqcORgyG8TjEMGq01CihKATNusDnSM+9GRKqYFUBZR1s87 PJ+Mw05ng1ic8YE/pS4txw3OlChiVOYwSpA31eyxFuG6GJDhtE/YzI9gyp08be2vhB78nx3Jxos +eNYEvZwCADHsTyfDGanRZCZp4YaDDOjAFF+TnZ0nXG0VrtSlhjnTaPJu/R95BC71QAEwuhDJQK MoLLfYsInQS6qaFOqRqR+q+zgZNTEgbypkp9oakRiy22ywSt1YGA== X-Received: by 2002:adf:e187:0:b0:486:ed36:b9c with SMTP id ffacd0b85a97d-4871e269f3amr845004f8f.29.1789696233046; Thu, 17 Sep 2026 18:50:33 -0700 (PDT) Received: from remote-01 ([84.17.55.229]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-487200745b5sm64224f8f.26.2026.09.17.18.50.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2026 18:50:32 -0700 (PDT) From: Aleksei Sviridkin To: netdev@vger.kernel.org Cc: andrew@lunn.ch, andrew+netdev@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, olteanv@gmail.com, Thangaraj.S@microchip.com, UNGLinuxDriver@microchip.com, steve.glendinning@shawell.net, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Aleksei Sviridkin Subject: [PATCH net v8 1/4] net: usb: lan78xx: register the PHY interrupt with the MDIO bus Date: Fri, 18 Sep 2026 04:50:26 +0300 Message-ID: <20260918015029.2518425-2-f@lex.la> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260918015029.2518425-1-f@lex.la> References: <20260918015029.2518425-1-f@lex.la> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The interrupt this driver maps for its PHY is written only into phydev->irq, while the bus table mdiobus->irq[] keeps reading PHY_POLL for the same address. That table is where phylib records what the bus described - phy_device_create() seeds phydev->irq from it - so the number lives only as long as nothing else writes that one field. Put it where the bus keeps it and take phydev->irq from there. What the PHY is attached with does not change. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin --- Notes: Compile-tested only; I have no LAN78xx device. No Fixes: tag on this one. On its own it fixes nothing - nothing reads the bus table back until patch 3 - which is also why it sorts ahead of that patch rather than after it. The else branch that forced PHY_POLL is dropped rather than moved to the table, for two reasons. It cannot run: lan78xx_setup_irq_domain() returns -EINVAL when it cannot create the mapping, lan78xx_bind() gives up on that return, and lan78xx_phy_init() only runs afterwards, so phyirq is always positive by the time this code is reached. And if it could run it would be wrong in the other direction: this bus is registered with of_mdiobus_register(), so the table may already hold an interrupt the devicetree described, and forcing PHY_POLL over it would invert what patches 3 and 4 are for. Teardown order keeps the number live for as long as it is read: lan78xx_disconnect() detaches the PHY through phylink_disconnect_phy(), and lan78xx_unbind() calls lan78xx_remove_irq_domain() only afterwards. drivers/net/usb/lan78xx.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index cb782d81d84f..d02e4ffcbbc1 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -2892,11 +2892,10 @@ static int lan78xx_phy_init(struct lan78xx_net *dev) return 0; } - /* if phyirq is not set, use polling mode in phylib */ if (dev->domain_data.phyirq > 0) - phydev->irq = dev->domain_data.phyirq; - else - phydev->irq = PHY_POLL; + dev->mdiobus->irq[phydev->mdio.addr] = dev->domain_data.phyirq; + + phydev->irq = dev->mdiobus->irq[phydev->mdio.addr]; netdev_dbg(dev->net, "phydev->irq = %d\n", phydev->irq); ret = phylink_connect_phy(dev->phylink, phydev); -- 2.53.0