crypto: qat - Enable all 32 IRQs

Enable interrupts from all 32 bundles.

Signed-off-by: Conor McLoughlin <conor.mcloughlin@intel.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Revert "PCI: Don't scan random busses in pci_scan_bridge()"

This reverts commit fc1b253141b3 ("PCI: Don't scan random busses in
pci_scan_bridge()") because it breaks CardBus on some machines.

David tested a Dell Latitude D505 that worked like this prior to
fc1b253141b3:

    pci 0000:00:1e.0: PCI bridge to [bus 01]
    pci 0000:01:01.0: CardBus bridge to [bus 02-05]

Note that the 01:01.0 CardBus bridge has a bus number aperture of
[bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus
number aperture, so accesses to buses 02-05 never reach CardBus.  This is
later patched up by yenta_fixup_parent_bridge(), which changes the
subordinate bus number of the 00:1e.0 PCI bridge:

    pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05

With fc1b253141b3, pci_scan_bridge() fails immediately when it notices that
we can't allocate a valid secondary bus number for the CardBus bridge, and
CardBus doesn't work at all:

    pci 0000:01:01.0: can't allocate child bus 01 from [bus 01]

I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic
into pci_scan_bridge() so we fix the bus number apertures up front.  But
I don't think we can do that before v3.17, so I'm going to revert this to
avoid the problem while we're working on the long-term fix.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=83441
Link: http://lkml.kernel.org/r/1409303414-5196-1-git-send-email-david.henningsson@canonical.com
Reported-by: David Henningsson <david.henningsson@canonical.com>
Tested-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.15+
Revert "PCI: Make sure bus number resources stay within their parents bounds"

This reverts commit 1820ffdccb9b ("PCI: Make sure bus number resources stay
within their parents bounds") because it breaks some systems with LSI Logic
FC949ES Fibre Channel Adapters, apparently by exposing a defect in those
adapters.

Dirk tested a Tyan VX50 (B4985) with this device that worked like this
prior to 1820ffdccb9b:

    bus: [bus 00-7f] on node 0 link 1
    ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07])
    pci 0000:00:0e.0: PCI bridge to [bus 0a]
    pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07])
    pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter)

Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS
defect in the PCI0 _CRS method.  But prior to 1820ffdccb9b, we didn't
enforce that aperture, and the FC adapter worked fine at 0a:00.0.

After 1820ffdccb9b, we notice that 00:0e.0's aperture is not contained in
the root bridge's aperture, so we reconfigure it so it *is* contained:

    pci 0000:00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring
    pci 0000:00:0e.0: PCI bridge to [bus 06-07]

This effectively moves the FC device from 0a:00.0 to 07:00.0, which should
be legal.  But when we enumerate bus 06, the FC device doesn't respond, so
we don't find anything.  This is probably a defect in the FC device.

Possible fixes (due to Yinghai):

    1) Add a quirk to fix the _CRS information based on what amd_bus.c read
       from the hardware

    2) Reset the FC device after we change its bus number

    3) Revert 1820ffdccb9b

Fix 1 would be relatively easy, but it does sweep the LSI FC issue under
the rug.  We might want to reconfigure bus numbers in the future for some
other reason, e.g., hotplug, and then we could trip over this again.

For that reason, I like fix 2, but we don't know whether it actually works,
and we don't have a patch for it yet.

This revert is fix 3, which also sweeps the LSI FC issue under the rug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84281
Reported-by: Dirk Gouders <dirk@gouders.net>
Tested-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.15+
CC: Yinghai Lu <yinghai@kernel.org>
[media] videobuf2-dma-sg: fix for wrong GFP mask to sg_alloc_table_from_pages

sg_alloc_table_from_pages() only allocates a sg_table, so it should just use
GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c
will call BUG_ON:

[  358.027515] ------------[ cut here ]------------
[  358.027546] kernel BUG at mm/slub.c:1416!
[  358.027558] invalid opcode: 0000 [#1] PREEMPT SMP
[  358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
[  358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167
[  358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014
[  358.027741] task: ffff880897c7d960 ti: ffff88089b4d4000 task.ti: ffff88089b4d4000
[  358.027753] RIP: 0010:[<ffffffff81196040>]  [<ffffffff81196040>] new_slab+0x280/0x320
[  358.027776] RSP: 0018:ffff88089b4d7ae8  EFLAGS: 00010002
[  358.027787] RAX: ffff880897c7d960 RBX: 0000000000000000 RCX: ffff88089b4d7b50
[  358.027798] RDX: 00000000ffffffff RSI: 0000000000000004 RDI: ffff88089f803b00
[  358.027809] RBP: ffff88089b4d7bb8 R08: 0000000000000000 R09: 0000000100400040
[  358.027821] R10: 0000160000000000 R11: ffff88109bc02c40 R12: 0000000000000001
[  358.027832] R13: ffff88089f8000c0 R14: ffff88089f803b00 R15: ffff8810bfcf4be0
[  358.027845] FS:  00007f83fe5c0700(0000) GS:ffff8810bfce0000(0000) knlGS:0000000000000000
[  358.027858] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  358.027868] CR2: 0000000001dfd568 CR3: 0000001097d5a000 CR4: 00000000000407e0
[  358.027878] Stack:
[  358.027885]  ffffffff81198860 ffff8810bfcf4be0 ffff880897c7d960 0000000000001b00
[  358.027905]  ffff880897c7d960 0000000000000000 ffff8810bfcf4bf0 0000000000000000
[  358.027924]  0000000000000000 0000000100000100 ffffffff813ef84a 00000004ffffffff
[  358.027944] Call Trace:
[  358.027956]  [<ffffffff81198860>] ? __slab_alloc+0x400/0x4e0
[  358.027973]  [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30
[  358.027985]  [<ffffffff81198f17>] __kmalloc+0x127/0x150
[  358.027997]  [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30
[  358.028009]  [<ffffffff813ef84a>] sg_kmalloc+0x1a/0x30
[  358.028023]  [<ffffffff813eff84>] __sg_alloc_table+0x74/0x180
[  358.028035]  [<ffffffff813ef830>] ? sg_kfree+0x20/0x20
[  358.028048]  [<ffffffff813f00af>] sg_alloc_table+0x1f/0x60
[  358.028061]  [<ffffffff813f0174>] sg_alloc_table_from_pages+0x84/0x1f0
[  358.028077]  [<ffffffffa007c3f9>] vb2_dma_sg_alloc+0x159/0x230 [videobuf2_dma_sg]
[  358.028095]  [<ffffffffa003d55a>] __vb2_queue_alloc+0x10a/0x680 [videobuf2_core]
[  358.028113]  [<ffffffffa003e110>] __reqbufs.isra.14+0x220/0x3e0 [videobuf2_core]
[  358.028130]  [<ffffffffa003e79d>] __vb2_init_fileio+0xbd/0x380 [videobuf2_core]
[  358.028147]  [<ffffffffa003f563>] __vb2_perform_fileio+0x5b3/0x6e0 [videobuf2_core]
[  358.028164]  [<ffffffffa003f871>] vb2_fop_read+0xb1/0x100 [videobuf2_core]
[  358.028184]  [<ffffffffa06dd2e5>] v4l2_read+0x65/0xb0 [videodev]
[  358.028198]  [<ffffffff811a243f>] vfs_read+0x8f/0x170
[  358.028210]  [<ffffffff811a30a1>] SyS_read+0x41/0xb0
[  358.028224]  [<ffffffff818f02e9>] system_call_fastpath+0x16/0x1b
[  358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff ff 0f 1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48
[  358.028415] RIP  [<ffffffff81196040>] new_slab+0x280/0x320
[  358.028432]  RSP <ffff88089b4d7ae8>
[  358.032208] ---[ end trace 6443240199c706e4 ]---

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org      # for v3.13 and up
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] videobuf2-core: add comments before the WARN_ON

Recently WARN_ON() calls have been added to warn if the driver is not
properly returning buffers to vb2 in start_streaming (if it fails) or
stop_streaming(). Add comments before those WARN_ON calls that refer
to the videobuf2-core.h header that explains what drivers are supposed
to do in these situations. That should help point developers in the
right direction if they see these warnings.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] videobuf2-core.h: fix comment

The comment for start_streaming that tells the developer with which vb2 state
buffers should be returned to vb2 gave the wrong state. Very confusing.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] vb2: fix vb2 state check when start_streaming fails

Commit bd994ddb2a12a3ff48cd549ec82cdceaea9614df (vb2: Fix stream start and
buffer completion race) broke the buffer state check in vb2_buffer_done.

So accept all three possible states there since I can no longer tell the
difference between vb2_buffer_done called from start_streaming or from
elsewhere.

Instead add a WARN_ON at the end of start_streaming that will check whether
any buffers were added to the done list, since that implies that the wrong
state was used as well.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@vger.kernel.org      # for v3.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] DocBook media: fix fieldname in struct v4l2_subdev_selection

Field 'rect' is really named 'r'.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] DocBook media: update version number and V4L2 changes

Note: the revision text for the v4l2_pix_format change from Laurent
erroneously mentioned 3.16 when it only got merged for 3.17. Fixed
that as well.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] vb2: fix plane index sanity check in vb2_plane_cookie()

It's also invalid when plane_no is equal to vb->num_planes

Signed-off-by: Zhaowei Yuan <zhaowei.yuan@samsung.com>
Cc: stable@vger.kernel.org      # for v3.7 and up
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] media/radio: fix radio-miropcm20.c build with io.h header file

Fix build errors in radio-miropcm20.c due to missing header file:

drivers/media/radio/radio-miropcm20.c: In function 'rds_waitread':
drivers/media/radio/radio-miropcm20.c:90:3: error: implicit declaration of function 'inb' [-Werror=implicit-function-declaration]
drivers/media/radio/radio-miropcm20.c: In function 'rds_rawwrite':
drivers/media/radio/radio-miropcm20.c:106:3: error: implicit declaration of function 'outb' [-Werror=implicit-function-declaration]

Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] adv7604: fix inverted condition

The log_status function should show HDMI information, but the test checking for
an HDMI input was inverted. Fix this.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org      # for v3.12 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] cx24123: fix kernel oops due to missing parent pointer

When I try to set the TV standard to e.g. PAL on my Hauppauge WinTV-HVR3000 I get
the following oops:

 9464.262345] CX24123: detected CX24123
[ 9464.262526] BUG: unable to handle kernel NULL pointer dereference at 0000000000000230
[ 9464.262555] IP: [<ffffffff816676b5>] acpi_i2c_install_space_handler+0x15/0xc0
[ 9464.262576] PGD 0
[ 9464.262584] Oops: 0000 [#1] PREEMPT SMP
[ 9464.262597] Modules linked in: cx24123 cx22702 cx88_dvb(+) videobuf_dvb cx88_vp3054_i2c cx88_blackbird cx8802 ir_lirc_codec ir_xmp_decoder ir_sanyo_decoder ir_jvc_decoder ir_mce_kbd_decoder ir_sharp_decoder lirc_dev ir_sony_decoder ir_rc6_decoder ir_nec_decoder ir_rc5_decoder rc_hauppauge wm8775 tuner_simple tuner_types tda9887 cx8800 cx88xx btcx_risc videobuf_dma_sg videobuf_core mt2131 s5h1409 tda8290 tuner cx25840 cx23885 altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core v4l2_common videodev media nouveau x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
[ 9464.262786] CPU: 2 PID: 2417 Comm: modprobe Not tainted 3.17.0-rc1-telek #322
[ 9464.262796] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014
[ 9464.262807] task: ffff881097959ad0 ti: ffff88109967c000 task.ti: ffff88109967c000
[ 9464.262817] RIP: 0010:[<ffffffff816676b5>]  [<ffffffff816676b5>] acpi_i2c_install_space_handler+0x15/0xc0
[ 9464.262834] RSP: 0018:ffff88109967fbd8  EFLAGS: 00010246
[ 9464.262843] RAX: 0000000000000000 RBX: ffff880892a89540 RCX: 0000000000000000
[ 9464.262853] RDX: 0000000080000001 RSI: ffff880892e75870 RDI: ffff880892a89540
[ 9464.262862] RBP: ffff88109967fbf8 R08: ffff881099b2ccc0 R09: ffff880891efa088
[ 9464.262872] R10: 0000000000000000 R11: 0000000000000022 R12: 0000000000000000
[ 9464.262883] R13: ffff880892a895b0 R14: 00000000ffffffed R15: ffff88089b48f800
[ 9464.262893] FS:  00007fe42b6d7700(0000) GS:ffff88089fc40000(0000) knlGS:0000000000000000
[ 9464.262904] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9464.262912] CR2: 0000000000000230 CR3: 0000001094078000 CR4: 00000000000407e0
[ 9464.262922] Stack:
[ 9464.262927]  ffff880892a89540 0000000000000000 ffff880892a895b0 ffff88109a155a80
[ 9464.262944]  ffff88109967fc20 ffffffff81666a36 0000000000000020 ffff880892a89540
[ 9464.262960]  ffffffffa01c8d40 ffff88109967fc40 ffffffff81666c67 ffff880892a89000
[ 9464.262977] Call Trace:
[ 9464.262987]  [<ffffffff81666a36>] i2c_register_adapter+0x166/0x340
[ 9464.262998]  [<ffffffff81666c67>] i2c_add_adapter+0x57/0x60
[ 9464.263011]  [<ffffffffa01e2c58>] cx24123_attach+0x108/0x1ba [cx24123]
[ 9464.263025]  [<ffffffffa01c5a76>] dvb_register+0x404/0x245b [cx88_dvb]
[ 9464.263039]  [<ffffffffa0059183>] ? videobuf_queue_core_init+0xe3/0x140 [videobuf_core]
[ 9464.263052]  [<ffffffffa01c54b1>] cx8802_dvb_probe+0x1e1/0x261 [cx88_dvb]
[ 9464.263066]  [<ffffffffa01a3b00>] cx8802_register_driver+0x190/0x20d [cx8802]
[ 9464.263077]  [<ffffffffa01cc000>] ? 0xffffffffa01cc000
[ 9464.263089]  [<ffffffffa01cc025>] dvb_init+0x25/0x27 [cx88_dvb]
[ 9464.263101]  [<ffffffff810002c4>] do_one_initcall+0x84/0x1c0
[ 9464.263113]  [<ffffffff811893fa>] ? __vunmap+0x9a/0x100
[ 9464.263125]  [<ffffffff81122a66>] load_module+0x1216/0x1790
[ 9464.263134]  [<ffffffff8111ff70>] ? __symbol_put+0x70/0x70
[ 9464.263145]  [<ffffffff811aa8cc>] ? vfs_read+0x11c/0x170
[ 9464.263156]  [<ffffffff811201d9>] ? copy_module_from_fd.isra.53+0x119/0x170
[ 9464.263168]  [<ffffffff81123116>] SyS_finit_module+0x76/0x80
[ 9464.263181]  [<ffffffff818d19e9>] system_call_fastpath+0x16/0x1b
[ 9464.263190] Code: 81 31 c0 e8 2e f6 e8 ff 48 83 c4 08 5b 5d eb de 66 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 53 41 be ed ff ff ff 48 8b 47 70 <48> 8b 80 30 02 00 00 48 85 c0 74 58 4c 8b 68 08 4d 85 ed 74 4f
[ 9464.263347] RIP  [<ffffffff816676b5>] acpi_i2c_install_space_handler+0x15/0xc0
[ 9464.263361]  RSP <ffff88109967fbd8>
[ 9464.263367] CR2: 0000000000000230
[ 9464.266919] ---[ end trace 57fd490bdb72e733 ]---

I traced this to a NULL i2c_adapter parent pointer when cx24123 creates its own
i2c adapter. The acpi_i2c_install_space_handler function appeared in 3.17, so
that's probably why this hasn't been seen before.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] cx2341x: fix kernel oops

The v4l2_ctrl_config struct must be zeroed before passing it to
v4l2_ctrl_new_custom(). This was always wrong, but with the recent
v4l2-ctrls.c changes this is now much more likely to lead to a
kernel bug.

This is the only place where this struct wasn't initialized properly.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Pridvorov Andrey <ua0lnj@bk.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] vb2: fix VBI/poll regression

The recent conversion of saa7134 to vb2 unconvered a poll() bug that
broke the teletext applications alevt and mtt. These applications
expect that calling poll() without having called VIDIOC_STREAMON will
cause poll() to return POLLERR. That did not happen in vb2.

This patch fixes that behavior. It also fixes what should happen when
poll() is called when STREAMON is called but no buffers have been
queued. In that case poll() will also return POLLERR, but only for
capture queues since output queues will always return POLLOUT
anyway in that situation.

This brings the vb2 behavior in line with the old videobuf behavior.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] DocBook media: fix the poll() 'no QBUF' documentation

Clarify what poll() returns if STREAMON was called but not QBUF.
Make explicit the different behavior for this scenario for
capture and output devices.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] DocBook media: improve the poll() documentation

The poll documentation was incomplete: document how events (POLLPRI)
are handled and fix the documentation of what poll does for display devices
and streaming I/O.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] em28xx: fix VBI handling logic

When both VBI and video are streaming, and video stream is stopped,
a subsequent trial to restart it will fail, because S_FMT will
return -EBUSY.

That prevents applications like zvbi to work properly.

Please notice that, while this fix it fully for zvbi, the
best is to get rid of streaming_users and res_get logic as a hole.

However, this single-line patch is better to be merged at -stable.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
md/raid1: intialise start_next_window for READ case to avoid hang

r1_bio->start_next_window is not initialised in the READ
case, so allow_barrier may incorrectly decrement
   conf->current_window_requests
which can cause raise_barrier() to block forever.

Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
cc: stable@vger.kernel.org (v3.13+)
Reported-by: Brassow Jonathan <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
md/raid1:  be more cautious where we read-balance during resync.

commit 79ef3a8aa1cb1523cc231c9a90a278333c21f761 made
it possible for reads to happen concurrently with resync.
This means that we need to be more careful where read_balancing
is allowed during resync - we can no longer be sure that any
resync that has already started will definitely finish.

So keep read_balancing to before recovery_cp, which is conservative
but safe.

This bug makes it possible to read from a device that doesn't
have up-to-date data, so it can cause data corruption.
So it is suitable for any kernel since 3.11.

Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: NeilBrown <neilb@suse.de>