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 44CF244C97; Fri, 22 Mar 2024 13:11:17 +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=1711113081; cv=none; b=Qlf0jGgS7vDyeuDNYfyaaizY8JuVPQZ4eH1tEuJ4T4/jtThbdHdKX4J5gTxyv8Eyi2NLSYXsJKWxbFI8sFxM/FqBReGzGnBx6dX4K7+jLmxGR+63dcaoVIiJXf/t6CenbYoZwiOvjEv5YY+M5C6gqodufXmCWbPHH+TOyx/puYI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711113081; c=relaxed/simple; bh=FTN5M/4n2j9wR7OBq/TUq/tbFZDX7NYrEDnkQCjXB1g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FhSo+d19D8rToHHFYctKQMBH7oyVYc84bHt0lCd5TSX67QZvmp0iYqaoQzfj8FJo5YQ1Xc4vmFEEajezyfJQtXTHDj8cLPxdfydS0f361/HrNhrZCJ7mPTfZMvbk1FmpExlKmQxSUXnJWbHfkZVeZ5FIYyBEWbBqGXz5XYxsBYM= 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=U9z6T2wk; 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="U9z6T2wk" 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=x5ozSz+s2mlcaFcznwcIfR3LT7eM0wy0PldnwgSngfQ=; b=U9z6T2wkbnu9XPCta7wwuPJNLO Q98P7B7QLYjQjJAZFgfY0Rue5B/ufsCzZ7xZb1pQ1PQX2wXuV6QKS1oNeEFt3o3R4FmPI0n1vzdUN aVVXtZ3kJNuS8MjRaWzWma3vL7hGpn4nUhjujYl9B0PcwwVguTxnSo53UfOk0fvK3cgQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rnefq-00AxcY-VU; Fri, 22 Mar 2024 14:11:06 +0100 Date: Fri, 22 Mar 2024 14:11:06 +0100 From: Andrew Lunn To: Josua Mayer Cc: Gregory Clement , Sebastian Hesselbarth , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Yazan Shhady , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards Message-ID: <4fff2165-c3cc-41d8-b541-6e69ce4d98ac@lunn.ch> References: <20240321-cn9130-som-v1-0-711127a409ae@solid-run.com> <20240321-cn9130-som-v1-2-711127a409ae@solid-run.com> <0d1afbcc-948e-4aff-8296-42f7166d318d@solid-run.com> Precedence: bulk X-Mailing-List: linux-kernel@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: <0d1afbcc-948e-4aff-8296-42f7166d318d@solid-run.com> > > Sorry, but no. List the LEDs in the PHY node, and they can then be > > controlled via /sys/class/leds. > May I ask more precisely the motivation? > Does this replace the phy's builtin automatic led control? > > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. > > I will investigate it. > > My main motivation for tweaking the led controls was to make them all consistent across the two boards: > - LEDs under control of PHYs on cpu mdio bus > - LEDs under control of ethernet switch on mdio bus > - LEDs under control of ethernet phy on external mdio bus behind ethernet switch > > It looks as if the marvell phy driver supports led subnodes, > The switch driver does not. https://lwn.net/Articles/965775/ There has been quite a bit of interest in mv88e6xxx driver support, so i expect support for other families outside of 6352 will be added after it has been merged, and it is not difficult code to write. > Finally one phy can only be written to but not read, > the cpu can never know its link state. O.K. That one cannot use the LED infrastructure in a meaningful way. > So I prefer (for the Clearfog Pro) board to explicitly use the phys > autonomous management of LEDs. > Is that still possible if I added led subnodes? You can combine both. The horrible marvell,reg-init will be applied first. The generic LED code will then take over controlling the LEDs. For the discrete PHYs, the generic LED code can make use of the hardware offload support to read back the hardware configuration and configure itself to match. The switch code is missing hardware offload at the moment. So it cannot read back the current configuration. However, it is simple code to add, and the discrete code is a good example to follow. marvell,reg-init is not going to go away, because of backwards compatibility with old DT blobs. But in general, i expect all vendor proprietary methods of configuring LEDs to be deprecated and replaced with the vendor neutral /sys/class/leds. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 75A69C47DD9 for ; Fri, 22 Mar 2024 13:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IMiX/szqA2WkssOMQlsW7VzaN9f/Zh81bJ1DYGk74xI=; b=PIFlVGJWto2iAf 1iScFeSEyZRN+subbByf1OhUlOznC8tzurjPmye2N8Sch9+QG2Gz4faqG8pINNu3NnNhaDTMkwcjA jgfDxiRyFYLna02Nfj7x7nfotLwvG3N7HLeWCVek1hdTrrPVsjDBctwKnujBF4TiDvOmw98TslG8S 7wYi3j2Hr25GVEAwgQX9vwqYKiVWu6522xqnBbVtJeWcFSY2u8/G2fG8mtc1nOZTxaexIRGf8pcoy Tp1w5YfCO2ssQH1N2bkjq/mzl2I0zzohAKmco0t01WWZg1WVjgNOAhvqGmksXRMCwReDXsNpiGFkg dchkslULBp/rl5WP0E8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rneg2-00000007FPO-18Bg; Fri, 22 Mar 2024 13:11:18 +0000 Received: from vps0.lunn.ch ([156.67.10.101]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnefy-00000007FOG-40WU for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 13:11:17 +0000 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=x5ozSz+s2mlcaFcznwcIfR3LT7eM0wy0PldnwgSngfQ=; b=U9z6T2wkbnu9XPCta7wwuPJNLO Q98P7B7QLYjQjJAZFgfY0Rue5B/ufsCzZ7xZb1pQ1PQX2wXuV6QKS1oNeEFt3o3R4FmPI0n1vzdUN aVVXtZ3kJNuS8MjRaWzWma3vL7hGpn4nUhjujYl9B0PcwwVguTxnSo53UfOk0fvK3cgQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rnefq-00AxcY-VU; Fri, 22 Mar 2024 14:11:06 +0100 Date: Fri, 22 Mar 2024 14:11:06 +0100 From: Andrew Lunn To: Josua Mayer Cc: Gregory Clement , Sebastian Hesselbarth , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Yazan Shhady , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards Message-ID: <4fff2165-c3cc-41d8-b541-6e69ce4d98ac@lunn.ch> References: <20240321-cn9130-som-v1-0-711127a409ae@solid-run.com> <20240321-cn9130-som-v1-2-711127a409ae@solid-run.com> <0d1afbcc-948e-4aff-8296-42f7166d318d@solid-run.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0d1afbcc-948e-4aff-8296-42f7166d318d@solid-run.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_061115_028469_CC22041D X-CRM114-Status: GOOD ( 19.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > > Sorry, but no. List the LEDs in the PHY node, and they can then be > > controlled via /sys/class/leds. > May I ask more precisely the motivation? > Does this replace the phy's builtin automatic led control? > > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. > > I will investigate it. > > My main motivation for tweaking the led controls was to make them all consistent across the two boards: > - LEDs under control of PHYs on cpu mdio bus > - LEDs under control of ethernet switch on mdio bus > - LEDs under control of ethernet phy on external mdio bus behind ethernet switch > > It looks as if the marvell phy driver supports led subnodes, > The switch driver does not. https://lwn.net/Articles/965775/ There has been quite a bit of interest in mv88e6xxx driver support, so i expect support for other families outside of 6352 will be added after it has been merged, and it is not difficult code to write. > Finally one phy can only be written to but not read, > the cpu can never know its link state. O.K. That one cannot use the LED infrastructure in a meaningful way. > So I prefer (for the Clearfog Pro) board to explicitly use the phys > autonomous management of LEDs. > Is that still possible if I added led subnodes? You can combine both. The horrible marvell,reg-init will be applied first. The generic LED code will then take over controlling the LEDs. For the discrete PHYs, the generic LED code can make use of the hardware offload support to read back the hardware configuration and configure itself to match. The switch code is missing hardware offload at the moment. So it cannot read back the current configuration. However, it is simple code to add, and the discrete code is a good example to follow. marvell,reg-init is not going to go away, because of backwards compatibility with old DT blobs. But in general, i expect all vendor proprietary methods of configuring LEDs to be deprecated and replaced with the vendor neutral /sys/class/leds. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel