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 EF5D6C4332F for ; Wed, 12 Oct 2022 20:34:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229436AbiJLUer (ORCPT ); Wed, 12 Oct 2022 16:34:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229619AbiJLUeo (ORCPT ); Wed, 12 Oct 2022 16:34:44 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F37726C6 for ; Wed, 12 Oct 2022 13:34:43 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id l4so17311686plb.8 for ; Wed, 12 Oct 2022 13:34:43 -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:message-id:reply-to; bh=RWLS2zNmieKOsxC1XL1cG5sTXnTxdPokhdiGwrdRjtI=; b=FUqh8yx3C7H1syIKJ+pei3UGKenBwTM/mUKJ/0IEkd64LGSIRtE07MDeUg1LV7sBV4 AI2MD5ZhzXtMGW3WASwz1+0ScTpJtVarcrZQvK0ekGrHy9E1HkHKRl0I8F9snuPqAVmj c20lE+0cMBsMwPvuCiZPg2QzENg6Qu27AA8hT7zBiRoo7h55Y//A39emLtj0efUEDnIp Jg2SZKpE9esjKUCW0o9e/V/055mWBeL4mOuXxB3R0BALZYg0iCJBXvtQyA7HD9UpVK3n hz85Xmc6T1o/KZ4mbwtSlsEmc30p4Ju03XkOn/0OHqq2zEM/YJaUPTrQYjgyJgYRb739 zqAg== 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 :message-id:reply-to; bh=RWLS2zNmieKOsxC1XL1cG5sTXnTxdPokhdiGwrdRjtI=; b=A5rb3ikf/ZJovBknQYWWr+iCdCrGUpaxOY/ck967y3XXeVe+bAQ9UdgJBY0E4mLzE/ t0OQ1ypGGM7198o/+X8O1/lqf3euSB3qkqiJWR3/cKeeVf/Edi7XPraAJzDyFe5grbyt yS/HcwEB24uqqKxO8LIjeZsJ0rVa+sRefULcVEToAIl0osjdeWd8uj2UomnANSPjP0dv M4yz9696ullCHAisyTtHvDItgRXMaGN9I++y6STCQR6xztWlEaXH8+YnIi7JR4ZZlLT1 IfV/lvBhCG2lmds5CfCTakGAUCkJ443Fem45f9CLBUX5Flis+m5SBBbddqVnBepV3tXl T9UQ== X-Gm-Message-State: ACrzQf2kAf3B24QgBT89ow6lJKT/ZmBTh0KuG+iJ3FnKFr3bYEt2w1UD qdXutvoTC4mwryciDd+Jrjk= X-Google-Smtp-Source: AMsMyM49pT77A7mxwVaiZ8MDvAzJww6ZJoKyXbRP/NnV0qPP2O/r0zjhh9iHYT5DTObvxzzU91oNaw== X-Received: by 2002:a17:902:c943:b0:182:f5af:40c5 with SMTP id i3-20020a170902c94300b00182f5af40c5mr14901508pla.72.1665606882732; Wed, 12 Oct 2022 13:34:42 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:d4c1:686c:5489:5df9]) by smtp.gmail.com with ESMTPSA id h15-20020a170902680f00b00178acc7ef16sm10904901plk.253.2022.10.12.13.34.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 13:34:42 -0700 (PDT) Date: Wed, 12 Oct 2022 13:34:38 -0700 From: Dmitry Torokhov To: Linus Walleij Cc: Daniel Thompson , Sascha Hauer , Krzysztof Kozlowski , Rob Herring , Lee Jones , Jingoo Han , Shawn Guo , Fabio Estevam , NXP Linux Team , 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 Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote: > On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson > wrote: > > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote: > > > On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov > > > wrote: > > > > > > > > Dmitry, could you fix this? Just patch away in gpiolib-of.c. > > > > > > > > Sure, I'll add a few quirks. I wonder what is the best way to merge > > > > this? I can create a bunch of IBs to be pulled, or I can send quirks to > > > > you/Bartosz and once they land send the patches to drivers... > > > > > > When I did it I was sufficiently convinced that I was the only one patching > > > the quirks in gpiolib-of.c that merge window so I just included it as > > > a hunk in the driver patch. If there will be some more patches to that > > > file I guess some separate patch(es) for gpiolib-of.c is needed, maybe > > > an immutable branch for those if it becomes a lot. > > > > Are renames likely to be a common quirk on the road to libgpiod > > conversion? > > > > I admit I sort of expected it to be common enough that there would be > > one rename quirk in the code supported by an alphabetized string table. > > Such a table would certainly still provoke troublesome merges but ones > > that are trivially resolved. > > Dmitry added a table of sorts, the problems are usually a bit unique > for each instance of nonstandard DT GPIO bindings, that's why I > mostly solved it with open coding in gpiolib-of.c. OK, so I sent out the patch adding "reset-gpios" -> "gpios-reset" translation quirk to keep compatibility with the legacy names, but we still need to figure out what to do with incorrect line polarity in current DTses in tree. Unlike with names we have no indication if out of tree DTSes specify correct polarity or not, so we can't reasonably come up with workarounds that are guaranteed to work for everyone. I see several options: - the driver could continue ignoring line polarity specified in DTS (and use gpiod_set_value_raw()) and hope that they all/will be wired in the same way? - we could fix up in-kernel DTSes, allow flexibility of connection in new designs and respect polarity specified in out of tree DTSes, but accept that there can be breakages with old DTSes not contributed to the mainline or DTSes that were "cached" from an older kernel release - add another quirk forcing "active low" polarity for the legacy "gpios-reset" name, which will allow us respecting polarity in new "reset-gpios" name. 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 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 EB643C4332F for ; Wed, 12 Oct 2022 20:34:52 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B6E5D10E1BB; Wed, 12 Oct 2022 20:34:51 +0000 (UTC) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by gabe.freedesktop.org (Postfix) with ESMTPS id 66F9410E046 for ; Wed, 12 Oct 2022 20:34:43 +0000 (UTC) Received: by mail-pl1-x62d.google.com with SMTP id i6so12252437pli.12 for ; Wed, 12 Oct 2022 13:34:43 -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:message-id:reply-to; bh=RWLS2zNmieKOsxC1XL1cG5sTXnTxdPokhdiGwrdRjtI=; b=FUqh8yx3C7H1syIKJ+pei3UGKenBwTM/mUKJ/0IEkd64LGSIRtE07MDeUg1LV7sBV4 AI2MD5ZhzXtMGW3WASwz1+0ScTpJtVarcrZQvK0ekGrHy9E1HkHKRl0I8F9snuPqAVmj c20lE+0cMBsMwPvuCiZPg2QzENg6Qu27AA8hT7zBiRoo7h55Y//A39emLtj0efUEDnIp Jg2SZKpE9esjKUCW0o9e/V/055mWBeL4mOuXxB3R0BALZYg0iCJBXvtQyA7HD9UpVK3n hz85Xmc6T1o/KZ4mbwtSlsEmc30p4Ju03XkOn/0OHqq2zEM/YJaUPTrQYjgyJgYRb739 zqAg== 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 :message-id:reply-to; bh=RWLS2zNmieKOsxC1XL1cG5sTXnTxdPokhdiGwrdRjtI=; b=IcOnKqPK/ckg7slzdJMyhV5wfZL607YnNU20tm9Ed9VbS+i64zAMZMOP2QOHe0wcnK QHFzX539bjLXbFir3+soASdCGc3lxDxiryPjKZgKHSSaEDmlXLjYrxpFmLVJmL6aZi1q JSgkK/HTTpvLekleQxEXl32kP9FclvdtfqNr7JzqOqZ+XPvxce9FXEa1k0eNRWfso7sB PdSXv7AcjtHdF+cfoUI2avMj7Ilc6b6h9VnFa90bgVZTpD9XwHkTFst5AkxV+FDm+i1N Rhjj5EbwqSSEAtPoyNPZIBMjClOVhCQ/+xOfdoocTQclq6qOBWDfo/Ab5zKAvBCUL4OW aPBQ== X-Gm-Message-State: ACrzQf3uzYIhktj7sGcrW9d4mwmmNvklfve0lRMyPVRuAtAIQH4BKBt4 ZleTzVxd827YQLvCKQjzvIE= X-Google-Smtp-Source: AMsMyM49pT77A7mxwVaiZ8MDvAzJww6ZJoKyXbRP/NnV0qPP2O/r0zjhh9iHYT5DTObvxzzU91oNaw== X-Received: by 2002:a17:902:c943:b0:182:f5af:40c5 with SMTP id i3-20020a170902c94300b00182f5af40c5mr14901508pla.72.1665606882732; Wed, 12 Oct 2022 13:34:42 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:d4c1:686c:5489:5df9]) by smtp.gmail.com with ESMTPSA id h15-20020a170902680f00b00178acc7ef16sm10904901plk.253.2022.10.12.13.34.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 13:34:42 -0700 (PDT) Date: Wed, 12 Oct 2022 13:34:38 -0700 From: Dmitry Torokhov To: Linus Walleij 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: Daniel Thompson , 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 Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote: > On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson > wrote: > > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote: > > > On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov > > > wrote: > > > > > > > > Dmitry, could you fix this? Just patch away in gpiolib-of.c. > > > > > > > > Sure, I'll add a few quirks. I wonder what is the best way to merge > > > > this? I can create a bunch of IBs to be pulled, or I can send quirks to > > > > you/Bartosz and once they land send the patches to drivers... > > > > > > When I did it I was sufficiently convinced that I was the only one patching > > > the quirks in gpiolib-of.c that merge window so I just included it as > > > a hunk in the driver patch. If there will be some more patches to that > > > file I guess some separate patch(es) for gpiolib-of.c is needed, maybe > > > an immutable branch for those if it becomes a lot. > > > > Are renames likely to be a common quirk on the road to libgpiod > > conversion? > > > > I admit I sort of expected it to be common enough that there would be > > one rename quirk in the code supported by an alphabetized string table. > > Such a table would certainly still provoke troublesome merges but ones > > that are trivially resolved. > > Dmitry added a table of sorts, the problems are usually a bit unique > for each instance of nonstandard DT GPIO bindings, that's why I > mostly solved it with open coding in gpiolib-of.c. OK, so I sent out the patch adding "reset-gpios" -> "gpios-reset" translation quirk to keep compatibility with the legacy names, but we still need to figure out what to do with incorrect line polarity in current DTses in tree. Unlike with names we have no indication if out of tree DTSes specify correct polarity or not, so we can't reasonably come up with workarounds that are guaranteed to work for everyone. I see several options: - the driver could continue ignoring line polarity specified in DTS (and use gpiod_set_value_raw()) and hope that they all/will be wired in the same way? - we could fix up in-kernel DTSes, allow flexibility of connection in new designs and respect polarity specified in out of tree DTSes, but accept that there can be breakages with old DTSes not contributed to the mainline or DTSes that were "cached" from an older kernel release - add another quirk forcing "active low" polarity for the legacy "gpios-reset" name, which will allow us respecting polarity in new "reset-gpios" name. 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 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 90A05C4332F for ; Wed, 12 Oct 2022 20:35:45 +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=aQXd7WTWdwHlP0moCOMKAn/mzMNWPkWaLfB1O/GJ7Tk=; b=SvF2oV/G7jFMb7 LMEMMZxR49W+F9mH6z8YjT9NQPhYd93zeBFBspzn0inQY8KqEUhOQVPPtuSO1uo1epBSen0nwVicD 3aJKvvYWwqatji4i/YuOsgamxXvPmqWpQYFzLLYu+/UBcZr6c/H45LXD3oVdABTIgD26eW8fKp1jO iBkz7k2bAcJYW8C1JnrM0b6n27zIu8nhglLOD3XTyYycT7c6QFJR65t2cne2+tg/U0dEzmFcD7wqs 6GjnVnpYOhT+ykrOTE3hxxfOsCl8JpE484C8pE6lH6zfHhbAeXcaM2jUBkKle3ovJwd2HGD9Mwpcb gTxPsRzddM7oUoaRIIoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiiRD-009Hfg-OE; Wed, 12 Oct 2022 20:34:47 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiiRA-009Hek-Ij for linux-arm-kernel@lists.infradead.org; Wed, 12 Oct 2022 20:34:46 +0000 Received: by mail-pj1-x102a.google.com with SMTP id fw14so60142pjb.3 for ; Wed, 12 Oct 2022 13:34:43 -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:message-id:reply-to; bh=RWLS2zNmieKOsxC1XL1cG5sTXnTxdPokhdiGwrdRjtI=; b=FUqh8yx3C7H1syIKJ+pei3UGKenBwTM/mUKJ/0IEkd64LGSIRtE07MDeUg1LV7sBV4 AI2MD5ZhzXtMGW3WASwz1+0ScTpJtVarcrZQvK0ekGrHy9E1HkHKRl0I8F9snuPqAVmj c20lE+0cMBsMwPvuCiZPg2QzENg6Qu27AA8hT7zBiRoo7h55Y//A39emLtj0efUEDnIp Jg2SZKpE9esjKUCW0o9e/V/055mWBeL4mOuXxB3R0BALZYg0iCJBXvtQyA7HD9UpVK3n hz85Xmc6T1o/KZ4mbwtSlsEmc30p4Ju03XkOn/0OHqq2zEM/YJaUPTrQYjgyJgYRb739 zqAg== 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 :message-id:reply-to; bh=RWLS2zNmieKOsxC1XL1cG5sTXnTxdPokhdiGwrdRjtI=; b=FXdWMQYbE9MJC9+y9xQqtRVFGlwN7J2wrUMzoFvp4r0RKPZpsGPgvDTzTzoU8Ef578 oo2XgF3PuAhw4UQeQvv9Pr1lXgewM6UVaXF06RqEKKLYEGApe1KfWLTvsrf9V9H1V0MT u8vCRmPJJazGO3/0ZSeMyocD+KueY9zizqJ3AO4ulUda8MiEynAGu6EHWMJHNdIdfQPj /ssRHGKuyk38xdHpuEYFzkYizQAGLtqZzh73FuGfrvvG+KHrrGyIdfLgi990Qz2iPH77 dRyXVC9G9LMVBsYBqOIaCddpeAwRxrBfBDVmOVQDTkERmO2lmbNKM07zovjB+IvyGgFW a3UQ== X-Gm-Message-State: ACrzQf3VgsWMYp9UL/hUPYonndv2FXgv1+0ehgaWgWrXQdi7hHInp4ta 7KsHj87a1Ru3dAqGw6h0Co0= X-Google-Smtp-Source: AMsMyM49pT77A7mxwVaiZ8MDvAzJww6ZJoKyXbRP/NnV0qPP2O/r0zjhh9iHYT5DTObvxzzU91oNaw== X-Received: by 2002:a17:902:c943:b0:182:f5af:40c5 with SMTP id i3-20020a170902c94300b00182f5af40c5mr14901508pla.72.1665606882732; Wed, 12 Oct 2022 13:34:42 -0700 (PDT) Received: from google.com ([2620:15c:9d:2:d4c1:686c:5489:5df9]) by smtp.gmail.com with ESMTPSA id h15-20020a170902680f00b00178acc7ef16sm10904901plk.253.2022.10.12.13.34.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 13:34:42 -0700 (PDT) Date: Wed, 12 Oct 2022 13:34:38 -0700 From: Dmitry Torokhov To: Linus Walleij Cc: Daniel Thompson , Sascha Hauer , Krzysztof Kozlowski , Rob Herring , Lee Jones , Jingoo Han , Shawn Guo , Fabio Estevam , NXP Linux Team , 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-20221012_133444_638515_3B89D570 X-CRM114-Status: GOOD ( 30.52 ) 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 Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote: > On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson > wrote: > > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote: > > > On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov > > > wrote: > > > > > > > > Dmitry, could you fix this? Just patch away in gpiolib-of.c. > > > > > > > > Sure, I'll add a few quirks. I wonder what is the best way to merge > > > > this? I can create a bunch of IBs to be pulled, or I can send quirks to > > > > you/Bartosz and once they land send the patches to drivers... > > > > > > When I did it I was sufficiently convinced that I was the only one patching > > > the quirks in gpiolib-of.c that merge window so I just included it as > > > a hunk in the driver patch. If there will be some more patches to that > > > file I guess some separate patch(es) for gpiolib-of.c is needed, maybe > > > an immutable branch for those if it becomes a lot. > > > > Are renames likely to be a common quirk on the road to libgpiod > > conversion? > > > > I admit I sort of expected it to be common enough that there would be > > one rename quirk in the code supported by an alphabetized string table. > > Such a table would certainly still provoke troublesome merges but ones > > that are trivially resolved. > > Dmitry added a table of sorts, the problems are usually a bit unique > for each instance of nonstandard DT GPIO bindings, that's why I > mostly solved it with open coding in gpiolib-of.c. OK, so I sent out the patch adding "reset-gpios" -> "gpios-reset" translation quirk to keep compatibility with the legacy names, but we still need to figure out what to do with incorrect line polarity in current DTses in tree. Unlike with names we have no indication if out of tree DTSes specify correct polarity or not, so we can't reasonably come up with workarounds that are guaranteed to work for everyone. I see several options: - the driver could continue ignoring line polarity specified in DTS (and use gpiod_set_value_raw()) and hope that they all/will be wired in the same way? - we could fix up in-kernel DTSes, allow flexibility of connection in new designs and respect polarity specified in out of tree DTSes, but accept that there can be breakages with old DTSes not contributed to the mainline or DTSes that were "cached" from an older kernel release - add another quirk forcing "active low" polarity for the legacy "gpios-reset" name, which will allow us respecting polarity in new "reset-gpios" name. Thanks. -- Dmitry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel