Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware

[Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>]

On 03/12/15 15:08, Rob Herring wrote:
> On Thu, Dec 3, 2015 at 4:14 AM, Martyn Welch
> <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> 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 <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> Signed-off-by: Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
>>>> ---
>>>>    .../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 @@
>>
>>
>> <snip>
>>
>>>> +
>>>> +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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html