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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0466FC433ED for ; Fri, 21 May 2021 10:24:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D15BB613CB for ; Fri, 21 May 2021 10:24:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232037AbhEUKZY (ORCPT ); Fri, 21 May 2021 06:25:24 -0400 Received: from mail-vs1-f52.google.com ([209.85.217.52]:42537 "EHLO mail-vs1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbhEUKZX (ORCPT ); Fri, 21 May 2021 06:25:23 -0400 Received: by mail-vs1-f52.google.com with SMTP id j12so5049654vsq.9; Fri, 21 May 2021 03:23:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=07JcO3CRBM1HaXZjYTRFNn1m7ZvE1K/0YDoSBc48cOA=; b=DCR55WXLVvbEc2gYXHvo216Z7lt4UsQ5SqxlA1beSinb3WoIzabDzXfUyzWw7kYZyi 6dgls0Vy9ebfJNDl4XQHzUwy8zxpNiMtQscsnRsFpDdYrmGxvuYbKqVGE4m8vi4dUQN4 DnzA5jKxOHefpY5yL8pD2JoUDbZKR2eic70gRYbgbnoeE/p2JfKOryH9sgI4Wj3/FFwt 3eOOeMKhlAXwcbD98c4CnqcChSLtG7YE28hrcZ+2CmlETsNpV1OupnLXEfKkfD7XENTE FB3KeZtTzu4xK9TNwVzAZFVwl+vdAlNxIJlHliOfadqkFsTlg19RogEbgBJ2BzqcW7Wo 9wfQ== X-Gm-Message-State: AOAM530SL8hFXYQwqyUQkBfrY3Se9HrTxpxEivxY4y99e77peRMvMp8g HX8i9KO7go1HC9YKGoBSke4ZttpYe0Q0ioh0o6trfRrM+4M= X-Google-Smtp-Source: ABdhPJyT4gwI8EtwVgoM5wwCrEysIqEoC18HpnH5bpZlayQihXs9cyrp/kDJFN3CX1Upp0Aj9A5c3Ip+YMLH51kO8wk= X-Received: by 2002:a05:6102:392:: with SMTP id m18mr9583479vsq.40.1621592638872; Fri, 21 May 2021 03:23:58 -0700 (PDT) MIME-Version: 1.0 References: <52df0592c81ac000d3f486a9ba5a4d84b0f42c47.1621583562.git.geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 21 May 2021 12:23:47 +0200 Message-ID: Subject: Re: [PATCH 3/3] dt-bindings: gpio: pcf857x: Convert to json-schema To: Linus Walleij Cc: Rob Herring , Laurent Pinchart , Bartosz Golaszewski , =?UTF-8?Q?Beno=C3=AEt_Cousson?= , Tony Lindgren , Jan Tuerk , Shawn Guo , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:GPIO SUBSYSTEM" , Linux-OMAP , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Hi Linus, On Fri, May 21, 2021 at 12:04 PM Linus Walleij wrote: > On Fri, May 21, 2021 at 9:54 AM Geert Uytterhoeven > wrote: > > Convert the PCF857x-compatible I/O expanders Device Tree binding > > documentation to json-schema. > > > > Document missing compatible values, properties, and gpio hogs. > > > > Signed-off-by: Geert Uytterhoeven > > (...) > > Perhaps the "ti,pcf8575" construct should be removed, and the few users > > fixed instead? > > You would rather list it as deprecated I think? > It is ABI... All DTS files use the "nxp,pcf8575" fallback, except for arch/x86/platform/ce4100/falconfalls.dts. The latter ain't working with Linux, as the Linux driver doesn't match against "ti,pcf8575"... > > + gpio-controller: true > > So this is implicitly using the generic schema in > /dtschema/schemas/gpio/gpio.yaml if you leave it out: Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml: ignoring, error in schema: properties warning: no schema found in file: Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml: properties: 'gpio-controller' is a dependency of '#gpio-cells' from schema $id: http://devicetree.org/meta-schemas/gpios.yaml# > > + lines-initial-states: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Bitmask that specifies the initial state of each line. > > + When a bit is set to zero, the corresponding line will be initialized to > > + the input (pulled-up) state. > > + When the bit is set to one, the line will be initialized to the > > + low-level output state. > > + If the property is not specified all lines will be initialized to the > > + input state. > > Is this something we standardized or something that should > actually be a custom "nxp," property we just missed it? > (Looks like the latter... oh well, now it is there.) Too late for an "nxp," prefix. See the NOTE in drivers/gpio/gpio-pcf857x.c: /* NOTE: these chips have strange "quasi-bidirectional" I/O pins. * We can't actually know whether a pin is configured (a) as output * and driving the signal low, or (b) as input and reporting a low * value ... without knowing the last value written since the chip * came out of reset (if any). We can't read the latched output. * * In short, the only reliable solution for setting up pin direction * is to do it explicitly. The setup() method can do that, but it * may cause transient glitching since it can't know the last value * written (some pins may need to be driven low). * * Using n_latch avoids that trouble. When left initialized to zero, * our software copy of the "latch" then matches the chip's all-ones * reset state. Otherwise it flags pins to be driven low. */ > > +patternProperties: > > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": > > + type: object > > But this is already in > /dtschema/schemas/gpio/gpio-hog.yaml > for nodename, isn't that where it properly belongs? > > I'm however confused here Rob will know what to do. If we leave this out, something still has to refer to it? I see no other binding doing that... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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 X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CCCBC433ED for ; Fri, 21 May 2021 10:25:58 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C0EEA613BD for ; Fri, 21 May 2021 10:25:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0EEA613BD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=idYyfdjmj08AkqM1iHPeeZjAIOVAeLbOclF5le5BG10=; b=DZ7ZGV7FkuIXwHzSJ/6LF/bpPN 5v9Uhesg1IoqKSk9ls/OUGqi0F+JfR1E0C0C3FIaUV7dKgn48jyRP0wEa9a70IbDCuwV26fWXxUTL cPB3BUu9C+WCEpMsmjipouwBZcZiAdmsBXoQ6YIIKCRvEgv5ztC/nFrCLYJddjhPuo4/jK8UINYyY Am6DjjWDRoPZIwQNXT9vBSog7ebi84jSJnhy11oIM96uqNjJlwtjUojo5sTG+kb4QMlwl33LRmlec C38m544E+ssFwdMeUI1s9mpSpvDRASkNRkMxADVVrp3Yl8KB5f9tdbLkiNM/UMLUBM/vb/nutD+6M wB7eU+fw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lk2K7-004t9v-Ux; Fri, 21 May 2021 10:24:08 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lk2K5-004t8g-6F for linux-arm-kernel@desiato.infradead.org; Fri, 21 May 2021 10:24:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=07JcO3CRBM1HaXZjYTRFNn1m7ZvE1K/0YDoSBc48cOA=; b=zqhWKd7m8O0mQOfG56jyaIcIJb /Bs+chVeixtrr9AhaEDhhspt7poZqxrlQd0u17t6LsI5LRaB/pb7tjUS8T6fg6KqK7ANhR/Cg8Vyv 2M57syvQ2UNY7sGsRkE5wdG8JFIzSKX1Sn7iV30GEGZfJkV0BdS8sN0H97Y0ZcRiUIj1PzcUUspk0 CDH79Zh5sUUPLR4wi6hRztgwlBjvIETppM63tOXJFD1gFZRtGtMG9pIP+Vv8m8WY8t9is7i4W0fVS xAS4NsDJLO/aZHmjpCoGf+neQGFnpPlU74BCTo4duyq5a31IS6/z93AXq39K9vZPfp3na5bgGSb/P FtJL181A==; Received: from mail-vs1-f43.google.com ([209.85.217.43]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lk2K2-00H1pZ-2b for linux-arm-kernel@lists.infradead.org; Fri, 21 May 2021 10:24:03 +0000 Received: by mail-vs1-f43.google.com with SMTP id q6so5880315vsp.13 for ; Fri, 21 May 2021 03:23:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=07JcO3CRBM1HaXZjYTRFNn1m7ZvE1K/0YDoSBc48cOA=; b=D87e8NZuIJfZZj1uo4nK96qoSp9dk5DAqv6Hk74PjweA0VktS69MKBhxcTcrmo5LJ3 PkQzDTlrC+fX+LkAwKzxRWl23jnOsNDgH+EFS2KdMoV6syJcJxDFW/QWWkPZOMcvQxQ5 QRGWqAkiRxQZYL13O9Sk7vwaEnEXm/E9r0LErWf8nVJyeuq9zDER6/3pDh577gA6Ig/i D1aXv0ef4OQD6DpZ6OcJuyrqzsl8TshBMru9v9XznPi4JaonhmVZFDdHNSZqqQyKXRZa a2jmPDjuDIZMrXm6koFCeRmGeIg7gAY6a0wxn5F6aDDywFruLatGG1eWlZYO2o/krLYm dlLA== X-Gm-Message-State: AOAM531mf3zvpmqpdSAK04qbiHY010qnobb73tUGdyvNVoFCpk0wYYjP k1Y37KPCUgcGhBk4nML/TOZq/+jSp0gKZFE/BEs= X-Google-Smtp-Source: ABdhPJyT4gwI8EtwVgoM5wwCrEysIqEoC18HpnH5bpZlayQihXs9cyrp/kDJFN3CX1Upp0Aj9A5c3Ip+YMLH51kO8wk= X-Received: by 2002:a05:6102:392:: with SMTP id m18mr9583479vsq.40.1621592638872; Fri, 21 May 2021 03:23:58 -0700 (PDT) MIME-Version: 1.0 References: <52df0592c81ac000d3f486a9ba5a4d84b0f42c47.1621583562.git.geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 21 May 2021 12:23:47 +0200 Message-ID: Subject: Re: [PATCH 3/3] dt-bindings: gpio: pcf857x: Convert to json-schema To: Linus Walleij Cc: Rob Herring , Laurent Pinchart , Bartosz Golaszewski , =?UTF-8?Q?Beno=C3=AEt_Cousson?= , Tony Lindgren , Jan Tuerk , Shawn Guo , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:GPIO SUBSYSTEM" , Linux-OMAP , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210521_032402_140862_694A513F X-CRM114-Status: GOOD ( 34.28 ) 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 Hi Linus, On Fri, May 21, 2021 at 12:04 PM Linus Walleij wrote: > On Fri, May 21, 2021 at 9:54 AM Geert Uytterhoeven > wrote: > > Convert the PCF857x-compatible I/O expanders Device Tree binding > > documentation to json-schema. > > > > Document missing compatible values, properties, and gpio hogs. > > > > Signed-off-by: Geert Uytterhoeven > > (...) > > Perhaps the "ti,pcf8575" construct should be removed, and the few users > > fixed instead? > > You would rather list it as deprecated I think? > It is ABI... All DTS files use the "nxp,pcf8575" fallback, except for arch/x86/platform/ce4100/falconfalls.dts. The latter ain't working with Linux, as the Linux driver doesn't match against "ti,pcf8575"... > > + gpio-controller: true > > So this is implicitly using the generic schema in > /dtschema/schemas/gpio/gpio.yaml if you leave it out: Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml: ignoring, error in schema: properties warning: no schema found in file: Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml: properties: 'gpio-controller' is a dependency of '#gpio-cells' from schema $id: http://devicetree.org/meta-schemas/gpios.yaml# > > + lines-initial-states: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Bitmask that specifies the initial state of each line. > > + When a bit is set to zero, the corresponding line will be initialized to > > + the input (pulled-up) state. > > + When the bit is set to one, the line will be initialized to the > > + low-level output state. > > + If the property is not specified all lines will be initialized to the > > + input state. > > Is this something we standardized or something that should > actually be a custom "nxp," property we just missed it? > (Looks like the latter... oh well, now it is there.) Too late for an "nxp," prefix. See the NOTE in drivers/gpio/gpio-pcf857x.c: /* NOTE: these chips have strange "quasi-bidirectional" I/O pins. * We can't actually know whether a pin is configured (a) as output * and driving the signal low, or (b) as input and reporting a low * value ... without knowing the last value written since the chip * came out of reset (if any). We can't read the latched output. * * In short, the only reliable solution for setting up pin direction * is to do it explicitly. The setup() method can do that, but it * may cause transient glitching since it can't know the last value * written (some pins may need to be driven low). * * Using n_latch avoids that trouble. When left initialized to zero, * our software copy of the "latch" then matches the chip's all-ones * reset state. Otherwise it flags pins to be driven low. */ > > +patternProperties: > > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": > > + type: object > > But this is already in > /dtschema/schemas/gpio/gpio-hog.yaml > for nodename, isn't that where it properly belongs? > > I'm however confused here Rob will know what to do. If we leave this out, something still has to refer to it? I see no other binding doing that... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel