Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.

Grouping the various iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
differently (or duplicated) in each driver.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Return error on out of range cpsdvsr value.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NVirupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

We leak the memory allocated to 'phi' when the variable goes out of scope
in hfcsusb_ph_info().
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Russell King said:
>
> So, to summarize what its doing:
>
> 1. It allocates buffers for rx and tx.
> 2. It maps them with dma_map_single().
>       This transfers ownership of the buffer to the DMA device.
> 3. In ep93xx_xmit,
> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
>       This violates the DMA buffer ownership rules - the CPU should
>       not be writing to this buffer while it is (in principle) owned
>       by the DMA device.
> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
>       This transfers ownership of the buffer to the CPU, which surely
>       is the wrong direction.
> 4. In ep93xx_rx,
> 4a. It calls dma_sync_single_for_cpu() for the buffer.
>       This at least transfers the DMA buffer ownership to the CPU
>       before the CPU reads the buffer
> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
>       At no point does it transfer ownership back to the DMA device.
> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
>       This transfers ownership of the buffer to the CPU.
> 6. It frees the buffer.
>
> While it may work on ep93xx, it's not respecting the DMA API rules,
> and with DMA debugging enabled it will probably encounter quite a few
> warnings.

This patch fixes these violations.
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: NPetr Stetiar <ynezz@true.cz>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit a197b59a (mm: fail GFP_DMA allocations when ZONE_DMA is not
configured) made page allocator to return NULL if GFP_DMA is set but
CONFIG_ZONE_DMA is disabled.

This causes ep93xx_eth to fail:

 WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
 Modules linked in:
 [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
 [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
 [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
 [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
 [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
 [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
 [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
 [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
 [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
 [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
 [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
 [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
 [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)

Since there is no restrictions for DMA on ep93xx, we can fix this by just
removing the GFP_DMA flag from the call.
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: NPetr Stetiar <ynezz@true.cz>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We can use simply kmalloc() to allocate the buffers. This also simplifies the
code and allows us to perform DMA sync operations more easily.

Memory is allocated with only GFP_KERNEL since there are no DMA allocation
restrictions on this platform.
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Tested-by: NPetr Stetiar <ynezz@true.cz>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We shouldn't use NULL for any DMA API functions, unless we are dealing with
ISA or EISA device. So pass correct struct dev pointer to these functions.
Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDaniel Hellstrom <daniel@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix:
/tmp/ccvoZ6h8.s: Assembler messages:
/tmp/ccvoZ6h8.s:284: Warning: register range not in ascending order
/tmp/ccvoZ6h8.s:881: Warning: register range not in ascending order
/tmp/ccvoZ6h8.s:1087: Warning: register range not in ascending order

by ensuring that we have temporary variables placed into specific
registers.  Reorder the code a bit to allow the resulting assembly
to be slightly more optimal.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We were clearing out the multicast filter whenever the interface was
upped, and not setting the mode bits correctly.  This can cause
problems if there are any multicast addresses already set at this
point, or if ALLMULTI was set.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Without this the compiler can (and does) optimize register reads away
from within loops, and other such optimizations.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

One of the legit warnings 'make W=3 drivers/ide/ide-cd.c'
generates is:
drivers/ide/ide-cd.c: In function ide_cd_do_request
drivers/ide/ide-cd.c:828:2: warning: conversion to int from \
unsigned int may change the sign of the result
drivers/ide/ide-cd.c:833:2: warning: conversion to int from \
unsigned int may change the sign of the result

nsectors is declared int, should be unsigned int.

blk_rq_sectors() returns unsigned int, and ide_complete_rq
expects unsigned int as well.  Fixes both warnings.
Signed-off-by: NConnor Hansen <cmdkhh@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The mach-nomadik machine did not compile properly due to bad
ux500-specific functions being called. Introduce new state
variables to fix this up.
Reported-by: NAxel Lin <axel.lin@gmail.com>
Cc: Alessandro Rubini <rubini@unipv.it>
Cc: Prafulla Wadaskar <prafulla.wadaskar@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

struct iio_info introduced a bug where the second channel of a MAX518 can't be
used. This commit fixes the typo (using max518 instead of the max517 struct).
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

! has higher precedence than !=.  H_RDY is 8 and since neither 0 nor
1 are equal to 8 the original condition was always true.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

int i is only needed if CONFIG_ACPI is set
so move it within a new ifdef so kernels without ACPI
don't allocate space for nothing. Fixes warning too.
Signed-off-by: NConnor Hansen <cmdkhh@gmail.com>
Signed-off-by: NPeter Jones <pjones@redhat.com>
[v2: Fixed warning when CONFIG_ACPI was defined]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad@kernel.org>

The patch moves rtc driver for PKUnity-v3 SoC from arch/unicore32/kernel/
to drivers/rtc/, with renaming it to rtc-puv3.c.
Also, Kconfig, Makefile, and MAINTAINERS are modified correspondingly.
Signed-off-by: NGuan Xuetao <gxt@mprc.pku.edu.cn>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Each eTSEC device should own localized filer table.
Signed-off-by: NJiajun Wu <b06378@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2.
Signed-off-by: NSteffen Sledz <sledz@dresearch-fe.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

One new offender detected by the recently increased type checking in
platform_get_drvdata():

drivers/rtc/rtc-m41t93.c: In function ‘m41t93_remove’:
drivers/rtc/rtc-m41t93.c:192: warning: passing argument 1 of ‘platform_get_drvdata’ from incompatible pointer type

Use spi_get_drvdata() instead of platform_get_drvdata(), cfr. commit
42fea15d ("spi/rtc-{ds1390,ds3234,m41t94}:
Use spi_get_drvdata() for SPI devices")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().

To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.

Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The cx23885 driver was including staging/altera.h, but that file has
moved back into the driver directory.

Why a non-staging driver was including a staging driver is beyond me,
but this fixes the build so everything is happy for now.

For the record, it's not ok for a non-staging driver to depend on a
staging one, as that implies that the non-staging one should also be in
the staging tree if that's needed.

Cc: Igor M. Liplianin <liplianin@netup.ru>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The flush_to_ldisc() work entry has special logic to notice when it has
seen the original tail of the data queue, and it avoids continuing the
flush if it sees that _original_ tail rather than the current tail.

This logic can trigger in case somebody is constantly adding new data to
the tty while the flushing is active - and the intent is to avoid
excessive CPU usage while flushing the tty, especially as we used to do
this from a softirq context which made it non-preemptible.

However, since we no longer re-arm the work-queue from within itself
(because that causes other trouble: see commit a5660b41 "tty: fix
endless work loop when the buffer fills up"), this just leads to
possible hung tty's (most easily seen in SMP and with a test-program
that floods a pty with data - nobody seems to have reported this for any
real-life situation yet).

And since the workqueue isn't done from timers and softirq's any more,
it's doubtful whether the CPU useage issue is really relevant any more.
So just remove the logic entirely, and see if anybody ever notices.

Alternatively, we might want to re-introduce the "re-arm the work" for
just this case, but then we'd have to re-introduce the delayed work
model or some explicit timer, which really doesn't seem worth it for
this.
Reported-and-tested-by: NGuillaume Chazarain <guichaz@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current RE'd code causes blank screens and
display problems on a lot of systems.  So disable
it by default for now.  It can still be enabled
by setting the audio parameter to 1.  E.g.:
radeon.audio=1

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38010
https://bugs.freedesktop.org/show_bug.cgi?id=27731
https://bugs.freedesktop.org/show_bug.cgi?id=35970
https://bugs.freedesktop.org/show_bug.cgi?id=26195
and many other reported problems.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On my x86_64 system with >4GB of ram and swiotlb instead of
a hardware iommu (because I have a VIA chipset), the call
to pci_set_dma_mask (see below) with 40bits returns an error.

But it seems that the radeon driver is designed to have
need_dma32 = true exactly if pci_set_dma_mask is called
with 32 bits and false if it is called with 40 bits.

I have read somewhere that the default are 32 bits. So if the
call fails I suppose that need_dma32 should be set to true.

And indeed the patch fixes the problem I have had before
and which I had described here:
http://choon.net/forum/read.php?21,106131,115940Acked-by: NAlex Deucher <alexdeucher@gmail.com>
cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Wierdly the kms parser never initialised the family, it wasn't really used
much, but the fmt checker patch started using it and it fell over.
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit a559d2c8.

Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc
when the option driver tries to bind to it.

So revert this as it doesn't seem to be needed at all.

Thanks to Michael Tokarev and Paweł Drobek for working on resolving this
issue.

Cc: Paweł Drobek <pawel.drobek@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The loops over connection ID strings in pm_runtime_clk_notify()
should actually iterate over the strings and not over the elements
of the first of them, so make them behave as appropriate.

This fixes a regression introduced by commit 600b776e
(OMAP1 / PM: Use generic clock manipulation routines for runtime PM).
Reported-and-tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to
the driver attempting to enable RSS on the PF device, which is not
supported by the i350.

When max_vfs is specified on an i350 adapter, set the number of RSS queues
to 1.

This issue affects 2.6.39 as well.

CC: stable@kernel.org
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Samsung GPIO drivers are always built-in when the relevant
platform is selected.  Change the Kconfig symbol to def_bool y
dependant on the platform.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

To work around controllers which can't properly plug events while
reset, ata_eh_reset() clears error states and ATA_PFLAG_EH_PENDING
after reset but before RESET is marked done.  As reset is the final
recovery action and full verification of devices including onlineness
and classfication match is done afterwards, this shouldn't lead to
lost devices or missed hotplug events.

Unfortunately, it forgot to thaw the port when clearing EH_PENDING, so
if the condition happens after resetting an empty port, the port could
be left frozen and EH will end without thawing it, making the port
unresponsive to further hotplug events.

Thaw if the port is frozen after clearing EH_PENDING.  This problem is
reported by Bruce Stenning in the following thread.

 http://thread.gmane.org/gmane.linux.kernel/1123265

stable: I think we should weather this patch a bit longer in -rcX
	before sending it to -stable.  Please wait at least a month
	after this patch makes upstream.  Thanks.

-v2: Fixed spelling in the comment per Dave Howorth.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NBruce Stenning <b.stenning@indigovision.com>
Cc: stable@kernel.org
Cc: Dave Howorth <dhoworth@mrc-lmb.cam.ac.uk>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

If CONFIG_PM is not set, init_iommu_pm_ops() introduced by commit
134fac3f (PCI / Intel IOMMU: Use
syscore_ops instead of sysdev class and sysdev) is not defined
appropriately.  Fix this issue.
Reported-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The data pointer should be freed in the error
cases of adis16400_trigger_handler().
Signed-off-by: NAndre Bartke <andre.bartke@gmail.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The kernel panic happens when we try to complete a pending
scan request while going to suspend state. The cause for this
kernel panic is accessing a freed memory (ar->arWmin). This
is freed before ar6k_cfg80211_scanComplete_event() getting
called where it is dereferenced.

RIP: 0010:[<ffffffffa042e726>]  [<ffffffffa042e726>] wlan_iterate_nodes+0x16/0xc0 [ath6kl]
RSP: 0018:ffff8800719fbce8  EFLAGS: 00010296
RAX: ffff880071bbcc00 RBX: ffff880037b22520 RCX: ffff880077413c80
RDX: ffff880037b221c0 RSI: ffffffffa041ef10 RDI: 0000000000000020
RBP: ffff8800719fbd18 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000400 R11: 0000000000000000 R12: 0000000000000010
R13: ffff8800719fbdd8 R14: 00007fff83a84b60 R15: 0000000000000001
FS:  00007fdccb8a7700(0000) GS:ffff880077400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000148 CR3: 0000000070604000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 1998, threadinfo ffff8800719fa000, task ffff880066712d80)
	Stack:
	0000000000000000 ffff880037b22520 0000000000000010 ffff8800719fbdd8
	00007fff83a84b60 0000000000000001 ffff8800719fbd28 ffffffffa0429fe2
	ffff8800719fbd58 ffffffffa041ee5f ffff8800719fbd58 ffff880037b22520
	Call Trace:
	[<ffffffffa0429fe2>] wmi_iterate_nodes+0x12/0x20 [ath6kl]
	[<ffffffffa041ee5f>] ar6k_cfg80211_scanComplete_event+0x3f/0xf0 [ath6kl]
	[<ffffffffa04245f1>] ar6000_close+0x61/0x100 [ath6kl]
	[<ffffffff814d6736>] __dev_close_many+0x96/0x100
	[<ffffffff814d688d>] dev_close_many+0x9d/0x120
	[<ffffffff814d6a48>] rollback_registered_many+0xe8/0x290
	[<ffffffff814d6d16>] unregister_netdevice_queue+0x96/0x100
	[<ffffffff814d6ea0>] unregister_netdev+0x20/0x30
	[<ffffffffa0420259>] ar6000_destroy+0x119/0x180 [ath6kl]
	[<ffffffffa043182a>] ar6k_cleanup_module+0x2a/0x33 [ath6kl]
	[<ffffffff81098fde>] sys_delete_module+0x19e/0x270
	[<ffffffff815d7542>] system_call_fastpath+0x16/0x1b
	Code: c3 0f 1f 40 00 48 89 df e8 68 ff ff ff eb df 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00
	8b af 28 01 00 00 4c 8d 7f 08 49 89 fc 48 89 f3 49 89 d6 41
	RIP  [<ffffffffa042e726>] wlan_iterate_nodes+0x16/0xc0 [ath6kl]
	RSP <ffff8800719fbce8>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Many Linux distributions would enable vesafb in order to display
early stage boot splash. In this case, we will get garbled X
Window screen if running X fbdev on psbfb.

This is because fb0 is occupied by vesafb while psbfb is on fb1.
They tried to drive the same pieces of hardware at the same
time. With unmodified X start-up, it would try to use default
fb0 framebuffer device and unfortunately it is now broken
becaues fb1 supersedes it.

We should let psbfb takeover framebuffer control from vesafb
to get around this problem.

See also commit : 4410f391Signed-off-by: NMichael Chang <mchang@novell.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets
in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When
there is no LVDS output the backlight support crashes so the patch also checks
for this before enabling it.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Implemented pre_reset and post_reset methods of the driver to prevent the
driver from being unbound upon a device reset. Because of this also the
asynchronous reset introduced to prevent a race condition is no longer necessary
(and sometimes causes problems, because it comes later then expected).
Signed-off-by: NArjan Mels <arjan.mels@gmx.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
Cc: Max Vozeler <max@vozeler.com>
Cc: usbip-devel <usbip-devel@lists.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Failure to set iio_poll_func private_data, causes zero pointer access
violations in all consumer trigger handlers.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Looks like a typo.
Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Reviewed-by: NPeter Huewe <peterhuewe@gmx.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>