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 E17CBC63706 for ; Wed, 7 Dec 2022 00:26:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229487AbiLGA0K (ORCPT ); Tue, 6 Dec 2022 19:26:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229554AbiLGA0J (ORCPT ); Tue, 6 Dec 2022 19:26:09 -0500 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1A7E222 for ; Tue, 6 Dec 2022 16:26:08 -0800 (PST) Received: by mail-yb1-xb35.google.com with SMTP id o127so20736697yba.5 for ; Tue, 06 Dec 2022 16:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZYj9KCsb8kRQIFxK0aVemzvvzUafcIYmATwlKu599UI=; b=vzW5c5uBK0GIU+Kn5Akt75iCuWqL7qzVV16OvHY3HFk6bfH64Dg6xNAodpJo/Gqjy8 00K2VO5AMXtc1mRtQmDL/m0HJ9hAFet8B6dlRUQg+IX6tCLPGfO4zaTaIxNtJMBK80VA C48vLuQM6fBLZ59iFd8YcLWgJowE2ohV44bTYZ442kbox5ckrQ1B2mMMUnbrcIAvbvEy SnLoGhHNgp65X0Cq9oxqmjbxQCspZWkDGyV/i/WMsaSErDmJBq0pgJPPFJUhpy8MKfIS 4tTaeb5ktk3YHynGzY+VAVJGWjsjYmhVamtsVIF5DeUn/QOMcPhZE4iWT7gIzo5i+kVj Glcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZYj9KCsb8kRQIFxK0aVemzvvzUafcIYmATwlKu599UI=; b=p2DlbhWfZI9h05+B3ZMFFB7qixUT9w+rnN3fGFvYsdBzfT4ew/BlPtezohy+ISfUZl QHlT5gtE4OJUnSLG5yzUISBh+kJRzw8Kng4d+xknlIcW/eeXuNAS+ETKYIsAzDU/lmlJ wgIZ4G+9JpCRJTEZ6d/b4VoDFi38b2uTxqObv/oxBh0W8QIP1sMr2HECEPDxgleFZLeZ z45B7kWzg7Y2DtEPT7ekyz1uMw5aZPilo4fLF7A+G3eu9OgwTvz6bMqpxJj29m7+DEvn afWgeUS+7LX4bnd/sb7W4qCpUcTjr92kTnjJVuHubAWsd69bx33bxadHU40PupQ+KKN8 ePqw== X-Gm-Message-State: ANoB5pmu0OZ7YthE6K4z0pSako2sUv543QhNGxwree7isWmnMxA7cEdw UQCNPMkNZM6cV+TkSh+cfP8LH2S52BBwQvomLWgJMw== X-Google-Smtp-Source: AA0mqf4AKQSwpp270vZpFCotxEx/+sVHte0YmayepwqKp3xynAgiNgkXkHQo92XzCDGjBno+PuM+OCP+QO4nnKgXabU= X-Received: by 2002:a25:bc8a:0:b0:6ee:e865:c2e2 with SMTP id e10-20020a25bc8a000000b006eee865c2e2mr22311303ybk.206.1670372767866; Tue, 06 Dec 2022 16:26:07 -0800 (PST) MIME-Version: 1.0 References: <20221128214408.165726-1-hdegoede@redhat.com> In-Reply-To: From: Linus Walleij Date: Wed, 7 Dec 2022 01:25:56 +0100 Message-ID: Subject: Re: [PATCH 0/5] gpio/media/int3472: Add support for tps68470 privacy-LED output To: Hans de Goede Cc: Bartosz Golaszewski , Mark Gross , Andy Shevchenko , Daniel Scally , Laurent Pinchart , platform-driver-x86@vger.kernel.org, linux-gpio@vger.kernel.org, Sakari Ailus , Kate Hsuan , linux-media@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Mon, Dec 5, 2022 at 4:01 PM Hans de Goede wrote: > An alternative approach, would be to add support for LED > lookup tables to the LED class code (like we already have > for GPIOs) and use this to allow tying a LED classdev to > a struct device on non devicetree platforms. > > Given the problems with the swnode approach from above > I believe that this would actually be better then > the swnode approach. > > Lookup tables like this use device-names, so we don't need > to have swnode-s ready for both the provider and the consumer > at the time of adding the lookup table entry. Instead all > that is necessary is to know the device-names of both > the provider and the consumer which are both known in > advance. I think this looks like a good idea. We attach other resources such as clocks, regulators, DMA channels, GPIOs exactly this way. So why not LEDs? As GPIO maintainer I every now and then get a suggestion like this to "just let this pass as a GPIO because it makes my life so much easier", but it is the same curse as the input subsystem has: it is versatile and well engineered so it starts to look like a golden hammer (everything start to look like nails). But we are two GPIO maintainers and right now Bartosz does the majority of the work, and if he thinks it's the best idea ever I will certainly reconsider. Yours, Linus Walleij