From patchwork Thu Apr 28 11:40:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Walle X-Patchwork-Id: 1623600 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.a=rsa-sha256 header.s=mail2016061301 header.b=Llz0IEVy; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=2620:137:e000::1:20; helo=out1.vger.email; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by bilbo.ozlabs.org (Postfix) with ESMTP id 4Kptws1Kd8z9s5V for ; Thu, 28 Apr 2022 21:41:01 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345628AbiD1LoM (ORCPT ); Thu, 28 Apr 2022 07:44:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345591AbiD1LoK (ORCPT ); Thu, 28 Apr 2022 07:44:10 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A65AB6160A; Thu, 28 Apr 2022 04:40:56 -0700 (PDT) Received: from mwalle01.kontron.local. (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 6DCF022248; Thu, 28 Apr 2022 13:40:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1651146054; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JiqBZQ8WhL/HQE3t9cKCnkvxEmKUyQmiYVcw2DHH7vU=; b=Llz0IEVyKKiZbUNetON7vPZE3J79hfcmVS88zCke5AyvvzwIySsM+PiCkBj4MTXMRadyJK q99b3vauhfJxqqfv7uCb+pbNxEnxmz1Q6CRrYl19KOWCEB6iEsgTCyGEXuBjBTZWqPNcKG l89th19gkY44IZUl7d5Tuo0E906cZAg= From: Michael Walle To: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Horatiu Vultur Cc: UNGLinuxDriver@microchip.com, Philipp Zabel , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Walle Subject: [PATCH net-next 1/2] dt-bindings: net: lan966x: remove PHY reset Date: Thu, 28 Apr 2022 13:40:48 +0200 Message-Id: <20220428114049.1456382-2-michael@walle.cc> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220428114049.1456382-1-michael@walle.cc> References: <20220428114049.1456382-1-michael@walle.cc> MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The PHY reset was intended to be a phandle for a special PHY reset driver for the integrated PHYs as well as any external PHYs. It turns out, that the culprit is how the reset of the switch device is done. In particular, the switch reset also affects other subsystems like the GPIO and the SGPIO block and it happens to be the case that the reset lines of the external PHYs are connected to a common GPIO line. Thus as soon as the switch issues a reset during probe time, all the external PHYs will go into reset because all the GPIO lines will switch to input and the pull-down on that signal will take effect. So even if there was a special PHY reset driver, it (1) won't fix the root cause of the problem and (2) it won't fix all the other consumers of GPIO lines which will also be reset. It turns out, the Ocelot SoC has the same weird behavior (or the lack of a dedicated switch reset) and there the problem is already solved and all the bits and pieces are already there and this PHY reset property isn't not needed at all. There are no users of this binding. Just remove it. Signed-off-by: Michael Walle --- .../devicetree/bindings/net/microchip,lan966x-switch.yaml | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index 131dc5a652de..f3ed708de0eb 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -53,12 +53,10 @@ properties: resets: items: - description: Reset controller used for switch core reset (soft reset) - - description: Reset controller used for releasing the phy from reset reset-names: items: - const: switch - - const: phy ethernet-ports: type: object