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=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 E656BC47089 for ; Thu, 27 May 2021 14:43:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C71B46101B for ; Thu, 27 May 2021 14:43:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234514AbhE0Op2 convert rfc822-to-8bit (ORCPT ); Thu, 27 May 2021 10:45:28 -0400 Received: from mail-ua1-f50.google.com ([209.85.222.50]:39920 "EHLO mail-ua1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234476AbhE0Op1 (ORCPT ); Thu, 27 May 2021 10:45:27 -0400 Received: by mail-ua1-f50.google.com with SMTP id f20so330512uax.6; Thu, 27 May 2021 07:43:53 -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:content-transfer-encoding; bh=mrubqU354Bw50F6NhJan1ixpgJfHonbN1b5m4Qiwgio=; b=dEJ6rhKBTaObD7d0Lo828vL5ojAKRBNhjvScfDvspKbdVeLBneqDmhIr4SNz9Cy2Y8 qBH24780dG5saxyDxrw7Q/OCY1H7Dxix9k8Vh1l22+z2Rig/4EStOR1yoYjW8iwQQ4le oDMGk3RC/LMaZ222y4D3cSKmFEKGYE2p0hG9ZEPslB2wfJ4Wvr3n8MLBrjcHPx64kso+ hXbtEzT4tt6CsihbWVaOBuaVty/JH0MDcryuziqwdzfYtlLTCmX6JsHWkximY2pgqRxQ ubjHP65tUFUY4O4c1IBOh8Q0w4PRjX3BzPXhk5InCSdJi5RGL/m9VE9+W7sxtSr5Fuui v+cw== X-Gm-Message-State: AOAM5326N2mI2ydwLoj1NCropEHGe9g8RvIDk3g4Zf8YF6QgjUuD419i zREW9qB/PpOrNq4KaZMdDsPd4nIxc89nEGOvIow= X-Google-Smtp-Source: ABdhPJxbQEybwWGbInGZt3HUnlN6JAN7z8azG8ldl9Rc665+8ANZ8MQfrKZ9bI9VbY2xg+l//EvVWH257GMEDN8MfPs= X-Received: by 2002:a05:6122:3c:: with SMTP id q28mr2430647vkd.5.1622126632870; Thu, 27 May 2021 07:43:52 -0700 (PDT) MIME-Version: 1.0 References: <52df0592c81ac000d3f486a9ba5a4d84b0f42c47.1621583562.git.geert+renesas@glider.be> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 27 May 2021 16:43:41 +0200 Message-ID: Subject: Re: [PATCH 3/3] dt-bindings: gpio: pcf857x: Convert to json-schema To: Laurent Pinchart Cc: Rob Herring , Linus Walleij , 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" , "open list:TI ETHERNET SWITCH DRIVER (CPSW)" , Linux ARM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org Hi Laurent, On Sun, May 23, 2021 at 3:52 AM Laurent Pinchart wrote: > On Fri, May 21, 2021 at 09:54:08AM +0200, 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? > > Given that the driver doesn't match against it, that could be done, if > you're confident enough that there's no difference between the TI and > NXP versions that would need to be taken into account. I've just checked the datasheets, and they're identical modulo shuffling. Probably TI is the mandatory second source for the NXP (née Philips) part. > > I have listed Laurent as the maintainer, as he wrote the original > > bindings. Laurent: Please scream if this is inappropriate ;-) > > I'm sure I'll regret it later, but I don't mind :-) Thanks! > > + 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. > > The line wrapping is weird. Is it? The different cases just start on a new line. Which makes no difference, as there's no "|". 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