linux-kernel - Re: [PATCH v2 2/2] watchdog: s3c2410_wdt: Report when the watchdog reset the system

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: <CAD=FV=W8S5FFBcAq=4enA0zbBUwbomr62eYeMyYtc+SAKXpqPg@mail.gmail.com>
Date:	Fri, 6 Dec 2013 13:08:15 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Wim Van Sebroeck <wim@...ana.be>,
	Leela Krishna Amudala <l.krishna@...sung.com>,
	Olof Johansson <olof@...om.net>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Ben Dooks <ben-linux@...ff.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	"linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] watchdog: s3c2410_wdt: Report when the watchdog
 reset the system

Guenter,

On Fri, Dec 6, 2013 at 11:54 AM, Guenter Roeck <linux@...ck-us.net> wrote:
> On Thu, Dec 05, 2013 at 10:15:29AM -0800, Doug Anderson wrote:
>> A good watchdog driver is supposed to report when it was responsible
>> for resetting the system.  Implement this for the s3c2410, at least on
>> exynos5250 and exynos5420 where we already have a pointer to the PMU
>> registers to read the information.
>>
>> Note that exynos4 SoCs also provide the reset status, but providing
>> that is left as an exercise for future changes and is not plumbed up
>> in this patch series.  Also note the exynos4 SoCs don't appear to need
>> any PMU config, which is why this patch separates the concepts of
>> having PMU Registers vs. needing PMU Config.
>>
>> Signed-off-by: Doug Anderson <dianders@...omium.org>
>> ---
>> Changes in v2:
>> - Explained QUIRK organization in patch descritpion.
>> - Reduced indentation as per Olof and Tomasz suggestion.
>> - Now atop proposed v12 of Leela Krishna's patches.
>
> Hi Doug,
>
> The patch doesn't apply on top of v12, unfortunately.

OK, I'll re-send shortly.


>> - NEEDS => HAS, EXYNOS5 prefix
>>
>>  drivers/watchdog/s3c2410_wdt.c | 42 +++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 39 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
>> index 6a00299..45a9503 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -62,9 +62,15 @@
>>  #define CONFIG_S3C2410_WATCHDOG_ATBOOT               (0)
>>  #define CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME (15)
>>
>> +#define EXYNOS5_RST_STAT_REG_OFFSET          0x0404
>>  #define EXYNOS5_WDT_DISABLE_REG_OFFSET               0x0408
>>  #define EXYNOS5_WDT_MASK_RESET_REG_OFFSET    0x040c
>>  #define QUIRK_HAS_PMU_CONFIG                 (1 << 0)
>> +#define QUIRK_HAS_RST_STAT                   (1 << 1)
>> +
>> +/* These quirks require that we have a PMU register map */
>> +#define QUIRKS_HAVE_PMUREG                   (QUIRK_HAS_PMU_CONFIG | \
>> +                                              QUIRK_HAS_RST_STAT)
>>
>>  static bool nowayout = WATCHDOG_NOWAYOUT;
>>  static int tmr_margin;
>> @@ -98,6 +104,9 @@ MODULE_PARM_DESC(debug, "Watchdog debug, set to >1 for debug (default 0)");
>>   * timer reset functionality.
>>   * @mask_bit: Bit number for the watchdog timer in the disable register and the
>>   * mask reset register.
>> + * @rst_stat_reg: Offset in pmureg for the register that has the reset status.
>> + * @rst_stat_bit: Bit number in the rst_stat register indicating a watchdog
>> + * reset.
>>   * @quirks: A bitfield of quirks.
>>   */
>>
>> @@ -105,6 +114,8 @@ struct s3c2410_wdt_variant {
>>       int disable_reg;
>>       int mask_reset_reg;
>>       int mask_bit;
>> +     int rst_stat_reg;
>> +     int rst_stat_bit;
>>       u32 quirks;
>>  };
>>
>> @@ -131,14 +142,20 @@ static const struct s3c2410_wdt_variant drv_data_exynos5250  = {
>>       .disable_reg = EXYNOS5_WDT_DISABLE_REG_OFFSET,
>>       .mask_reset_reg = EXYNOS5_WDT_MASK_RESET_REG_OFFSET,
>>       .mask_bit = 20,
>> -     .quirks = QUIRK_HAS_PMU_CONFIG
>> +     .rst_stat_reg = EXYNOS5_RST_STAT_REG_OFFSET,
>> +     .rst_stat_bit = 20,
>> +     .quirks = QUIRK_HAS_PMU_CONFIG |
>> +             QUIRK_HAS_RST_STAT,
>
> Any reason not to use QUIRKS_HAVE_PMUREG ?

My intent was that the QUIRKS_HAVE_PMUREG is a list of quirks that
require a PMU register and is used for testing, not for setting.  When
someone adds another quirk that requires the PMU Registers I don't
want that to automatically apply to old hardware.


>>  };
>>
>>  static const struct s3c2410_wdt_variant drv_data_exynos5420 = {
>>       .disable_reg = EXYNOS5_WDT_DISABLE_REG_OFFSET,
>>       .mask_reset_reg = EXYNOS5_WDT_MASK_RESET_REG_OFFSET,
>>       .mask_bit = 0,
>> -     .quirks = QUIRK_HAS_PMU_CONFIG
>> +     .rst_stat_reg = EXYNOS5_RST_STAT_REG_OFFSET,
>> +     .rst_stat_bit = 9,
>> +     .quirks = QUIRK_HAS_PMU_CONFIG |
>> +             QUIRK_HAS_RST_STAT,
>
> Same here. Even if you don't use QUIRKS_HAVE_PMUREG, the continuation line is not needed.

I will spin.


Thanks!

-Doug
--
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/