From nobody Sat Jul 25 23:03:45 2026 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 94B9A33E367 for ; Sun, 12 Jul 2026 04:53:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783832004; cv=none; b=P9TPUT5vmpvfpQ5XCIgLARwXZpq9d9XLMLEhOyVP4wPCJawmC6Qth/mkvat6a1jmGfiOp41YQ4HOri0988Ot5OAXqb4Q0nvdl/bmr0igfrJRREwCmYo5SBgTwVigo3VP6c4KA/fyQsFIvJwTSMa16wzIwWz1I8D2Zt7XJRZIw1Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783832004; c=relaxed/simple; bh=shhBzf8yexRu7jj90QvU8W+4YZ4WazeRu+Yf64bVNvw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=lsEvBRoR/sMcCQrw1y1sxYSyjfvMGehpmhSJzNMe2h71y0imsfruPZLW7BbzLRi9T4IBSkVgWuq/Es35n9E/IwNgtHzTcEhNz6vzek4SFlVEUeJ94YlVqycxJjFv/LNJ8o/SWJLh2ZZbipWvq99F2opD4G24eudS/IVk86Gr0Q4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZRtEn0hr; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZRtEn0hr" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2cca24023edso25867055ad.1 for ; Sat, 11 Jul 2026 21:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783832003; x=1784436803; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Vtqux2brqZY3L9xWBvozGrzsW9R7W5/4mbtliRjhCrk=; b=ZRtEn0hrZWiDP0SrY9SHWUQSF8WKuOnuFRGMqp7dAQf80hcPXgGf0hSz3xk5VFdWuF p0zJ56IK0/2CKH2YVgBGdjURnvjI8pbFYwqxoQlMU2qUelO61llzCIDgorTd7DDoCAPN YiVbOmkrvDt+E4XuDHZ05jD0U6YNFCB1CX3/kYVwS1HLJZ1gp7nuG3u5A0/V3TCklnkV 1Un9LRv2B99g2XkR7g4JCNkU8ySiGOjI4yhSeCCSiFFxcVncZ6HK7J+mXJGn3v10uKYP hRRMetG0cdjG/QubbCpBPFJdSvXeP0U7Wd1H6C5clgZCAEl0R3tqpRQa3HQSXbEt+3Uk 4RAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783832003; x=1784436803; h=content-transfer-encoding:mime-version: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=Vtqux2brqZY3L9xWBvozGrzsW9R7W5/4mbtliRjhCrk=; b=K8PdnWM8Bjnt7POHAS4tiOLn83+EvEjs3mXANhMMYgengpGz6UKVAsZe0IUgetHeGQ U01EQ9SZaz/fOYMDLmj0e48kU14MpzmTWw4jE27y34y3MrzHvs6gcXpjd72ejH4f508u b52wBT65ON79lrg3hHkLG2Rn4rcJTzFgPl5qS6PkgC9lkckxhhgYQghuQTXCtbSrDoq9 Bu1bZL8bixW1QcPHLuCCCi2wpRJ1ylBzjfyhBqjsPrxdc8Gs8q4L7Efhx+wi1hl9FteC 7fivg8i1S2ZWxbAcNZFH2VVzVfpSP+HB9MJKGDcg3asetxWt9N5GW/2b4TX1T6LoA6HW Pm+Q== X-Forwarded-Encrypted: i=1; AHgh+RriAXJa7uFRj/ZhX6uBGdpXRAU25X1vKJg81FP/5vqU2R6zQZ7pVSb5fbDS48IB/Y8GDDqKmJNbd3HgLqc=@vger.kernel.org X-Gm-Message-State: AOJu0YyyTLpfZc7+loSAo/642854ndYGh/uk9JRiDdDl+n235RMIgqxp aAMNnJ2DscnBef77bLLOPk8LxzPDSiCXewFCIXIxzTsMqdI1bjfT1gI3 X-Gm-Gg: AfdE7ckgy1zqX+fJ/yA5exOWEWVr4fyBlzVv48ZSPbwUtqXe8bZpQLPZkFyV52sf+ZE ZQ5rM4JPfvMx9oFX7nHhswpVtSPFMHJDYYaiMjZRwEEXW2wBY/pqkskcXu/WOYZCYt3crFAhFfE XcOYu70F4q357nJ05DzJVPS3AIkWjO0cMuMlBfo1dfSZ0zv6338vvPaGb+PV5VoDLCK/rHcR/iV tDZjJ+mW3ywHbNfl4ULs9e/OES2RaQf+YO4Y/Nb0yKlRZg/Hh2anGldx/1qD1mlsCNPwS27s4RN bagM9fQXdH/HugVEHjOzvL1j+YJUMQzBoKBKxdJQE/GlIhn/zN3RAlQLgoNAGOD2BG4kekXmu+y 1bBUKsN+pjapQhnRfbdmVgEhiqStiwwUHA79P2bDqVv6weTFSZLQ0SwRWJjoZz/f7Glk0jPzEqK s= X-Received: by 2002:a17:902:f68b:b0:2ca:1eef:5096 with SMTP id d9443c01a7336-2ce9f15ccacmr45287845ad.36.1783832002767; Sat, 11 Jul 2026 21:53:22 -0700 (PDT) Received: from localhost ([2001:da8:7001:11::cb]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ccc9d3da55sm81624355ad.71.2026.07.11.21.53.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jul 2026 21:53:22 -0700 (PDT) From: Inochi Amaoto To: Inochi Amaoto , Andrew Lunn , Eric Dumazet , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Yixun Lan , Maxime Coquelin , Alexandre Torgue Cc: netdev@vger.kernel.org, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, E Shattow , Han Gao Subject: Failed to reinit phy of spacemit-dwmac when reset-gpio is present Date: Sun, 12 Jul 2026 12:52:33 +0800 Message-ID: <20260712045233.800748-1-inochiama@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" TL;DR: The DWMAC on Spacemit K3 is failled to register phy after the reload the driver module (rmmod then insmod). Because the reset-gpio is asserted while unloading the driver and is not desserted before reading the c22 id, which leads to a fault. Description In a few days ago, E Shattow reports he has sufferred the a weird issue, when unloading the spacemit-dwmac driver and then reloading it, he got the following error: [ 60.713071] mdio_bus stmmac-0: MDIO device at address 1 is missing. This only occurs when reloading the driver but the first initialization successed. After some function tracking, I found it is failed at reading c22 id. The call graph is as the follows: stmmac_mdio_register mdiobus_alloc of_mdiobus_register __of_mdiobus_register __mdiobus_register __of_mdiobus_parse_phys of_mdiobus_child_is_phy of_mdiobus_register_phy fwnode_mdiobus_register_phy get_phy_device get_phy_c22_id By checking the difference between the initialization process and the reloading process, I found the reset gpio is asserted in the function mdiobus_unregister(). And there is no any function desserted this reset gpio in the loading stage. And in the initialization process, the reset goio is deasserted. This bug report is sent as I found it is hard to solve this problem and ask for help to fix this issue as it is related to the framework instead of a specific driver. The possible workaround I found is as the following, just use the phy id in the compatible string (Confirmed by dlan): Tested-by: E Shattow --- --- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts @@ -196,7 +196,8 @@ ð0 { mdio { phy0: phy@1 { - compatible =3D "ethernet-phy-ieee802.3-c22"; + compatible =3D "ethernet-phy-id001c.c916", + "ethernet-phy-ieee802.3-c22"; reg =3D <1>; reset-gpios =3D <&gpio 0 15 GPIO_ACTIVE_LOW>; reset-assert-us =3D <10000>; --- An interesting thing is, moving the reset-gpio to the MDIO bus level does not solve this problem. Only setting the right phy id can mitigate the problem. Regards, Inochi