Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property
Hello Mark, On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote: Hello Lee, Thanks a lot for your feedback. On 07/20/2015 10:10 AM, Lee Jones wrote: On Fri, 17 Jul 2015, Javier Martinez Canillas wrote: The regulator-compatible property from the regulator DT binding was deprecated. But the max77686 DT binding doc still suggest to use it instead of the regulator node name's which is the correct approach. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com By convention shouldn't this be buck@1, or something? Need Mark to look at this. That's a very good question, the ePAPR doc says: The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree This PMIC uses a single I2C address for all the regulators and these are controlled by writing to different I2C register addresses. So the regulator nodes don't have a reg property in this case. By looking at other regulators bindings, besides the generic regulator.txt and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use the node-name@unit-address convention mentioned in the ePAPR document. AFAICT all these are for regulators that are actually in different addresses but I could be wrong so let's see what Mark says. Any opinions on this? thanks a lot and best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property
On Mon, Jul 27, 2015 at 12:28:07PM +0200, Javier Martinez Canillas wrote: On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote: This PMIC uses a single I2C address for all the regulators and these are controlled by writing to different I2C register addresses. So the regulator nodes don't have a reg property in this case. By looking at other regulators bindings, besides the generic regulator.txt and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use the node-name@unit-address convention mentioned in the ePAPR document. AFAICT all these are for regulators that are actually in different addresses but I could be wrong so let's see what Mark says. Any opinions on this? I just don't care, this is just syntactic noise which has no practical meaning as far as I can tell. signature.asc Description: Digital signature
Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property
Hello Mark, On 07/27/2015 12:33 PM, Mark Brown wrote: On Mon, Jul 27, 2015 at 12:28:07PM +0200, Javier Martinez Canillas wrote: On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote: This PMIC uses a single I2C address for all the regulators and these are controlled by writing to different I2C register addresses. So the regulator nodes don't have a reg property in this case. By looking at other regulators bindings, besides the generic regulator.txt and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use the node-name@unit-address convention mentioned in the ePAPR document. AFAICT all these are for regulators that are actually in different addresses but I could be wrong so let's see what Mark says. Any opinions on this? I just don't care, this is just syntactic noise which has no practical meaning as far as I can tell. thanks, I'll then leave the regulator's node name as is in the patch since that is consistent with the rest of the regulator DT bindings. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property
On Fri, 17 Jul 2015, Javier Martinez Canillas wrote: The regulator-compatible property from the regulator DT binding was deprecated. But the max77686 DT binding doc still suggest to use it instead of the regulator node name's which is the correct approach. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com By convention shouldn't this be buck@1, or something? Need Mark to look at this. --- Changes in v2: - Add Krzysztof Kozlowski Reviewed-by tag in patch #1. Documentation/devicetree/bindings/mfd/max77686.txt | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt index 163bd81a4607..8221102d3fc2 100644 --- a/Documentation/devicetree/bindings/mfd/max77686.txt +++ b/Documentation/devicetree/bindings/mfd/max77686.txt @@ -26,7 +26,7 @@ Optional node: }; refer Documentation/devicetree/bindings/regulator/regulator.txt - The regulator-compatible property of regulator should initialized with string + The regulator node's name should be initialized with a string to get matched with their hardware counterparts as follow: -LDOn : for LDOs, where n can lie in range 1 to 26. @@ -55,16 +55,14 @@ Example: reg = 0x09; voltage-regulators { - ldo11_reg { - regulator-compatible = LDO11; + ldo11_reg: LDO11 { regulator-name = vdd_ldo11; regulator-min-microvolt = 190; regulator-max-microvolt = 190; regulator-always-on; }; - buck1_reg { - regulator-compatible = BUCK1; + buck1_reg: BUCK1 { regulator-name = vdd_mif; regulator-min-microvolt = 95; regulator-max-microvolt = 130; @@ -72,8 +70,7 @@ Example: regulator-boot-on; }; - buck9_reg { - regulator-compatible = BUCK9; + buck9_reg: BUCK9 { regulator-name = CAM_ISP_CORE_1.2V; regulator-min-microvolt = 100; regulator-max-microvolt = 120; -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property
Hello Lee, Thanks a lot for your feedback. On 07/20/2015 10:10 AM, Lee Jones wrote: On Fri, 17 Jul 2015, Javier Martinez Canillas wrote: The regulator-compatible property from the regulator DT binding was deprecated. But the max77686 DT binding doc still suggest to use it instead of the regulator node name's which is the correct approach. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com By convention shouldn't this be buck@1, or something? Need Mark to look at this. That's a very good question, the ePAPR doc says: The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree This PMIC uses a single I2C address for all the regulators and these are controlled by writing to different I2C register addresses. So the regulator nodes don't have a reg property in this case. By looking at other regulators bindings, besides the generic regulator.txt and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use the node-name@unit-address convention mentioned in the ePAPR document. AFAICT all these are for regulators that are actually in different addresses but I could be wrong so let's see what Mark says. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html