Message ID | 20240212083426.26757-1-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-61206-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp2301871dyd; Mon, 12 Feb 2024 00:35:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IHVejgVEVDf4IuCIVbEorkmtVgf3SFH9TqYHxxloEr7Ol0EnCGIjG/DHadmtMSYZIJvYbqo X-Received: by 2002:aa7:d6ca:0:b0:560:d9d5:7b11 with SMTP id x10-20020aa7d6ca000000b00560d9d57b11mr4414266edr.42.1707726903177; Mon, 12 Feb 2024 00:35:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707726903; cv=pass; d=google.com; s=arc-20160816; b=qqAo+XGwqymWeDRI8BtVIBRt5VP8sgEXT+oZeViD3WAXnXmQ+uCzFJNxkIc12x6FrU wWdZ1uTTPjxKRULFKc/XnU24TSNHKQRSU8ZCyAKioL6H7ivxBxqnn8c2hnZlDxWt09iL npdTCUgGT4+hOwUl9QVZnHU86LBBJUlrBdx+nnL250Pb33c0xh2o+sGIGguBnj0lPERS UYyXpo++5oiHmDg3c4PG75YIA9JRheO8mYFAJ+YlTK9wRcmX1Mo4g22uedHJ8nCwpunk D9XU4VtorK0xryW76X0HyLmwKA3qvMO8clLfeUTqCLkyfqz1qJ9LrzBU22GeM6eZgdPl JpqA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=gv5wKhvz2IkMiVTY6JBsKVbcSvEbLs7uJIPS1y/GGHA=; fh=X5AWO4cpoxTkGRhe2jz8Ufoecabh0SEsV7pdAuKTbt4=; b=fVcTLjBIrG2ovUOTAnk6SHqTuJgDAbYlDXrVqN6AQSJPUBR4j958QQJPlmTn7J5o30 IQyzr72xCUhFl7Gk9B9yHLhmRupwdMyfncmloOYme1YnF4mOBcORV035gpby1Kz/i6Co u+Nzqsyv9K0OQz9tNzoQUgYg5qwpaEIDlkYclhWmSt+GBUGaNreWBy0ZmcTxAuetngeJ QTX2vep/H6cGCSAwp3NmpKmXTqZJEzkV5Qmp4lRDqIeY9pxALeIQomfL5AXyobUcdYP5 jdCAysjRcPCl4veND4M+KZRCFU4vy/0q4AJajusX8Tu3sPWdDV38vwFDBWWY0WT2Woi1 syDQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hHVahMUL; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-61206-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61206-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org X-Forwarded-Encrypted: i=2; AJvYcCWjd2iGb211EIwqH8cd7qqiJBcVN2zp6lQqWvZrhg3mogYDYu/S2AIDT7EW2beBgKll5QOOr+osWofGoJb92xo94rnSjw== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id b15-20020aa7cd0f000000b0056119abcd45si2552419edw.611.2024.02.12.00.35.03 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 00:35:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-61206-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hHVahMUL; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-61206-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61206-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id C8AC11F261DB for <ouuuleilei@gmail.com>; Mon, 12 Feb 2024 08:35:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AE969101E8; Mon, 12 Feb 2024 08:34:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="hHVahMUL" Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E12B410A23 for <linux-kernel@vger.kernel.org>; Mon, 12 Feb 2024 08:34:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707726873; cv=none; b=nSZYaKPTGa56h6K0Ff7icpom+k44nHgV2ajw+HrmiV1HFhSz9ROVazinmWzosRZM+Fcly6xzd6W/ia6iZASDts25kfaJtNwHot7WQygFPrrdwxIJlwowN+NzB/M0OnWQ5m69oHG/PEGsvWgVfdSWyFjPpxy0CYRkT3cBCmxepU8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707726873; c=relaxed/simple; bh=HlXn3h+kaQ0ElD0RQ8Ha9CS2kgD8dt6z4YNhjTiljZA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=SGJhZpooEa7Q/0sIE5e5igB+Kvq/ZJsGBn/SQPfAUK13X1vr5Lqj29m5V6FFgwAlcZ4z112dIqQOknWCNC1APd/iuOc83m6NlajH8/6z9Iy1pe2Tp1xeb+u+6PwjcpPgkpX1nuJsCByz/hCHQsUbeNmz7RwHWcGQPVPFWXHU4GE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=hHVahMUL; arc=none smtp.client-ip=209.85.167.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5114c05806eso4568955e87.1 for <linux-kernel@vger.kernel.org>; Mon, 12 Feb 2024 00:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707726870; x=1708331670; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=gv5wKhvz2IkMiVTY6JBsKVbcSvEbLs7uJIPS1y/GGHA=; b=hHVahMUL7Ie+bKU+dKwYKKqREmmxVR5DYml1yKsOevkq7Fyc1rggzJIg5dGjU8aTRT zcamReHQwBxIt1g17pjoqcaZKvVw0C/msaA6RqZ+7S/0pn5vekU2qP3H4kWvnn057oQE MLI8aAGZcfH8NZDFNYUGbtJsNuDw7c4hNuUWftJa2gx7LrcUosN/aZpGf8/RHwh/gknv Rc8jYSylKOeChQkViHIsSLaP3UFAuI6i/5U/SHVEOJ73lxcd+gR0l9vL+HqFUDKEZAhg 3bCUfxacZC417VUSrXsSvhzerTzuyMCCEKs124Elbwyk0Yez2Gek7NkFbaQZtPkN2JIE NBbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707726870; x=1708331670; 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=gv5wKhvz2IkMiVTY6JBsKVbcSvEbLs7uJIPS1y/GGHA=; b=AFzk+N9bIwrH3E1d80b1uKIZkR+1th6s2UTwBh1GWmEedGYYPW8oZcBdHQ/1QpLTEX rrdBAgDKHi+B8njBfc2tDXKSna0SZTB4JBXwYfmaPYJDHJgKVyoXoQkgtsL/b+grilCn hY80X8ctLR3xpfbsXENrHN8hqeQlJfcyLGJ5hkXUa4eAdN/7vkVPsrVpa36NjD0U5p+v uuLOyTtah/jGWjUisgQEoQ4+Hmj+Bvzu6oxLXVPm+YqbsKRodiWqtNuXkdwPJtv6rjS/ u6KIKC3npu25kWni96SG4w80GOG3ghHVxch5QP3GXvkbUeBAVoPeBDCajC+Zz6UDqisu ApNA== X-Gm-Message-State: AOJu0YwnBwkceEP37feVza8P9HEkUHl01jYbAiVyRFGN/G7vsXzvFjvN GKHQyhnBXRBjswAMEjnU/5BqOK0NwoKzkMqRhtIj649au3BflI7Dj/RS8HIc+w0= X-Received: by 2002:a05:6512:ac3:b0:511:622a:97bc with SMTP id n3-20020a0565120ac300b00511622a97bcmr4332576lfu.18.1707726869900; Mon, 12 Feb 2024 00:34:29 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCX2/OOxwQkBfCOqrL69OJ2Og2SLXQbIWxYUftBYaEdpQwcR9KvBj46EaZ/X0p/ECSV6BbcYFfOvCibaxWiaIH8O+40/0TBOGdb42Ra6AqIcOSAVcCwIRGv573ZeMpqVLuvr4YJKNtDlP1j41LiGSiUDlEV69bRyqOTMbMYfZeoUo/MS13JUVmk16rtLWu02oj0un0+f1SKLSEAaBfb9PkljhnaKNk1CPrurjGfcdB+GOhPzgd8rYFcgPH+jHSpRy16k6PrmGXja33hzMUoD53Nor5PTjdU4ofSJDeXN6g8VETb2iRyUdxHLWklpu51CDB2n9fe6R729XyFpfNQzuu558tQ+sozROWCXAuzkCRW8gjrffGPFBWPP01J3r+6Y4uah0YAmR41ZtopZObs= Received: from krzk-bin.. ([178.197.223.6]) by smtp.gmail.com with ESMTPSA id y12-20020a056000108c00b0033b40a3f92asm6111024wrw.25.2024.02.12.00.34.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 00:34:29 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Linus Walleij <linus.walleij@linaro.org>, Miguel Ojeda <ojeda@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Robin van der Gracht <robin@protonic.nl>, Paul Burton <paulburton@kernel.org>, Geert Uytterhoeven <geert@linux-m68k.org>, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com> Subject: [PATCH 1/3] dt-bindings: auxdisplay: hit,hd44780: drop redundant GPIO node Date: Mon, 12 Feb 2024 09:34:24 +0100 Message-Id: <20240212083426.26757-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790681445242998878 X-GMAIL-MSGID: 1790681445242998878 |
Series |
[1/3] dt-bindings: auxdisplay: hit,hd44780: drop redundant GPIO node
|
|
Commit Message
Krzysztof Kozlowski
Feb. 12, 2024, 8:34 a.m. UTC
Examples of other nodes, like GPIO controller, are redundant and not
really needed in device bindings.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 10 ----------
1 file changed, 10 deletions(-)
Comments
Hi Krzysztof, CC Ralf On Mon, Feb 12, 2024 at 9:34 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > Examples of other nodes, like GPIO controller, are redundant and not > really needed in device bindings. > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Thanks for your patch! > --- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml > +++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml > @@ -99,17 +99,7 @@ examples: > }; > - | > #include <dt-bindings/gpio/gpio.h> > - i2c { > - #address-cells = <1>; > - #size-cells = <0>; > > - pcf8574: pcf8574@27 { > - compatible = "nxp,pcf8574"; > - reg = <0x27>; > - gpio-controller; > - #gpio-cells = <2>; > - }; > - }; This part was added delberately in commit c784e46c8445635a ("auxdisplay: Add I2C gpio expander example"), to aid makers who are not DT experts. Note that there are no other examples of this popular wiring scheme in upstream DTS. > hd44780 { > compatible = "hit,hd44780"; > display-height-chars = <2>; If you do want to insist on removing the i2c GPIO expander part, I think this node should be removed too, as it is almost identical to the first example. Gr{oetje,eeting}s, Geert
On 12/02/2024 09:41, Geert Uytterhoeven wrote: > Thanks for your patch! > >> --- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml >> +++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml >> @@ -99,17 +99,7 @@ examples: >> }; >> - | >> #include <dt-bindings/gpio/gpio.h> >> - i2c { >> - #address-cells = <1>; >> - #size-cells = <0>; >> >> - pcf8574: pcf8574@27 { >> - compatible = "nxp,pcf8574"; >> - reg = <0x27>; >> - gpio-controller; >> - #gpio-cells = <2>; >> - }; >> - }; > > This part was added delberately in commit c784e46c8445635a ("auxdisplay: > Add I2C gpio expander example"), to aid makers who are not DT experts. > Note that there are no other examples of this popular wiring scheme > in upstream DTS. Hm, I don't understand how exactly it helps. The GPIO expander has its own example and as you pointed below, this is basically the same code, except rw and backlight GPIOs. > >> hd44780 { >> compatible = "hit,hd44780"; >> display-height-chars = <2>; > > If you do want to insist on removing the i2c GPIO expander part, > I think this node should be removed too, as it is almost identical > to the first example. > > Gr{oetje,eeting}s, > > Geert > Best regards, Krzysztof
On Mon, Feb 12, 2024 at 12:25:48PM +0100, Krzysztof Kozlowski wrote: > > Hm, I don't understand how exactly it helps. The GPIO expander has its > own example and as you pointed below, this is basically the same code, > except rw and backlight GPIOs. The hd44780 is a display that is very often used. By people (like me some time ago) not familiar with the nice io expander implementation in Linux. The consequence of that is that you'll find several out-of-tree implementations for this display with i2c out in the wild. So my thought of documenting this (again) at that location is to make it easier for people with a hd44780 with the standard i2c interface to see how it is done in Linux. So I really think it helps. It would have helped me :-) Ralf
On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > On Mon, Feb 12, 2024 at 12:25:48PM +0100, Krzysztof Kozlowski wrote: >> >> Hm, I don't understand how exactly it helps. The GPIO expander has its >> own example and as you pointed below, this is basically the same code, >> except rw and backlight GPIOs. > > The hd44780 is a display that is very often used. > By people (like me some time ago) not familiar with the nice io expander > implementation in Linux. The consequence of that is that you'll find > several out-of-tree implementations for this display with i2c out in the > wild. So my thought of documenting this (again) at that location is to > make it easier for people with a hd44780 with the standard i2c interface > to see how it is done in Linux. GPIO expanders and their usage is nothing specific to this device - other devices also might benefit of them. Or the SoCs which have enough of GPIOs... I really do not understand why do we need expander here and how does it help Anyway, binding examples should not be collection of unrelated solutions, because then we should accept for each device schema several other variations and combinations. Best regards, Krzysztof
On Mon, Feb 12, 2024 at 09:34:24AM +0100, Krzysztof Kozlowski wrote: > Examples of other nodes, like GPIO controller, are redundant and not > really needed in device bindings. .. > - i2c { > - #address-cells = <1>; > - #size-cells = <0>; > > - pcf8574: pcf8574@27 { > - compatible = "nxp,pcf8574"; > - reg = <0x27>; > - gpio-controller; > - #gpio-cells = <2>; > - }; > - }; In patch 3 you updated the lines that have lost their sense due to this one. And I agree with others, please leave this example in place.
On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 12:58, Ralf Schlatterbeck wrote: .. > Anyway, binding examples should not be collection of unrelated > solutions, because then we should accept for each device schema several > other variations and combinations. Is this documented? In any case, you would need to amend your series one way or another.
On 12/02/2024 14:39, Andy Shevchenko wrote: > On Mon, Feb 12, 2024 at 09:34:24AM +0100, Krzysztof Kozlowski wrote: >> Examples of other nodes, like GPIO controller, are redundant and not >> really needed in device bindings. > > ... > >> - i2c { >> - #address-cells = <1>; >> - #size-cells = <0>; >> >> - pcf8574: pcf8574@27 { >> - compatible = "nxp,pcf8574"; >> - reg = <0x27>; >> - gpio-controller; >> - #gpio-cells = <2>; >> - }; >> - }; > > In patch 3 you updated the lines that have lost their sense due to this one. How did they lose it? > And I agree with others, please leave this example in place. What for? Why this binding is special and 99% of others do not need GPIO expander in the example? Best regards, Krzysztof
On 12/02/2024 14:43, Andy Shevchenko wrote: > On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: >> On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > > ... > >> Anyway, binding examples should not be collection of unrelated >> solutions, because then we should accept for each device schema several >> other variations and combinations. > > Is this documented? Yes, writing schema says what the example is. We repeated it multiple times on multiple reviews, we made multiple commits multiple times and I briefly mentioned it also in my talks. Best regards, Krzysztof
On Mon, Feb 12, 2024 at 02:59:02PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 14:43, Andy Shevchenko wrote: > > On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > >> On 12/02/2024 12:58, Ralf Schlatterbeck wrote: .. > >> Anyway, binding examples should not be collection of unrelated > >> solutions, because then we should accept for each device schema several > >> other variations and combinations. > > > > Is this documented? > > Yes, writing schema says what the example is. We repeated it multiple > times on multiple reviews, we made multiple commits multiple times and I > briefly mentioned it also in my talks. Good to know, thanks!
On Mon, Feb 12, 2024 at 02:56:43PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 14:39, Andy Shevchenko wrote: > > On Mon, Feb 12, 2024 at 09:34:24AM +0100, Krzysztof Kozlowski wrote: .. > >> - i2c { > >> - #address-cells = <1>; > >> - #size-cells = <0>; > >> > >> - pcf8574: pcf8574@27 { > >> - compatible = "nxp,pcf8574"; > >> - reg = <0x27>; > >> - gpio-controller; > >> - #gpio-cells = <2>; > >> - }; > >> - }; > > > > In patch 3 you updated the lines that have lost their sense due to this one. > > How did they lose it? Now they are referring to the non-existed node in the example. OTOH, there is already hc595 case... The Q here (as you pointed out that it's better to name nodes in generic way), how these names are okay with the schema (hc595, pcf8574) as being referred to? .. > > And I agree with others, please leave this example in place. > > What for? Why this binding is special and 99% of others do not need GPIO > expander in the example? Some people already tried to explain you their point of view, but I see that: - the unrelated nodes in the schemas are not welcome (as per your talks and documentation); - the current file has other references that have no existing node in the example; - you are DT maintainer, so I believe you know this better. With this, I'm almost (see above question though) satisfied with the series.
On 12/02/2024 15:09, Andy Shevchenko wrote: > On Mon, Feb 12, 2024 at 02:56:43PM +0100, Krzysztof Kozlowski wrote: >> On 12/02/2024 14:39, Andy Shevchenko wrote: >>> On Mon, Feb 12, 2024 at 09:34:24AM +0100, Krzysztof Kozlowski wrote: > > ... > >>>> - i2c { >>>> - #address-cells = <1>; >>>> - #size-cells = <0>; >>>> >>>> - pcf8574: pcf8574@27 { >>>> - compatible = "nxp,pcf8574"; >>>> - reg = <0x27>; >>>> - gpio-controller; >>>> - #gpio-cells = <2>; >>>> - }; >>>> - }; >>> >>> In patch 3 you updated the lines that have lost their sense due to this one. >> >> How did they lose it? > > Now they are referring to the non-existed node in the example. OTOH, there is > already hc595 case... All of the bindings examples do it. It's expected. > > The Q here (as you pointed out that it's better to name nodes in generic way), > how these names are okay with the schema (hc595, pcf8574) as being referred to? They are not OK, although I don't see the name "hc595". There is phandle to the hc595 label, but that's fine. Not a node name. Best regards, Krzysztof
On Mon, Feb 12, 2024 at 03:20:26PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 15:09, Andy Shevchenko wrote: > > On Mon, Feb 12, 2024 at 02:56:43PM +0100, Krzysztof Kozlowski wrote: > >> On 12/02/2024 14:39, Andy Shevchenko wrote: > >>> On Mon, Feb 12, 2024 at 09:34:24AM +0100, Krzysztof Kozlowski wrote: .. > >>>> - i2c { > >>>> - #address-cells = <1>; > >>>> - #size-cells = <0>; > >>>> > >>>> - pcf8574: pcf8574@27 { > >>>> - compatible = "nxp,pcf8574"; > >>>> - reg = <0x27>; > >>>> - gpio-controller; > >>>> - #gpio-cells = <2>; > >>>> - }; > >>>> - }; > >>> > >>> In patch 3 you updated the lines that have lost their sense due to this one. > >> > >> How did they lose it? > > > > Now they are referring to the non-existed node in the example. OTOH, there is > > already hc595 case... > > All of the bindings examples do it. It's expected. > > > > > The Q here (as you pointed out that it's better to name nodes in generic way), > > how these names are okay with the schema (hc595, pcf8574) as being referred to? > > They are not OK, although I don't see the name "hc595". There is phandle > to the hc595 label, but that's fine. Not a node name. Ah, okay, so it's a semantic difference. Thank you for your patience and elaboration!
On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > > GPIO expanders and their usage is nothing specific to this device - > other devices also might benefit of them. Or the SoCs which have enough > of GPIOs... I really do not understand why do we need expander here and > how does it help Can we then at least link the I/O Expander example to the docs of that display? I've documented my experience here: https://blog.runtux.com/posts/2021/01/06/ And at the time there were two out-of-tree implementations. Note that I think that redundancy in code is bad. Not so for documentation. Thanks + kind regards Ralf
Hi Ralf, On Mon, Feb 12, 2024 at 3:40 PM Ralf Schlatterbeck <rsc@runtux.com> wrote: > On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > > On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > > GPIO expanders and their usage is nothing specific to this device - > > other devices also might benefit of them. Or the SoCs which have enough > > of GPIOs... I really do not understand why do we need expander here and > > how does it help > > Can we then at least link the I/O Expander example to the docs of that > display? > I've documented my experience here: > https://blog.runtux.com/posts/2021/01/06/ Any chance you can update the DT overlays to use sugar syntax instead of raw fragments, target{,-path} properties, and __overlay__ subnodes? You can find examples in my DT overlay collection, e.g. https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/renesas-overlays&id=3a41e34a2dd902c7bf74d11254a56190787252b6 > And at the time there were two out-of-tree implementations. Only two? ;-) Gr{oetje,eeting}s, Geert
On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > > On Mon, Feb 12, 2024 at 12:25:48PM +0100, Krzysztof Kozlowski wrote: > >> > >> Hm, I don't understand how exactly it helps. The GPIO expander has its > >> own example and as you pointed below, this is basically the same code, > >> except rw and backlight GPIOs. > > > > The hd44780 is a display that is very often used. > > GPIO expanders and their usage is nothing specific to this device - > other devices also might benefit of them. Or the SoCs which have enough > of GPIOs... I really do not understand why do we need expander here and > how does it help The hd44780 is most often sold together with that specific I/O expander. The idea was to help people with that combination how to get their device working. > Anyway, binding examples should not be collection of unrelated > solutions, because then we should accept for each device schema several > other variations and combinations. The solutions in that case are not unrelated because they document the most-often-used hw combo. I also didn't find any documentation of how to actually *use* the pcf8575 I/O expander. Even Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml has only docs on how to instantiate the device on the i2c bus but not how then to use the I/Os of the chip for something else. So I'd ask again to not remove that piece of useful documentation. And to get somehow philosophic: I think that docs should be didactic, not optimized to the least redundancy. Thanks and kind regards, Ralf
On Mon, Feb 12, 2024 at 02:59:02PM +0100, Krzysztof Kozlowski wrote: > On 12/02/2024 14:43, Andy Shevchenko wrote: > > On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > >> On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > > > > ... > > > >> Anyway, binding examples should not be collection of unrelated > >> solutions, because then we should accept for each device schema several > >> other variations and combinations. > > > > Is this documented? > > Yes, writing schema says what the example is. We repeated it multiple > times on multiple reviews, we made multiple commits multiple times and I > briefly mentioned it also in my talks. While yes, this is the guidance, I think this case has provided enough justification to keep it. Let's move on please. Rob
On Tue, Feb 13, 2024 at 10:19:05AM -0600, Rob Herring wrote: > On Mon, Feb 12, 2024 at 02:59:02PM +0100, Krzysztof Kozlowski wrote: > > On 12/02/2024 14:43, Andy Shevchenko wrote: > > > On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: > > >> On 12/02/2024 12:58, Ralf Schlatterbeck wrote: .. > > >> Anyway, binding examples should not be collection of unrelated > > >> solutions, because then we should accept for each device schema several > > >> other variations and combinations. > > > > > > Is this documented? > > > > Yes, writing schema says what the example is. We repeated it multiple > > times on multiple reviews, we made multiple commits multiple times and I > > briefly mentioned it also in my talks. > > While yes, this is the guidance, I think this case has provided enough > justification to keep it. Let's move on please. Thank you, Rob. Krzysztof, can you send v2, I'll apply it to the tree?
On 13/02/2024 17:43, Andy Shevchenko wrote: > On Tue, Feb 13, 2024 at 10:19:05AM -0600, Rob Herring wrote: >> On Mon, Feb 12, 2024 at 02:59:02PM +0100, Krzysztof Kozlowski wrote: >>> On 12/02/2024 14:43, Andy Shevchenko wrote: >>>> On Mon, Feb 12, 2024 at 02:38:27PM +0100, Krzysztof Kozlowski wrote: >>>>> On 12/02/2024 12:58, Ralf Schlatterbeck wrote: > > ... > >>>>> Anyway, binding examples should not be collection of unrelated >>>>> solutions, because then we should accept for each device schema several >>>>> other variations and combinations. >>>> >>>> Is this documented? >>> >>> Yes, writing schema says what the example is. We repeated it multiple >>> times on multiple reviews, we made multiple commits multiple times and I >>> briefly mentioned it also in my talks. >> >> While yes, this is the guidance, I think this case has provided enough >> justification to keep it. Let's move on please. > > Thank you, Rob. > > Krzysztof, can you send v2, I'll apply it to the tree? Sure. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml index 406a922a714e..73d07f2cb303 100644 --- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml @@ -99,17 +99,7 @@ examples: }; - | #include <dt-bindings/gpio/gpio.h> - i2c { - #address-cells = <1>; - #size-cells = <0>; - pcf8574: pcf8574@27 { - compatible = "nxp,pcf8574"; - reg = <0x27>; - gpio-controller; - #gpio-cells = <2>; - }; - }; hd44780 { compatible = "hit,hd44780"; display-height-chars = <2>;