Instead of requiring the user to provide an IO address per module
parameter, auto-detect it as well as supported chips.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Try to reset the watchdog counter 4 or 2 times more often than actually
requested, to avoid spurious watchdog reset.
If this is not possible because of the min_heartbeat value, reset it at
the min_heartbeat period.
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Use the min_heartbeat value instead of the calculated heartbeat value for
the first watchdog reset to avoid spurious watchdog reset.

Resetting the watchdog counter during init might lead to a watchdog fault
reset because the watchdog counter has to be running for at least
min_heartbeat.

Resetting the watchdog counter after heartbeat might lead to a watchdog
timeout reset because the watchdog counter is running for more than
max_heartbeat time.

Using min_heartbeat instead of heartbeat does not guarantee that the
watchdog won't trigger a reset, but at least it reduces the chances to be
in such a case.
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Fix the secs_to_ticks macro in case 0 is passed as an argument.
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

The at91sam9 watchdog timer can only be configured once, and the current
implementation tries to configure it in a static way:
- 2 seconds timeout
- wdt restart every 500ms

If the timer has already been configured with different values, it returns an
error and do not create any watchdog device.

This is not critical if the watchdog is disabled, but if it has been enabled with
different timeout values it will lead to a SoC reset.

This patch series tries to address this issue by adapting the heartbeat value
according the WDT timer config:
- it first tries to configure the timer as requested.
- if it fails it fallbacks to the current config, adapting its heartbeat timer
to the needs

This patch series also move to a dynamically allocated at91wdt device instead
of the static instance.

It adds a new at91 wdt type: software. This new type make use of the at91 wdt
interrupt to trigger a software reboot.

Finally it adds several properties to the device tree bindings.
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Add sp805_wdt depends on ARM64.
Signed-off-by: NNaresh Bhat <naresh.bhat@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

mach-moxart lacks a separate register for reset; as a workaround,
add a function that can be hooked to arm_pm_restart.
Signed-off-by: NJonas Jensen <jonas.jensen@gmail.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Convert mpc8xxx_wdt.c to the new watchdog API.
Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

'sirfsoc_wdt_of_match' is always compiled in. Hence the
helper macro is not needed.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

This patch is being submitted to output a general string when the panic comes
in that informs the user of the possible places to look for the source of the
NMI. Because various systems log the message in different places this would
give a single display of where to go look instead of code that acts on all
these different server names or IDs.
Signed-off-by: NThomas Mingarelli <thomas.mingarelli@hp.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

There is nothing ARM specific in this driver, and we intend to use it on the
Xtensa architecture. Also, clk.h now includes stubs for !CONFIG_HAVE_CLK, so
the driver should build anyway.
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Acked-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

We should set watchdog timer to be disabled in low power mode,
as there is no service running in background, otherwise, system
will reset unexpected.
Signed-off-by: NAnson Huang <b20788@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

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: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Add device tree support for exynos5250 and 5420 SoCs and use syscon regmap interface
to configure AUTOMATIC_WDT_RESET_DISABLE and MASK_WDT_RESET_REQUEST registers of PMU
to mask/unmask enable/disable of watchdog in probe and s2r scenarios.
Signed-off-by: NLeela Krishna Amudala <l.krishna@samsung.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.

Specifically if you had a timeout of 32 seconds and an input clock of
66666666, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.

Specifically DBG printouts showed:
  s3c2410wdt_set_heartbeat: count=16666656, timeout=32, freq=520833
  s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=16666656 (0000ff4f)
and the final timeout reported to the user was:
  ((count / divisor) * divisor) / freq
  (0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
  (0xff4f * 255) / (66666666.0 / 128) = 31.9998

By using "DIV_ROUND_UP" we can be a little more correct.
  s3c2410wdt_set_heartbeat: count=16666688, timeout=32, freq=520834
  s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=16666688 (0000ff50)
and the final timeout reported to the user:
  (0xff50 * 255) / 520834 = 32
the technically "correct" value is:
  (0xff50 * 255) / (66666666.0 / 128) = 32.0003

We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.

At the same time we can avoid a for loop by just doing the right math.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

On modern SoCs the watchdog timer is parented on a clock that doesn't
change every time we have a cpufreq change.  That means we don't need
to constantly adjust the watchdog timer, so avoid registering for and
dealing with cpufreq transitions unless we've actually got
CONFIG_ARM_S3C24XX_CPUFREQ defined.

Note that this is more than just an optimization.  The s3c2410
watchdog driver actually pats the watchdog on every CPU frequency
change.  On modern systems these happen many times per second (even in
a system where "nothing" is happening).  That effectively makes any
userspace watchdog program useless (the watchdog is constantly patted
by the kernel).  If we need ARM_S3C24XX_CPUFREQ defined on a
multiplatform kernel we'll need to make sure that kernel supports
common clock and change this to user common clock framework.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

This patch adds a watchdog driver for devices controlled through GPIO,
(Analog Devices ADM706, Maxim MAX823, National NE555 etc).
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

The keystone arch uses the same IP watchdog, so add "ti,keystone-wdt"
compatible and correct identity.

The Keystone arch is using clocks in DT and source clock for watchdog
has to be specified, so add this to binding.
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Currently, the davinci watchdog can be read while counting,
so we can add ability to report the remaining time before
the system will reboot.
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Some SoCs, like Keystone 2, can support more than one WDT and each
watchdog device has to use it's own base address, clock source,
watchdog device, so add new davinci_wdt_device structure to hold
device data.
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGuenter roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.

Davinci WDT can't be stopped and once it's expired - it can be
rearmed only after hardware reset, that's why nowayout feature
is enforced.
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

This change introduces debugfs support for the BCM281xx watchdog driver.
Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

This commit adds support for the watchdog timer used on the BCM281xx
family of SoCs.
Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org>
Reviewed-by: NMatt Porter <matt.porter@linaro.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

It is valid for a watchdog driver to have 0 for a "min" and "max"
timeout if the driver doesn't need the core to enforce the concepts of
min and max.  The s3c2410_wdt driver is one such driver.  Specifically
it can be hard for that driver to come up with a static "max" on all
platforms without a lot more information since the input clock on
S3C2410 and S3C2440 can change with DVFS.

As written, watchdog_init_timeout() will not ever read "timeout-sec"
on these drivers since watchdog_timeout_invalid() will _never_ return
true.  Change to not consider a timeout_parm of 0 as valid even if
min/max aren't specified by the driver.  Also handle the case when
there is no min/max and no "timeout-sec" property.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI.  This
causes problems on other archs when introducing DMI support that depends
on EFI, as it results in a recursive dependency:

  arch/arm/Kconfig:1845:error: recursive dependency detected!
  arch/arm/Kconfig:1845:	symbol DMI depends on EFI

Fix by changing the 'select EFI' to a 'depends on EFI'.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Rientjes <rientjes@google.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Return proper errors for a lot of IPMI failure cases.  Also call
pci_disable_device when IPMI PCI devices are removed.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Loading ipmi_si module while bmc is disconnected, we found the timeout
is longer than 5 secs.  Actually it takes about 3 mins and 20
secs.(HZ=250)

error message as below:
  Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
  Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
  [...]
  Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
  Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
  Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
  Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]

Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
usecs from timeout.
Reported-by: NHu Shiyuan <hushiyuan@huawei.com>
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use USEC_PER_SEC instead of 1000000, that making the later bugfix
more clearly.
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The adapter is freed before we check its flags. It was caused
by commit 144be3d9 ("net/cxgb4: Avoid disabling PCI device for
towice"). The problem was reported by Intel's "0-day" tool.

The patch fixes it to avoid reverting commit 144be3d9.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To provide access to the set-partition-resource-parameter interface
to user space add a new attribute to hypfs/debugfs:
 * s390_hypsfs/diag_304
The data for the query-partition-resource-parameters command can
be access by a read on the attribute. All other diagnose 0x304
requests need to be submitted via ioctl with CAP_SYS_ADMIN rights.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Strong pullup is emulated by driving pin logic high after write command
when using tri-state push-pull GPIO.
Signed-off-by: NEvgeny Boger <boger@contactless.ru>
Cc: Greg KH <greg@kroah.com>
Acked-by: NDavid Fries <david@fries.net>
Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch is used to add support for ms card. The main difference
between ms card and mspro card is long data transfer mode. mspro card
can use auto mode DMA for long data transfer, but ms can not use this
mode, it should use normal mode DMA.

The memstick core added support for ms card, but the original driver will
make ms card fail at initialization, because it uses auto mode DMA.  This
patch makes the ms card work properly.
Signed-off-by: NMicky Ching <micky_ching@realsil.com.cn>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Alex Dubov <oakad@yahoo.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add support for SMBus-only adapters (e.g.  i2c-piix4).  The driver has
implemented only support for I2C adapters which implement the
I2C_FUNC_SMBUS_I2C_BLOCK functionality before.

With this patch it is possible to load and use the RTC driver with I2C and
SMBUS adapters like the rtc-ds1307 does.

Tested on AMD G Series Platform (i2c-piix4 adapter driver).
Signed-off-by: NAndreas Werner <andreas.werner@men.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If CONFIG_PM_SLEEP=n:

drivers/rtc/rtc-s5m.c:643: warning: `s5m_rtc_resume' defined but not used
drivers/rtc/rtc-s5m.c:654: warning: `s5m_rtc_suspend' defined but not used
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current MAX8907 driver has two issues related to weekday value
handling:

1)

The HW WEEKDAY register has range 0..6 rather than 1..7 as documented.
Note that I validated the actual HW range by observing the HW register
roll from 6->0 rather than 6->7->1 as would otherwise be expected.

This matches Linux's tm_wday range of 0..6.

When the CMOS RAM content is lost, the date returned from the device is
2007-01-01 00:00:00, which is a Monday.  The WEEKDAY register reads 1 in
this case.  This matches the numbering in Linux's tm_wday field.

Hence we should write Linux's tm_wday value to the register without
modifying it.  Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday.

2)

There's no need to make alarms match on the WEEKDAY register, since the
other fields together uniquely define the alarm date/time.  Ignoring the
WEEKDAY value in the match isolates the driver from any incorrect value in
the current time copy of the WEEKDAY register.

Each change individually, or both together, solves an issue that I
observed; "hwclock -r" would time out waiting for its alarm to fire if the
CMOS RAM content had been lost, and hence the WEEKDAY register value
mismatched what the driver expected it to be.  "hwclock -w" would solve
this by over-writing the HW default WEEKDAY register value with what the
driver expected.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

'hym8563_clkout_ops' is used only in this file.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

'hym8563_dt_idtable' is always compiled in.  Hence the helper macro is not
needed.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

'ds1742_rtc_of_match' is always compiled in.  Hence the helper macro is
not needed.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>