From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 652693F54C4 for ; Mon, 24 Aug 2026 09:17:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787563043; cv=none; b=RRxdugIGFhofyEBJ0FymhR9kCVOEVJ+lT5Aqq6Nejq203VKTPhVbkRdIwhFYmct06lLb3oS/3EbSPeD7gVJF2RmD50OT3qBfBz0QP5X3eidP5AJaBp1TvIR3uoNsBn4tGY7LutDvEFBzFmpPYbDEheO0M9x6JxIx0bcbpo6s7Zo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787563043; c=relaxed/simple; bh=UYJh2MdQumhQG/EQROPql19ITOL7tikzrHjRGItiHmg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OU8tqSJiFDdAorh/MrIJnEQorvgVJ55XB/eits1vGJfzdE3+9/O5jXpAcGIODYpcfnLc5xZoxj3NsEiMytCgE9TOuDVskspRdnUINI7/Le5t+kOMifXVfY2aa4DX01pUsA6KH7xwOwhOLU1SbRMW2+HbHIRS7CWWg+s/X+uO0aQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b=akqef6Ax; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b="akqef6Ax" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-47ddf7b09e5so2848150f8f.1 for ; Mon, 24 Aug 2026 02:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1787563039; x=1788167839; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=1KWOdEO9XQSV3ds07vANFxSNMOkEh8mcBPlw2ud0ZcY=; b=akqef6Axy7C2vgALYbN7SAqk9ay1qLQmpaR3NmVbO320MNpuuhdsigs7nQm3Y9IUCq GKKutHCm1tKBciicTkLCKhTDuIPoTFwSNQoY2hQ4oRTw56amFAOq0NwUSiJTdpdsJTYX su0wJPzWILENU0b2iWbStIIU4lNU55K8v4hMNcgh3krHTT6LP88b26Hb+8YeiItWAKh/ 5l5N7mncNZxAPSsyM44X5fs6gc55C9yM09pZMfDolyY/URlMqHlnpIEFO5RkyfPPcmDS F3YHfn1+m30Oxd03Ea+Oo7shVXDrXZ9Go+uck3Ns+/P7uT+uHBUYhdfwkyzi5whvBEyh OGlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787563039; x=1788167839; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1KWOdEO9XQSV3ds07vANFxSNMOkEh8mcBPlw2ud0ZcY=; b=AMRBA9jIwBTV1CWYQVn7fgsCvOJu6OmvPWRGBHSFWbOO3B1BCSgBt/dVexooy+glX8 unNdjVqvAstEMnbo9ksbjQHsg03n/Oh6hZa01M1DRBFN1Fr/NdQ/WEgdP+Sztu9dJ9Vk 0SgvvuPnjT0INDxfayywlE823xy5lNU7L4hyaQmmY7gYXh4JyC4LppoAzsPd8oG8XNG/ k3at9oJ1NMhxOkgoTS/Uyk6x0JkrfwvCXqJBHYC8PPbmIHeIBv7rCINSYqlrklgiF16O Ousa3vPqeRYqnarcPAoSJX8UULimoQ8TOgIt8QEbMWnGi2I1M4t4zwSlpy7+Pv2VOm8z wxbQ== X-Forwarded-Encrypted: i=1; AHgh+Roq2Dgtie4t8mU4n51nxnbbiP9KQkqxwHHUvWy2vgw6kQUro4q5xuG31xnEsBEmkKEVMm7N8mvWcG6bGns=@vger.kernel.org X-Gm-Message-State: AFuF++lyiw/EfgBJ/QLZVFJyzVngb5xNXpxqyuXMBxLMfAu/5NNirNWa WranS9fQNoiZY2GD8TgAUEVCvWvJOaPHH0W26QN2ByOVBxEFKIrDhnHqNunQwKFvkfE= X-Gm-Gg: AR+sD12peElCoqztMaQ7vijU6yQZLyKZQvW9dc384ckhmAdm3YXfmYwhXKGSMpvYyY2 //Ugm8DliFMtYrNmFpQEyPhbQrscs6YG3VorcKZzbc//VfWkMG/jutOJXNUxsDbBi5sH5Tj2W7Y suYEpOzXIRRrNu4jqrA9ZetSTpRuEpFcGqWe5gz7MDp6CG5lS7qYZRAV2qV41MgBdvNFSLC+W+R 53RUYnzrUuiegbb/ovp3vJvrMDhG7GPjeaQHYi3v7BtS9RZI3vFGkEKIYzyakVjORkReWPUixcg yYgb5OpUAHgMkERag6JsB9WDBIREVOLP50pzAxsm1SYH/DuqpNj30+bHS9gOVI23I7tOlpXswOw JT57Iv0zDWzFcIaT3O7/8zocsWPTNBzladoMe3Uw6HpQcaSHRE0zLl8LuyW/ItUSTRc3JtUM9LA HQocIWuV2xajSxufL7oMYLcaBwTm9/DrSRZClabbXSFDm6bXfTW+hOC6MUj20pQGV1PK7QwetRa A2N85f5L6EHibif04+3Imx58PPJ/SvmhWCnLiD36RGhUUaIf3G2N5kPdsRsulx+K0zkYaPvpTBs vKBWokwOpuB59Jh1uGVRiSevJ5ZMLE/9X0WhzI4sm9INW1RJnp9Yw4Y1 X-Received: by 2002:a5d:59c6:0:b0:47f:773f:2d68 with SMTP id ffacd0b85a97d-482c0ba3307mr32820982f8f.16.1787563039461; Mon, 24 Aug 2026 02:17:19 -0700 (PDT) Received: from aspen.lan (aztw-34-b2-v4wan-166919-cust780.vm26.cable.virginm.net. [82.37.195.13]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-482c9bfd2bbsm7567131f8f.18.2026.08.24.02.17.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 02:17:18 -0700 (PDT) Date: Mon, 24 Aug 2026 10:17:17 +0100 From: Daniel Thompson To: "A. Sverdlin" Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Andrew Davis , Lee Jones , Pavel Machek , Daniel Thompson , Jingoo Han , Helge Deller , linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org Subject: Re: [PATCH 1/2] backlight: led_bl: Add devm_led_backlight_register() helper Message-ID: References: <20260817170817.1933046-1-alexander.sverdlin@siemens.com> <20260817170817.1933046-2-alexander.sverdlin@siemens.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260817170817.1933046-2-alexander.sverdlin@siemens.com> On Mon, Aug 17, 2026 at 07:08:14PM +0200, A. Sverdlin wrote: > From: Alexander Sverdlin > > The led-backlight driver could so far only be instantiated from a > device-tree node with the "led-backlight" compatible. This makes it > impossible for a self-contained LED provider (e.g. a hot-pluggable I2C > LED controller) to expose a backlight interface tied to its own > lifetime. > > Factor the actual backlight registration out of the probe path into a > shared led_bl_register() helper and export devm_led_backlight_register(), > which registers a backlight class device driven by a single LED, without > device tree and bound to the caller's device lifetime. The backlight > device and the LED sysfs handover are now devres-managed, so the probe > path shrinks and the explicit .remove callback is no longer needed. Please can you split this patch into two pieces to make review easier. One to introduce make the backlight device and LED sysfs handover devre -managed and the other to introduce devm_led_backlight_register(). > diff --git a/include/linux/led_bl.h b/include/linux/led_bl.h > new file mode 100644 > index 0000000000000..e38e4d62bf653 > --- /dev/null > +++ b/include/linux/led_bl.h > @@ -0,0 +1,20 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_LED_BL_H > +#define _LINUX_LED_BL_H > + > +#include > + > +struct device; > +struct led_classdev; > + > +#if IS_REACHABLE(CONFIG_BACKLIGHT_LED) > +int devm_led_backlight_register(struct device *dev, struct led_classdev *led); > +#else > +static inline int devm_led_backlight_register(struct device *dev, > + struct led_classdev *led) > +{ > + return 0; This should not return success; it has not succeeded in registering a backlight. > +} > +#endif Daniel.