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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7B56C10DC1 for ; Fri, 8 Dec 2023 06:58:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233183AbjLHG6I (ORCPT ); Fri, 8 Dec 2023 01:58:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233070AbjLHG6D (ORCPT ); Fri, 8 Dec 2023 01:58:03 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 226BC1724 for ; Thu, 7 Dec 2023 22:58:10 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0810C433C7; Fri, 8 Dec 2023 06:58:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702018689; bh=GMos9O4HmmM+U55/J8+WlvlVh/uZHHlzuooomDAHT8c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=poAC46PKgZhBiAFlrbze1CMXAMTKpwovQsFdJgOEkVmN7GQu2TDRfmUPf2AQwHWlH /ltyjzWd2/4XtT6kOALILrTKGzZDC1lfoxJsseDAKV1Kpd+wIFGr0A/kqzizofxPNH OF/O9+bD8mzuE9+tbQ5cgYrWesJYMKUdHiqesRvRssMTJaSkwkuaDb1Xtv3OEHTguz XlI2+YnDRUIAJ7hxsJqWtO6XzwItfBxmpl9x1qG65JaJcY3GOxr9Gu+5MEB8UzAKk/ og1GQzvJy+IJm9LNkS68ooB6lwUJtl8WkbFO67PyeK6Ly9OhgssdWURyDZ35lE0bka LigbPHxmusB6g== Date: Fri, 8 Dec 2023 07:58:04 +0100 From: Marek =?UTF-8?B?QmVow7pu?= To: Andrew Lunn Cc: Daniel Golle , Lee Jones , Pavel Machek , Jakub Kicinski , Christian Marangi , "David S. Miller" , Li Zetao , linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org Subject: Re: [PATCH v3 1/2] leds: trigger: netdev: extend speeds up to 10G Message-ID: <20231208075804.4f8559e6@dellmb> In-Reply-To: References: <99e7d3304c6bba7f4863a4a80764a869855f2085.1701143925.git.daniel@makrotopia.org> <20231207172923.62ce530e@dellmb> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Dec 2023 18:11:29 +0100 Andrew Lunn wrote: > On Thu, Dec 07, 2023 at 05:29:23PM +0100, Marek Beh=C3=BAn wrote: > > On Tue, 28 Nov 2023 04:00:10 +0000 > > Daniel Golle wrote: > > =20 > > > Add 2.5G, 5G and 10G as available speeds to the netdev LED trigger. > > >=20 > > > Signed-off-by: Daniel Golle > > > Reviewed-by: Andrew Lunn =20 > >=20 > > So what will happen when there are more speeds? Will we create a > > separate file for each speed? > >=20 > > Will we have a separate sysfs file for 10, 100, 1000, 2500, 5000, > > 10000, 20000, 25000, 40000, 50000, 56000, 100000, 200000, 400000, > > 800000 ? > >=20 > > These are all speeds from include/uapi/linux/ethtool.h. > >=20 > > Maybe we should have reused ethtool link mode bits, or something... =20 >=20 > That gets pretty ugly. The bits are not in any logical order, since > they just get appended onto the end as needed. >=20 > > Also, the files should only be present if the requested speed is > > supported by the net device. So if 2500 mbps is not supported, there > > should no be link_2500. =20 >=20 > Yes, this would be nice. We have the information in the phy_setting > settings[] table in phy-core.c. What if the netdev does not have a PHY? The MAC also has speed information. Maybe create a function bool dev_supports_speed(netdev, speed) ? Marek