Message ID | 20221011-gpiolib-quirks-v3-0-eae9cc2ed0a1@gmail.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1789378wrs; Mon, 17 Oct 2022 22:42:15 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6ubTze9iIgyXYRJ3CbTlehjrUPYTzME5bt0Sp0oW1oh3dJuDnz5cTn5s3udsN2YoIaMR6f X-Received: by 2002:a17:903:2342:b0:17c:ae18:1c86 with SMTP id c2-20020a170903234200b0017cae181c86mr1514320plh.5.1666071734840; Mon, 17 Oct 2022 22:42:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666071734; cv=none; d=google.com; s=arc-20160816; b=FhmzymMQ1fVEFescPE8ZXHm0ZvwiddDvTqeNFMsLZukyqWFgWaggVCDE8Ao/ABC5T9 1RqYfYCefr0w7MBM1T6/I+h9k+cfKtCzNA1En4SiBMmOzNbI/m5gALAVzn3cAL92IC5G uCNtF372JBDKOntGoUrehFGdg8ANy99Jxt82ew9kBVTBGkQHkkvfOixy6YN8GjPlWmhe Kb5K8m0hL+W7IW2pWo/WgKDJr5P2oUVqVJT9PNTEjLzp0cdM6WPGoJ9cB1lsJVKSpkde Dhhgs1m10Tf7c48gAVyr+dCJxmo+QEzmhfHtfGeDIDk/avBSIyI2wH6RlB+m5NRIjRdP Q/uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=9NG3CBgcMhiqdPdVXVfFN0tafSKygxdY4MZpqU8ulL8=; b=s5ZBzNE0z++YyYDZ0mZ6IO9gLTUGjZCCqI6ldogFi0Ieey8ELDRJh+oJEDg+cF2YhQ ptNxiOI8gNYDSRwkbEAXpCJ7qQ0EnU7tQ3w+B1U8B5PCvQ0Fha5GcSybeKH3UG0LDkI5 azFReYDG4p9rok7KsQY9RYjYfJTR+9Bjy3aVxF28kU7vEj6+A/ahmIHqOwAJPyLE5GDJ 1OnmFY3cB7+OTsafhuDEJV4c+HR0Tbl4jpAmk8XSd82xK/AbwXL+pDaBRf+nZT6idao4 /DaYvPsfV616snGOR3hsTnLyuLXDSQmot9oNrSBNGYAZAux6ZprMNQ8NPUTI4oyVaxtA hHRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QLcHi1gU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p35-20020a056a0026e300b0053b36138dc5si12285595pfw.222.2022.10.17.22.42.02; Mon, 17 Oct 2022 22:42:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QLcHi1gU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230171AbiJRFlT (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Tue, 18 Oct 2022 01:41:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229729AbiJRFlR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Oct 2022 01:41:17 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 993449E2DF; Mon, 17 Oct 2022 22:41:16 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id h2so5469980plb.2; Mon, 17 Oct 2022 22:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=9NG3CBgcMhiqdPdVXVfFN0tafSKygxdY4MZpqU8ulL8=; b=QLcHi1gUfZaa/q2+yUxqZL2jA8pWuPlvSDT+67V72EZmsg5g8+XkKWJ1c7xsUNwz5y gXtwcdEmwzHxyrMUnsfe8X1LgcGDXVsDr88y+aVVhsro9/NAtasgg2If4YYEu9Q1XTlP FXytHzi3CwMIXxNDEs/c15cmSgNOnS9KnPjg+jSuJsgESciv3tfgBdM10fRfoRmNehRu /PaYZ7u9fO6P/7iaA5MLy4xlPl8SsK9pNRiZTt8EnK8PFTdsIBLPEgYcRZvqbj1/ei9t CF9U8mM0F+Pz0g+0bBwcRg6XYe8ZsXv3sw2+8z3gpl6BSZant2UqtrYEB+rUD2ex71zM CjVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9NG3CBgcMhiqdPdVXVfFN0tafSKygxdY4MZpqU8ulL8=; b=3hMymn0h+9q1GzYubpytCTSSKS7GIIIF9IHe7ru2yL/y1G4+PIRKRZzg/noU9I56Rv sM8ooP1ls1sVVzFcqk8UasUwa30ZiEsIkQnRfquRsN5hE12Yk89XaB6qGq6aUftdKB3d 7mX3B5P+7LL5fp3iSZqsfVXQOnk/ZmzwYZQRaWZM1pOosmmmia1wo544dzjqTxAIZAoW kT0nde418C2i32uUNU0+wZB6je2HpxXKfmcuCnwwhAXJUM6nsqeGNqA9bMQary0bhlWx RRuF0l4dfv/oOLkNTNI2OKAFCYqRdc/wXt/KD3x8BJcqE8M8sVLrWg9QswiJc0b8ZYG3 h8sw== X-Gm-Message-State: ACrzQf00Zv7XD9AHpgblDHRNHMFl/DVkEOLTBnSJvvptB9VYozEGK+9+ lpShljnxFvL8JGufz4CAwG4= X-Received: by 2002:a17:90b:4ac5:b0:20a:de32:366b with SMTP id mh5-20020a17090b4ac500b0020ade32366bmr1625503pjb.197.1666071675818; Mon, 17 Oct 2022 22:41:15 -0700 (PDT) Received: from dtor-ws.mtv.corp.google.com ([2620:15c:9d:2:f7bc:1bb5:e0b1:92cb]) by smtp.gmail.com with ESMTPSA id z7-20020a1709027e8700b00172f4835f53sm7597435pla.192.2022.10.17.22.41.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Oct 2022 22:41:14 -0700 (PDT) From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: Bartosz Golaszewski <brgl@bgdev.pl>, Linus Walleij <linus.walleij@linaro.org> Cc: Alexander Stein <alexander.stein@ew.tq-group.com>, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Daniel Thompson <daniel.thompson@linaro.org>, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH v3 00/10] gpiolib: more quirks to handle legacy names Date: Mon, 17 Oct 2022 22:41:01 -0700 Message-Id: <20221011-gpiolib-quirks-v3-0-eae9cc2ed0a1@gmail.com> X-Mailer: git-send-email 2.38.0.413.g74048e4d9e-goog MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: b4 0.11.0-dev-5166b Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747002835789396200?= X-GMAIL-MSGID: =?utf-8?q?1747002835789396200?= |
Series |
gpiolib: more quirks to handle legacy names
|
|
Message
Dmitry Torokhov
Oct. 18, 2022, 5:41 a.m. UTC
In preparation to converting several drivers to gpiod API, and to keep existing DTS working, this series adds additional quirks to locate gpio lines with legacy names. Additionally the quirk handling has been reworked (once again) to pull all simple renames (ones that do not involve change of indices or other complex manipulations) into a single quirk with a table containing transformations. This should make adding new quirks easier. When using legacy names gpiolib will emit a message to nudge users to update DTSes (when possible). Note that the last patch requires the following change from the OF tree: 88269151be67 ("of: base: make of_device_compatible_match() accept const device node") The change is also available in mainline - it has been merged in 6.1 merge window. Thanks. To: Linus Walleij <linus.walleij@linaro.org> To: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org --- Changes in v3: - added missed legacy compatible for UART variant of Marvell NFC controller - added naming quirk for MOXA ART RTC - Link to v2: https://lore.kernel.org/r/20221011-gpiolib-quirks-v2-0-73cb7176fd94@gmail.com Changes in v2: - fixed 'fsl,imx8mq-fec' & 'fsl,imx8qm-fec' compatibles issue noticed by Alexander Stein - implemented Daniel Thompson's suggestion on tightening configs selecting renaming quirks and added a comment to discourage adding rename quirks without checks for specific compatible(s) - added a polarity quirk for Himax LCDs - collected reviewed-by tags - Link to v1: https://lore.kernel.org/r/20221011-gpiolib-quirks-v1-0-e01d9d3e7b29@gmail.com --- Dmitry Torokhov (10): gpiolib: of: add a quirk for legacy names in Mediatek mt2701-cs42448 gpiolib: of: consolidate simple renames into a single quirk gpiolib: of: tighten selection of gpio renaming quirks gpiolib: of: add quirk for locating reset lines with legacy bindings gpiolib: of: add a quirk for reset line for Marvell NFC controller gpiolib: of: add a quirk for reset line for Cirrus CS42L56 codec gpiolib: of: add a quirk for legacy names in MOXA ART RTC gpiolib: of: factor out code overriding gpio line polarity gpiolib: of: add quirk for phy reset polarity for Freescale Ethernet gpiolib: of: add a quirk for reset line polarity for Himax LCDs drivers/gpio/gpiolib-of.c | 349 ++++++++++++++++++++++++++++++---------------- 1 file changed, 227 insertions(+), 122 deletions(-) --- base-commit: dca0a0385a4963145593ba417e1417af88a7c18d change-id: 20221011-gpiolib-quirks-d452ed31d24e -- Dmitry
Comments
On Mon, Oct 17, 2022 at 10:41:01PM -0700, Dmitry Torokhov wrote: > In preparation to converting several drivers to gpiod API, and to keep > existing DTS working, this series adds additional quirks to locate > gpio lines with legacy names. > > Additionally the quirk handling has been reworked (once again) to pull > all simple renames (ones that do not involve change of indices or other > complex manipulations) into a single quirk with a table containing > transformations. This should make adding new quirks easier. > When using legacy names gpiolib will emit a message to nudge users to > update DTSes (when possible). > > Note that the last patch requires the following change from the OF tree: > > 88269151be67 ("of: base: make of_device_compatible_match() accept const device node") > > The change is also available in mainline - it has been merged in 6.1 > merge window. I was wondering if we can use the approach that ACPI chose for itself, i.e. the separate data that can be filled by the corresponding driver and then GPIO OF common code may use it. In that case each driver knows the exact list of compatible strings and associated quirks.
On Tue, Oct 18, 2022 at 2:32 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Mon, Oct 17, 2022 at 10:41:01PM -0700, Dmitry Torokhov wrote: > > In preparation to converting several drivers to gpiod API, and to keep > > existing DTS working, this series adds additional quirks to locate > > gpio lines with legacy names. > > > > Additionally the quirk handling has been reworked (once again) to pull > > all simple renames (ones that do not involve change of indices or other > > complex manipulations) into a single quirk with a table containing > > transformations. This should make adding new quirks easier. > > When using legacy names gpiolib will emit a message to nudge users to > > update DTSes (when possible). > > > > Note that the last patch requires the following change from the OF tree: > > > > 88269151be67 ("of: base: make of_device_compatible_match() accept const device node") > > > > The change is also available in mainline - it has been merged in 6.1 > > merge window. > > I was wondering if we can use the approach that ACPI chose for itself, > i.e. the separate data that can be filled by the corresponding driver > and then GPIO OF common code may use it. In that case each driver knows > the exact list of compatible strings and associated quirks. I actually deliverately chose the other way around, to centralize all quirks, so that drivers look nice and simple and the ugly historical errors of the device tree be hidden away in gpiolib-of.c. Yours, Linus Walleij
On Wed, Oct 19, 2022 at 12:56:31PM +0200, Linus Walleij wrote: > On Tue, Oct 18, 2022 at 2:32 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Oct 17, 2022 at 10:41:01PM -0700, Dmitry Torokhov wrote: > > > In preparation to converting several drivers to gpiod API, and to keep > > > existing DTS working, this series adds additional quirks to locate > > > gpio lines with legacy names. > > > > > > Additionally the quirk handling has been reworked (once again) to pull > > > all simple renames (ones that do not involve change of indices or other > > > complex manipulations) into a single quirk with a table containing > > > transformations. This should make adding new quirks easier. > > > When using legacy names gpiolib will emit a message to nudge users to > > > update DTSes (when possible). > > > > > > Note that the last patch requires the following change from the OF tree: > > > > > > 88269151be67 ("of: base: make of_device_compatible_match() accept const device node") > > > > > > The change is also available in mainline - it has been merged in 6.1 > > > merge window. > > > > I was wondering if we can use the approach that ACPI chose for itself, > > i.e. the separate data that can be filled by the corresponding driver > > and then GPIO OF common code may use it. In that case each driver knows > > the exact list of compatible strings and associated quirks. > > I actually deliverately chose the other way around, to centralize all quirks, > so that drivers look nice and simple and the ugly historical errors of the > device tree be hidden away in gpiolib-of.c. This makes sense if and only if we may guarantee no quirks will appear in the future. So, it may be true for DT, but I'm quite skeptical about ACPI...
On Wed, Oct 19, 2022 at 1:16 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Wed, Oct 19, 2022 at 12:56:31PM +0200, Linus Walleij wrote: > > On Tue, Oct 18, 2022 at 2:32 PM Andy Shevchenko > > > I was wondering if we can use the approach that ACPI chose for itself, > > > i.e. the separate data that can be filled by the corresponding driver > > > and then GPIO OF common code may use it. In that case each driver knows > > > the exact list of compatible strings and associated quirks. > > > > I actually deliverately chose the other way around, to centralize all quirks, > > so that drivers look nice and simple and the ugly historical errors of the > > device tree be hidden away in gpiolib-of.c. > > This makes sense if and only if we may guarantee no quirks will appear in the > future. So, it may be true for DT, but I'm quite skeptical about ACPI... Right, the idea is to stop more idiomatic DT bindings from coming into existance by review and formal verification of the reviewed bindings by using YAML schemas. ACPI is somewhat lacking public review of "bindings" and DSDT tables, and I don't know if there is some counterpart to the schema validation, so that makes for more new bugs. But maybe ACPI has some tricks up its sleeve that I don't know about. To me it seems like bugs in ACPI are discovered by developers after the devices are already produced :/ There are bindings and device trees which lack public review too, most notably Apple Mac, so especially for them we are redefining new bindings and who knows, maybe Apple will pick them up eventually! Yours, Linus Walleij
On Tue, Oct 18, 2022 at 7:41 AM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > In preparation to converting several drivers to gpiod API, and to keep > existing DTS working, this series adds additional quirks to locate > gpio lines with legacy names. > > Additionally the quirk handling has been reworked (once again) to pull > all simple renames (ones that do not involve change of indices or other > complex manipulations) into a single quirk with a table containing > transformations. This should make adding new quirks easier. > When using legacy names gpiolib will emit a message to nudge users to > update DTSes (when possible). > > Note that the last patch requires the following change from the OF tree: > > 88269151be67 ("of: base: make of_device_compatible_match() accept const device node") > > The change is also available in mainline - it has been merged in 6.1 > merge window. > > Thanks. > > To: Linus Walleij <linus.walleij@linaro.org> > To: Bartosz Golaszewski <brgl@bgdev.pl> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > Cc: Daniel Thompson <daniel.thompson@linaro.org> > Cc: linux-gpio@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-mediatek@lists.infradead.org > I applied the entire series. Bartosz