Devices that do not have a special driver are handled by the generic
driver. This patch does the same thing using device groups; Instead of
forcing a particular driver, the appropriate driver is picked up by
udev. As a consequence, one can now move a device from generic to
specific handling by a simple rebind. By adding a new device id to the
generic driver, the same thing can be done in reverse.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Most HID drivers do not need to know what bus driver is in use.
A generic group driver can drive any hid device, and the device
list should not need to be duplicated for each new bus.

This patch adds wildcard matching to the HID bus, simplifying device
list handling for group drivers.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In order to allow the report descriptor to influence the hid device
properties, one needs to parse the descriptor early, without reference
to any driver. Scan the descriptor for group information during device
add, before the device has been broadcast to userland. The device
modalias will contain group information which can be used to
differentiate between modules. For starters, just handle the generic
group.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID devices are only partially presented to userland.  Hotplugged
devices emit events containing a modalias based on the basic bus,
vendor and product entities. However, in practise a hid device can
depend on details such as a single usb interface or a particular item
in a report descriptor.

This patch adds a device group to the hid device id, and broadcasts it
using uevent and the device modalias.  The module alias generation is
modified to match. As a consequence, a device with a non-zero group
will be processed by the corresponding group driver instead of by the
generic hid driver.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The low-level driver can read the report descriptor, but it cannot
determine driver-specific changes to it. The hid core can fixup
and parse the report descriptor during driver attach, but does
not have direct access to the descriptor when doing so.

To be able to handle attach/detach of hid drivers properly,
a semantic change to hid_parse_report() is needed. This function has
been used in two ways, both as descriptor reader in the ll drivers and
as a parsor in the probe of the drivers. This patch splits the usage
by introducing hid_open_report(), and modifies the hid_parse() macro
to call hid_open_report() instead. The only usage of hid_parse_report()
is then to read and store the device descriptor. As a consequence, we
can handle the report fixups automatically inside the hid core.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Tested-by: NNikolai Kondrashov <spbnick@gmail.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The current code allows several consecutive calls to hid_parse_report(),
which may have happened to work before, but would cause a memory leak
and generally be incorrect. This patch collects all the reports
before sending them once.

Cc: Nestor Lopez Casado <nlopezcasad@logitech.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Upcoming changes will split the semantics of hid_parse_report()
and hid_parse(), so make sure drivers use hid_parse() in probe().
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When the force changes went in back in 3.3.0, we ended up returning
disconnected in the !force case, and the connected in when forced,
as it hit the hardcoded check.

Fix it so all exits go via the hardcoded check and stop spurious
modesets on platforms with hardcoded EDIDs.

Reported-by: Evan McNabb (Red Hat)
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

During DRM release, all the FBs and gem objects are released. If
a gem object is being used as a FB and set to a crtc, it must not
be freed before releasing the framebuffer first.

If FBs are released first, the crtc using the FB is disabled first
so now the GEM object can be freed safely. The CRTC will be enabled
again when the driver restores fbdev mode.
Signed-off-by: NPrathyush K <prathyush.k@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

NUL-terminate after strncpy.

If the parameter "profile" has length 16 or more, then strncpy
leaves "string" with no NUL terminator, so the following search
for '\n' may read beyond the end of that 16-byte buffer.
If it finds a newline there, then it will also write beyond the
end of that stack buffer.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The output of "make versioncheck" points a incorrect include of
version.h in the drivers/gpu/drm/gma500/mdfld_dsi_output.h:

drivers/gpu/drm/gma500/mdfld_dsi_output.h: 32 linux/version.h not needed.

If we take a look in the file, we can agree to remove it.

Cc: David Airlie <airlied@linux.ie>
Cc: <dri-devel@lists.freedesktop.org>
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If AGP is placed in the middle, the size_af is off-by-one, it results
in VRAM being placed at 0x7fffffff instead of 0x8000000.

v2: fix the vram_start setup.
v3: also fix r7xx & newer ASIC

Reported-by: russiane39 on #radeon
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Free event and restore event_space only when page_flip->flags has
DRM_MODE_PAGE_FLIP_EVENT if page_flip() is failed.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms:
fix analog load detection on DVI-I connectors] is obviously wrong, and
it's the culprit of the regression on my workstation with DVI-analog
connection resulting in the blank output.

Fixed the typo now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 4f5ca836 "HID: hid-input: add support for HID devices reporting
Battery Strength" added the CONFIG_HID_BATTERY_STRENGTH option to report
the battery strength of HID devices.  The commit log explicitly mentions
it not working properly with recent userspace, but it is default y
anyway.  This is rather odd, and actually causes problems on real
systems.

This works around Fedora bug
https://bugzilla.redhat.com/show_bug.cgi?id=806295Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Allows this module to load correctly with certain debugging options on.

Reported on irc by scientes
Signed-off-by: NDave Airlie <airlied@redhat.com>

Forbid port runtime pm by default because it has known hotplug issue.
User can allow it by, for example

echo auto > /sys/devices/pci0000:00/0000:00:1f.2/ata2/power/control
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This reverts commit 6fe0d062.

Paul bisected this regression.

The conversion was done blindly and is wrong, as it does not provide a
primary handler to disable the level type irq on the device level.
Neither does it set the IRQF_ONESHOT flag which handles that at the irq
line level.  This can't be done as the interrupt might be shared, though
we might extend the core to force it.

So an interrupt on this line will wake up the thread, but immediately
unmask the irq after that.  Due to the interrupt being level type the
hardware interrupt is raised over and over and prevents the irq thread
from handling it.  Fail.

request_irq() unfortunately does not refuse such a request and the patch
was obviously never tested with real interrupts.
Bisected-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Not only do the pageflip work without it at non-native modes (i.e. with
the panel fitter enabled), it also causes normal (non-pageflipped)
modesets to fail.
Reported-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Wanted-by-for-fixes: Dave Airlie <airlied@gmail.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some shortcomings introduced into pci_restore_state() by commit
26f41062 ("PCI: check for pci bar restore completion and retry")
have been fixed by recent commit ebfc5b80 ("PCI: Fix regression in
pci_restore_state(), v3"), but that commit treats all PCI devices as
those with Type 0 configuration headers.

That is not entirely correct, because Type 1 and Type 2 headers have
different layouts.  In particular, the area occupied by BARs in Type 0
config headers contains the secondary status register in Type 1 ones and
it doesn't make sense to retry the restoration of that register even if
the value read back from it after a write is not the same as the written
one (it very well may be different).

For this reason, make pci_restore_state() only retry the restoration
of BARs for Type 0 config headers.  This effectively makes it behave
as before commit 26f41062 for all header types except for Type 0.
Tested-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Upon lastclose(), we switch back to the fbcon configuration. This
requires taking the mode_config lock in order to serialise the change
with output probing elsewhere.
Reported-by: NOleksij Rempel <bug-track@fisher-privat.net>
References: https://bugs.freedesktop.org/show_bug.cgi?id=48652Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Forget to unreserve after pinning.  This can lead to problems in
soft reset and resume.

v2: rework patch as per Michel's suggestion.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

My rv515 card is very flaky with msi enabled. Every so often it loses a rearm
and never comes back, manually banging the rearm brings it back.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This regression has been introduced in

commit ca9bfa7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 14:49:20 2012 +0100

    drm/i915: fixup interlaced vertical timings confusion, part 1

Unfortunately that commit failed to take into account that the lvds
code does some special adjustements to the crtc timings for upscaling
an centering.

Fix this by explicitly computing crtc timings in the lvds mode fixup
function and setting a special flag in mode->private_flags if the crtc
timings have been adjusted.

v2: Add a comment to explain the new mode driver private flag,
suggested by Eugeni Dodonov.

v3: Kill the confusing and now redundant set_crtcinfo call in
intel_fixed_panel_mode, noticed by Chris Wilson.
Reported-and-Tested-by: NHans de Bruin <jmdebruin@xmsnet.nl>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit 26f41062 ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.

First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one).  Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt.  Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.

All of this actually caused resume failures for some devices on Mikko's
system.

To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value.  Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 18a4d0a2 ("[SCSI] Handle disk devices which can not process
medium access commands") introduced a bug in which we would attempt to
dereference the scsi driver even when the device had no ULD attached.

Ensure that a driver is registered and make the driver accessor function
more resilient to errors during device discovery.
Reported-by: NElric Fu <elricfu1@gmail.com>
Reported-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As reported by David Gibson, current code handles PAGE_SIZE != 4k
completely wrong which can lead to guest memory corruption errors:

- page_to_balloon_pfn is wrong: e.g. on system with 64K page size
 it gives the same pfn value for 16 different pages.

- we also need to convert back to linux pfns when we free.

- for each linux page we need to tell host about multiple balloon
  pages, but code only adds one pfn to the array.

This patch fixes all that, tested with a 64k ppc64 kernel.
Reported-by: NDavid Gibson <david@gibson.dropbear.id.au>
Tested-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Although virtio config space fields are usually in guest-native endian,
the spec for the virtio balloon device explicitly states that both fields
in its config space are little-endian.

However, the current virtio_balloon driver does not have a suitable endian
swap for the 'num_pages' field, although it does have one for the 'actual'
field.  This patch corrects the bug, adding sparse annotation while we're
at it.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.

This 'depends on' was in the original patch from Russell King, but was
erroneously removed by me when making this option user-selectable in
commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.)  This
patch remedies that.

Apologies to Russell King for breaking his originally working patch.

Also, thanks to Grazvydas Ignotas for reporting the same problem.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The change
    commit 461cbe77
    Author: Gregory Bean <gbean@codeaurora.org>
    Date:   Wed Jul 28 10:22:13 2010 -0700

        video: msm: Fix section mismatch in mddi.c.

fixes a section mismatch between the board file and the driver's probe
function, however, it misses the additional mismatches between the
probe function and some routines it calls.  Fix these up as well.
Signed-off-by: NDavid Brown <davidb@codeaurora.org>

The AMBA bus regulator support is being used to model on/off switches
for power domains which isn't terribly idiomatic for modern kernels with
the generic power domain code and creates integration problems on platforms
which don't use regulators for their power domains as it's hard to tell
the difference between a regulator that is needed but failed to be provided
and one that isn't supposed to be there (though DT does make that easier).

Platforms that wish to use the regulator API to manage their power domains
can indirect via the power domain interface.

This feature is only used with the vape supply of the db8500 PRCMU
driver which supplies the UARTs and MMC controllers, none of which have
support for managing vcore at runtime in mainline (only pl022 SPI
controller does).  Update that supply to have an always_on constraint
until the power domain support for the system is updated so that it is
enabled for these users, this is likely to have no impact on practical
systems as probably at least one of these devices will be active and
cause AMBA to hold the supply on anyway.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If, in __persistent_ram_init(), the call to
persistent_ram_buffer_init() fails or the call to
persistent_ram_init_ecc() fails then we fail to free the memory we
allocated to 'prz' with kzalloc() - thus leaking it.

To prevent the leaks I consolidated all error exits from the function
at a 'err:' label at the end and made all error cases jump to that
label where we can then make sure we always free 'prz'. This is safe
since all the situations where the code bails out happen before 'prz'
has been stored anywhere and although we'll do a redundant kfree(NULL)
call in the case of kzalloc() itself failing that's OK since kfree()
deals gracefully with NULL pointers and I felt it was more important
to keep all error exits at a single location than to avoid that one
harmless/redundant kfree() on a error path.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NColin Cross <ccross@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If copy_to_user() fails in the WLAN_CMD_GET_NODE_LIST case of the
switch in drivers/staging/vt6656/ioctl.c::private_ioctl() we'll leak
the memory allocated to 'pNodeList'. Fix that by kfree'ing the memory
in the failure case.
Also remove a pointless cast (to type 'PSNodeList') of a kmalloc()
return value - kmalloc() returns a void pointer that is implicitly
converted, so there is no need for an explicit cast.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix crash after issuing:
	echo hmc5843 0x1e > /sys/class/i2c-dev/i2c-2/device/new_device

	[   37.180999] device: '2-001e': device_add
	[   37.188293] bus: 'i2c': add device 2-001e
	[   37.194549] PM: Adding info for i2c:2-001e
	[   37.200958] bus: 'i2c': driver_probe_device: matched device 2-001e with driver hmc5843
	[   37.210815] bus: 'i2c': really_probe: probing driver hmc5843 with device 2-001e
	[   37.224884] HMC5843 initialized
	[   37.228759] ------------[ cut here ]------------
	[   37.233612] kernel BUG at mm/slab.c:505!
	[   37.237701] Internal error: Oops - BUG: 0 [#1] PREEMPT
	[   37.243103] Modules linked in:
	[   37.246337] CPU: 0    Not tainted  (3.3.1-gta04+ #28)
	[   37.251647] PC is at kfree+0x84/0x144
	[   37.255493] LR is at kfree+0x20/0x144
	[   37.259338] pc : [<c00b408c>]    lr : [<c00b4028>]    psr: 40000093
	[   37.259368] sp : de249cd8  ip : 0000000c  fp : 00000090
	[   37.271362] r10: 0000000a  r9 : de229eac  r8 : c0236274
	[   37.276855] r7 : c09d6490  r6 : a0000013  r5 : de229c00  r4 : de229c10
	[   37.283691] r3 : c0f00218  r2 : 00000400  r1 : c0eea000  r0 : c00b4028
	[   37.290527] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
	[   37.298095] Control: 10c5387d  Table: 9e1d0019  DAC: 00000015
	[   37.304107] Process sh (pid: 91, stack limit = 0xde2482f0)
	[   37.309844] Stack: (0xde249cd8 to 0xde24a000)
	[   37.314422] 9cc0:                                                       de229c10 de229c00
	[   37.322998] 9ce0: de229c10 ffffffea 00000005 c0236274 de140a80 c00b4798 dec00080 de140a80
	[   37.331573] 9d00: c032f37c dec00080 000080d0 00000001 de229c00 de229c10 c048d578 00000005
	[   37.340148] 9d20: de229eac 0000000a 00000090 c032fa40 00000001 00000000 00000001 de229c10
	[   37.348724] 9d40: de229eac 00000029 c075b558 00000001 00000003 00000004 de229c10 c048d594
	[   37.357299] 9d60: 00000000 60000013 00000018 205b0007 37332020 3432322e 5d343838 c0060020
	[   37.365905] 9d80: de251600 00000001 00000000 de251600 00000001 c0065a84 de229c00 de229c48
	[   37.374481] 9da0: 00000006 0048d62c de229c38 de229c00 de229c00 de1f6c00 de1f6c20 00000001
	[   37.383056] 9dc0: 00000000 c048d62c 00000000 de229c00 de229c00 de1f6c00 de1f6c20 00000001
	[   37.391632] 9de0: 00000000 c048d62c 00000000 c0330164 00000000 de1f6c20 c048d62c de1f6c00
	[   37.400207] 9e00: c0330078 de1f6c04 c078d714 de189b58 00000000 c02ccfd8 de1f6c20 c0795f40
	[   37.408782] 9e20: c0238330 00000000 00000000 c02381a8 de1b9fc0 de1f6c20 de1f6c20 de249e48
	[   37.417358] 9e40: c0238330 c0236bb0 decdbed8 de7d0f14 de1f6c20 de1f6c20 de1f6c54 de1f6c20
	[   37.425933] 9e60: 00000000 c0238030 de1f6c20 c078d7bc de1f6c20 c02377ec de1f6c20 de1f6c28
	[   37.434509] 9e80: dee64cb0 c0236138 c047c554 de189b58 00000000 c004b45c de1f6c20 de1f6cd8
	[   37.443084] 9ea0: c0edfa6c de1f6c00 dee64c68 de1f6c04 de1f6c20 dee64cb8 c047c554 de189b58
	[   37.451690] 9ec0: 00000000 c02cd634 dee64c68 de249ef4 de23b008 dee64cb0 0000000d de23b000
	[   37.460266] 9ee0: de23b007 c02cd78c 00000002 00000000 00000000 35636d68 00333438 00000000
	[   37.468841] 9f00: 00000000 00000000 001e0000 00000000 00000000 00000000 00000000 0a10cec0
	[   37.477416] 9f20: 00000002 de249f80 0000000d dee62990 de189b40 c0234d88 0000000d c010c354
	[   37.485992] 9f40: 0000000d de210f28 000acc88 de249f80 0000000d de248000 00000000 c00b7bf8
	[   37.494567] 9f60: de210f28 000acc88 de210f28 000acc88 00000000 00000000 0000000d c00b7ed8
	[   37.503143] 9f80: 00000000 00000000 0000000d 00000000 0007fa28 0000000d 000acc88 00000004
	[   37.511718] 9fa0: c000e544 c000e380 0007fa28 0000000d 00000001 000acc88 0000000d 00000000
	[   37.520294] 9fc0: 0007fa28 0000000d 000acc88 00000004 00000001 00000020 00000002 00000000
	[   37.528869] 9fe0: 00000000 beab8624 0000ea05 b6eaebac 600d0010 00000001 00000000 00000000
	[   37.537475] [<c00b408c>] (kfree+0x84/0x144) from [<c0236274>] (device_add+0x530/0x57c)
	[   37.545806] [<c0236274>] (device_add+0x530/0x57c) from [<c032fa40>] (iio_device_register+0x8c8/0x990)
	[   37.555480] [<c032fa40>] (iio_device_register+0x8c8/0x990) from [<c0330164>] (hmc5843_probe+0xec/0x114)
	[   37.565338] [<c0330164>] (hmc5843_probe+0xec/0x114) from [<c02ccfd8>] (i2c_device_probe+0xc4/0xf8)
	[   37.574737] [<c02ccfd8>] (i2c_device_probe+0xc4/0xf8) from [<c02381a8>] (driver_probe_device+0x118/0x218)
	[   37.584777] [<c02381a8>] (driver_probe_device+0x118/0x218) from [<c0236bb0>] (bus_for_each_drv+0x4c/0x84)
	[   37.594818] [<c0236bb0>] (bus_for_each_drv+0x4c/0x84) from [<c0238030>] (device_attach+0x78/0xa4)
	[   37.604125] [<c0238030>] (device_attach+0x78/0xa4) from [<c02377ec>] (bus_probe_device+0x28/0x9c)
	[   37.613433] [<c02377ec>] (bus_probe_device+0x28/0x9c) from [<c0236138>] (device_add+0x3f4/0x57c)
	[   37.622650] [<c0236138>] (device_add+0x3f4/0x57c) from [<c02cd634>] (i2c_new_device+0xf8/0x19c)
	[   37.631805] [<c02cd634>] (i2c_new_device+0xf8/0x19c) from [<c02cd78c>] (i2c_sysfs_new_device+0xb4/0x130)
	[   37.641754] [<c02cd78c>] (i2c_sysfs_new_device+0xb4/0x130) from [<c0234d88>] (dev_attr_store+0x18/0x24)
	[   37.651611] [<c0234d88>] (dev_attr_store+0x18/0x24) from [<c010c354>] (sysfs_write_file+0x10c/0x140)
	[   37.661193] [<c010c354>] (sysfs_write_file+0x10c/0x140) from [<c00b7bf8>] (vfs_write+0xb0/0x178)
	[   37.670410] [<c00b7bf8>] (vfs_write+0xb0/0x178) from [<c00b7ed8>] (sys_write+0x3c/0x68)
	[   37.678833] [<c00b7ed8>] (sys_write+0x3c/0x68) from [<c000e380>] (ret_fast_syscall+0x0/0x3c)
	[   37.687683] Code: 1593301c e5932000 e3120080 1a000000 (e7f001f2)
	[   37.700775] ---[ end trace aaf805debdb69390 ]---

Client data was assigned to iio_dev structure in probe but in
hmc5843_init_client function casted to private driver data structure which
is wrong. Possibly calling mutex_init(&data->lock); corrupt data
which the lead to above crash.
Signed-off-by: NMarek Belisko <marek.belisko@open-nandra.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ST variants of the PL031 all require bit 26 in the control register
to be set before they work properly.  Discovered this when testing on
the Nomadik board where it would suprisingly just stand still.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

RTC stores time and date in several registers.  Due to the fact that
these registers can't be read instantaneously, there is a chance that
reading from counting registers gives an error of one minute, one hour,
one day, etc.

To address this issue, the RTC has hardware support to copy the RTC
counting registers to static shadowed registers.  The current
implementation does not use this feature, and in a stress test, we can
reproduce this error at a rate of around two times per 300000 readings.

Fix the implementation to ensure that the right snapshot of time is
captured.
Signed-off-by: NKonstantin Shlyakhovoy <x0155534@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>
Acked-by: NMykola Oleksiienko <x0174904@ti.com>
Acked-by: NOleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
Acked-by: NGraeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Driver data field is a pointer, hence assigning that to an integer results
in compilation warnings.

Fixes following compilation warnings:

  drivers/rtc/rtc-s3c.c: In function `s3c_rtc_get_driver_data':
  drivers/rtc/rtc-s3c.c:452:3: warning: return makes integer from pointer without a cast [enabled by default]
  drivers/rtc/rtc-s3c.c: At top level:
  drivers/rtc/rtc-s3c.c:674:3: warning: initialization makes pointer from integer without a cast [enabled by default]
  drivers/rtc/rtc-s3c.c:674:3: warning: (near initialization for `s3c_rtc_dt_match[1].data') [enabled by default]
  drivers/rtc/rtc-s3c.c:677:3: warning: initialization makes pointer from integer without a cast [enabled by default]
  drivers/rtc/rtc-s3c.c:677:3: warning: (near initialization for `s3c_rtc_dt_match[2].data') [enabled by default]
  drivers/rtc/rtc-s3c.c:680:3: warning: initialization makes pointer from integer without a cast [enabled by default]
  drivers/rtc/rtc-s3c.c:680:3: warning: (near initialization for `s3c_rtc_dt_match[3].data') [enabled by default]
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this error:

  drivers/rtc/rtc-s3c.c: At top level:
  drivers/rtc/rtc-s3c.c:671:3: error: request for member `data' in something not a structure or union
  drivers/rtc/rtc-s3c.c:674:3: error: request for member `data' in something not a structure or union
  drivers/rtc/rtc-s3c.c:677:3: error: request for member `data' in something not a structure or union
  drivers/rtc/rtc-s3c.c:680:3: error: request for member `data' in something not a structure or union
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

efi_rtc_init() uses platform_driver_probe(), so there's no need to also
set efi_rtc_driver's probe member (as it won't be used anyway).  This
fixes a modpost section mismatch warning (as efi_rtc_probe() validly is
__init).
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>