From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 77EE3199D8 for ; Sun, 19 Jul 2026 07:35:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784446531; cv=none; b=tJYuDeJ8uiDTP+Uhtj7i9KzQGaSh0e67+jFyjdh4hbJZbjF/QlsSNZrNJLVcy2wyp6+z/xRmgC0z6e9GzCl/EK55sQQZH9efFCYrpnfWm6T5nTD/k43tw9M1uJOOJjnrrkEd9sGFuP140FnnOVfyOCG5Mk+aNY5bWZkVryN6o4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784446531; c=relaxed/simple; bh=4ecBlAcbYQf2cS+lrV+mfChuXK9dvIG474QSj/Aj9KA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B/lIAJXe0eHAa95u1DZtaadrA4otAy9/hyKTprD7MB4l4708YIct7jLL2xGJxEdW9hQeVg19Pvz5KN1Oerq2f3nhBH8oDyiSr/1ouPCwqxzX0bqfWgwDAZFutFQ2TV+t26QSQUexk4819nKCdekTHZhZku0qwnZDk6Q070AVIhw= 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=NZtUrjb9; arc=none smtp.client-ip=209.85.221.46 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="NZtUrjb9" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-47f752b3423so71807f8f.3 for ; Sun, 19 Jul 2026 00:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784446529; x=1785051329; 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=Imm+2HdKzD/NJViR1a5kBtUfxMpdoo/1H9QI/inJ3Ik=; b=NZtUrjb9VTAqAM3mVZxFrpIcPbVP9dDroJhTd1q4m6K8i7pqVRYqBSwG4SH8e5+E02 MuAlfAIm3Bm+GjLC6I+pOj6TgwirlACQ6rsrYNhtVnppEIhpudPHmpefKNfOXjVdEIpe cv3mTIHQht+f/ZafvvpmHwujvlMexZV4EWoYlzkODeGt/HVUtv4Y6wKNbv0kE6+RS3nH rOR/Vko9IJWEangB5ay0mog+RQtcPZGQXK1tBQ9hyA5NkVpwdLuZPDUlzXjvZsRXyzrM dpb9EQU13mKdiQeuRqdaMkBiyj/8ipNr3OzRfapaz/CL63FsOfjufePWNP3fux43EVhl XKuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784446529; x=1785051329; 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=Imm+2HdKzD/NJViR1a5kBtUfxMpdoo/1H9QI/inJ3Ik=; b=D1Zn1nNJTm4RsVi9BVNccgApYFtsm9okDWregVEDtyLigXxApJi7aK3sKVxOeSCkCh XJgjYsVUyWXtRjxMCqUqSIOJQxSGB6HnOnDolXjmwLYvyYrSalIgKRl8Zx5QdDDlmuwL CvvrStSVP+j5jAUeazywjiau+j1zQDm2v1s1KwnTpr/YDLGUQo67Xc5VIq7Dptqa0wt+ Z6eQSH8qOV5EckgO6l3ZU+0XGKTs28bQSQYzqk2f3PvKBWCn+6ppv9Yug10WaDKSwdVa X0aMK3RZ8hVcPbrk/fjlFNsh/2cGaeRPgchVrz9psj7bQtun3Q5I6gr3Zcx7Kpil6eGZ uUaQ== X-Forwarded-Encrypted: i=1; AHgh+RonRcs9Dyv1iHmNAZhW0Fa7vtNJUVGoPOG6AghAXn1fmvLK4QuAa+pt5U4ABOZbno1Gd+zU+ZUF6zDCCgk=@vger.kernel.org X-Gm-Message-State: AOJu0YyNWCY6MyWyfGhakIq5HU1tRrewESkhPOufbIIFMCt6MIzdsizf ylx/5KhifAtWMpESqwZZtXceu/VObb8CR+ZcHc1Gaol8aTfg5vtVf1xO X-Gm-Gg: AfdE7cmuYEpX3i1nyLIK4RKvT++x57Y95UkIeT84eM09qwntQ/8IiFFr2HX4oiZH4AD pe/ZnFz7O4w/QhJq339N3nvSzfs2TmZ4twrPP9gjwKefLvQMbqDn7kx1NAxpQdl+m9YM43sHk/i wZ/jzLm9rMn0hbWutyXMVjB3arRieJg82+P57qhwgQBS19euED0bQqWl26kzwsu1eZOuVj1upiD Ukrm0VU+y5hkePu+NTjAGkqXcWhGweUxOBLSDg9EZl/gWzWTl+g5VDZuZ7y2Swgq4II2JJoL4nG ob1BxU+EQsMddFy69tVHAYND+4d4txvOUREwZ8zCKnRaEyRlsrGRhZaztt3AHLeXPWgflheSsof g9CfS4YWK7h8YuSDnWGudYfNX0EERjlesIL91BKETKObNqkLb78JIqAliW0qjphCRLM4HRw2tux R87D1kgpZfVrwgVZCwlHL2mcfjq2xX7doD5wSzcQrp5P7A/tIdoJ2ayBSQD0Df8/4= X-Received: by 2002:a5d:5d82:0:b0:472:aaba:faed with SMTP id ffacd0b85a97d-47f6232c345mr10116308f8f.31.1784446528361; Sun, 19 Jul 2026 00:35:28 -0700 (PDT) Received: from VivoBook-ASUS-X712UA-M712UA.lan (public-gprs693195.centertel.pl. [5.184.251.12]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f69e5eff1sm11116540f8f.19.2026.07.19.00.35.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 00:35:27 -0700 (PDT) From: Stanislaw To: Johan Alvarado , Mieczyslaw Nalewaj Cc: Linus Walleij , Alvin Sipraga , Andrew Lunn , Vladimir Oltean , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Russell King , Maxime Chevallier , Luiz Angelo Daros de Luca , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v6 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S Date: Sun, 19 Jul 2026 09:35:19 +0200 Message-ID: <20260719073519.10947-1-kuncy7@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Luiz, Two updates from the bench: last night's cold-soak result, and a correction about the reset GPIO. 1) A 3-minute pre-init wait PREVENTS the bad state. Last night's image carried a plain msleep(180000) at the top of rtl83xx_probe(), before anything touches the chip - and nothing else on top of the v6 series (no busy-wait, no 0x060C writes). After ~10 h powered off, the first init landed clean for the first time: 0 FCS errors on the SerDes CPU port, 0 drop events, DHCP lease right away, 0% loss on the trunk. Every comparable soak before (same hardware, overnight off, no wait) came up degraded. Single morning so far - I will repeat it - but this is the first thing that has *prevented* the state rather than cured it after the fact. During those 180 s the chip is powered and out of its (bus-level) reset, just untouched by the driver. So your time-vs-state discriminator leans "time": the very same init sequence that lands bad when run at t=3.5 s lands clean when run at t=187 s. It does not fully separate "the switch needs time" from "something else on the board needs time", but nothing else shows any distress at t=3.5 s - the SoC-side MAC/PCS come up fine, and even in the bad state the switch's transmit direction is byte-exact clean. 2) Correction: the realtek driver performs NO hard reset here. I mis-stated this earlier: reset-gpios on this board sits on the MDIO *bus* node (the IPQ5018 MDIO bus driver toggles it once at bus init), not on the switch node. rtl83xx_probe() therefore sees neither reset_ctl nor a reset gpio and the hard-reset branch never runs - I confirmed it with a print inside that branch. So the curing re-probe is a pure *soft* full init (detect + complete setup/jam-table sequence, the only chip reset being the soft one in setup), no pin involved. The "double reset in probe" scenario does not apply on this board at all. 3) Next steps, along your suggestions: - Bisect the required off-time with the no-wait image, to get reproductions on demand instead of one per night. - On the next on-demand bad state: full register dump via regmap debugfs, bad state vs. post-cure, plus the reset-bit isolation. - Then bisect the wait itself (180 s -> 90 -> 45 ...) to find the threshold - that number should hint at which physical process we are waiting out. Best regards, Stanislaw