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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 324DFC636C8 for ; Sun, 18 Jul 2021 22:33:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 040A661108 for ; Sun, 18 Jul 2021 22:33:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232895AbhGRWgy (ORCPT ); Sun, 18 Jul 2021 18:36:54 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:32934 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbhGRWgv (ORCPT ); Sun, 18 Jul 2021 18:36:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=ayhWRsSlF7QKCWEVGjS1pgeLkcfIT3hF0BxjwsBDYXg=; b=r+3K+R1Sh4bofVnfvDbNvpYGuW S640NDtmdDe/c6Mev6Mh5j9x0dZSMz1T4jrkLAKT+Rku0pUmD6mGF91i01erqoQxfY0/DRbJWN++A zs7V9ksOU3F6RY1kfzBCkoR+irrt7goKn1XZjjWgMqz1U9xqiKwXeXnxM4VgAXecOwVE=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1m5FM0-00DpcA-L2; Mon, 19 Jul 2021 00:33:44 +0200 Date: Mon, 19 Jul 2021 00:33:44 +0200 From: Andrew Lunn To: Heiner Kallweit Cc: Tony Nguyen , Kurt Kanzenbach , davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, sasha.neftin@intel.com, vitaly.lifshits@intel.com, vinicius.gomes@intel.com, Sebastian Andrzej Siewior , Dvora Fuxbrumer Subject: Re: [PATCH net-next 5/5] igc: Export LEDs Message-ID: References: <20210716212427.821834-1-anthony.l.nguyen@intel.com> <20210716212427.821834-6-anthony.l.nguyen@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Jul 19, 2021 at 12:10:52AM +0200, Heiner Kallweit wrote: > On 16.07.2021 23:56, Andrew Lunn wrote: > > On Fri, Jul 16, 2021 at 02:24:27PM -0700, Tony Nguyen wrote: > >> From: Kurt Kanzenbach > >> > >> Each i225 has three LEDs. Export them via the LED class framework. > >> > >> Each LED is controllable via sysfs. Example: > >> > >> $ cd /sys/class/leds/igc_led0 > >> $ cat brightness # Current Mode > >> $ cat max_brightness # 15 > >> $ echo 0 > brightness # Mode 0 > >> $ echo 1 > brightness # Mode 1 > >> > >> The brightness field here reflects the different LED modes ranging > >> from 0 to 15. > > > > What do you mean by mode? Do you mean blink mode? Like On means 1G > > link, and it blinks for packet TX? > > > Supposedly mode refers to a 4-bit bitfield in a LED control register > where each value 0 .. 15 stands for a different blink mode. > So you would need the datasheet to know which value to set. If the brightness is being abused to represent the blink mode, this patch is going to get my NACK. Unfortunately, i cannot find a datasheet for this chip to know what the LED control register actually does. So i'm waiting for a reply to my question. There is a broad agreement between the LED maintainers and the PHYLIB maintainers how Ethernet LEDs should be described with the hardware blinking the LED for different reasons. The LED trigger mechanisms should be used, one trigger per mode, and the trigger is then offloaded to the hardware. Andrew