Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp2176359rwl; Thu, 6 Apr 2023 06:56:37 -0700 (PDT) X-Google-Smtp-Source: AKy350b2dcvKR1UC57JtxQk+6MQihKk4X8BLBJ1dzZ0A10J8kMz/mSCVghPH1Nnd7HmM8l0AGbe8 X-Received: by 2002:aa7:9a0b:0:b0:627:6328:79d7 with SMTP id w11-20020aa79a0b000000b00627632879d7mr8781800pfj.34.1680789397686; Thu, 06 Apr 2023 06:56:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680789397; cv=none; d=google.com; s=arc-20160816; b=efEQvIIxweceUsZ3gu9yC2tqMFUd/x/mYq3icIQQyk0745cQoL5KgeuzDn+VIixr42 PvxCGe8l8uAl1gLOxkM5/xPQdjJPfoXT5odLt0oCoajsKY5YSgSUISRedcxx4JOjXf+B k2aLakOviV3AD1vLhpA1URakPzfVLWJCwo/hut56a6qorurHvrLBvIsfiiFD58SCIvAH fWXrs8c6Vi7vefsqTa9EKY+sA5qmwuvreHNJaO89WPxEN+tK7mgTwIrS4dUB59P6x5bp 7GPm/25cE09FN1xedWb2B+n+19U2JPA1IQS7h7yUYTmHIuhqGKyzuVGJAcTs62WilBmu Fowg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eCyDhIIH7zROrQHs1/YiKAKEaRN5MqlP/rzgVydjPvI=; b=0yFc6/F6LKtXK14kUIzlL7KDC9JGxDSvCaJ2et3d2pP5sSaf0PURO+Yp1DjWZuesmV QqBqXrMh1aZzZUcytT6qu9IVN+5XUVo5IbVjfV0RyR7nw8/owOpnsZJoefL7HQ2nk0SL 6ALXtX+ONX1q8Sk5iNw8wtKhDfK/C1FwKiKbEQvHVL4INkCjJ5Y444rC51k9gRg50t1i eQHn3N8u5Z0BUCgkCUF9LNnYNL1DT2IZbDXyMPCwzg57/PxWluCoqRvqoz+IsOpSR0xN VaPlQGeRKUhYrQxDflCLLBh3y0my/spMikd+fm0IG1unTKBQYjElZzlrYmq1IjuViUwb ZB+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=T8qx3rQo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w25-20020a631619000000b0051353d86539si1314719pgl.687.2023.04.06.06.56.25; Thu, 06 Apr 2023 06:56:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=T8qx3rQo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238149AbjDFNzB (ORCPT + 99 others); Thu, 6 Apr 2023 09:55:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238363AbjDFNyl (ORCPT ); Thu, 6 Apr 2023 09:54:41 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B5D09777; Thu, 6 Apr 2023 06:54:35 -0700 (PDT) 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=eCyDhIIH7zROrQHs1/YiKAKEaRN5MqlP/rzgVydjPvI=; b=T8qx3rQouZ7XvU4SiE9YvRbYYJ eZ/TIFFWd6LmzPMmlepLNKX294cnNsz5NBy1K0lf6uyD5yo8cEVMMD66JAuSKt2jdTgaf6+EumK2y H3+38xMvHD4Jz1kfvnOmzRVGQzMEvPTeRioo/AiUb+xhnlOoHJmBpes1tBDESCRP7XFs=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pkQ46-009dDs-Gr; Thu, 06 Apr 2023 15:54:14 +0200 Date: Thu, 6 Apr 2023 15:54:14 +0200 From: Andrew Lunn To: Pavel Machek Cc: Christian Marangi , Lee Jones , Rob Herring , Krzysztof Kozlowski , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , Russell King , Gregory Clement , Sebastian Hesselbarth , Andy Gross , Bjorn Andersson , Konrad Dybcio , John Crispin , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [net-next PATCH v6 16/16] arm: mvebu: dt: Add PHY LED support for 370-rd WAN port Message-ID: References: <20230327141031.11904-1-ansuelsmth@gmail.com> <20230327141031.11904-17-ansuelsmth@gmail.com> <2e5c6dfb-5f55-416f-a934-6fa3997783b7@lunn.ch> <7cadf888-8d6e-4b7d-8f94-7e869fd49ee2@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=unavailable 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: linux-kernel@vger.kernel.org > I don't think basing stuff on position is reasonable. (And am not sure > if making difference between MAC and PHY leds is good idea). > > Normally, there's ethernet port with two LEDs, one is usually green > and indicates link, second being yellow and indicates activity, > correct? Nope. I have machines with 1, 2 or 3 LEDs. I have green, yellow, white and red LEDs. Part of the problem is 802.3 says absolutely nothing about LEDs. So every vendor is free to do whatever why want. There is no standardisation at all. So we have to assume every vendor does something different. > On devices like ADSL modems, there is one LED per port, typically on > with link and blinking with activity. > > Could we use that distinction instead? (id):green:link, > (id):yellow:activity, (id):?:linkact -- for combined LED as it seems. > > Are there any other common leds? I seem to remember "100mbps" lights > from time where 100mbit was fast...? But what about 2.5G, 5G, 10G, 40G... And 10Mbps for automotive. And collision for 1/2 duplex, which is making a bit of a comeback in automotive. Plus, we are using ledtrig-netdev. A wifi device is a netdev. A CAN bus devices is a netdev. Link speed has a totally different meaning for 802.11 and CAN. You are also assuming the LEDs have fixed meaning. But they are not fixed, they mean whatever the ledtrig-netdev is configured to make them blink. I even have one of my boxes blinking heartbeat, because if has a habit of crashing... And i think for Linux LEDs in general, we should not really tie an LED to a meaning. Maybe tie it to a label on the case, but the meaning of an LED is all about software, what ledtrig- is controlling it. As to differentiating MAC and PHY, we need to, because as i said, both could offer LEDs. Generally, Ethernet switches have LED controllers per MAC port. Most switches have internal PHYs, and those PHYs don't have LED controllers. However, not all ports have internal PHYs, there can be external PHYs with its own LED controller. So in that case, both the MAC and the PHY could register an LED controller for the same netdev. It comes down to DT to indicate what LED controllers are actually wired to an LED. Andrew