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 7C9BFC77B78 for ; Thu, 13 Apr 2023 14:44:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229598AbjDMOoB (ORCPT ); Thu, 13 Apr 2023 10:44:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229784AbjDMOnu (ORCPT ); Thu, 13 Apr 2023 10:43:50 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4DBFB76E; Thu, 13 Apr 2023 07:43:40 -0700 (PDT) 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=J5w0b8Fobg2W9RujUD13uGJH7vRMN8dHc0B4sOAwikM=; b=5TjbN28trjt5HISvTlm95p0A9G D9M1FUwIBttbFB3gbsuaO9mbk3vXv4+yRqyZZ19apAILewifcs3qVozNt1PG9U/NozW0WFJ5NF4Mn 26Hx/eLWptWB7cbOupRNhwJelVtjvJ+RY33Xa4ZQEc6x6adDxZx3Gjac/K9aKr2J/KXA=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pmyAb-00ACJL-AV; Thu, 13 Apr 2023 16:43:29 +0200 Date: Thu, 13 Apr 2023 16:43:29 +0200 From: Andrew Lunn To: Florian Fainelli Cc: Christian Marangi , Pavel Machek , Lee Jones , Rob Herring , Krzysztof Kozlowski , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , Russell King , Gregory Clement , Sebastian Hesselbarth , Andy Gross , Bjorn Andersson , Konrad Dybcio , John Crispin , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [net-next PATCH v6 06/16] net: phy: phy_device: Call into the PHY driver to set LED brightness Message-ID: <60d5bad7-e7c1-4ffe-be6c-5d92e482b1ba@lunn.ch> References: <20230327141031.11904-1-ansuelsmth@gmail.com> <20230327141031.11904-7-ansuelsmth@gmail.com> <202ae4b9-8995-474a-1282-876078e15e47@gmail.com> <64380b46.7b0a0220.978a.1eb4@mx.google.com> <7ea465d9-95eb-d158-632a-a2aa892fd2bf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ea465d9-95eb-d158-632a-a2aa892fd2bf@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Humm just thought of something else, is it OK for led_brightness_set and > led_blink_set to call into functions that might require sleeping (MDIO, I2C, > SPI, etc.)? Hi Florian That is fine. The LED class is similar to GPIOs. There is a can sleep version, and an atomic version. For phylib we are using the can sleep version. The LED core then hides the differences from the users. Andrew