From patchwork Thu Apr 27 00:15:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Marangi X-Patchwork-Id: 678280 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 82801C77B60 for ; Thu, 27 Apr 2023 00:18:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239903AbjD0AS5 (ORCPT ); Wed, 26 Apr 2023 20:18:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239435AbjD0AS4 (ORCPT ); Wed, 26 Apr 2023 20:18:56 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F22262101; Wed, 26 Apr 2023 17:18:54 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-3f086770a50so52615785e9.2; Wed, 26 Apr 2023 17:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682554733; x=1685146733; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=mSvwzY2UlZlmB3HYmCg+9GgEn9N6fP96TrWBJYvA1GY=; b=oWX3zrV+c9w918yqvuiLWLGHRlWgHIbYGlmgRhWJEV1K5yOlaH68MFJyb7rhw4LQV4 vnaG42/xjTrjJqvqnFiIImzpBozQsKfZJVSanM11hkgZqUIj4vdlN0vBmMPF68iLhpWz fbebcqqBSKgdplsZ022gP+ABGGgP1hBqsT71UQ4i7ofqS6KwPXddlvMnb5FwWvFHgIb6 BBaWZpZqifUFBWAHY6BviWnX4DyEMZONMJKXOjLCpsigPZ/U5uNigPSdeR5yZ894+9qD GM8NTqCrLQ3rCgUAJEnaQ+Lbuq3ErHam8uwHaeRi39fGChbSfH80owsz5BPYgsbwwEGX WBuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682554733; x=1685146733; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mSvwzY2UlZlmB3HYmCg+9GgEn9N6fP96TrWBJYvA1GY=; b=VrtdqygOFbgYOJqe6STFh2btKYafwxIrXtBI3Xhf/2vF31HhmXu9uFL/m6KH4blzYF qKxY63IQmeh8f0SFxMuwgi1A7TFvmtYZxMl/oTzOmrIUUfwAelPwapMERl0HiS7r/nkl H4BPnGJQ0UwANkBX8PqiyPwQUq41F38s7fAtqqxKKkCXlCrm1oX3RoYQG5n/i53R0pfh RxjmevPViYKkWcBIpXevbWoAQdrEQN08tePvuGIjhcWwYEiO3tVqO6hItE3iNCU2th7v xWjdHu2QzGCmf0GHMjFCeRhP919LnvTlI6xbHnqMJidPbhCQOkoQSmPbCL8UDcdtAVOi Ddnw== X-Gm-Message-State: AAQBX9eFe1ATWja7mtAxOXw8nyL/vHLX4/vx1ebHUq4FFHlNzKFXDS2q xKhrbUu95cgNGX5SwC8QXsZY4mQWgQE= X-Google-Smtp-Source: AKy350aSmNWnTXa97z5pVcnWRXYztfHmrd1OsGs7y1DM145lmROIRumSTYrOHS7oM7fy4eG2e95sTQ== X-Received: by 2002:a7b:c845:0:b0:3f1:9526:22be with SMTP id c5-20020a7bc845000000b003f1952622bemr12781700wml.23.1682554733112; Wed, 26 Apr 2023 17:18:53 -0700 (PDT) Received: from localhost.localdomain (93-34-93-173.ip49.fastwebnet.it. [93.34.93.173]) by smtp.googlemail.com with ESMTPSA id r3-20020adfda43000000b003047ae72b14sm8624916wrl.82.2023.04.26.17.18.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 17:18:52 -0700 (PDT) From: Christian Marangi To: Jonathan Corbet , Pavel Machek , Lee Jones , Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Marangi , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 00/11] leds: introduce new LED hw control APIs Date: Thu, 27 Apr 2023 02:15:30 +0200 Message-Id: <20230427001541.18704-1-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org This is a continue of [1]. It was decided to take a more gradual approach to implement LEDs support for switch and phy starting with basic support and then implementing the hw control part when we have all the prereq done. This is the main part of the series, the one that actually implement the hw control API. Some history about this feature and why ======================================= This proposal is highly requested by the entire net community but the API is not strictly designed for net usage but for a more generic usage. Initial version were very flexible and designed to try to support every aspect of the LED driver with many complex function that served multiple purpose. There was an idea to have sw only and hw only LEDs and sw only and hw only LEDs. With some heads up from Andrew from the net mailing list, it was suggested to implement a more basic yet easy to implement system. These API strictly work with a designated trigger to offload their function. This may be confused with hw blink offload but LED may have an even more advanced configuration where the entire aspect of the trigger is offloaded and completely handled by the hardware. An example of this usage are PHY or switch port LEDs. Almost every of these kind of device have multiple LED attached and provide info of the current port state. Currently we lack any support of them but these device always provide a way to configure them, from basic feature like turning the LED off or no (implemented in previous series related to this feature) or even entirely driven by the hw and power on/off/blink based on some events, like tx/rx traffic, ethernet cable attached, link speed of 10mbps, 100mbps, 1000mbps or more. They can also support multiple logic like blink with traffic only if a particular link speed is attached. (an example of this is when a LED is designated to be turned on only with 100mbps link speed and configured to blink on traffic and a secondary LED of a different color is present to serve the same function but only when the link speed is 1000mbps) These case are very common for a PHY or a switch but they were never standardized so OEM support all kind of variant and configuration. Again with Andrew we compared some feature and we reached a common set of modes that are for sure present in every kind of devices. And this concludes history and why. What is present in this series ============================== This patch contain the required API to support this feature, I decided on the name of hw control to quickly describe this feature. I documented each require API in the related Documentation for leds-class so I think it might me redundant to expose them here. Feel free to tell me how to improve it if anything is not clear. On an abstract idea, this feature require this: - The trigger needs to make use of it, this is currently implemented for the netdev trigger but other trigger can be expanded if the device expose these function. An idea might be a anything that handle a storage disk and have the LED configurable to blink when there is any activity to the disk. - The LED driver needs to expose and implement these new API. Currently a LED driver supports only a trigger. The trigger should use the related helper to check if the LED can be driven hy hardware. The different modes a trigger support are exposed in the kernel include leds.h header and are used by the LED driver to understand what to do. The LED driver expose a mask of the different modes supported and trigger use this to validate the modes and decide what to enable.