All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
To: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Cc: Wim Van Sebroeck <wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org>,
	linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/2] watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC
Date: Sun, 22 Mar 2015 22:50:28 -0700	[thread overview]
Message-ID: <550FA9A4.5010304@roeck-us.net> (raw)
In-Reply-To: <20150323053355.GJ2825@tarshish>

On 03/22/2015 10:33 PM, Baruch Siach wrote:

> [...]
>
>>>>> +	wdt->restart_handler.notifier_call = dc_restart_handler;
>>>>> +	wdt->restart_handler.priority = 128;
>>>>
>>>> Is 128 intentional, ie is this the expected reset method for this platform ?
>>>> If not, it may be better to select a lower priority (eg 64). Using a watchdog
>>>> to reset a system should in general be a method of last resort.
>>>
>>> Copied this value from imx2_wdt. grep indicates that almost all other watchdog
>>> drivers implementing restart_handler use priority of 128 (except bcm47xx_wdt).
>>> What is the policy here?
>>
>> The policy is to do what is sensible for the platform. That can only be decided
>> on a case-by-case basis. The documentation suggests to use 128 for "Default restart
>> handler; use if no other restart handler is expected to be available, and/or if
>> restart functionality is sufficient to restart the entire system".
>>
>> So if this is the only means expected to be available to reset the system
>> for this architecture/platform, and if the watchdog resets the entire system
>> (not just the CPU), 128 may be ok to use. If, however, there may be other
>> means to reset the system, such as a GPIO pin, maybe not.
>
> This driver is for a SoC hardware block. The restart_handler priority level is
> hard coded in the drivers, and should thus work reasonably well for all its
> users. The fact that the common priority level is 128, is significant in this
> case IMO (as apposed to issues discussed above). Systems designers are likely
> take this priority level into account in their designs. If this does not match
> the documentation, then documentation needs to change to reflect reality.
>
Seems to me you are arguing (again) that it is ok to use priority 128 not
because of merit, but because others do it as well. As you may have noticed,
I kind of dislike that line of argument. Actually, I don't consider it to be
a valid argument in the first place.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Baruch Siach <baruch@tkos.co.il>
Cc: Wim Van Sebroeck <wim@iguana.be>,
	linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC
Date: Sun, 22 Mar 2015 22:50:28 -0700	[thread overview]
Message-ID: <550FA9A4.5010304@roeck-us.net> (raw)
In-Reply-To: <20150323053355.GJ2825@tarshish>

On 03/22/2015 10:33 PM, Baruch Siach wrote:

> [...]
>
>>>>> +	wdt->restart_handler.notifier_call = dc_restart_handler;
>>>>> +	wdt->restart_handler.priority = 128;
>>>>
>>>> Is 128 intentional, ie is this the expected reset method for this platform ?
>>>> If not, it may be better to select a lower priority (eg 64). Using a watchdog
>>>> to reset a system should in general be a method of last resort.
>>>
>>> Copied this value from imx2_wdt. grep indicates that almost all other watchdog
>>> drivers implementing restart_handler use priority of 128 (except bcm47xx_wdt).
>>> What is the policy here?
>>
>> The policy is to do what is sensible for the platform. That can only be decided
>> on a case-by-case basis. The documentation suggests to use 128 for "Default restart
>> handler; use if no other restart handler is expected to be available, and/or if
>> restart functionality is sufficient to restart the entire system".
>>
>> So if this is the only means expected to be available to reset the system
>> for this architecture/platform, and if the watchdog resets the entire system
>> (not just the CPU), 128 may be ok to use. If, however, there may be other
>> means to reset the system, such as a GPIO pin, maybe not.
>
> This driver is for a SoC hardware block. The restart_handler priority level is
> hard coded in the drivers, and should thus work reasonably well for all its
> users. The fact that the common priority level is 128, is significant in this
> case IMO (as apposed to issues discussed above). Systems designers are likely
> take this priority level into account in their designs. If this does not match
> the documentation, then documentation needs to change to reflect reality.
>
Seems to me you are arguing (again) that it is ok to use priority 128 not
because of merit, but because others do it as well. As you may have noticed,
I kind of dislike that line of argument. Actually, I don't consider it to be
a valid argument in the first place.

Guenter


WARNING: multiple messages have this Message-ID (diff)
From: linux@roeck-us.net (Guenter Roeck)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC
Date: Sun, 22 Mar 2015 22:50:28 -0700	[thread overview]
Message-ID: <550FA9A4.5010304@roeck-us.net> (raw)
In-Reply-To: <20150323053355.GJ2825@tarshish>

On 03/22/2015 10:33 PM, Baruch Siach wrote:

> [...]
>
>>>>> +	wdt->restart_handler.notifier_call = dc_restart_handler;
>>>>> +	wdt->restart_handler.priority = 128;
>>>>
>>>> Is 128 intentional, ie is this the expected reset method for this platform ?
>>>> If not, it may be better to select a lower priority (eg 64). Using a watchdog
>>>> to reset a system should in general be a method of last resort.
>>>
>>> Copied this value from imx2_wdt. grep indicates that almost all other watchdog
>>> drivers implementing restart_handler use priority of 128 (except bcm47xx_wdt).
>>> What is the policy here?
>>
>> The policy is to do what is sensible for the platform. That can only be decided
>> on a case-by-case basis. The documentation suggests to use 128 for "Default restart
>> handler; use if no other restart handler is expected to be available, and/or if
>> restart functionality is sufficient to restart the entire system".
>>
>> So if this is the only means expected to be available to reset the system
>> for this architecture/platform, and if the watchdog resets the entire system
>> (not just the CPU), 128 may be ok to use. If, however, there may be other
>> means to reset the system, such as a GPIO pin, maybe not.
>
> This driver is for a SoC hardware block. The restart_handler priority level is
> hard coded in the drivers, and should thus work reasonably well for all its
> users. The fact that the common priority level is 128, is significant in this
> case IMO (as apposed to issues discussed above). Systems designers are likely
> take this priority level into account in their designs. If this does not match
> the documentation, then documentation needs to change to reflect reality.
>
Seems to me you are arguing (again) that it is ok to use priority 128 not
because of merit, but because others do it as well. As you may have noticed,
I kind of dislike that line of argument. Actually, I don't consider it to be
a valid argument in the first place.

Guenter

  reply	other threads:[~2015-03-23  5:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22 12:40 [PATCH 1/2] watchdog: digicolor: document device tree binding Baruch Siach
2015-03-22 12:40 ` Baruch Siach
2015-03-22 12:40 ` Baruch Siach
     [not found] ` <6bc6e867b500cd3cfc629b96f90442f5c0aced3a.1427028036.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
2015-03-22 12:40   ` [PATCH 2/2] watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC Baruch Siach
2015-03-22 12:40     ` Baruch Siach
2015-03-22 12:40     ` Baruch Siach
     [not found]     ` <409ece75204d3911dc526a9bc0c908fc30893b26.1427028036.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
2015-03-22 16:59       ` Guenter Roeck
2015-03-22 16:59         ` Guenter Roeck
2015-03-22 16:59         ` Guenter Roeck
     [not found]         ` <550EF4DA.6040407-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-03-22 18:08           ` Baruch Siach
2015-03-22 18:08             ` Baruch Siach
2015-03-22 18:08             ` Baruch Siach
2015-03-22 18:59             ` Guenter Roeck
2015-03-22 18:59               ` Guenter Roeck
2015-03-22 18:59               ` Guenter Roeck
     [not found]               ` <550F111F.9060400-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-03-23  5:33                 ` Baruch Siach
2015-03-23  5:33                   ` Baruch Siach
2015-03-23  5:33                   ` Baruch Siach
2015-03-23  5:50                   ` Guenter Roeck [this message]
2015-03-23  5:50                     ` Guenter Roeck
2015-03-23  5:50                     ` Guenter Roeck
2015-03-23  6:17                     ` Baruch Siach
2015-03-23  6:17                       ` Baruch Siach
2015-03-23  6:17                       ` Baruch Siach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550FA9A4.5010304@roeck-us.net \
    --to=linux-0h96xk9xttrk1umjsbkqmq@public.gmane.org \
    --cc=baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.