linux-kernel - Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53093038.6000604@roeck-us.net>
Date:	Sat, 22 Feb 2014 15:18:16 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Alejandro Cabrera <acabrera@...o.cujae.edu.cu>,
	Wim Van Sebroeck <wim@...ana.be>
CC:	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, monstr@...str.eu,
	linux-watchdog@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
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<michal.simek@...inx.com>
>>>> Reviewed-by: Guenter Roeck<linux@...ck-us.net>
>>>> ---
>>>>
>>>> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/