2014-02-12 13:35:11

by Michal Simek

Subject: [PATCH v3 0/11] Xilinx watchdog changes

Attachments:

2014-02-12 13:35:20

by Michal Simek

Subject: [PATCH v3 01/11] watchdog: xilinx: Convert driver to the watchdog framework

Attachments:

2014-02-12 13:35:29

by Michal Simek

Subject: [PATCH v3 03/11] watchdog: xilinx: Simplify probe and remove functions

Attachments:

2014-02-12 13:36:01

by Michal Simek

Subject: [PATCH v3 04/11] watchdog: xilinx: Move no_timeout to probe function

Attachments:

2014-02-12 13:36:38

by Michal Simek

Subject: [PATCH v3 02/11] watchdog: xilinx: Move control_status_reg to functions

Attachments:

2014-02-12 13:41:45

by Michal Simek

Subject: [PATCH v3 05/11] watchdog: xilinx: Allocate private structure per device

Attachments:

2014-02-12 13:41:52

by Michal Simek

Subject: [PATCH v3 06/11] watchdog: xilinx: Fix all printk messages

Attachments:

2014-02-12 13:42:12

by Michal Simek

Subject: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

Attachments:

2014-02-12 13:42:18

by Michal Simek

Subject: [PATCH v3 08/11] watchdog: xilinx: Use correct comment indentation

Attachments:

2014-02-12 13:42:25

by Michal Simek

Subject: [PATCH v3 10/11] watchdog: xilinx: Enable this driver for Zynq

Attachments:

2014-02-12 13:42:32

by Michal Simek

Subject: [PATCH v3 11/11] watchdog: xilinx: Remove no_timeout variable

Attachments:

2014-02-12 13:43:27

by Michal Simek

Subject: [PATCH v3 09/11] watchdog: xilinx: Add missing binding

Attachments:

2014-02-12 17:15:17

by Guenter Roeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
> Use of_property_read_u32 functions to clean probe function.
>
> Signed-off-by: Michal Simek <[email protected]>
> Reviewed-by: Guenter Roeck <[email protected]>
> ---
>
> Changes in v3:
> - Remove one if checking and use variable directly
>

Looks good.

Another comment/remark.

>
> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
> - "clock-frequency", NULL);
> -
> - if (pfreq == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
> + if (rc) {
> dev_warn(&pdev->dev,
> "The watchdog clock frequency cannot be obtained\n");
> no_timeout = true;
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-interval", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> + &xdev->wdt_interval);
> + if (rc) {
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-interval\" not found\n");
> no_timeout = true;
> - } else {
> - xdev->wdt_interval = *tmptr;
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-enable-once", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> + &enable_once);
> + if (rc)
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-enable-once\" not found\n");
> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
> - }

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.

Thanks,
Guenter

2014-02-22 18:44:25

by Wim Van Sebroeck

Subject: Re: [PATCH v3 10/11] watchdog: xilinx: Enable this driver for Zynq

Hi Michal,

> Enable this driver for Zynq.
> Move it to architecture independent Kconfig part.
>
> Signed-off-by: Michal Simek <[email protected]>
> Reviewed-by: Guenter Roeck <[email protected]>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> Build tested by zero day testing system.
> ---
> drivers/watchdog/Kconfig | 22 +++++++++-------------
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 9db5d3c..6120403 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -111,6 +111,15 @@ config WM8350_WATCHDOG
> Support for the watchdog in the WM8350 AudioPlus PMIC. When
> the watchdog triggers the system will be reset.
>
> +config XILINX_WATCHDOG
> + tristate "Xilinx Watchdog timer"
> + select WATCHDOG_CORE
> + help
> + Watchdog driver for the xps_timebase_wdt ip core.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called of_xilinx_wdt.
> +
> # ALPHA Architecture
>
> # ARM Architecture
> @@ -1022,19 +1031,6 @@ config M54xx_WATCHDOG
>
> # MicroBlaze Architecture
>
> -config XILINX_WATCHDOG
> - tristate "Xilinx Watchdog timer"
> - depends on MICROBLAZE
> - select WATCHDOG_CORE
> - ---help---
> - Watchdog driver for the xps_timebase_wdt ip core.
> -
> - IMPORTANT: The xps_timebase_wdt parent must have the property
> - "clock-frequency" at device tree.
> -
> - To compile this driver as a module, choose M here: the
> - module will be called of_xilinx_wdt.
> -
> # MIPS Architecture
>
> config ATH79_WDT
> --
> 1.8.2.3
>

Are we sure that we don't need an additional dependancy (like depends on HAS_IOMEM) to not have issues with other architectures?

Kind regards,
Wim.

2014-02-22 18:46:09

by Wim Van Sebroeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

Hi All,

> Hi Michal,
>
> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
> > Use of_property_read_u32 functions to clean probe function.
> >
> > Signed-off-by: Michal Simek <[email protected]>
> > Reviewed-by: Guenter Roeck <[email protected]>
> > ---
> >
> > Changes in v3:
> > - Remove one if checking and use variable directly
> >
>
> Looks good.
>
> Another comment/remark.
>
> >
> > - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
> > - "clock-frequency", NULL);
> > -
> > - if (pfreq == NULL) {
> > + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
> > + if (rc) {
> > dev_warn(&pdev->dev,
> > "The watchdog clock frequency cannot be obtained\n");
> > no_timeout = true;
> > }
> >
> > - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> > - "xlnx,wdt-interval", NULL);
> > - if (tmptr == NULL) {
> > + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> > + &xdev->wdt_interval);
> > + if (rc) {
> > dev_warn(&pdev->dev,
> > "Parameter \"xlnx,wdt-interval\" not found\n");
> > no_timeout = true;
> > - } else {
> > - xdev->wdt_interval = *tmptr;
> > }
> >
> > - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> > - "xlnx,wdt-enable-once", NULL);
> > - if (tmptr == NULL) {
> > + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> > + &enable_once);
> > + if (rc)
> > dev_warn(&pdev->dev,
> > "Parameter \"xlnx,wdt-enable-once\" not found\n");
> > - watchdog_set_nowayout(xilinx_wdt_wdd, true);
> > - }
>
> All the above properties are optional. Is a warning really
> warranted in this case ? I usually associate a warning with
> something that is wrong, which is not the case here.
>
> I would encourage you to drop those warnings, but that should be
> a separate patch.

I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.

Kind regards,
Wim.

2014-02-22 20:42:33

by Guenter Roeck

Subject: Re: [PATCH v3 10/11] watchdog: xilinx: Enable this driver for Zynq

On 02/22/2014 10:44 AM, Wim Van Sebroeck wrote:
> Hi Michal,
>
>> Enable this driver for Zynq.
>> Move it to architecture independent Kconfig part.
>>
>> Signed-off-by: Michal Simek <[email protected]>
>> Reviewed-by: Guenter Roeck <[email protected]>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> Build tested by zero day testing system.
>> ---
>> drivers/watchdog/Kconfig | 22 +++++++++-------------
>> 1 file changed, 9 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 9db5d3c..6120403 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -111,6 +111,15 @@ config WM8350_WATCHDOG
>> Support for the watchdog in the WM8350 AudioPlus PMIC. When
>> the watchdog triggers the system will be reset.
>>
>> +config XILINX_WATCHDOG
>> + tristate "Xilinx Watchdog timer"
>> + select WATCHDOG_CORE
>> + help
>> + Watchdog driver for the xps_timebase_wdt ip core.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called of_xilinx_wdt.
>> +
>> # ALPHA Architecture
>>
>> # ARM Architecture
>> @@ -1022,19 +1031,6 @@ config M54xx_WATCHDOG
>>
>> # MicroBlaze Architecture
>>
>> -config XILINX_WATCHDOG
>> - tristate "Xilinx Watchdog timer"
>> - depends on MICROBLAZE
>> - select WATCHDOG_CORE
>> - ---help---
>> - Watchdog driver for the xps_timebase_wdt ip core.
>> -
>> - IMPORTANT: The xps_timebase_wdt parent must have the property
>> - "clock-frequency" at device tree.
>> -
>> - To compile this driver as a module, choose M here: the
>> - module will be called of_xilinx_wdt.
>> -
>> # MIPS Architecture
>>
>> config ATH79_WDT
>> --
>> 1.8.2.3
>>
>
> Are we sure that we don't need an additional dependancy (like depends on HAS_IOMEM) to not have issues with other architectures?
>

Hi Wim,

Doesn't look like it. I have the series in my build test and did not
see any failures because of it. See http://server.roeck-us.net:8010/builders,
branch watchdog-next.

Which reminds me that I wanted to reparent the branch to 3.14-rc3.
I just did that; you should be able to see build results in a couple
of hours.

Guenter

2014-02-22 22:19:10

by Alejandro Cabrera

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
> Hi All,
>
>> Hi Michal,
>>
>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>> Use of_property_read_u32 functions to clean probe function.
>>>
>>> Signed-off-by: Michal Simek<[email protected]>
>>> Reviewed-by: Guenter Roeck<[email protected]>
>>> ---
>>>
>>> Changes in v3:
>>> - Remove one if checking and use variable directly
>>>
>> Looks good.
>>
>> Another comment/remark.
>>
>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>> - "clock-frequency", NULL);
>>> -
>>> - if (pfreq == NULL) {
>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>> + if (rc) {
>>> dev_warn(&pdev->dev,
>>> "The watchdog clock frequency cannot be obtained\n");
>>> no_timeout = true;
>>> }
>>>
>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>> - "xlnx,wdt-interval", NULL);
>>> - if (tmptr == NULL) {
>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>> + &xdev->wdt_interval);
>>> + if (rc) {
>>> dev_warn(&pdev->dev,
>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>> no_timeout = true;
>>> - } else {
>>> - xdev->wdt_interval = *tmptr;
>>> }
>>>
>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>> - "xlnx,wdt-enable-once", NULL);
>>> - if (tmptr == NULL) {
>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>> + &enable_once);
>>> + if (rc)
>>> dev_warn(&pdev->dev,
>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>> - }
>> All the above properties are optional. Is a warning really
>> warranted in this case ? I usually associate a warning with
>> something that is wrong, which is not the case here.
>>
>> I would encourage you to drop those warnings, but that should be
>> a separate patch.
> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
Hi

I support Michal intention, I think it is a warning because device tree
blob must have the "xlnx,wdt-enable-once" property specified in order to
allow the system to be sure of the real value of this property. In
addition to, this warning can be helpful to detect a wrong device tree
specification.

Best regards
Alejandro



50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu

2014-02-22 23:18:19

by Guenter Roeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>> Hi All,
>>
>>> Hi Michal,
>>>
>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>> Use of_property_read_u32 functions to clean probe function.
>>>>
>>>> Signed-off-by: Michal Simek<[email protected]>
>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> - Remove one if checking and use variable directly
>>>>
>>> Looks good.
>>>
>>> Another comment/remark.
>>>
>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>> - "clock-frequency", NULL);
>>>> -
>>>> - if (pfreq == NULL) {
>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>>> + if (rc) {
>>>> dev_warn(&pdev->dev,
>>>> "The watchdog clock frequency cannot be obtained\n");
>>>> no_timeout = true;
>>>> }
>>>>
>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>> - "xlnx,wdt-interval", NULL);
>>>> - if (tmptr == NULL) {
>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>>> + &xdev->wdt_interval);
>>>> + if (rc) {
>>>> dev_warn(&pdev->dev,
>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>> no_timeout = true;
>>>> - } else {
>>>> - xdev->wdt_interval = *tmptr;
>>>> }
>>>>
>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>> - "xlnx,wdt-enable-once", NULL);
>>>> - if (tmptr == NULL) {
>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>>> + &enable_once);
>>>> + if (rc)
>>>> dev_warn(&pdev->dev,
>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>> - }
>>> All the above properties are optional. Is a warning really
>>> warranted in this case ? I usually associate a warning with
>>> something that is wrong, which is not the case here.
>>>
>>> I would encourage you to drop those warnings, but that should be
>>> a separate patch.
>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
> Hi
>
> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
>

The dt documentation states that the properties are optional.

Optional properties:
- clock-frequency : Frequency of clock in Hz
- xlnx,wdt-enable-once : 0 - Watchdog can be restarted
1 - Watchdog can be enabled just once
- xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
<val> is integer from 8 to 31.

This clearly conflicts with your statement. An optional property
is just that, optional. If it warrants a warning, it must
not be optional. If you claim that not providing the properties
would be "wrong", why are they defined as optional ?
What is your definition of "wrong" and "must have" ?
How do you expect anyone to know that omitting those
"optional" properties is by some definition "wrong" ?

Guenter

2014-02-23 00:56:35

by Alejandro Cabrera

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 22/2/2014 3:18 PM, Guenter Roeck wrote:
> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>> Hi All,
>>>
>>>> Hi Michal,
>>>>
>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>
>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>> ---
>>>>>
>>>>> Changes in v3:
>>>>> - Remove one if checking and use variable directly
>>>>>
>>>> Looks good.
>>>>
>>>> Another comment/remark.
>>>>
>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>> - "clock-frequency", NULL);
>>>>> -
>>>>> - if (pfreq == NULL) {
>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>> "clock-frequency",&pfreq);
>>>>> + if (rc) {
>>>>> dev_warn(&pdev->dev,
>>>>> "The watchdog clock frequency cannot be obtained\n");
>>>>> no_timeout = true;
>>>>> }
>>>>>
>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>> - "xlnx,wdt-interval", NULL);
>>>>> - if (tmptr == NULL) {
>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>> "xlnx,wdt-interval",
>>>>> + &xdev->wdt_interval);
>>>>> + if (rc) {
>>>>> dev_warn(&pdev->dev,
>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>> no_timeout = true;
>>>>> - } else {
>>>>> - xdev->wdt_interval = *tmptr;
>>>>> }
>>>>>
>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>> - if (tmptr == NULL) {
>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>> "xlnx,wdt-enable-once",
>>>>> + &enable_once);
>>>>> + if (rc)
>>>>> dev_warn(&pdev->dev,
>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>> - }
>>>> All the above properties are optional. Is a warning really
>>>> warranted in this case ? I usually associate a warning with
>>>> something that is wrong, which is not the case here.
>>>>
>>>> I would encourage you to drop those warnings, but that should be
>>>> a separate patch.
>>> I agree with Guenter: these are not really warnings. Seperate patch
>>> is thus welcome.
>> Hi
>>
>> I support Michal intention, I think it is a warning because device
>> tree blob must have the "xlnx,wdt-enable-once" property specified in
>> order to allow the system to be sure of the real value of this
>> property. In addition to, this warning can be helpful to detect a
>> wrong device tree specification.
>>
>
> The dt documentation states that the properties are optional.
>
> Optional properties:
> - clock-frequency : Frequency of clock in Hz
> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
> 1 - Watchdog can be enabled just once
> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock
> cycles,
> <val> is integer from 8 to 31.
>
> This clearly conflicts with your statement. An optional property
> is just that, optional. If it warrants a warning, it must
> not be optional. If you claim that not providing the properties
> would be "wrong", why are they defined as optional ?
Hi Guenter

I didn't know that these properties was classified as optional...
I think that they should not be, because all xilinx watchog devices (at
least for microblaze processor)
have these properties defined in theirs MPD files and theirs values can
be obtained during the
hardware specification to device tree conversion.
> What is your definition of "wrong" and "must have" ?
what I mean for "must have" is: if these properties can be obtained
for all xilinx watchdog devices they must be present in the device tree
because they allows
the system (linux/user) to know exactly how a watchdog device is configured.
Because these properties always can be obtained from hardware design
there is no
reason to leave them out from the device tree. This is why I consider
that a device tree without
these properties should be considered as "wrong" device tree.
> How do you expect anyone to know that omitting those
> "optional" properties is by some definition "wrong" ?
I'm agree with you.
Maybe these properties shouldn't be optional.
For example suppose that "xlnx,wdt-enable-once" is missing in the device
tree,
when a watchdog daemon ask for this property what is the obtained value ?
Independently of this value, why do not warn the user about this missing
property
when it can always be in the device tree ?

Regards
Alejandro




50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu

2014-02-23 01:36:36

by Guenter Roeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>> Hi All,
>>>>
>>>>> Hi Michal,
>>>>>
>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>
>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>> ---
>>>>>>
>>>>>> Changes in v3:
>>>>>> - Remove one if checking and use variable directly
>>>>>>
>>>>> Looks good.
>>>>>
>>>>> Another comment/remark.
>>>>>
>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>> - "clock-frequency", NULL);
>>>>>> -
>>>>>> - if (pfreq == NULL) {
>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>>>>> + if (rc) {
>>>>>> dev_warn(&pdev->dev,
>>>>>> "The watchdog clock frequency cannot be obtained\n");
>>>>>> no_timeout = true;
>>>>>> }
>>>>>>
>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>> - if (tmptr == NULL) {
>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>>>>> + &xdev->wdt_interval);
>>>>>> + if (rc) {
>>>>>> dev_warn(&pdev->dev,
>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>> no_timeout = true;
>>>>>> - } else {
>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>> }
>>>>>>
>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>> - if (tmptr == NULL) {
>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>>>>> + &enable_once);
>>>>>> + if (rc)
>>>>>> dev_warn(&pdev->dev,
>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>> - }
>>>>> All the above properties are optional. Is a warning really
>>>>> warranted in this case ? I usually associate a warning with
>>>>> something that is wrong, which is not the case here.
>>>>>
>>>>> I would encourage you to drop those warnings, but that should be
>>>>> a separate patch.
>>>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
>>> Hi
>>>
>>> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
>>>
>>
>> The dt documentation states that the properties are optional.
>>
>> Optional properties:
>> - clock-frequency : Frequency of clock in Hz
>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>> 1 - Watchdog can be enabled just once
>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
>> <val> is integer from 8 to 31.
>>
>> This clearly conflicts with your statement. An optional property
>> is just that, optional. If it warrants a warning, it must
>> not be optional. If you claim that not providing the properties
>> would be "wrong", why are they defined as optional ?
> Hi Guenter
>
> I didn't know that these properties was classified as optional...
> I think that they should not be, because all xilinx watchog devices (at least for microblaze processor)
> have these properties defined in theirs MPD files and theirs values can be obtained during the
> hardware specification to device tree conversion.
>> What is your definition of "wrong" and "must have" ?
> what I mean for "must have" is: if these properties can be obtained
> for all xilinx watchdog devices they must be present in the device tree because they allows
> the system (linux/user) to know exactly how a watchdog device is configured.
> Because these properties always can be obtained from hardware design there is no
> reason to leave them out from the device tree. This is why I consider that a device tree without
> these properties should be considered as "wrong" device tree.
>> How do you expect anyone to know that omitting those
>> "optional" properties is by some definition "wrong" ?
> I'm agree with you.
> Maybe these properties shouldn't be optional.
> For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
> when a watchdog daemon ask for this property what is the obtained value ?
> Independently of this value, why do not warn the user about this missing property
> when it can always be in the device tree ?
>

Really, this line of argument doesn't make any sense to me.
"xlnx,wdt-enable-once", for example, is a boolean and means
that the watchdog, when enabled, can not be stopped. It defaults
to false, and thus is inherently optional. Making it mandatory
doesn't really add any value.

Similar, the driver choses defaults for the other values.
If that is incorrect, it should not do it.

Really, something is very fishy here. Either the properties are
optional or they are not. If they are optional, the driver should
accept the fact silently. If they are mandatory, the driver should
act accordingly and bail out if the attributes are not there.

You can not have it both ways. I am close to recommending
that Wim should not accept this driver until that is sorted out.

Guenter

2014-02-23 03:17:52

by Alejandro Cabrera

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 22/2/2014 5:36 PM, Guenter Roeck wrote:
> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>> Hi All,
>>>>>
>>>>>> Hi Michal,
>>>>>>
>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>
>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>> ---
>>>>>>>
>>>>>>> Changes in v3:
>>>>>>> - Remove one if checking and use variable directly
>>>>>>>
>>>>>> Looks good.
>>>>>>
>>>>>> Another comment/remark.
>>>>>>
>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>> - "clock-frequency", NULL);
>>>>>>> -
>>>>>>> - if (pfreq == NULL) {
>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>> "clock-frequency",&pfreq);
>>>>>>> + if (rc) {
>>>>>>> dev_warn(&pdev->dev,
>>>>>>> "The watchdog clock frequency cannot be
>>>>>>> obtained\n");
>>>>>>> no_timeout = true;
>>>>>>> }
>>>>>>>
>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>> - if (tmptr == NULL) {
>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>> "xlnx,wdt-interval",
>>>>>>> + &xdev->wdt_interval);
>>>>>>> + if (rc) {
>>>>>>> dev_warn(&pdev->dev,
>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>> no_timeout = true;
>>>>>>> - } else {
>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>> }
>>>>>>>
>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>> - if (tmptr == NULL) {
>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>> "xlnx,wdt-enable-once",
>>>>>>> + &enable_once);
>>>>>>> + if (rc)
>>>>>>> dev_warn(&pdev->dev,
>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>> - }
>>>>>> All the above properties are optional. Is a warning really
>>>>>> warranted in this case ? I usually associate a warning with
>>>>>> something that is wrong, which is not the case here.
>>>>>>
>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>> a separate patch.
>>>>> I agree with Guenter: these are not really warnings. Seperate
>>>>> patch is thus welcome.
>>>> Hi
>>>>
>>>> I support Michal intention, I think it is a warning because device
>>>> tree blob must have the "xlnx,wdt-enable-once" property specified
>>>> in order to allow the system to be sure of the real value of this
>>>> property. In addition to, this warning can be helpful to detect a
>>>> wrong device tree specification.
>>>>
>>>
>>> The dt documentation states that the properties are optional.
>>>
>>> Optional properties:
>>> - clock-frequency : Frequency of clock in Hz
>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>> 1 - Watchdog can be enabled just once
>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock
>>> cycles,
>>> <val> is integer from 8 to 31.
>>>
>>> This clearly conflicts with your statement. An optional property
>>> is just that, optional. If it warrants a warning, it must
>>> not be optional. If you claim that not providing the properties
>>> would be "wrong", why are they defined as optional ?
>> Hi Guenter
>>
>> I didn't know that these properties was classified as optional...
>> I think that they should not be, because all xilinx watchog devices
>> (at least for microblaze processor)
>> have these properties defined in theirs MPD files and theirs values
>> can be obtained during the
>> hardware specification to device tree conversion.
>>> What is your definition of "wrong" and "must have" ?
>> what I mean for "must have" is: if these properties can be obtained
>> for all xilinx watchdog devices they must be present in the device
>> tree because they allows
>> the system (linux/user) to know exactly how a watchdog device is
>> configured.
>> Because these properties always can be obtained from hardware design
>> there is no
>> reason to leave them out from the device tree. This is why I consider
>> that a device tree without
>> these properties should be considered as "wrong" device tree.
>>> How do you expect anyone to know that omitting those
>>> "optional" properties is by some definition "wrong" ?
>> I'm agree with you.
>> Maybe these properties shouldn't be optional.
>> For example suppose that "xlnx,wdt-enable-once" is missing in the
>> device tree,
>> when a watchdog daemon ask for this property what is the obtained
>> value ?
>> Independently of this value, why do not warn the user about this
>> missing property
>> when it can always be in the device tree ?
>>
>
> Really, this line of argument doesn't make any sense to me.
> "xlnx,wdt-enable-once", for example, is a boolean and means
> that the watchdog, when enabled, can not be stopped. It defaults
> to false, and thus is inherently optional. Making it mandatory
> doesn't really add any value.
>

If the device has been configured with wdt-enable-once=true
and the device tree doesn't have this property then a watchdog daemon
would see it as "false" because it is the default making the system to
misbehave...
A warning during driver loading could help user to identify the problem.

Making these properties as mandatory and warn where any of them
are not in device tree may be helpful.

Alejandro



50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu

2014-02-23 03:44:16

by Guenter Roeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>>> Hi All,
>>>>>>
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>>
>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes in v3:
>>>>>>>> - Remove one if checking and use variable directly
>>>>>>>>
>>>>>>> Looks good.
>>>>>>>
>>>>>>> Another comment/remark.
>>>>>>>
>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>> - "clock-frequency", NULL);
>>>>>>>> -
>>>>>>>> - if (pfreq == NULL) {
>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>>>>>>> + if (rc) {
>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>> "The watchdog clock frequency cannot be obtained\n");
>>>>>>>> no_timeout = true;
>>>>>>>> }
>>>>>>>>
>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>>> - if (tmptr == NULL) {
>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>>>>>>> + &xdev->wdt_interval);
>>>>>>>> + if (rc) {
>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>>> no_timeout = true;
>>>>>>>> - } else {
>>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>>> }
>>>>>>>>
>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>>> - if (tmptr == NULL) {
>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>>>>>>> + &enable_once);
>>>>>>>> + if (rc)
>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>>> - }
>>>>>>> All the above properties are optional. Is a warning really
>>>>>>> warranted in this case ? I usually associate a warning with
>>>>>>> something that is wrong, which is not the case here.
>>>>>>>
>>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>>> a separate patch.
>>>>>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
>>>>> Hi
>>>>>
>>>>> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
>>>>>
>>>>
>>>> The dt documentation states that the properties are optional.
>>>>
>>>> Optional properties:
>>>> - clock-frequency : Frequency of clock in Hz
>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>>> 1 - Watchdog can be enabled just once
>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
>>>> <val> is integer from 8 to 31.
>>>>
>>>> This clearly conflicts with your statement. An optional property
>>>> is just that, optional. If it warrants a warning, it must
>>>> not be optional. If you claim that not providing the properties
>>>> would be "wrong", why are they defined as optional ?
>>> Hi Guenter
>>>
>>> I didn't know that these properties was classified as optional...
>>> I think that they should not be, because all xilinx watchog devices (at least for microblaze processor)
>>> have these properties defined in theirs MPD files and theirs values can be obtained during the
>>> hardware specification to device tree conversion.
>>>> What is your definition of "wrong" and "must have" ?
>>> what I mean for "must have" is: if these properties can be obtained
>>> for all xilinx watchdog devices they must be present in the device tree because they allows
>>> the system (linux/user) to know exactly how a watchdog device is configured.
>>> Because these properties always can be obtained from hardware design there is no
>>> reason to leave them out from the device tree. This is why I consider that a device tree without
>>> these properties should be considered as "wrong" device tree.
>>>> How do you expect anyone to know that omitting those
>>>> "optional" properties is by some definition "wrong" ?
>>> I'm agree with you.
>>> Maybe these properties shouldn't be optional.
>>> For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
>>> when a watchdog daemon ask for this property what is the obtained value ?
>>> Independently of this value, why do not warn the user about this missing property
>>> when it can always be in the device tree ?
>>>
>>
>> Really, this line of argument doesn't make any sense to me.
>> "xlnx,wdt-enable-once", for example, is a boolean and means
>> that the watchdog, when enabled, can not be stopped. It defaults
>> to false, and thus is inherently optional. Making it mandatory
>> doesn't really add any value.
>>
>
> If the device has been configured with wdt-enable-once=true
> and the device tree doesn't have this property then a watchdog daemon
> would see it as "false" because it is the default making the system to misbehave...
> A warning during driver loading could help user to identify the problem.
>

All this would give you is a false sense of safety. The property could
just as well be there and be wrong (eg be configured as = <0> when it
should be 1, or with a wrong frequency. Following your logic, every driver
would need to warn about everything, just to be sure.

Guenter

2014-02-23 13:29:05

by Alejandro Cabrera

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 22/2/2014 7:44 PM, Guenter Roeck wrote:
> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
>>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>>> Hi Michal,
>>>>>>>>
>>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> Changes in v3:
>>>>>>>>> - Remove one if checking and use variable directly
>>>>>>>>>
>>>>>>>> Looks good.
>>>>>>>>
>>>>>>>> Another comment/remark.
>>>>>>>>
>>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>> - "clock-frequency", NULL);
>>>>>>>>> -
>>>>>>>>> - if (pfreq == NULL) {
>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>>>> "clock-frequency",&pfreq);
>>>>>>>>> + if (rc) {
>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>> "The watchdog clock frequency cannot be
>>>>>>>>> obtained\n");
>>>>>>>>> no_timeout = true;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>>>> "xlnx,wdt-interval",
>>>>>>>>> + &xdev->wdt_interval);
>>>>>>>>> + if (rc) {
>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>>>> no_timeout = true;
>>>>>>>>> - } else {
>>>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>>>> "xlnx,wdt-enable-once",
>>>>>>>>> + &enable_once);
>>>>>>>>> + if (rc)
>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>>>> - }
>>>>>>>> All the above properties are optional. Is a warning really
>>>>>>>> warranted in this case ? I usually associate a warning with
>>>>>>>> something that is wrong, which is not the case here.
>>>>>>>>
>>>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>>>> a separate patch.
>>>>>>> I agree with Guenter: these are not really warnings. Seperate
>>>>>>> patch is thus welcome.
>>>>>> Hi
>>>>>>
>>>>>> I support Michal intention, I think it is a warning because
>>>>>> device tree blob must have the "xlnx,wdt-enable-once" property
>>>>>> specified in order to allow the system to be sure of the real
>>>>>> value of this property. In addition to, this warning can be
>>>>>> helpful to detect a wrong device tree specification.
>>>>>>
>>>>>
>>>>> The dt documentation states that the properties are optional.
>>>>>
>>>>> Optional properties:
>>>>> - clock-frequency : Frequency of clock in Hz
>>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>>>> 1 - Watchdog can be enabled just once
>>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val>
>>>>> clock cycles,
>>>>> <val> is integer from 8 to 31.
>>>>>
>>>>> This clearly conflicts with your statement. An optional property
>>>>> is just that, optional. If it warrants a warning, it must
>>>>> not be optional. If you claim that not providing the properties
>>>>> would be "wrong", why are they defined as optional ?
>>>> Hi Guenter
>>>>
>>>> I didn't know that these properties was classified as optional...
>>>> I think that they should not be, because all xilinx watchog devices
>>>> (at least for microblaze processor)
>>>> have these properties defined in theirs MPD files and theirs values
>>>> can be obtained during the
>>>> hardware specification to device tree conversion.
>>>>> What is your definition of "wrong" and "must have" ?
>>>> what I mean for "must have" is: if these properties can be obtained
>>>> for all xilinx watchdog devices they must be present in the device
>>>> tree because they allows
>>>> the system (linux/user) to know exactly how a watchdog device is
>>>> configured.
>>>> Because these properties always can be obtained from hardware
>>>> design there is no
>>>> reason to leave them out from the device tree. This is why I
>>>> consider that a device tree without
>>>> these properties should be considered as "wrong" device tree.
>>>>> How do you expect anyone to know that omitting those
>>>>> "optional" properties is by some definition "wrong" ?
>>>> I'm agree with you.
>>>> Maybe these properties shouldn't be optional.
>>>> For example suppose that "xlnx,wdt-enable-once" is missing in the
>>>> device tree,
>>>> when a watchdog daemon ask for this property what is the obtained
>>>> value ?
>>>> Independently of this value, why do not warn the user about this
>>>> missing property
>>>> when it can always be in the device tree ?
>>>>
>>>
>>> Really, this line of argument doesn't make any sense to me.
>>> "xlnx,wdt-enable-once", for example, is a boolean and means
>>> that the watchdog, when enabled, can not be stopped. It defaults
>>> to false, and thus is inherently optional. Making it mandatory
>>> doesn't really add any value.
>>>
>>
>> If the device has been configured with wdt-enable-once=true
>> and the device tree doesn't have this property then a watchdog daemon
>> would see it as "false" because it is the default making the system
>> to misbehave...
>> A warning during driver loading could help user to identify the problem.
>>
>
> All this would give you is a false sense of safety. The property could
> just as well be there and be wrong (eg be configured as = <0> when it
> should be 1, or with a wrong frequency.
These issues "cannot" be detected but the missing properties yes.
> Following your logic, every driver
> would need to warn about everything, just to be sure.
Every driver should warn about anything that it considers weird and let
the user to decide if it matters or not.
I think that an example of weird could be the lack of an expected property.

Alejandro





50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu

2014-02-23 14:43:25

by Guenter Roeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 02/23/2014 08:25 AM, Alejandro Cabrera wrote:
> On 22/2/2014 7:44 PM, Guenter Roeck wrote:
>> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
>>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
>>>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>>>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>>> Hi Michal,
>>>>>>>>>
>>>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> Changes in v3:
>>>>>>>>>> - Remove one if checking and use variable directly
>>>>>>>>>>
>>>>>>>>> Looks good.
>>>>>>>>>
>>>>>>>>> Another comment/remark.
>>>>>>>>>
>>>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>> - "clock-frequency", NULL);
>>>>>>>>>> -
>>>>>>>>>> - if (pfreq == NULL) {
>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>>>>>>>>> + if (rc) {
>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>> "The watchdog clock frequency cannot be obtained\n");
>>>>>>>>>> no_timeout = true;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>>>>>>>>> + &xdev->wdt_interval);
>>>>>>>>>> + if (rc) {
>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>>>>> no_timeout = true;
>>>>>>>>>> - } else {
>>>>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>>>>>>>>> + &enable_once);
>>>>>>>>>> + if (rc)
>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>>>>> - }
>>>>>>>>> All the above properties are optional. Is a warning really
>>>>>>>>> warranted in this case ? I usually associate a warning with
>>>>>>>>> something that is wrong, which is not the case here.
>>>>>>>>>
>>>>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>>>>> a separate patch.
>>>>>>>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
>>>>>>> Hi
>>>>>>>
>>>>>>> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
>>>>>>>
>>>>>>
>>>>>> The dt documentation states that the properties are optional.
>>>>>>
>>>>>> Optional properties:
>>>>>> - clock-frequency : Frequency of clock in Hz
>>>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>>>>> 1 - Watchdog can be enabled just once
>>>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
>>>>>> <val> is integer from 8 to 31.
>>>>>>
>>>>>> This clearly conflicts with your statement. An optional property
>>>>>> is just that, optional. If it warrants a warning, it must
>>>>>> not be optional. If you claim that not providing the properties
>>>>>> would be "wrong", why are they defined as optional ?
>>>>> Hi Guenter
>>>>>
>>>>> I didn't know that these properties was classified as optional...
>>>>> I think that they should not be, because all xilinx watchog devices (at least for microblaze processor)
>>>>> have these properties defined in theirs MPD files and theirs values can be obtained during the
>>>>> hardware specification to device tree conversion.
>>>>>> What is your definition of "wrong" and "must have" ?
>>>>> what I mean for "must have" is: if these properties can be obtained
>>>>> for all xilinx watchdog devices they must be present in the device tree because they allows
>>>>> the system (linux/user) to know exactly how a watchdog device is configured.
>>>>> Because these properties always can be obtained from hardware design there is no
>>>>> reason to leave them out from the device tree. This is why I consider that a device tree without
>>>>> these properties should be considered as "wrong" device tree.
>>>>>> How do you expect anyone to know that omitting those
>>>>>> "optional" properties is by some definition "wrong" ?
>>>>> I'm agree with you.
>>>>> Maybe these properties shouldn't be optional.
>>>>> For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
>>>>> when a watchdog daemon ask for this property what is the obtained value ?
>>>>> Independently of this value, why do not warn the user about this missing property
>>>>> when it can always be in the device tree ?
>>>>>
>>>>
>>>> Really, this line of argument doesn't make any sense to me.
>>>> "xlnx,wdt-enable-once", for example, is a boolean and means
>>>> that the watchdog, when enabled, can not be stopped. It defaults
>>>> to false, and thus is inherently optional. Making it mandatory
>>>> doesn't really add any value.
>>>>
>>>
>>> If the device has been configured with wdt-enable-once=true
>>> and the device tree doesn't have this property then a watchdog daemon
>>> would see it as "false" because it is the default making the system to misbehave...
>>> A warning during driver loading could help user to identify the problem.
>>>
>>
>> All this would give you is a false sense of safety. The property could
>> just as well be there and be wrong (eg be configured as = <0> when it
>> should be 1, or with a wrong frequency.
> These issues "cannot" be detected but the missing properties yes.
>> Following your logic, every driver
>> would need to warn about everything, just to be sure.
> Every driver should warn about anything that it considers weird and let the user to decide if it matters or not.
> I think that an example of weird could be the lack of an expected property.
>

I don't think it makes sense to continue this discussion.
We have fundamental differences in opinion which we won't
resolve by repeating our arguments over and over.

Wim, I'll let you decide how to handle this. My recommendation
is to request the author to decide if the properties are optional
or not before accepting this patch set. Either the properties
are optional, and there should be no warnings, or they are
mandatory and the driver should bail out if they are missing.

Guenter

2014-02-23 16:03:57

by Alejandro Cabrera

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 23/2/2014 6:43 AM, Guenter Roeck wrote:
> On 02/23/2014 08:25 AM, Alejandro Cabrera wrote:
>> On 22/2/2014 7:44 PM, Guenter Roeck wrote:
>>> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
>>>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
>>>>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>>>>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>>>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>>> Hi Michal,
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> Changes in v3:
>>>>>>>>>>> - Remove one if checking and use variable directly
>>>>>>>>>>>
>>>>>>>>>> Looks good.
>>>>>>>>>>
>>>>>>>>>> Another comment/remark.
>>>>>>>>>>
>>>>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>> - "clock-frequency", NULL);
>>>>>>>>>>> -
>>>>>>>>>>> - if (pfreq == NULL) {
>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>>>>>> "clock-frequency",&pfreq);
>>>>>>>>>>> + if (rc) {
>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>> "The watchdog clock frequency cannot be
>>>>>>>>>>> obtained\n");
>>>>>>>>>>> no_timeout = true;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>>>>>> "xlnx,wdt-interval",
>>>>>>>>>>> + &xdev->wdt_interval);
>>>>>>>>>>> + if (rc) {
>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>>>>>> no_timeout = true;
>>>>>>>>>>> - } else {
>>>>>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node,
>>>>>>>>>>> "xlnx,wdt-enable-once",
>>>>>>>>>>> + &enable_once);
>>>>>>>>>>> + if (rc)
>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not
>>>>>>>>>>> found\n");
>>>>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>>>>>> - }
>>>>>>>>>> All the above properties are optional. Is a warning really
>>>>>>>>>> warranted in this case ? I usually associate a warning with
>>>>>>>>>> something that is wrong, which is not the case here.
>>>>>>>>>>
>>>>>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>>>>>> a separate patch.
>>>>>>>>> I agree with Guenter: these are not really warnings. Seperate
>>>>>>>>> patch is thus welcome.
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I support Michal intention, I think it is a warning because
>>>>>>>> device tree blob must have the "xlnx,wdt-enable-once" property
>>>>>>>> specified in order to allow the system to be sure of the real
>>>>>>>> value of this property. In addition to, this warning can be
>>>>>>>> helpful to detect a wrong device tree specification.
>>>>>>>>
>>>>>>>
>>>>>>> The dt documentation states that the properties are optional.
>>>>>>>
>>>>>>> Optional properties:
>>>>>>> - clock-frequency : Frequency of clock in Hz
>>>>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>>>>>> 1 - Watchdog can be enabled just once
>>>>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val>
>>>>>>> clock cycles,
>>>>>>> <val> is integer from 8 to 31.
>>>>>>>
>>>>>>> This clearly conflicts with your statement. An optional property
>>>>>>> is just that, optional. If it warrants a warning, it must
>>>>>>> not be optional. If you claim that not providing the properties
>>>>>>> would be "wrong", why are they defined as optional ?
>>>>>> Hi Guenter
>>>>>>
>>>>>> I didn't know that these properties was classified as optional...
>>>>>> I think that they should not be, because all xilinx watchog
>>>>>> devices (at least for microblaze processor)
>>>>>> have these properties defined in theirs MPD files and theirs
>>>>>> values can be obtained during the
>>>>>> hardware specification to device tree conversion.
>>>>>>> What is your definition of "wrong" and "must have" ?
>>>>>> what I mean for "must have" is: if these properties can be obtained
>>>>>> for all xilinx watchdog devices they must be present in the
>>>>>> device tree because they allows
>>>>>> the system (linux/user) to know exactly how a watchdog device is
>>>>>> configured.
>>>>>> Because these properties always can be obtained from hardware
>>>>>> design there is no
>>>>>> reason to leave them out from the device tree. This is why I
>>>>>> consider that a device tree without
>>>>>> these properties should be considered as "wrong" device tree.
>>>>>>> How do you expect anyone to know that omitting those
>>>>>>> "optional" properties is by some definition "wrong" ?
>>>>>> I'm agree with you.
>>>>>> Maybe these properties shouldn't be optional.
>>>>>> For example suppose that "xlnx,wdt-enable-once" is missing in the
>>>>>> device tree,
>>>>>> when a watchdog daemon ask for this property what is the obtained
>>>>>> value ?
>>>>>> Independently of this value, why do not warn the user about this
>>>>>> missing property
>>>>>> when it can always be in the device tree ?
>>>>>>
>>>>>
>>>>> Really, this line of argument doesn't make any sense to me.
>>>>> "xlnx,wdt-enable-once", for example, is a boolean and means
>>>>> that the watchdog, when enabled, can not be stopped. It defaults
>>>>> to false, and thus is inherently optional. Making it mandatory
>>>>> doesn't really add any value.
>>>>>
>>>>
>>>> If the device has been configured with wdt-enable-once=true
>>>> and the device tree doesn't have this property then a watchdog daemon
>>>> would see it as "false" because it is the default making the system
>>>> to misbehave...
>>>> A warning during driver loading could help user to identify the
>>>> problem.
>>>>
>>>
>>> All this would give you is a false sense of safety. The property could
>>> just as well be there and be wrong (eg be configured as = <0> when it
>>> should be 1, or with a wrong frequency.
>> These issues "cannot" be detected but the missing properties yes.
>>> Following your logic, every driver
>>> would need to warn about everything, just to be sure.
>> Every driver should warn about anything that it considers weird and
>> let the user to decide if it matters or not.
>> I think that an example of weird could be the lack of an expected
>> property.
>>
>
> I don't think it makes sense to continue this discussion.
> We have fundamental differences in opinion which we won't
> resolve by repeating our arguments over and over.
>
> Wim, I'll let you decide how to handle this. My recommendation
> is to request the author to decide if the properties are optional
> or not before accepting this patch set. Either the properties
> are optional, and there should be no warnings, or they are
> mandatory and the driver should bail out if they are missing.
>
I'm totally agreed with you :)




50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu

2014-02-24 08:52:50

by Michal Simek

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 02/23/2014 08:00 PM, Alejandro Cabrera wrote:
> On 23/2/2014 6:43 AM, Guenter Roeck wrote:
>> On 02/23/2014 08:25 AM, Alejandro Cabrera wrote:
>>> On 22/2/2014 7:44 PM, Guenter Roeck wrote:
>>>> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
>>>>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
>>>>>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>>>>>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>>>>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>>>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>>> Hi Michal,
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> Changes in v3:
>>>>>>>>>>>> - Remove one if checking and use variable directly
>>>>>>>>>>>>
>>>>>>>>>>> Looks good.
>>>>>>>>>>>
>>>>>>>>>>> Another comment/remark.
>>>>>>>>>>>
>>>>>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>>> - "clock-frequency", NULL);
>>>>>>>>>>>> -
>>>>>>>>>>>> - if (pfreq == NULL) {
>>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>>>>>>>>>>> + if (rc) {
>>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>>> "The watchdog clock frequency cannot be obtained\n");
>>>>>>>>>>>> no_timeout = true;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>>>>>>>>>>> + &xdev->wdt_interval);
>>>>>>>>>>>> + if (rc) {
>>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>>>>>>> no_timeout = true;
>>>>>>>>>>>> - } else {
>>>>>>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>>>>>>>>>>> + &enable_once);
>>>>>>>>>>>> + if (rc)
>>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>>>>>>> - }
>>>>>>>>>>> All the above properties are optional. Is a warning really
>>>>>>>>>>> warranted in this case ? I usually associate a warning with
>>>>>>>>>>> something that is wrong, which is not the case here.
>>>>>>>>>>>
>>>>>>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>>>>>>> a separate patch.
>>>>>>>>>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The dt documentation states that the properties are optional.
>>>>>>>>
>>>>>>>> Optional properties:
>>>>>>>> - clock-frequency : Frequency of clock in Hz
>>>>>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>>>>>>> 1 - Watchdog can be enabled just once
>>>>>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
>>>>>>>> <val> is integer from 8 to 31.
>>>>>>>>
>>>>>>>> This clearly conflicts with your statement. An optional property
>>>>>>>> is just that, optional. If it warrants a warning, it must
>>>>>>>> not be optional. If you claim that not providing the properties
>>>>>>>> would be "wrong", why are they defined as optional ?
>>>>>>> Hi Guenter
>>>>>>>
>>>>>>> I didn't know that these properties was classified as optional...
>>>>>>> I think that they should not be, because all xilinx watchog devices (at least for microblaze processor)
>>>>>>> have these properties defined in theirs MPD files and theirs values can be obtained during the
>>>>>>> hardware specification to device tree conversion.
>>>>>>>> What is your definition of "wrong" and "must have" ?
>>>>>>> what I mean for "must have" is: if these properties can be obtained
>>>>>>> for all xilinx watchdog devices they must be present in the device tree because they allows
>>>>>>> the system (linux/user) to know exactly how a watchdog device is configured.
>>>>>>> Because these properties always can be obtained from hardware design there is no
>>>>>>> reason to leave them out from the device tree. This is why I consider that a device tree without
>>>>>>> these properties should be considered as "wrong" device tree.
>>>>>>>> How do you expect anyone to know that omitting those
>>>>>>>> "optional" properties is by some definition "wrong" ?
>>>>>>> I'm agree with you.
>>>>>>> Maybe these properties shouldn't be optional.
>>>>>>> For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
>>>>>>> when a watchdog daemon ask for this property what is the obtained value ?
>>>>>>> Independently of this value, why do not warn the user about this missing property
>>>>>>> when it can always be in the device tree ?
>>>>>>>
>>>>>>
>>>>>> Really, this line of argument doesn't make any sense to me.
>>>>>> "xlnx,wdt-enable-once", for example, is a boolean and means
>>>>>> that the watchdog, when enabled, can not be stopped. It defaults
>>>>>> to false, and thus is inherently optional. Making it mandatory
>>>>>> doesn't really add any value.
>>>>>>
>>>>>
>>>>> If the device has been configured with wdt-enable-once=true
>>>>> and the device tree doesn't have this property then a watchdog daemon
>>>>> would see it as "false" because it is the default making the system to misbehave...
>>>>> A warning during driver loading could help user to identify the problem.
>>>>>
>>>>
>>>> All this would give you is a false sense of safety. The property could
>>>> just as well be there and be wrong (eg be configured as = <0> when it
>>>> should be 1, or with a wrong frequency.
>>> These issues "cannot" be detected but the missing properties yes.
>>>> Following your logic, every driver
>>>> would need to warn about everything, just to be sure.
>>> Every driver should warn about anything that it considers weird and let the user to decide if it matters or not.
>>> I think that an example of weird could be the lack of an expected property.
>>>
>>
>> I don't think it makes sense to continue this discussion.
>> We have fundamental differences in opinion which we won't
>> resolve by repeating our arguments over and over.
>>
>> Wim, I'll let you decide how to handle this. My recommendation
>> is to request the author to decide if the properties are optional
>> or not before accepting this patch set. Either the properties
>> are optional, and there should be no warnings, or they are
>> mandatory and the driver should bail out if they are missing.
>>
> I'm totally agreed with you :)
>

You have reached to completely different discussion.
We should talk just about the code I have sent.
I have checked what I have done and the intention was just to have better driver.
I even didn't change any logic about DT and probe. DT binding just describes
what it is written in the driver, nothing more nothing else.

Please keep this in your mind.

The driver with this binding is in the kernel for a while and if binding is wrong
let's change it but it should be in separate patch which can fix binding
warn/error messages.

Wim: If you agree, I have no problem to send this follow up patch
which can be applied on the top of this series.
We can make xlnx,wdt-enable-once and xlnx,wdt-interval as required properties
and clock-frequence can go away and we can use CCF.

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

Attachments:

2014-02-24 19:25:24

by Wim Van Sebroeck

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

Hi Michal,

> On 02/23/2014 08:00 PM, Alejandro Cabrera wrote:
> > On 23/2/2014 6:43 AM, Guenter Roeck wrote:
> >> On 02/23/2014 08:25 AM, Alejandro Cabrera wrote:
> >>> On 22/2/2014 7:44 PM, Guenter Roeck wrote:
> >>>> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
> >>>>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
> >>>>>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
> >>>>>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
> >>>>>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
> >>>>>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
> >>>>>>>>>> Hi All,
> >>>>>>>>>>
> >>>>>>>>>>> Hi Michal,
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
> >>>>>>>>>>>> Use of_property_read_u32 functions to clean probe function.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
> >>>>>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> Changes in v3:
> >>>>>>>>>>>> - Remove one if checking and use variable directly
> >>>>>>>>>>>>
> >>>>>>>>>>> Looks good.
> >>>>>>>>>>>
> >>>>>>>>>>> Another comment/remark.
> >>>>>>>>>>>
> >>>>>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
> >>>>>>>>>>>> - "clock-frequency", NULL);
> >>>>>>>>>>>> -
> >>>>>>>>>>>> - if (pfreq == NULL) {
> >>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
> >>>>>>>>>>>> + if (rc) {
> >>>>>>>>>>>> dev_warn(&pdev->dev,
> >>>>>>>>>>>> "The watchdog clock frequency cannot be obtained\n");
> >>>>>>>>>>>> no_timeout = true;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> >>>>>>>>>>>> - "xlnx,wdt-interval", NULL);
> >>>>>>>>>>>> - if (tmptr == NULL) {
> >>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> >>>>>>>>>>>> + &xdev->wdt_interval);
> >>>>>>>>>>>> + if (rc) {
> >>>>>>>>>>>> dev_warn(&pdev->dev,
> >>>>>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
> >>>>>>>>>>>> no_timeout = true;
> >>>>>>>>>>>> - } else {
> >>>>>>>>>>>> - xdev->wdt_interval = *tmptr;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> >>>>>>>>>>>> - "xlnx,wdt-enable-once", NULL);
> >>>>>>>>>>>> - if (tmptr == NULL) {
> >>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> >>>>>>>>>>>> + &enable_once);
> >>>>>>>>>>>> + if (rc)
> >>>>>>>>>>>> dev_warn(&pdev->dev,
> >>>>>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
> >>>>>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
> >>>>>>>>>>>> - }
> >>>>>>>>>>> All the above properties are optional. Is a warning really
> >>>>>>>>>>> warranted in this case ? I usually associate a warning with
> >>>>>>>>>>> something that is wrong, which is not the case here.
> >>>>>>>>>>>
> >>>>>>>>>>> I would encourage you to drop those warnings, but that should be
> >>>>>>>>>>> a separate patch.
> >>>>>>>>>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The dt documentation states that the properties are optional.
> >>>>>>>>
> >>>>>>>> Optional properties:
> >>>>>>>> - clock-frequency : Frequency of clock in Hz
> >>>>>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
> >>>>>>>> 1 - Watchdog can be enabled just once
> >>>>>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
> >>>>>>>> <val> is integer from 8 to 31.
> >>>>>>>>
> >>>>>>>> This clearly conflicts with your statement. An optional property
> >>>>>>>> is just that, optional. If it warrants a warning, it must
> >>>>>>>> not be optional. If you claim that not providing the properties
> >>>>>>>> would be "wrong", why are they defined as optional ?
> >>>>>>> Hi Guenter
> >>>>>>>
> >>>>>>> I didn't know that these properties was classified as optional...
> >>>>>>> I think that they should not be, because all xilinx watchog devices (at least for microblaze processor)
> >>>>>>> have these properties defined in theirs MPD files and theirs values can be obtained during the
> >>>>>>> hardware specification to device tree conversion.
> >>>>>>>> What is your definition of "wrong" and "must have" ?
> >>>>>>> what I mean for "must have" is: if these properties can be obtained
> >>>>>>> for all xilinx watchdog devices they must be present in the device tree because they allows
> >>>>>>> the system (linux/user) to know exactly how a watchdog device is configured.
> >>>>>>> Because these properties always can be obtained from hardware design there is no
> >>>>>>> reason to leave them out from the device tree. This is why I consider that a device tree without
> >>>>>>> these properties should be considered as "wrong" device tree.
> >>>>>>>> How do you expect anyone to know that omitting those
> >>>>>>>> "optional" properties is by some definition "wrong" ?
> >>>>>>> I'm agree with you.
> >>>>>>> Maybe these properties shouldn't be optional.
> >>>>>>> For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
> >>>>>>> when a watchdog daemon ask for this property what is the obtained value ?
> >>>>>>> Independently of this value, why do not warn the user about this missing property
> >>>>>>> when it can always be in the device tree ?
> >>>>>>>
> >>>>>>
> >>>>>> Really, this line of argument doesn't make any sense to me.
> >>>>>> "xlnx,wdt-enable-once", for example, is a boolean and means
> >>>>>> that the watchdog, when enabled, can not be stopped. It defaults
> >>>>>> to false, and thus is inherently optional. Making it mandatory
> >>>>>> doesn't really add any value.
> >>>>>>
> >>>>>
> >>>>> If the device has been configured with wdt-enable-once=true
> >>>>> and the device tree doesn't have this property then a watchdog daemon
> >>>>> would see it as "false" because it is the default making the system to misbehave...
> >>>>> A warning during driver loading could help user to identify the problem.
> >>>>>
> >>>>
> >>>> All this would give you is a false sense of safety. The property could
> >>>> just as well be there and be wrong (eg be configured as = <0> when it
> >>>> should be 1, or with a wrong frequency.
> >>> These issues "cannot" be detected but the missing properties yes.
> >>>> Following your logic, every driver
> >>>> would need to warn about everything, just to be sure.
> >>> Every driver should warn about anything that it considers weird and let the user to decide if it matters or not.
> >>> I think that an example of weird could be the lack of an expected property.
> >>>
> >>
> >> I don't think it makes sense to continue this discussion.
> >> We have fundamental differences in opinion which we won't
> >> resolve by repeating our arguments over and over.
> >>
> >> Wim, I'll let you decide how to handle this. My recommendation
> >> is to request the author to decide if the properties are optional
> >> or not before accepting this patch set. Either the properties
> >> are optional, and there should be no warnings, or they are
> >> mandatory and the driver should bail out if they are missing.
> >>
> > I'm totally agreed with you :)
> >
>
> You have reached to completely different discussion.
> We should talk just about the code I have sent.
> I have checked what I have done and the intention was just to have better driver.
> I even didn't change any logic about DT and probe. DT binding just describes
> what it is written in the driver, nothing more nothing else.
>
> Please keep this in your mind.
>
> The driver with this binding is in the kernel for a while and if binding is wrong
> let's change it but it should be in separate patch which can fix binding
> warn/error messages.
>
> Wim: If you agree, I have no problem to send this follow up patch
> which can be applied on the top of this series.
> We can make xlnx,wdt-enable-once and xlnx,wdt-interval as required properties
> and clock-frequence can go away and we can use CCF.

As said: a follow up patch would be welcome. So yes I agree.
And I also think that the discussion was interesting because it pointed out that a review of the bindings could also be usefull (what is required versus what os optional).

Kind regards,
Wim.

2014-02-24 20:02:07

by Wim Van Sebroeck

Subject: Re: [PATCH v3 0/11] Xilinx watchdog changes

Hi Michal,

> Hi,
>
> This series contains changes for Xilinx watchdog.
> The whole code series have been reviewed by Guenter
> and device-tree binding was acked by Arnd.
>
> I have also pushed this v3 to git repo
> for easier pulling here:
> git://git.monstr.eu/linux-2.6-microblaze.git watchdog
>
> Thanks,
> Michal
>
> Changes in v3:
> - Remove one if checking and use variable directly
>
> Changes in v2:
> - Fix enable_once logic
> - Change patch subject
> - New patch in this series
>
> Michal Simek (11):
> watchdog: xilinx: Convert driver to the watchdog framework
> watchdog: xilinx: Move control_status_reg to functions
> watchdog: xilinx: Simplify probe and remove functions
> watchdog: xilinx: Move no_timeout to probe function
> watchdog: xilinx: Allocate private structure per device
> watchdog: xilinx: Fix all printk messages
> watchdog: xilinx: Use of_property_read_u32
> watchdog: xilinx: Use correct comment indentation
> watchdog: xilinx: Add missing binding
> watchdog: xilinx: Enable this driver for Zynq
> watchdog: xilinx: Remove no_timeout variable
>
> .../devicetree/bindings/watchdog/of-xilinx-wdt.txt | 23 ++
> drivers/watchdog/Kconfig | 21 +-
> drivers/watchdog/of_xilinx_wdt.c | 389 ++++++---------------
> 3 files changed, 148 insertions(+), 285 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
>
> --
> 1.8.2.3
>

This patch series has been added to linux-watchdog-next.

Kind regards,
Wim.

2014-02-25 07:39:30

by Michal Simek

Subject: Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

On 02/24/2014 08:25 PM, Wim Van Sebroeck wrote:
> Hi Michal,
>
>> On 02/23/2014 08:00 PM, Alejandro Cabrera wrote:
>>> On 23/2/2014 6:43 AM, Guenter Roeck wrote:
>>>> On 02/23/2014 08:25 AM, Alejandro Cabrera wrote:
>>>>> On 22/2/2014 7:44 PM, Guenter Roeck wrote:
>>>>>> On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:
>>>>>>> On 22/2/2014 5:36 PM, Guenter Roeck wrote:
>>>>>>>> On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:
>>>>>>>>> On 22/2/2014 3:18 PM, Guenter Roeck wrote:
>>>>>>>>>> On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:
>>>>>>>>>>> On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Michal,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
>>>>>>>>>>>>>> Use of_property_read_u32 functions to clean probe function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Michal Simek<[email protected]>
>>>>>>>>>>>>>> Reviewed-by: Guenter Roeck<[email protected]>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Changes in v3:
>>>>>>>>>>>>>> - Remove one if checking and use variable directly
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another comment/remark.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>>>>> - "clock-frequency", NULL);
>>>>>>>>>>>>>> -
>>>>>>>>>>>>>> - if (pfreq == NULL) {
>>>>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",&pfreq);
>>>>>>>>>>>>>> + if (rc) {
>>>>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>>>>> "The watchdog clock frequency cannot be obtained\n");
>>>>>>>>>>>>>> no_timeout = true;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>>>>> - "xlnx,wdt-interval", NULL);
>>>>>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>>>>>>>>>>>>> + &xdev->wdt_interval);
>>>>>>>>>>>>>> + if (rc) {
>>>>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>>>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>>>>>>>>>>>>> no_timeout = true;
>>>>>>>>>>>>>> - } else {
>>>>>>>>>>>>>> - xdev->wdt_interval = *tmptr;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>>>>>>>>>>>>> - "xlnx,wdt-enable-once", NULL);
>>>>>>>>>>>>>> - if (tmptr == NULL) {
>>>>>>>>>>>>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>>>>>>>>>>>>> + &enable_once);
>>>>>>>>>>>>>> + if (rc)
>>>>>>>>>>>>>> dev_warn(&pdev->dev,
>>>>>>>>>>>>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>>>>>>>>>>>>> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>>>>>>>>>>>>> - }
>>>>>>>>>>>>> All the above properties are optional. Is a warning really
>>>>>>>>>>>>> warranted in this case ? I usually associate a warning with
>>>>>>>>>>>>> something that is wrong, which is not the case here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would encourage you to drop those warnings, but that should be
>>>>>>>>>>>>> a separate patch.
>>>>>>>>>>>> I agree with Guenter: these are not really warnings. Seperate patch is thus welcome.
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> I support Michal intention, I think it is a warning because device tree blob must have the "xlnx,wdt-enable-once" property specified in order to allow the system to be sure of the real value of this property. In addition to, this warning can be helpful to detect a wrong device tree specification.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The dt documentation states that the properties are optional.
>>>>>>>>>>
>>>>>>>>>> Optional properties:
>>>>>>>>>> - clock-frequency : Frequency of clock in Hz
>>>>>>>>>> - xlnx,wdt-enable-once : 0 - Watchdog can be restarted
>>>>>>>>>> 1 - Watchdog can be enabled just once
>>>>>>>>>> - xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
>>>>>>>>>> <val> is integer from 8 to 31.
>>>>>>>>>>
>>>>>>>>>> This clearly conflicts with your statement. An optional property
>>>>>>>>>> is just that, optional. If it warrants a warning, it must
>>>>>>>>>> not be optional. If you claim that not providing the properties
>>>>>>>>>> would be "wrong", why are they defined as optional ?
>>>>>>>>> Hi Guenter
>>>>>>>>>
>>>>>>>>> I didn't know that these properties was classified as optional...
>>>>>>>>> I think that they should not be, because all xilinx watchog devices (at least for microblaze processor)
>>>>>>>>> have these properties defined in theirs MPD files and theirs values can be obtained during the
>>>>>>>>> hardware specification to device tree conversion.
>>>>>>>>>> What is your definition of "wrong" and "must have" ?
>>>>>>>>> what I mean for "must have" is: if these properties can be obtained
>>>>>>>>> for all xilinx watchdog devices they must be present in the device tree because they allows
>>>>>>>>> the system (linux/user) to know exactly how a watchdog device is configured.
>>>>>>>>> Because these properties always can be obtained from hardware design there is no
>>>>>>>>> reason to leave them out from the device tree. This is why I consider that a device tree without
>>>>>>>>> these properties should be considered as "wrong" device tree.
>>>>>>>>>> How do you expect anyone to know that omitting those
>>>>>>>>>> "optional" properties is by some definition "wrong" ?
>>>>>>>>> I'm agree with you.
>>>>>>>>> Maybe these properties shouldn't be optional.
>>>>>>>>> For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
>>>>>>>>> when a watchdog daemon ask for this property what is the obtained value ?
>>>>>>>>> Independently of this value, why do not warn the user about this missing property
>>>>>>>>> when it can always be in the device tree ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Really, this line of argument doesn't make any sense to me.
>>>>>>>> "xlnx,wdt-enable-once", for example, is a boolean and means
>>>>>>>> that the watchdog, when enabled, can not be stopped. It defaults
>>>>>>>> to false, and thus is inherently optional. Making it mandatory
>>>>>>>> doesn't really add any value.
>>>>>>>>
>>>>>>>
>>>>>>> If the device has been configured with wdt-enable-once=true
>>>>>>> and the device tree doesn't have this property then a watchdog daemon
>>>>>>> would see it as "false" because it is the default making the system to misbehave...
>>>>>>> A warning during driver loading could help user to identify the problem.
>>>>>>>
>>>>>>
>>>>>> All this would give you is a false sense of safety. The property could
>>>>>> just as well be there and be wrong (eg be configured as = <0> when it
>>>>>> should be 1, or with a wrong frequency.
>>>>> These issues "cannot" be detected but the missing properties yes.
>>>>>> Following your logic, every driver
>>>>>> would need to warn about everything, just to be sure.
>>>>> Every driver should warn about anything that it considers weird and let the user to decide if it matters or not.
>>>>> I think that an example of weird could be the lack of an expected property.
>>>>>
>>>>
>>>> I don't think it makes sense to continue this discussion.
>>>> We have fundamental differences in opinion which we won't
>>>> resolve by repeating our arguments over and over.
>>>>
>>>> Wim, I'll let you decide how to handle this. My recommendation
>>>> is to request the author to decide if the properties are optional
>>>> or not before accepting this patch set. Either the properties
>>>> are optional, and there should be no warnings, or they are
>>>> mandatory and the driver should bail out if they are missing.
>>>>
>>> I'm totally agreed with you :)
>>>
>>
>> You have reached to completely different discussion.
>> We should talk just about the code I have sent.
>> I have checked what I have done and the intention was just to have better driver.
>> I even didn't change any logic about DT and probe. DT binding just describes
>> what it is written in the driver, nothing more nothing else.
>>
>> Please keep this in your mind.
>>
>> The driver with this binding is in the kernel for a while and if binding is wrong
>> let's change it but it should be in separate patch which can fix binding
>> warn/error messages.
>>
>> Wim: If you agree, I have no problem to send this follow up patch
>> which can be applied on the top of this series.
>> We can make xlnx,wdt-enable-once and xlnx,wdt-interval as required properties
>> and clock-frequence can go away and we can use CCF.
>
> As said: a follow up patch would be welcome. So yes I agree.
> And I also think that the discussion was interesting because it pointed out that
a review of the bindings could also be usefull (what is required versus what os optional).

Definitely it is not the first time where binding doc is useful.
Also from binding we can see which features are common for all
drivers in the same kind.

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

Attachments: