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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29227C742D1 for ; Fri, 12 Jul 2019 17:28:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F2C2720665 for ; Fri, 12 Jul 2019 17:28:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="iBxbrmeQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727380AbfGLR2c (ORCPT ); Fri, 12 Jul 2019 13:28:32 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:45050 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726977AbfGLR2b (ORCPT ); Fri, 12 Jul 2019 13:28:31 -0400 Received: by mail-pl1-f196.google.com with SMTP id t14so5065769plr.11 for ; Fri, 12 Jul 2019 10:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=B2UJfx4oFfYv8Nk1qbPMoO6T0uqv31ruVH0IxQrtWQA=; b=iBxbrmeQQMmLS1jq1GtyHY5qZg7l2qZRSwJNAsVsfEkOFtHxVhhIuE7waHJwEe3PdF fak9SbSHQvhdY+O7eClTrM2dADhgY/8jRZTTospg3OAuqIY5jSfAvF3SarACjohfvzeu MeKAsUCyBCqi1Y11JHPllssQWdp918PvYrkJg= 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=B2UJfx4oFfYv8Nk1qbPMoO6T0uqv31ruVH0IxQrtWQA=; b=aeb0qNLTc5VWYdp88l7ZcUw0BS2ivfl0mxfnM5J0LOmZuYjPkn+deqGP8rILLVNJMN EKCwXA5bE9BLFv3FpMt1kApZCukDq7cnOm+dDc5DhD8TwdSp5Q1TtH9OUe3BBneZaK34 KWxGgZkDxRa6wEjzgrhNFCEAl0l4uN0DgmRcOsqpR7hGe6GN6YlgCX8fuSgHnz16uAk+ VwalIeMpNSDfh/ry0Pkoz/3sOzskgPPzpDQn/ccL+sNiB8nHlxNbcb2KU/X6f+qcSuhK mCQa/LLBBu3gUlGRMjFO4cyo2DSgK3D0TX2T9vp9E0C7t2pIZHUG522upMX72HwYdvvH CchA== X-Gm-Message-State: APjAAAUm8MT/FIzQlXCxypIVW/pezYKZMjOD2RQTdNGeU2IBJ/455VIk 4bnt88b4EvJe7Zn5/JBPPn55wQ== X-Google-Smtp-Source: APXvYqziV0raXuB1SklCG7h9zCcyg+VtfHgaqjWoJjwuMXIOcx7BlysV6VD6pCNKw924mhMgGvhO/A== X-Received: by 2002:a17:902:424:: with SMTP id 33mr12806201ple.151.1562952510548; Fri, 12 Jul 2019 10:28:30 -0700 (PDT) Received: from localhost ([2620:15c:202:1:75a:3f6e:21d:9374]) by smtp.gmail.com with ESMTPSA id k25sm4027806pgt.53.2019.07.12.10.28.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 10:28:30 -0700 (PDT) Date: Fri, 12 Jul 2019 10:28:27 -0700 From: Matthias Kaehlcke To: Florian Fainelli Cc: Rob Herring , Andrew Lunn , Heiner Kallweit , "David S . Miller" , Mark Rutland , netdev , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , Douglas Anderson Subject: Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode Message-ID: <20190712172827.GR250418@google.com> References: <20190703193724.246854-1-mka@chromium.org> <20190703193724.246854-6-mka@chromium.org> <20190703232331.GL250418@google.com> <7d102d81-750d-32d9-a554-95f018e69f2f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7d102d81-750d-32d9-a554-95f018e69f2f@gmail.com> 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 Hi Florian, On Wed, Jul 10, 2019 at 09:28:39AM -0700, Florian Fainelli wrote: > On 7/10/19 8:55 AM, Rob Herring wrote: > > On Wed, Jul 3, 2019 at 5:23 PM Matthias Kaehlcke wrote: > >> > >> Hi Florian, > >> > >> On Wed, Jul 03, 2019 at 02:37:47PM -0700, Florian Fainelli wrote: > >>> On 7/3/19 12:37 PM, Matthias Kaehlcke wrote: > >>>> The LED behavior of some Realtek PHYs is configurable. Add the > >>>> property 'realtek,led-modes' to specify the configuration of the > >>>> LEDs. > >>>> > >>>> Signed-off-by: Matthias Kaehlcke > >>>> --- > >>>> Changes in v2: > >>>> - patch added to the series > >>>> --- > >>>> .../devicetree/bindings/net/realtek.txt | 9 +++++++++ > >>>> include/dt-bindings/net/realtek.h | 17 +++++++++++++++++ > >>>> 2 files changed, 26 insertions(+) > >>>> create mode 100644 include/dt-bindings/net/realtek.h > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt > >>>> index 71d386c78269..40b0d6f9ee21 100644 > >>>> --- a/Documentation/devicetree/bindings/net/realtek.txt > >>>> +++ b/Documentation/devicetree/bindings/net/realtek.txt > >>>> @@ -9,6 +9,12 @@ Optional properties: > >>>> > >>>> SSC is only available on some Realtek PHYs (e.g. RTL8211E). > >>>> > >>>> +- realtek,led-modes: LED mode configuration. > >>>> + > >>>> + A 0..3 element vector, with each element configuring the operating > >>>> + mode of an LED. Omitted LEDs are turned off. Allowed values are > >>>> + defined in "include/dt-bindings/net/realtek.h". > >>> > >>> This should probably be made more general and we should define LED modes > >>> that makes sense regardless of the PHY device, introduce a set of > >>> generic functions for validating and then add new function pointer for > >>> setting the LED configuration to the PHY driver. This would allow to be > >>> more future proof where each PHY driver could expose standard LEDs class > >>> devices to user-space, and it would also allow facilities like: ethtool > >>> -p to plug into that. > >>> > >>> Right now, each driver invents its own way of configuring LEDs, that > >>> does not scale, and there is not really a good reason for that other > >>> than reviewing drivers in isolation and therefore making it harder to > >>> extract the commonality. Yes, I realize that since you are the latest > >>> person submitting something in that area, you are being selected :) > > > > I agree. > > > >> I see the merit of your proposal to come up with a generic mechanism > >> to configure Ethernet LEDs, however I can't justify spending much of > >> my work time on this. If it is deemed useful I'm happy to send another > >> version of the current patchset that addresses the reviewer's comments, > >> but if the implementation of a generic LED configuration interface is > >> a requirement I will have to abandon at least the LED configuration > >> part of this series. > > > > Can you at least define a common binding for this. Maybe that's just > > removing 'realtek'. While the kernel side can evolve to a common > > infrastructure, the DT bindings can't. > > That would be a great start, and that is actually what I had in mind > (should have been more specific), I was not going to have you Matthias > do the grand slam and convert all this LED configuration into the LEDs > class etc. that would not be fair. > > It seems to be that we can fairly easily agree on a common binding for > LED configuration, I would define something along those lines to be > flexible: > > phy-led-configuration = ; > > where LED_NUM_MASK is one of: > > 0 -> link > 1 -> activity > 2 -> speed I don't understand this proposal completely. Is LED_NUM_MASK actually a mask/set (potentially containing multiple LEDs) or is it "one of" the LEDs? Are you suggesting to assign each LED a specific role (link, activity, speed)? Could you maybe post a specific example involving multiple LEDs? Thanks Matthias > that way you can define single/dual/triple LED configurations by > updating the bitmask. > > LED_CFG_MASK is one of: > > 0 -> LED_CFG_10 > 1 -> LED_CFG_100 > 2 -> LED_CFG_1000 > > (let's assume 1Gbps or less for now) > > or this can be combined in a single cell with a left shift. > > Andrew, Heiner, do you see that approach working correctly and scaling > appropriately?