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=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 0DC9CC433E0 for ; Tue, 28 Jul 2020 17:28:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E16972078E for ; Tue, 28 Jul 2020 17:28:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731826AbgG1R2l (ORCPT ); Tue, 28 Jul 2020 13:28:41 -0400 Received: from lists.nic.cz ([217.31.204.67]:59002 "EHLO mail.nic.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731892AbgG1R2l (ORCPT ); Tue, 28 Jul 2020 13:28:41 -0400 Received: from localhost (unknown [IPv6:2a0e:b107:ae1:0:3e97:eff:fe61:c680]) by mail.nic.cz (Postfix) with ESMTPSA id 2127F140760; Tue, 28 Jul 2020 19:28:39 +0200 (CEST) Date: Tue, 28 Jul 2020 19:28:38 +0200 From: Marek Behun To: Andrew Lunn Cc: netdev@vger.kernel.org, linux-leds@vger.kernel.org, Pavel Machek , jacek.anaszewski@gmail.com, Dan Murphy , =?UTF-8?B?T25kxZllag==?= Jirman , Russell King , Thomas Petazzoni , Gregory Clement , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs controlled by PHY HW Message-ID: <20200728192838.29c798a9@nic.cz> In-Reply-To: <20200728161800.GJ1705504@lunn.ch> References: <20200728150530.28827-1-marek.behun@nic.cz> <20200728150530.28827-2-marek.behun@nic.cz> <20200728161800.GJ1705504@lunn.ch> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Sender: linux-leds-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Tue, 28 Jul 2020 18:18:00 +0200 Andrew Lunn wrote: > > +static int of_phy_register_led(struct phy_device *phydev, struct device_node *np) > > +{ > > + struct led_init_data init_data = {}; > > + struct phy_device_led *led; > > + u32 reg; > > + int ret; > > + > > + ret = of_property_read_u32(np, "reg", ®); > > + if (ret < 0) > > + return ret; > > + > > + led = devm_kzalloc(&phydev->mdio.dev, sizeof(struct phy_device_led), GFP_KERNEL); > > + if (!led) > > + return -ENOMEM; > > + > > + led->cdev.brightness_set_blocking = phy_led_brightness_set; > > + led->cdev.trigger_type = &phy_hw_led_trig_type; > > + led->addr = reg; > > + > > + of_property_read_string(np, "linux,default-trigger", &led->cdev.default_trigger); > > Hi Marek > > I think we need one more optional property. If the trigger has been > set to the PHY hardware trigger, we then should be able to set which > of the different blink patterns we want the LED to use. I guess most > users will never actually make use of the sys/class/led interface, if > the default in device tree is sensible. But that requires DT can fully > configure the LED. > > Andrew Yes, I also thought about that. We have the linux,default-trigger property, so maybe we could add linux,default-hw-control-mode property as well. Marek