Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760279AbbLCQL0 (ORCPT ); Thu, 3 Dec 2015 11:11:26 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:57463 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752320AbbLCQLY (ORCPT ); Thu, 3 Dec 2015 11:11:24 -0500 Message-ID: <566069A8.1070002@collabora.co.uk> Date: Thu, 03 Dec 2015 16:11:20 +0000 From: Martyn Welch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Rob Herring CC: Olof Johansson , "linux-kernel@vger.kernel.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , Frank Rowand , Grant Likely Subject: Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware References: <1448997171-7064-1-git-send-email-martyn.welch@collabora.co.uk> <1448997171-7064-2-git-send-email-martyn.welch@collabora.co.uk> <20151202151552.GA11101@rob-hp-laptop> <56601611.6010800@collabora.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4520 Lines: 141 On 03/12/15 15:08, Rob Herring wrote: > On Thu, Dec 3, 2015 at 4:14 AM, Martyn Welch > wrote: >> >> On 02/12/15 15:15, Rob Herring wrote: >>> >>> On Tue, Dec 01, 2015 at 07:12:49PM +0000, Martyn Welch wrote: >>>> >>>> This patch adds documentation for the chromeos-firmware binding. >>>> >>>> Cc: Rob Herring >>>> Cc: Pawel Moll >>>> Cc: Mark Rutland >>>> Cc: Ian Campbell >>>> Cc: Kumar Gala >>>> Cc: devicetree@vger.kernel.org >>>> Signed-off-by: Martyn Welch >>>> --- >>>> .../devicetree/bindings/misc/chromeos-firmware.txt | 27 >>>> ++++++++++++++++++++++ >>> >>> >>> bindings/firmware/ please. >>> >>>> 1 file changed, 27 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/misc/chromeos-firmware.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt >>>> b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt >>>> new file mode 100644 >>>> index 0000000..8240611 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt >>>> @@ -0,0 +1,27 @@ >> >> >> >> >>>> + >>>> +Each signal is represented as a sub-node of "chromeos_firmware": >>>> +Subnode properties: >>>> + >>>> + - gpios: OF device-tree gpio specification. >>>> + >>>> +Example nodes: >>>> + >>>> + chromeos_firmware { >>> >>> >>> This should go under /firmware >>> >> >> I've changed this to be: >> >> firmware { >> chromeos { >> ... >> }; >> ]; >> >> Which I generally accept (assuming this is considered a part of the >> firmware) as a better way to represent this in the device tree, however this >> has the nasty side effect of causing the device tree parsing to avoid >> parsing the chromeos child and seeing it's compatible property (as the >> firmware node isn't a bus), resulting in the probe routine not being called. >> >> If I add a 'compatible = "simple-bus"' property to the firmware node it >> works, but this doesn't seem quite right as I believe "simple-bus" is >> defined as a "simple memory mapped bus". >> >> I /could/ rewrite the initialisation to call of_find_compatible_node(), but >> this seems rather hacky and inefficient. I can think of 2 other ways this >> could be resolved: >> >> (1) As this is only tangentially related to firmware, I rename it something >> like "chromeos-signals" and make it it's own node. In essence this driver >> provides a mechanism built on top of specific GPIO (ala gpio-keys seems to >> be, after-all this has a similar use of resources to that). > > I'm starting to fail to understand the relationship to firmware here... > > gpio-keys are at least a thing (being a key or set of keys). Your > grouping is a rather random collection of GPIOs. Maybe you need > "gpio-switch" binding and then the function would be "label" property. > So, something like this: gpio-switch { compatible = "gpio-switch"; pinctrl-names = "default"; pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>; write-protect { label = "write-protect"; gpios = <&gpx3 0 GPIO_ACTIVE_LOW>; read-only; }; developer-switch { label = "developer-switch"; gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>; read-only; }; recovery-switch { label = "recovery-switch"; gpios = <&gpx0 7 GPIO_ACTIVE_LOW>; read-only; }; }; (Making it much more generic in the process.) >> (2) Add a compatible string something like 'compatible="logical-group";' to >> the firmware node and add that too the bus matching logic. This would have >> the advantage of solving this in the general case (I guess there are other >> instances where a grouping of things more logically rather than physically >> connected would ideally be grouped together), though I expect there may be >> some strong views regarding this approach. > > Why do you need them grouped? > That's effectively what is achieved by putting this (and I assume anything else considered "firmware" under a firmware node isn't it? (or and I miss-understanding your request?) I think it is a moot point, I'll rework as you've suggested. Martyn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/