watchdog: omap_wdt: eliminate goto

Eliminate a goto to simplify the code.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: DA9055 Watchdog driver

This is the Watchdog patch for the DA9055 PMIC. This patch has got dependency on
the DA9055 MFD core.

This patch is functionally tested on SMDK6410

Signed-off-by: David Dajun Chen <dchen@diasemi.com>
Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: Convert dev_printk(KERN_<LEVEL> to dev_<level>(

dev_<level> calls take less code than dev_printk(KERN_<LEVEL>
and reducing object size is good.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: remove depends on CONFIG_EXPERIMENTAL

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: twl4030_wdt: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER

To facilitate upcoming cleanup in twl stack.
No functional changes.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: da9052: Fix invalid free of devm_ allocated data

It is not required to free devm_ allocated data. Since kref_put
needs a valid release function, da9052_wdt_release_resources()
is not deleted.

Fixes following warning.
drivers/watchdog/da9052_wdt.c:59:1-6: WARNING: invalid free of
devm_ allocated data

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: davinci_wdt: add OF support

This adds OF support for davinci_wdt driver.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: sp5100_tco: Add SB8x0 chipset support

The current sp5100_tco driver only supports SP5100/SB7x0 chipset, doesn't
support SB8x0 chipset, because current sp5100_tco driver doesn't know that the
offset address for watchdog timer was changed from SB8x0 chipset.

The offset address of SP5100 and SB7x0 chipsets are as follows, quote from the
AMD SB700/710/750 Register Reference Guide (Page 164) and the AMD SP5100
Register Reference Guide (Page 166).

  WatchDogTimerControl 69h
  WatchDogTimerBase0   6Ch
  WatchDogTimerBase1   6Dh
  WatchDogTimerBase2   6Eh
  WatchDogTimerBase3   6Fh

In contrast, the offset address of SB8x0 chipset is as follows, quote from
AMD SB800-Series Southbridges Register Reference Guide (Page 147).

  WatchDogTimerEn      48h
  WatchDogTimerConfig  4Ch

So, In the case of SB8x0 chipset, sp5100_tco reads meaningless MMIO
address (for example, 0xbafe00) from wrong offset address, and the following
message is logged.

   SP5100 TCO timer: mmio address 0xbafe00 already in use

With this patch, sp5100_tco driver supports SB8x0 chipset, and can avoid
iomem resource conflict. The processing of this patch is as follows.

 Step 1) Attempt to get the watchdog base address from indirect I/O (0xCD6
         and 0xCD7).
  - Go to the step 7 if obtained address hasn't conflicted with other
    resource. But, currently, the address (0xfec000f0) conflicts with the
    IOAPIC MMIO address, and the following message is logged.

       SP5100 TCO timer: mmio address 0xfec000f0 already in use

    0xfec000f0 is recommended by AMD BIOS Developer's Guide. So, go to the
    next step.

 Step 2) Attempt to get the SBResource_MMIO base address from AcpiMmioEN (for
         SB8x0,  PM_Reg:24h) or SBResource_MMIO (SP5100/SB7x0, PCI_Reg:9Ch)
         register.
  - Go to the step 7 if these register has enabled by BIOS, and obtained
    address hasn't conflicted with other resource.
  - If above condition isn't true, go to the next step.

 Step 3) Attempt to get the free MMIO address from allocate_resource().
  - Go to the step 7 if these register has enabled by BIOS, and obtained
    address hasn't conflicted with other resource.
  - Driver initialization has failed if obtained address has conflicted
    with other resource, and no 'force_addr' parameter is specified.

 Step 4) Use the specified address If 'force_addr' parameter is specified.
  - allocate_resource() function may fail, when the PCI bridge device occupies
    iomem resource from 0xf0000000 to 0xffffffff. To handle such a case,
    I added 'force_addr' parameter to sp5100_tco driver. With 'force_addr'
    parameter, sp5100_tco driver directly can assign MMIO address for watchdog
    timer from free iomem region. Note that It's dangerous to specify wrong
    address in the 'force_addr' parameter.

      Example of force_addr parameter use
        # cat /proc/iomem
        ...snip...
        fec00000-fec003ff : IOAPIC 0
                                      <--- free MMIO region
        fec10000-fec1001f : pnp 00:0b
        fec20000-fec203ff : IOAPIC 1
        ...snip...
        # cat /etc/modprobe.d/sp5100_tco.conf
        options sp5100_tco force_addr=0xfec00800
        # modprobe sp5100_tco
        # cat /proc/iomem
        ...snip...
        fec00000-fec003ff : IOAPIC 0
        fec00800-fec00807 : SP5100 TCO  <--- watchdog timer MMIO address
        fec10000-fec1001f : pnp 00:0b
        fec20000-fec203ff : IOAPIC 1
        ...snip...
        #

  - Driver initialization has failed if specified address has conflicted
    with other resource.

 Step 5) Disable the watchdog timer
  - To rewrite the watchdog timer register of the chipset, absolutely
    guarantee that the watchdog timer is disabled.

 Step 6) Re-program the watchdog timer MMIO address to chipset.
  - Re-program the obtained MMIO address in Step 3 or Step 4 to chipset via
    indirect I/O (0xCD6 and 0xCD7).

 Step 7) Enable and setup the watchdog timer

This patch has worked fine on my test environment (ASUS M4A89GTD-PRO/USB3 and
DL165G7). therefore I believe that it's no problem to re-program the MMIO
address for watchdog timer to chipset during disabled watchdog. However,
I'm not sure about it, because I don't know much about chipset programming.

So, any comments will be welcome.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176
Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Takahisa Tanaka <mc74hc00@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: Orion: Fix possible null-deference in orion_wdt_probe

If the DT does not include a regs parameter then the null res
would be dereferenced.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: mei: avoid oops in watchdog unregister code path

With commit c7d3df3 "mei: use internal watchdog device registration
tracking" will crash the kernel on shutdown path on systems
where ME watchdog is not present.
Since the watchdog was never initialized in such case
the WDOG_UNREGISTERED bit is never set and the system
crashes on access to uninitialized variables down the path.

To solve the issue we query for NULL on watchdog driver driver_data
to check whether the device is registered. This is handled in the
driver and doesn't depend on watchdog core internals.

Cc: Borislav Petkov <bp@alien8.de>
Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Jerry Snitselaar <jerry.snitselaar@oracle.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

Fix regression introduced by 85b144f860176
"drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3"

Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase
refcount on &bo->sync_obj instead of bo->sync_obj.

The compiler didn't complain since sync_obj_ref takes a void pointer,
so it was still valid c.

This could result in lockups, memory corruptions, and warnings like
these when graphics card VRAM usage is high:

------------[ cut here ]------------
WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40()
Hardware name: System Product Name
Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f-dirty #174
Call Trace:
[<ffffffff81058c84>] ? warn_slowpath_common+0x74/0xb0
[<ffffffff8129273c>] ? radeon_fence_ref+0x2c/0x40
[<ffffffff8125e95c>] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0
[<ffffffff8125f17c>] ? ttm_mem_evict_first+0x1dc/0x2a0
[<ffffffff81264452>] ? ttm_bo_man_get_node+0x62/0xb0
[<ffffffff8125f4ce>] ? ttm_bo_mem_space+0x28e/0x340
[<ffffffff8125fb0c>] ? ttm_bo_move_buffer+0xfc/0x170
[<ffffffff810de172>] ? kmem_cache_alloc+0xb2/0xc0
[<ffffffff8125fc15>] ? ttm_bo_validate+0x95/0x110
[<ffffffff8125ff7c>] ? ttm_bo_init+0x2ec/0x3b0
[<ffffffff8129419a>] ? radeon_bo_create+0x18a/0x200
[<ffffffff81293e80>] ? radeon_bo_clear_va+0x40/0x40
[<ffffffff812a5342>] ? radeon_gem_object_create+0x92/0x160
[<ffffffff812a575c>] ? radeon_gem_create_ioctl+0x6c/0x150
[<ffffffff812a529f>] ? radeon_gem_object_free+0x2f/0x40
[<ffffffff81246b60>] ? drm_ioctl+0x420/0x4f0
[<ffffffff812a56f0>] ? radeon_gem_pwrite_ioctl+0x20/0x20
[<ffffffff810f53a4>] ? do_vfs_ioctl+0x2e4/0x4e0
[<ffffffff810e5588>] ? vfs_read+0x118/0x160
[<ffffffff810f55ec>] ? sys_ioctl+0x4c/0xa0
[<ffffffff810e5851>] ? sys_read+0x51/0xa0
[<ffffffff814b0612>] ? system_call_fastpath+0x16/0x1b

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
gpio/ich: Add missing spinlock init

As reported by CONFIG_DEBUG_SPINLOCK=y.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
gpio/mvebu-gpio: Make mvebu-gpio depend on OF_CONFIG

When building without device tree support (for the mv78x00 SoCs for
example), the build failed because of_irq_count is undeclared. However
mvebu-gpio is not designed to build without device tree support. So
make it depends on OF_CONFIG, remove the #ifdef OF_CONFIG line and the
platform_device_id.

Tested on RD-78x00-mASA, DB-78460-BP, DB-88F6710-BP-DDR3,
DB-MV784MP-GP, Mirabox and OpenBlocks AX3.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
8139cp: Prevent dev_close/cp_interrupt race on MTU change

commit:  cb64edb6b89491edfdbae52ba7db9a8b8391d339 upstream

Above commit may introduce a race between cp_interrupt and dev_close
/ change MTU / dev_open up state. Changes cp_interrupt to tolerate
this.  Change spin_locking in cp_interrupt to avoid possible
but unobserved race.

Reported-by: "Francois Romieu" <romieu@fr.zoreil.com>

Tested on virtual hardware, Tx MTU size up to 4096, max tx payload
    was ping -s 4068 for MTU of 4096. No real hardware, need test
    assist.

Signed-off-by: "John Greene" <jogreene@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: "David Woodhouse" <David.Woodhouse@intel.com>
Tested-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drm/radeon: don't leave fence blocked process on failed GPU reset

Force all fence to signal if GPU reset failed so no process get stuck
on waiting fence.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/radeon: avoid deadlock in pm path when waiting for fence

radeon_fence_wait_empty_locked should not trigger GPU reset as no
place where it's call from would benefit from such thing and it
actually lead to a kernel deadlock in case the reset is triggered
from pm codepath. Instead force ring completion in place where it
makes sense or return early in others.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/radeon: restore modeset late in GPU reset path

Modeset path seems to conflict sometimes with the memory management
leading to kernel deadlock. This move modesetting reset after GPU
acceleration reset.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/radeon: add support for MEM_WRITE packet

To make it easier to debug some lockup from userspace add support
to MEM_WRITE packet.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
solos-pci: add GPIO support for newer versions on Geos board

dwmw2: Tidy up a little, simpler matching on which GPIO is being accessed,
       only register on newer boards, register under PCI device instead of
       duplicating them under each ATM device.

Signed-off-by: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
solos-pci: remove superfluous debug output

Signed-off-by: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>