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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 08593C32771 for ; Wed, 28 Sep 2022 18:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mMjF0xoN+0rmBcqXNBlJWqDbKAZ/ailPgh5Mr8MIp2c=; b=WYxM10EQr0ypIj +tUBFypGMRgFa1VsU644C1BQLalfJbsDSmt+GUHQcxNZQo28UcgKUtyQ7Dt4/NkFaBqckq62hNyKa hAlqBUzNsZaugdLRv0fSawLDBG5NssSVgu+n6bQXhIl4aFprFkvTpex8IyRrPkg5Cydu/uSPe07Ao fOiDik9FDuSJVxIUpYzDsV/qc8yUpBdOtvmPp5rVVeGRLK/m8srAHgDqVFWoAHoeSvfm6s8Zd3iUD KWZ7XQG2m2/AOP5+glx8ltSfsgbtoi8p0ZDGNYifepo8UT087wnThZHVVpORMIIuMxHwFFidFFpIZ h2+OJvqrqE3ohANPmUJg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1odbsh-0002OZ-G9; Wed, 28 Sep 2022 18:34:03 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1odbsd-0002NZ-Tz for linux-arm-kernel@lists.infradead.org; Wed, 28 Sep 2022 18:34:01 +0000 Received: by mail-pl1-x62f.google.com with SMTP id w20so12424859ply.12 for ; Wed, 28 Sep 2022 11:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=RCwN9AlZXOuaFvwKPoD1PGnGUo7LPQsYg7VzFOMyJew=; b=MHeB94dSU3FwqTwJadXEU9+F8OjEtOOwquMEtUMivcj5jdJ4cgrVk53R8QNAN5ENqx ZrVSf741fNPl6Ia6docjWSEc/hR3SS0SpxA02sEqPs7clmhuM+/rifA5ab8Wf7wIiCoR fSe2e0Rt0JanGxvlFsiqCQSZExoWR7z+ybZEbAz9KIZEHlBqez1Img/ekGpzieghvfAm +jFoe8pH2chP1xmjU2D8Pwd8SECv8NwXa4bsHuN8S5uoqvn4/IKzexrWAD4HmbLMpoWq mP7OotrWLOvGhGyhQKDVqcwVNm/AR0WN1d5P/gc9yweo26PGXqzQ6d/VV2rnU3MkY31g 597A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=RCwN9AlZXOuaFvwKPoD1PGnGUo7LPQsYg7VzFOMyJew=; b=ToLHfprdmRyL0uyF4z+bRTVhkfSE2NEt8N/dcxSlxG6GzI4ckiXxVmPnqqDsgZySfA uqAi4d9gfNHCxwcV/3tV9vQJtW1MH1Jty8CrIcZV0p3ATDJIrmRT3Avfc+oOK4fdZ9UO s6QQuFFTmeQfj2siBvrMHx+I1cLeYSKTWr5O3BIgt9/CXZDAoFSpzUj1KXAQ1wz/C8Zv rHaAu6H8pxwTNle9avLMmu9vu01h1DiqOZ9zMczBuhIV42o2R1Ct/m2dRADoXQlTgRAc spZoX0wzxlR4U/DxRhZFsYKVqTXTFvIjwT/95L4v79mOfT0/CyHkOX2tlO9qDTaLLRXz XuLA== X-Gm-Message-State: ACrzQf1iHYW9Pv+LolDCLKqPM3il6MILPb9Zl7u2RE5jhAsVImSbaZ8W 9JTjwjBe4T5D1ohpYxgarec= X-Google-Smtp-Source: AMsMyM6k5db8r+hiQex825d7BF9QeN6Ds6JothB2v1yH9cYQ/oS6YP/TBXWy8yPTTm3B3uFFgZLUSg== X-Received: by 2002:a17:903:244b:b0:178:1c88:4a4c with SMTP id l11-20020a170903244b00b001781c884a4cmr1090298pls.95.1664390036324; Wed, 28 Sep 2022 11:33:56 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:1a91:59b8:faf:7b4f]) by smtp.gmail.com with ESMTPSA id t16-20020aa79470000000b0053e5b905843sm4366265pfq.203.2022.09.28.11.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 11:33:55 -0700 (PDT) Date: Wed, 28 Sep 2022 11:33:52 -0700 From: Dmitry Torokhov To: Daniel Thompson Cc: Krzysztof Kozlowski , Rob Herring , Lee Jones , Jingoo Han , Shawn Guo , Sascha Hauer , Fabio Estevam , NXP Linux Team , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220928_113359_994252_C65F01C7 X-CRM114-Status: GOOD ( 41.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 28, 2022 at 12:00:51PM +0100, Daniel Thompson wrote: > On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote: > > Properties describing GPIOs should be named as "-gpios" or > > "-gpio", and that is what gpiod API expects, however the > > driver uses non-standard "gpios-reset" name. Let's adjust this, and also > > note that the reset line is active low as that is also important to > > gpiod API. > > No objections to the goal but... > > > > Signed-off-by: Dmitry Torokhov > > --- > > > > Another option is to add another quirk into gpiolib-of.c, but we > > may end up with a ton of them once we convert everything away from > > of_get_named_gpio() to gpiod API, so I'd prefer not doing that. > > ... it is unusual to permit backwards incompatible changes to the DT > bindings[1]: creating "flag days" where hardware stops functioning if > you boot an new kernel with an old DT is a known annoyance to users. > > I usually favour quirks tables or similar[2] rather than break legacy > DTs. Very occasionally I accept (believable) arguments that no legacy > DTs actually exist but that can very difficult to verify. > > Overall I'd like to solicit views from both GPIO and DT maintainers > before rejecting quirks tables as a way to help smooth these sort of > changes (or links to ML archives if this has already been discussed). I believe I was able to convince Rob once or twice that keeping compatibility was not worth it (not in general but in a couple of concrete cases), at least while device tree bindings are part of the kernel. Can't find the emails though... I think we should consider several options: 1. DTS/DTB is in firmware. In this case absolutely, we need to keep binary compatibility as we can not expect users to reflash firmware (there might not even be a new firmware). This situation matches what we have with ACPI systems where we are trying to work around issues 2. DTS is shipped with the kernel: 2a. DTS is present in upstream kernel - awesome, we can patch it as needed and have one less thing to worry about. 2b. DTS is not upstream. Vendor did not bother sending it. In this case it is extremely unlikely that an upstream kernel will work on such system out of the box, and updating the kernel is a large engineering task where you pull down new kernel, rework and apply non-upstream patches, rework kernel config (new Kconfig options can be introduced, old options can be renamed, etc). And then spend several weeks stabilizing the system and tracking down regressions (in general, not DTS-related ones) 3. DTS is not in firmware and not in kernel. Are there such systems? So my opinion is that while device trees are part of kernel code and have not been split into a separate project they are a fair game. If the change can be handled in the driver without much effort (something like "wakeup-source" vs "linux,wakeup" vs "linux,keypad-wakeup") - fine, we can just put a tiny quirk in the driver, but if we need something more substantial we need to think long and hard if we should implement a fallback and how much effort there is to maintain/test it so it does not bitrot. Anyway, I hope Rob, Linux and Krzysztof to chime in on this exciting topic once again ;) > > [1] For this particular driver the situation is muddied slightly > because it looks like complex since it looks the bindings for > himax,hx8357 and himax,hx8369 are undocumented (and badly named). > > [2] When the property is not parsed by library code mostly we handle > legacy by consuming both new or old names in the parser code. > > > > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c > > index 9b50bc96e00f..41332f48b2df 100644 > > --- a/drivers/video/backlight/hx8357.c > > +++ b/drivers/video/backlight/hx8357.c > > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi) > > if (!match || !match->data) > > return -EINVAL; > > > > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0); > > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0); > > if (!gpio_is_valid(lcd->reset)) { > > dev_err(&spi->dev, "Missing dt property: gpios-reset\n"); > > return -EINVAL; > > Daniel. Thanks. -- Dmitry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8D812C32771 for ; Wed, 28 Sep 2022 18:34:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3733E10E725; Wed, 28 Sep 2022 18:34:00 +0000 (UTC) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by gabe.freedesktop.org (Postfix) with ESMTPS id 11EF210E725 for ; Wed, 28 Sep 2022 18:33:57 +0000 (UTC) Received: by mail-pj1-x102a.google.com with SMTP id l9-20020a17090a4d4900b00205e295400eso2419582pjh.4 for ; Wed, 28 Sep 2022 11:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=RCwN9AlZXOuaFvwKPoD1PGnGUo7LPQsYg7VzFOMyJew=; b=MHeB94dSU3FwqTwJadXEU9+F8OjEtOOwquMEtUMivcj5jdJ4cgrVk53R8QNAN5ENqx ZrVSf741fNPl6Ia6docjWSEc/hR3SS0SpxA02sEqPs7clmhuM+/rifA5ab8Wf7wIiCoR fSe2e0Rt0JanGxvlFsiqCQSZExoWR7z+ybZEbAz9KIZEHlBqez1Img/ekGpzieghvfAm +jFoe8pH2chP1xmjU2D8Pwd8SECv8NwXa4bsHuN8S5uoqvn4/IKzexrWAD4HmbLMpoWq mP7OotrWLOvGhGyhQKDVqcwVNm/AR0WN1d5P/gc9yweo26PGXqzQ6d/VV2rnU3MkY31g 597A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=RCwN9AlZXOuaFvwKPoD1PGnGUo7LPQsYg7VzFOMyJew=; b=SFcWs1vszVd069H0xM/s90IV8eTF3JVFzMGsATJXS+V/vjuWI6BmGK8Naoe3e3iXau fLbxcsmLyUjoRYcpr+EbKlzrdPJ43d3DrZO9uPUCncUf5eWkyRCSvZxa2hs8yoo4dzKx j79357Sv4a63n26Tw2WnH33yq345anB03n4Yrx+72l4l9fHEcpKq7XGZaD5WH3JfqFdM i2UZMePl+jjbrtYQ6Ehve7Jv5Qc7PIKjm1QLBJ4W1tYrqML2ovSLg76NwYivG88SJYgp T8BazJOnLJcJ8lin3klTxO5LsBYq9fp86PPTqalqydyQBthwnNyKU70LK5Nlfbb6/731 miHQ== X-Gm-Message-State: ACrzQf38aZZEYboYG0DjATjKS434ohbrUHD9/Jo4pKXtw9nD4K20/HEw D9RP40a6ICb+5Ky0TeL1A7I= X-Google-Smtp-Source: AMsMyM6k5db8r+hiQex825d7BF9QeN6Ds6JothB2v1yH9cYQ/oS6YP/TBXWy8yPTTm3B3uFFgZLUSg== X-Received: by 2002:a17:903:244b:b0:178:1c88:4a4c with SMTP id l11-20020a170903244b00b001781c884a4cmr1090298pls.95.1664390036324; Wed, 28 Sep 2022 11:33:56 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:1a91:59b8:faf:7b4f]) by smtp.gmail.com with ESMTPSA id t16-20020aa79470000000b0053e5b905843sm4366265pfq.203.2022.09.28.11.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 11:33:55 -0700 (PDT) Date: Wed, 28 Sep 2022 11:33:52 -0700 From: Dmitry Torokhov To: Daniel Thompson Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jingoo Han , Sascha Hauer , Lee Jones , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rob Herring , NXP Linux Team , Krzysztof Kozlowski , Shawn Guo , linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Sep 28, 2022 at 12:00:51PM +0100, Daniel Thompson wrote: > On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote: > > Properties describing GPIOs should be named as "-gpios" or > > "-gpio", and that is what gpiod API expects, however the > > driver uses non-standard "gpios-reset" name. Let's adjust this, and also > > note that the reset line is active low as that is also important to > > gpiod API. > > No objections to the goal but... > > > > Signed-off-by: Dmitry Torokhov > > --- > > > > Another option is to add another quirk into gpiolib-of.c, but we > > may end up with a ton of them once we convert everything away from > > of_get_named_gpio() to gpiod API, so I'd prefer not doing that. > > ... it is unusual to permit backwards incompatible changes to the DT > bindings[1]: creating "flag days" where hardware stops functioning if > you boot an new kernel with an old DT is a known annoyance to users. > > I usually favour quirks tables or similar[2] rather than break legacy > DTs. Very occasionally I accept (believable) arguments that no legacy > DTs actually exist but that can very difficult to verify. > > Overall I'd like to solicit views from both GPIO and DT maintainers > before rejecting quirks tables as a way to help smooth these sort of > changes (or links to ML archives if this has already been discussed). I believe I was able to convince Rob once or twice that keeping compatibility was not worth it (not in general but in a couple of concrete cases), at least while device tree bindings are part of the kernel. Can't find the emails though... I think we should consider several options: 1. DTS/DTB is in firmware. In this case absolutely, we need to keep binary compatibility as we can not expect users to reflash firmware (there might not even be a new firmware). This situation matches what we have with ACPI systems where we are trying to work around issues 2. DTS is shipped with the kernel: 2a. DTS is present in upstream kernel - awesome, we can patch it as needed and have one less thing to worry about. 2b. DTS is not upstream. Vendor did not bother sending it. In this case it is extremely unlikely that an upstream kernel will work on such system out of the box, and updating the kernel is a large engineering task where you pull down new kernel, rework and apply non-upstream patches, rework kernel config (new Kconfig options can be introduced, old options can be renamed, etc). And then spend several weeks stabilizing the system and tracking down regressions (in general, not DTS-related ones) 3. DTS is not in firmware and not in kernel. Are there such systems? So my opinion is that while device trees are part of kernel code and have not been split into a separate project they are a fair game. If the change can be handled in the driver without much effort (something like "wakeup-source" vs "linux,wakeup" vs "linux,keypad-wakeup") - fine, we can just put a tiny quirk in the driver, but if we need something more substantial we need to think long and hard if we should implement a fallback and how much effort there is to maintain/test it so it does not bitrot. Anyway, I hope Rob, Linux and Krzysztof to chime in on this exciting topic once again ;) > > [1] For this particular driver the situation is muddied slightly > because it looks like complex since it looks the bindings for > himax,hx8357 and himax,hx8369 are undocumented (and badly named). > > [2] When the property is not parsed by library code mostly we handle > legacy by consuming both new or old names in the parser code. > > > > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c > > index 9b50bc96e00f..41332f48b2df 100644 > > --- a/drivers/video/backlight/hx8357.c > > +++ b/drivers/video/backlight/hx8357.c > > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi) > > if (!match || !match->data) > > return -EINVAL; > > > > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0); > > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0); > > if (!gpio_is_valid(lcd->reset)) { > > dev_err(&spi->dev, "Missing dt property: gpios-reset\n"); > > return -EINVAL; > > Daniel. Thanks. -- Dmitry 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 AFF4EC04A95 for ; Wed, 28 Sep 2022 18:34:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229736AbiI1SeA (ORCPT ); Wed, 28 Sep 2022 14:34:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231652AbiI1Sd6 (ORCPT ); Wed, 28 Sep 2022 14:33:58 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08BBA75FE3 for ; Wed, 28 Sep 2022 11:33:57 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id lx7so6314418pjb.0 for ; Wed, 28 Sep 2022 11:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=RCwN9AlZXOuaFvwKPoD1PGnGUo7LPQsYg7VzFOMyJew=; b=MHeB94dSU3FwqTwJadXEU9+F8OjEtOOwquMEtUMivcj5jdJ4cgrVk53R8QNAN5ENqx ZrVSf741fNPl6Ia6docjWSEc/hR3SS0SpxA02sEqPs7clmhuM+/rifA5ab8Wf7wIiCoR fSe2e0Rt0JanGxvlFsiqCQSZExoWR7z+ybZEbAz9KIZEHlBqez1Img/ekGpzieghvfAm +jFoe8pH2chP1xmjU2D8Pwd8SECv8NwXa4bsHuN8S5uoqvn4/IKzexrWAD4HmbLMpoWq mP7OotrWLOvGhGyhQKDVqcwVNm/AR0WN1d5P/gc9yweo26PGXqzQ6d/VV2rnU3MkY31g 597A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=RCwN9AlZXOuaFvwKPoD1PGnGUo7LPQsYg7VzFOMyJew=; b=ht66yLQtnLIhhFdV89DzA7w8pDmZbm7Fl9w7qZ71G3Xdj2qOl5nG5NgUZOO0wrwuuS Q40QrJQ7QERfFMuOh/J4NBG+dMyMwxNPkIJFFmrXbehKv64iFrzJooxijvaybzQDkmG8 m1YsP7TYE0IVHf4oU72i8D2pw1p3NKO52l8LIf13srMmRQEDTi0xT/iCH/qteoZGiy35 hl6g4y8VJL6f3u72DexaiQwzVGjZpOk1Djz3t68M6vbf0e3zWwFZdrXN99zgZC1BIw3A NYiwfe432gHE3ScgtmHrJnZSBsxc9HB8ckPtUSUNPSq72zyvKLK+miJnfZGbkgAfe8mn 6Wtg== X-Gm-Message-State: ACrzQf05ZhOVN7qu50yRuyy1UJmBhBMVZs8CURtbGJhNK065c3VkkqJf 4S3Be7bqlYNxqTolxQH3poI= X-Google-Smtp-Source: AMsMyM6k5db8r+hiQex825d7BF9QeN6Ds6JothB2v1yH9cYQ/oS6YP/TBXWy8yPTTm3B3uFFgZLUSg== X-Received: by 2002:a17:903:244b:b0:178:1c88:4a4c with SMTP id l11-20020a170903244b00b001781c884a4cmr1090298pls.95.1664390036324; Wed, 28 Sep 2022 11:33:56 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:1a91:59b8:faf:7b4f]) by smtp.gmail.com with ESMTPSA id t16-20020aa79470000000b0053e5b905843sm4366265pfq.203.2022.09.28.11.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 11:33:55 -0700 (PDT) Date: Wed, 28 Sep 2022 11:33:52 -0700 From: Dmitry Torokhov To: Daniel Thompson Cc: Krzysztof Kozlowski , Rob Herring , Lee Jones , Jingoo Han , Shawn Guo , Sascha Hauer , Fabio Estevam , NXP Linux Team , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 28, 2022 at 12:00:51PM +0100, Daniel Thompson wrote: > On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote: > > Properties describing GPIOs should be named as "-gpios" or > > "-gpio", and that is what gpiod API expects, however the > > driver uses non-standard "gpios-reset" name. Let's adjust this, and also > > note that the reset line is active low as that is also important to > > gpiod API. > > No objections to the goal but... > > > > Signed-off-by: Dmitry Torokhov > > --- > > > > Another option is to add another quirk into gpiolib-of.c, but we > > may end up with a ton of them once we convert everything away from > > of_get_named_gpio() to gpiod API, so I'd prefer not doing that. > > ... it is unusual to permit backwards incompatible changes to the DT > bindings[1]: creating "flag days" where hardware stops functioning if > you boot an new kernel with an old DT is a known annoyance to users. > > I usually favour quirks tables or similar[2] rather than break legacy > DTs. Very occasionally I accept (believable) arguments that no legacy > DTs actually exist but that can very difficult to verify. > > Overall I'd like to solicit views from both GPIO and DT maintainers > before rejecting quirks tables as a way to help smooth these sort of > changes (or links to ML archives if this has already been discussed). I believe I was able to convince Rob once or twice that keeping compatibility was not worth it (not in general but in a couple of concrete cases), at least while device tree bindings are part of the kernel. Can't find the emails though... I think we should consider several options: 1. DTS/DTB is in firmware. In this case absolutely, we need to keep binary compatibility as we can not expect users to reflash firmware (there might not even be a new firmware). This situation matches what we have with ACPI systems where we are trying to work around issues 2. DTS is shipped with the kernel: 2a. DTS is present in upstream kernel - awesome, we can patch it as needed and have one less thing to worry about. 2b. DTS is not upstream. Vendor did not bother sending it. In this case it is extremely unlikely that an upstream kernel will work on such system out of the box, and updating the kernel is a large engineering task where you pull down new kernel, rework and apply non-upstream patches, rework kernel config (new Kconfig options can be introduced, old options can be renamed, etc). And then spend several weeks stabilizing the system and tracking down regressions (in general, not DTS-related ones) 3. DTS is not in firmware and not in kernel. Are there such systems? So my opinion is that while device trees are part of kernel code and have not been split into a separate project they are a fair game. If the change can be handled in the driver without much effort (something like "wakeup-source" vs "linux,wakeup" vs "linux,keypad-wakeup") - fine, we can just put a tiny quirk in the driver, but if we need something more substantial we need to think long and hard if we should implement a fallback and how much effort there is to maintain/test it so it does not bitrot. Anyway, I hope Rob, Linux and Krzysztof to chime in on this exciting topic once again ;) > > [1] For this particular driver the situation is muddied slightly > because it looks like complex since it looks the bindings for > himax,hx8357 and himax,hx8369 are undocumented (and badly named). > > [2] When the property is not parsed by library code mostly we handle > legacy by consuming both new or old names in the parser code. > > > > diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c > > index 9b50bc96e00f..41332f48b2df 100644 > > --- a/drivers/video/backlight/hx8357.c > > +++ b/drivers/video/backlight/hx8357.c > > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi) > > if (!match || !match->data) > > return -EINVAL; > > > > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0); > > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0); > > if (!gpio_is_valid(lcd->reset)) { > > dev_err(&spi->dev, "Missing dt property: gpios-reset\n"); > > return -EINVAL; > > Daniel. Thanks. -- Dmitry