Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1216464pxb; Fri, 1 Oct 2021 06:09:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJw0wd/SkNqjuWO63hKzsFG9PRTtDtVgfUTOjetvqkJRp9KLiHXGW7dwT1+M3vahlL279O X-Received: by 2002:a65:62c4:: with SMTP id m4mr9792945pgv.453.1633093768534; Fri, 01 Oct 2021 06:09:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633093768; cv=none; d=google.com; s=arc-20160816; b=SAMfeNwwqk1Pq24mAkSu3YE6G9aTCxhyFn2TIYbnBXF7WdLSzWKXI+bQU8smfRp6yR tUk3aUxVB1y8/uTRiN3qev4LnGp3fbnl53Xx/ncLXBLNYZUj6Fd/vXrWkBJV2sAqEk3C BaAhuRD3MiWvI9UsvH3YQxxTh6AAaf3e3ZG2nNBfz61ma9v27IXjYCv3DgizrAVq/WJC 5i801WUU2Uz9w2MNVH5J2juzV/FAMhz4mIhRaT8QLTKEgVOGMCRNxe0WkI9yY+D8aapI ScjE4QF+u/j04qoIaNzSlbxi7Zc/xP2HxLGQ8IF+8EHy/K8I0lWGQGg1IYSnapXUc3G5 MyKA== 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 :message-id:subject:cc:to:from:date:dkim-signature; bh=AeX5a5rzF+zHqpq23HIX59T5OXQg2gh8s/4seiuFzio=; b=Oeuh/lrI80v29KZUZrv3RF7VdcSp+K87KfvfLKxq4fA8SAAtKLZQCbJTUDKRI5nZH+ Q1SU3Tv5QGJCFYj3n0OodxXy3UduPX76KXNwWiwTKOOR8XmaHXxpsgb8cG/RVlMdCRzM 75/VFlSq3ZCGY2F0zZTkq9facNMpQAbNcdvjPJwRIoKCA4FC74Kxkd/9lroWWz//dMIW fO3dHerz3gp9wjt78tQ9+3W+RA0CZ9TnF4AED1gm2Q57sCJd8HknEdeglfGcDhTv8+ec OEjjJeojjV8ael9ExDUvNyq26Ue6Jh/hO6uynRUrRnmaMEmhoZ0nvwIS6R+SSE1Adw1o eQQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eb8bfBHS; 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 p1si7867302plf.130.2021.10.01.06.09.04; Fri, 01 Oct 2021 06:09:28 -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=eb8bfBHS; 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 S1353840AbhJAMhw (ORCPT + 99 others); Fri, 1 Oct 2021 08:37:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:55388 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231352AbhJAMhv (ORCPT ); Fri, 1 Oct 2021 08:37:51 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id DED5A61A8B; Fri, 1 Oct 2021 12:36:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633091767; bh=4n6FROUAmxcbTg/roy1p496VFp3nU8QQo8Jp8WUJ5wI=; h=Date:From:To:Cc:Subject:From; b=eb8bfBHSSpETWEgA3oa8OPg39Wub9Pzm1NGQCLsK5bF/dPh+U1Rz0FFJ68RZzQEsj h2+BdSP6ZlqxTxVS5Vp4qn80NYrjkyR1q6flWN1fm9XjT9mkRI33ydQthJf2J5bWDb 22Jdus8dmGGnRyU1s3Mr/V3cy97aX1xpYxqYz5HQFfEqhvMDkewWetsGGSYgtHknPu DBLeJL4HiUztPdrD4sCe2ScUOyiYudxc3yZLOnfDKTooBNtoMTyrLB+Y6GYbw49xLd jyKkoYdb20XhFhCb23K6cqcWonUocx9Uh9oAJodLDZ70SCNpsHaaeTdj9NsjTrdpjq L+jreN3PPTXeA== Date: Fri, 1 Oct 2021 14:36:01 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Pavel Machek , Jacek Anaszewski , Rob Herring Cc: Andrew Lunn , "linux-leds@vger.kernel.org" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: lets settle the LED `function` property regarding the netdev trigger Message-ID: <20211001143601.5f57eb1a@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 Hello Pavel, Jacek, Rob and others, I'd like to settle DT binding for the LED function property regarding the netdev LED trigger. Currently we have, in include/dt-bindings/leds/common.h, the following functions defined that could be interpreted as request to enable netdev trigger on given LEDs: activity lan rx tx wan wlan The "activity" function was originally meant to imply the CPU activity trigger, while "rx" and "tx" are AFAIK meant as UART indicators (tty LED trigger), see https://lore.kernel.org/linux-leds/20190609190803.14815-27-jacek.anaszewski@gmail.com/ The netdev trigger supports different settings: - indicate link - blink on rx, blink on tx, blink on both The current scheme does not allow for implying these. I therefore propose that when a LED has a network device handle in the trigger-sources property, the "rx", "tx" and "activity" functions should also imply netdev trigger (with the corresponding setting). A "link" function should be added, also implying netdev trigger. What about if a LED is meant by the device vendor to indicate both link (on) and activity (blink)? The function property is currently a string. This could be changed to array of strings, and then we can have function = "link", "activity"; Since the function property is also used for composing LED classdev names, I think only the first member should be used for that. This would allow for ethernet LEDs with names ethphy-0:green:link ethphy-0:yellow:activity to be controlled by netdev trigger in a specific setting without the need to set the trigger in /sys/class/leds. Opinions? Marek