Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4980581pxb; Tue, 5 Oct 2021 14:46:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzREC0eMZAzz6ZaUKgUDWW6OKopVZdOASusqbyeXfGl8ywrn1XmxOCSBieKznOilpgkLkPo X-Received: by 2002:a17:90a:2902:: with SMTP id g2mr6514420pjd.161.1633470367549; Tue, 05 Oct 2021 14:46:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633470367; cv=none; d=google.com; s=arc-20160816; b=tFtj85zNR62b9bXAmcGkFXVoNhijS7Fjjn7Q+A0+S9/JWlpMKWJJvJRl+EnrJ6kCBQ Zt8/lQ+vN40735DsWkB8Ly3EDv9gUmOaZayB8YnPbUZRr3eHuKOtVwqlx1uMhImWRQfL HQw6RgXZW+SDYC3ylgfXvbJ6OWGs8x7pIA5YdJ/6TN3pz6BHHJ02NG6RPUJaGtTpzG/V jd5stlLvdjvBGXpwxAJbkb1cLlQLsyxIxopM1E/r6+R/KHq10GH9ZOadGorIpo4FV3+6 nPGxx6gO1+iyEDuDxTZSwpXQLGVgtoKpZa1+3D9YSrqs/zCTLjtPsTQ0SE1kX/YTBwB2 VZkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=+OxhddcfZEcLjkJvvHpsiGYRYBoznPKpWIbeB7ju8t0=; b=tgLja7J6ZHhaqovfV+Yox8IGw8XFbEcYdxKoczgSnM3bcTiB7Q2faedYrVQ/yrf52t pTZrKmHmXJJvvnVinkPuPU92gIX+y/ghuHOgrr+hbPAa8JRvGpPYobTUZr0D3FvDvV0l A7DwcqvkYdGY4loZdiHcO59+0jTlcByQV97rZaPff1OuLJY10yjRuInRqy1zxDLSlayF kBOBYOZVG4mGD80ColP7M+lmOpak5SKUfV0X7SMqPLOlXt9x2+/2juke/s2O0TMVUk7O VTFm2ygp3s61yg39jCx8Uwuqm05rk1ZmM8zxxqZYrTBwYLmO8e42uva23PhCfnIxpn3i EPsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ScmUt3fs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k10si250461plk.450.2021.10.05.14.45.54; Tue, 05 Oct 2021 14:46:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ScmUt3fs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236707AbhJEVpi (ORCPT + 99 others); Tue, 5 Oct 2021 17:45:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:55970 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231167AbhJEVph (ORCPT ); Tue, 5 Oct 2021 17:45:37 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CA53B6115B; Tue, 5 Oct 2021 21:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633470226; bh=WSHqCxwflqcKiT4irCE8NVjFBqw/353tC8L3Y9Ud/TI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ScmUt3fswhW0wl194TQi6oZyg8Vnh1ZvtfHQ9IWUNX/pReP6oohtj8AgjDUSbtZEz zVL/iYigoegiTcipiIhaJICnIckaUQZGL8vie8YySTZe+r+texQfzMQU5Hp+8xUH9I Uu5t/397vlJONtqayAAqVrNpkes3cGbJuBTYiG8lTh5n0vuSFqVJdRvgxRVx+8JvVl 36Q1zw+SmY5BjYBQJOU2nOMzjOY/gpQ7T0Bo/vU3h2cWPv+D2I/BZHh9n2QGHEVEEz LSYUCFNH3+oIg5AvyTFfaGZKb7Vnp9fg/YJh8Io6+P3W4hbaP2cq4rINjyxNijkKOi yYcOO1wb3E9Tw== Date: Tue, 5 Oct 2021 23:43:42 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Andrew Lunn Cc: Jacek Anaszewski , Rob Herring , Pavel Machek , "linux-leds@vger.kernel.org" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: lets settle the LED `function` property regarding the netdev trigger Message-ID: <20211005234342.7334061b@thinkpad> In-Reply-To: References: <20211001143601.5f57eb1a@thinkpad> <20211003212654.30fa43f5@thinkpad> <20211004170847.3f92ef48@thinkpad> <0b1bc2d7-6e62-5adb-5aed-48b99770d80d@gmail.com> <20211005222657.7d1b2a19@thinkpad> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Oct 2021 23:01:18 +0200 Andrew Lunn wrote: > > In the discussed case (ethernet PHY LEDs) - it is sometimes possible to > > have multiple brightness levels per color channel. For example some > > Marvell PHYs allow to set 8 levels of brightness for Dual Mode LEDs. > > Dual Mode is what Marvell calls when the PHY allows to pair two > > LED pins to control one dual-color LED (green-red, for example) into > > one. > > > > Moreover for this Dual Mode case they also allow for HW control of > > this dual LED, which, when enabled, does something like this, in HW: > > 1g link green > > 100m link yellow > > 10m link red > > no link off > > > > Note that actual colors depend on the LEDs themselves. The PHY > > documentation does not talk about the color, only about which pin is > > on/off. The thing is that if we want to somehow set this mode for the > > LED, it should be represented as one LED class device. > > > > I want to extend the netdev trigger to support such configuration, > > so that when you have multicolor LED, you will be able to say which > > color should be set for which link mode. > > This is getting into the exotic level i don't think we need to > support. How many PHYs have you seen that support something like this? This isn't about whether there are PHYs which support this in HW. The extension to netdev trigger will be able to do this in SW. For example the Turris Omnia has 12 RGB LEDs on the front panel, of which 6 are dedicated to ethernet ports (and there are no LEDs on ethernet ports themselves). It would make sense to be able to have netdev trigger (or it's extension) show link mode by color (for example green on 1g, yellow on 100g, orange on 10g). Anyway when you have a green-yellow LED on an ethernet port wired in such a way than it can only be off, green or yellow, but not both green and yellow, I don't think we should register these as 2 LED class devices. > I suggest we start with simple independent LEDs. That gives enough to > support the majority of use cases people actually need. And is enough > to unblock people who i keep NACKing patches and tell them to wait for > this work to get merged. Of course, and I plan to do so. Those netdev trigger extensions and multi-color function definitions are for later :) We got side tracked in this discussion, sorry about that. In this thread I just wanted to settle the LED function property for LEDs indicating network ports. So would you, Andrew, agree with: - extending function property to be array of strings instead of only one string, so that we can do function = "link", "activity"; - having separate functions for different link modes function = "link1000", "link100"; or should this insted be in another property function = "link"; link-modes = <1000 100>; ? Marek