Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp652625ybb; Thu, 28 Mar 2019 09:29:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqxESZDxF3xSu+ZgsukfxdgNGUxD1mUO7LnIQByZH7s8WKZa8p2K7OvptDl2DWHKu+0Qzh5S X-Received: by 2002:aa7:80c8:: with SMTP id a8mr42875659pfn.193.1553790596619; Thu, 28 Mar 2019 09:29:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553790596; cv=none; d=google.com; s=arc-20160816; b=UTEppB17zO3D79ig0qw8FDdOaM01WqysaIhqM63vzXl8CxbFYw/xWeGfUj71X4kQ9Q 6twX/cADXDsWJsbtA6SpbapF6YK64ZVjzOuEt3yJg+k0es1rujeHTBi6o6lfuk6QBOCb 78JrcZVurGDkwJLk8l8gPUg1TrD52okxEWQ9JaTC5zknia1y24dQRAoVGKtIeylBuXaI AVXDuGe1vwdI9oE9rHgbOvg89AfG0TXZrTe7UmZvkg0Z76Y79/MP7VQYrLrSbcQP1xYS uFlYYX1BilWE9F2MNovBV4ONGK26ADMkeiYEPt0SqIK4CmeqlIpdtcQNhP48vM1yAioe H8cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=awOg/48iAqQFPw8p4NI3hF5iP5KBfF1+0EfD1TD635M=; b=ox5eHh7Qlf6nAVPwaJyyazClQnI7GbUQ+it1R4mlwj3wv2ArhgEHslaHd4V1kDEckx Js3EEYQrnL6WMR/S6Y9Va+W+hz/+S3dSVcZoQJ17sKW08S8WY3+tR3P5iCmoNLMcLU/V buLzIgv6gB9IlRpPpe74GeT6Xu29S42/mrxx8qnfoGBYcygKaOxMdEmKLUvUPvQUMrHC H5wovfYoZ0H5YWM0Wc7YU7msGRxULMY5gLEWsJwv1Ilr3DUgRTBVkCZ6JZ9H/xIXvyYS qoAV1L6vQUiNucAQLQa+M7+K1MqbDIeuRtA4UzkBL9YLmZkoN15ZgNFwP9crJueAcGRw T3tA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e10si21300573pgm.298.2019.03.28.09.29.41; Thu, 28 Mar 2019 09:29:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727623AbfC1Q2o (ORCPT + 99 others); Thu, 28 Mar 2019 12:28:44 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:41893 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbfC1Q2o (ORCPT ); Thu, 28 Mar 2019 12:28:44 -0400 Received: by mail-ot1-f65.google.com with SMTP id 64so18889973otb.8; Thu, 28 Mar 2019 09:28:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=awOg/48iAqQFPw8p4NI3hF5iP5KBfF1+0EfD1TD635M=; b=fhsK1nnHcvnthj009r4m4q7ozkrRiHU6wNLu56ptfbFbe/zI/+RWpQ8eu6tPxTx+wI +04oIm4JfAUVFAoUDhhavoELmK0ETyCidHxFrDTGUvkAUGKWdfi7w8XAj0eM+FO6KWuY c8p98Rj9IhdDm2AKPnHpoflzmOyzb8I8B9LV4LurDzc4uKodT8694BT5LtxsmYGD7HAh GsiOAPaH4Mqt5uERsvs1L/i6zjRx2PAiXUVmIJQfsAEQy7m1m4vSNLq/m6NfaS5sPiYU iAQekRmc65nAIermAl2nPBkhxEVKUCw/16zzFqvp8WSv/Hg9or7RaxSCUD52LYynATx9 2XMg== X-Gm-Message-State: APjAAAWC0KjDDDZPG3OxoWYSkL3+6we9kFqRGjL+GHJedzu1ou9UqEDS jA/mDGwhihVKEzwzifAQGQ== X-Received: by 2002:a05:6830:11c2:: with SMTP id v2mr15513257otq.161.1553790523591; Thu, 28 Mar 2019 09:28:43 -0700 (PDT) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id q18sm9804511otl.51.2019.03.28.09.28.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Mar 2019 09:28:42 -0700 (PDT) Date: Thu, 28 Mar 2019 11:28:42 -0500 From: Rob Herring To: Rasmus Villemoes Cc: Pavel Machek , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Jacek Anaszewski , LKML , linux-leds@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree Message-ID: <20190328162842.GA11865@bogus> References: <20190313202615.22883-1-linux@rasmusvillemoes.dk> <20190314140619.3309-1-linux@rasmusvillemoes.dk> <20190314140619.3309-7-linux@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190314140619.3309-7-linux@rasmusvillemoes.dk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 14, 2019 at 03:06:19PM +0100, Rasmus Villemoes wrote: > It can be quite convenient to initialize a netdev-triggered LED with a > device name and setting the rx,tx,link properties from device tree, > instead of having to do that in an init script (or udev rule) in > userspace. > > My main motivation for this is to be able to switch away from the > deprecated CONFIG_CAN_LEDS. The example added to common.txt > corresponds to switching linux,default-trigger = "can0-rxtx" to > "netdev" and adding the indicated netdev subnode. > > Signed-off-by: Rasmus Villemoes > --- > .../devicetree/bindings/leds/common.txt | 11 +++++++ > drivers/leds/trigger/ledtrig-netdev.c | 30 +++++++++++++++++++ > 2 files changed, 41 insertions(+) > > diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt > index 7cb88460a47c..f8078c4cf6f8 100644 > --- a/Documentation/devicetree/bindings/leds/common.txt > +++ b/Documentation/devicetree/bindings/leds/common.txt > @@ -43,6 +43,17 @@ Optional properties for child nodes: > Documentation/ABI/testing/sysfs-class-led-trigger-netdev) > to reflect the state and activity of a net device. > > + The optional child node netdev can be used to > + configure initial values for the link, rx, tx and > + device_name properties. For example, > + > + netdev { I was going to let the use of netdev slide, but now you have it twice and that's a Linuxism. > + rx; > + tx; > + link; What do these mean? > + device-name = "can0"; can0 is a linux thing and doesn't belong in DT. > + }; I really don't like this. What's this going to look like if every trigger wants to add something like this? What's special about netdev leds? We really need to decouple the Linux LED trigger design from the DT bindings. I have no problem associating LEDs with devices in DT, but it shouldn't just bring the LED trigger design into the bindings.