From 42ccd781bb206804501ff490fd771bb940ca9969 Mon Sep 17 00:00:00 2001 From: Xiubo Li Date: Mon, 13 Jan 2014 11:07:28 +0800 Subject: [PATCH 1/2] of: Fix __of_device_is_available check From IEEE 1275, there defined a standard 'status' property indicating the operational status of one device. The 'status' property has four possible values: 'okay/ok', 'disabled', 'fail' and 'fail-xxx'. If it is absent, that means the status of the device is unknown or okay. The __of_device_is_available checks the state of the 'status' property of a device. If the property is absent or set to 'okay/ok', it returns 1. Otherwise it returns 0. While in __of_device_is_available: > status = of_get_property(device, "status", &statlen); > if (status == NULL) > return 1; The status value returned from 'of_get_property()' will be NULL in two cases: Firstly: the 'device' value (device node) is NULL. Secondly: the 'status' property is actaully not exist. If the device node is NULL, the __of_device_is_available will return true, that will mean the absent state of the 'status' property. So this add the device node check before checking the 'status' property's state, and if the device node is not exist, 0 will be returned. Signed-off-by: Xiubo Li Signed-off-by: Grant Likely --- drivers/of/base.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/base.c b/drivers/of/base.c index f807d0edabf3..ba195fbce4c6 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -415,6 +415,9 @@ static int __of_device_is_available(const struct device_node *device) const char *status; int statlen; + if (!device) + return 0; + status = __of_get_property(device, "status", &statlen); if (status == NULL) return 1; From 2a9330010bea5982a5c6593824bc036bf62d67b7 Mon Sep 17 00:00:00 2001 From: Jason Cooper Date: Tue, 17 Dec 2013 16:59:40 +0000 Subject: [PATCH 2/2] dt/bindings: submitting patches and ABI documents Add some guidance documentation about what to do with device tree bindings and how ABI stability is to be handled. Signed-off-by: Jason Cooper [grant.likely: added some clarification on subsystem binding rules] Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/ABI.txt | 39 +++++++++++++++++++ .../bindings/submitting-patches.txt | 38 ++++++++++++++++++ 2 files changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/ABI.txt create mode 100644 Documentation/devicetree/bindings/submitting-patches.txt diff --git a/Documentation/devicetree/bindings/ABI.txt b/Documentation/devicetree/bindings/ABI.txt new file mode 100644 index 000000000000..d25f8d379680 --- /dev/null +++ b/Documentation/devicetree/bindings/ABI.txt @@ -0,0 +1,39 @@ + + Devicetree (DT) ABI + +I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit + summary document: + + "That still leaves the question of, what does a stable binding look + like? Certainly a stable binding means that a newer kernel will not + break on an older device tree, but that doesn't mean the binding is + frozen for all time. Grant said there are ways to change bindings that + don't result in breakage. For instance, if a new property is added, + then default to the previous behaviour if it is missing. If a binding + truly needs an incompatible change, then change the compatible string + at the same time. The driver can bind against both the old and the + new. These guidelines aren't new, but they desperately need to be + documented." + +II. General binding rules + + 1) Maintainers, don't let perfect be the enemy of good. Don't hold up a + binding because it isn't perfect. + + 2) Use specific compatible strings so that if we need to add a feature (DMA) + in the future, we can create a new compatible string. See I. + + 3) Bindings can be augmented, but the driver shouldn't break when given + the old binding. ie. add additional properties, but don't change the + meaning of an existing property. For drivers, default to the original + behaviour when a newly added property is missing. + + 4) Don't submit bindings for staging or unstable. That will be decided by + the devicetree maintainers *after* discussion on the mailinglist. + +III. Notes + + 1) This document is intended as a general familiarization with the process as + decided at the 2013 Kernel Summit. When in doubt, the current word of the + devicetree maintainers overrules this document. In that situation, a patch + updating this document would be appreciated. diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt new file mode 100644 index 000000000000..042a0273b8ba --- /dev/null +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -0,0 +1,38 @@ + + Submitting devicetree (DT) binding patches + +I. For patch submitters + + 0) Normal patch submission rules from Documentation/SubmittingPatches + applies. + + 1) The Documentation/ portion of the patch should be a separate patch. + + 2) Submit the entire series to the devicetree mailinglist at + + devicetree@vger.kernel.org + +II. For kernel maintainers + + 1) If you aren't comfortable reviewing a given binding, reply to it and ask + the devicetree maintainers for guidance. This will help them prioritize + which ones to review and which ones are ok to let go. + + 2) For driver (not subsystem) bindings: If you are comfortable with the + binding, and it hasn't received an Acked-by from the devicetree + maintainers after a few weeks, go ahead and take it. + + Subsystem bindings (anything affecting more than a single device) + then getting a devicetree maintainer to review it is required. + + 3) For a series going though multiple trees, the binding patch should be + kept with the driver using the binding. + +III. Notes + + 0) Please see ...bindings/ABI.txt for details regarding devicetree ABI. + + 1) This document is intended as a general familiarization with the process as + decided at the 2013 Kernel Summit. When in doubt, the current word of the + devicetree maintainers overrules this document. In that situation, a patch + updating this document would be appreciated.