As struct device is used as a function argument, it should at
least be declared (device.h is not included).
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The irqdomain conversion failed to notice that we do not always
have a DT node to dereference, fix this up by using a simple
dev_err() that also tells the name of the device.
Cc: Loic Pallardy <loic.pallardy@st.com>
Cc: Patrice Chotard <patrice.chotard@stericsson.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is no specific atomic64 support code for any m68k CPUs, so we should
select CONFIG_GENERIC_ATOMC64 for all. Remove the existing per CPU selection
of this and select it for all m68k.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
This change updates the code related to configuring the transmit frame
checksum. Specifically I have updated the code so that we can only skip
inserting the checksum in the case that we are not performing some other
offload that will modify the frame data.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This change moves the RSC code into the non-EOP descriptor handling
function. The main motivation behind this change is to help reduce the
overhead in the non-RSC case. Previously the non-RSC path code would
always be checking for append count even if RSC had been disabled. Now
this code is completely skipped in a single conditional check instead of
having to make two separate checks.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This patch creates a function named ixgbe_fetch_rx_buffer. The sole
purpose of this function is to retrieve a single buffer off of the ring and
to place it in an skb.
The advantage to doing this is that it helps improve the readability since
I can decrease the indentation and for the code in this section.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This change makes it so that if only the first 256 bytes of a buffer are
used we just copy the data out and leave the offset and page count
unchanged. There are multiple advantages to this. First it allows us to
reuse the page much more in the case of pages larger than 4K. It also
allows us to avoid some expensive atomic operations in the form of
get_page/put_page. In perf I have seen CPU utilization for put_page drop
from 3.5% to 1.8% as a result of this patch when doing small packet routing,
and packet rates increased by about 3%.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This change creates a separate function for functionality similar to
pskb_pull_tail. The main motivation for moving it to a separate function
is so that later I can just skip this function in the case where we have
already copied the buffer into skb->head.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This patch makes it so that we will always have ownership of the buffers by
the time we get to ixgbe_add_rx_frag. This is necessary as I am planning to
add a copy-break to ixgbe_add_rx_frag and in order for that to function
correctly we need the CPU to have ownership of the buffer.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This change makes it so that we do not use double buffering if the page
size is larger than 4K. Instead we will simply walk through the page using
up to 3K per receive, and if we receive less than we only move the offset
by that amount. We will free the page when there is no longer any space
left that we can use instead of checking the page count to see if we can
cycle back to the start.
The main motivation behind this is to avoid the unnecessary truesize cost
for using a half page when most packets are 2K or smaller. With this new
approach the largest possible truesize for a page fragment will be 3K when
PAGE_SIZE is larger than 4K.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This patch combines ixgbe_add_rx_frag and ixgbe_can_reuse_page into a
single function. The main motivation behind this is to make better use of
the values so that we don't have to load them from memory and into
registers twice.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
This change reverts an earlier patch that introduced
ixgbe_init_rx_page_offset. The idea behind the function was to provide
some variation in the starting offset for the page in order to reduce
hot-spots in the cache. However it doesn't appear to provide any
significant benefit in the testing I have done. It has however been a
source of several bugs, and it blocks us from being able to use 2K
fragments on larger page sizes. So the decision I made was to remove it.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
A race exists where creating cgroups and also updating the priomap
may result in losing a priomap update. This is because priomap
writers are not protected by rtnl_lock.
Move priority writer into rtnl_lock()/rtnl_unlock().
CC: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A socket fd passed in a SCM_RIGHTS datagram was not getting
updated with the new tasks cgrp prioidx. This leaves IO on
the socket tagged with the old tasks priority.
To fix this add a check in the scm recvmsg path to update the
sock cgrp prioidx with the new tasks value.
Thanks to Al Viro for catching this.
CC: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add lock to prevent a race with a file closing and also remove
useless and ugly sscanf code. The extra code was never needed
and the case it supposedly protected against is in fact handled
correctly by sock_from_file as pointed out by Al Viro.
CC: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We drop packet unconditionally when we fail to mirror it. This is not intended
in some cases. Consdier for kvm guest, we may mirror the traffic of the bridge
to a tap device used by a VM. When kernel fails to mirror the packet in
conditions such as when qemu crashes or stop polling the tap, it's hard for the
management software to detect such condition and clean the the mirroring
before. This would lead all packets to the bridge to be dropped and break the
netowrk of other virtual machines.
To solve the issue, the patch does not drop packets when kernel fails to mirror
it, and only drop the redirected packets.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
These mostly consist of fixes from Lars-Peter Clausen that were
the first part of a large series reworking the drivers concerned.
Turns out these drivers had quite a wealth of minor bugs.
Also here are some build warning fixes for lm3533-als and
adjd_s111 (both new drives in this cycle).
Final elements are a a div factor overflow and a warning
related fix in a couple of Analog Devices drivers.
All in all nothing major, but a worthwhile bunch of short
fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJQLUxMAAoJEFSFNJnE9BaI1PgQALfDZXRXLaR3zxp+ZJMZsY6e
LkGbi0PioGXyJG0/a5KYTTntFGrWTR6RDhofG1AAMiUCvfmR68a5E4dS3C+huHx4
5yvoiFo2W70Cuavne34C15ObmCX2sBQx9T0i1xMCbqizjN7hfwCsM2gyieMJ3/so
xhxV1wvztqJOfLY93fGZUe7sz9vZa34fdZ5cgAQqF1GpO9awDY/fvMb6ecAJjPqV
qxgsmdXhYJ0v41ukjnvZbebeHZKcbf6Ffo1DGLCvjw8w8h1JMdg8/gXuwmj3RLcY
Y/oUvfUFGOx0RRkbGamgxhwo2STQ9SDwUohzblIufY38HFAEfiBFueJ7IctxXy6K
HPdm0UL4nDgs751rOh5on3lbiv4wX0RHsXwkoKIXlueK0rptQ+uA+Uq/irCnEfJy
xxn0X03kaNMgNtI3EK3/PbEsPpDEoVpeNHFW+ikVl6FBCjRpraoxnNGMg6ajV9kH
U0Wigwj0vVZdVwpUQAXZoz1so/i00mC5pHOt+3znReEdgJkV63AnlY69IbjvxoLi
3eq50EMZUsxbCQdDdIIADPtabwxKRN2rphRMb/eAG/6ZAJCYZWrhrli/OTUmqzXs
4MaYEPyAjpUiyABVtKzONtSccP640kz3YSIg6ZKwGGYoI0/jXTlrXTlsKQUeNOtn
ll/kwhqy1mXYW+Q7kpj3
=+LMV
-----END PGP SIGNATURE-----
Merge tag 'v3.6-rc1-iio-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
IIO fixes for v3.6-rc1
These mostly consist of fixes from Lars-Peter Clausen that were
the first part of a large series reworking the drivers concerned.
Turns out these drivers had quite a wealth of minor bugs.
Also here are some build warning fixes for lm3533-als and
adjd_s111 (both new drives in this cycle).
Final elements are a a div factor overflow and a warning
related fix in a couple of Analog Devices drivers.
All in all nothing major, but a worthwhile bunch of short
fixes.
There is an extra semi-colon here, so we always return 0 instead of
calling __sctp_auth_cid().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
struct seq_net_private has no struct net
if CONFIG_NET_NS is not enabled
Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for maxim ds1825 based 1-wire temperature sensors.
Signed-off-by: Raphael Assenat <raph@8d.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ll_device_want_to_wakeup(): Fix the NULL pointer check on pdata->chip_awake,
which is performed on the wrong function pointer
Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix below build warnings:
CC [M] drivers/iio/light/lm3533-als.o
drivers/iio/light/lm3533-als.c:667:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: (near initialization for 'dev_attr_in_illuminance0_thresh_either_en.show') [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/iio/light/lm3533-als.c:667:8: warning: (near initialization for 'dev_attr_in_illuminance0_thresh_either_en.store') [enabled by default]
Signed-off-by: Axel Lin <axel.lin@gmail.com>
The values reported by the AD7780 are unsigned with a binary offset:
0x000000 is negative fullscale
0x800000 is zeroscale
0xffffff is positive fullscale
So mark the channel in the channel spec as unsigned rather than signed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The temperature channel reports values in degree Kelvin with sensitivity of 5630
codes per degree. If the chip is configured in bipolar mode there is an
additional binary offset of 0x800000 and the sensitivity is divided by two.
Currently the driver does the mapping from the raw value to degree Celsius when
doing a manual conversion. This has several disadvantages, the major one being
that it does not work for buffered mode, also by doing the division by the
sensitivity in the driver the precession of the reported value is needlessly
reduced.
Furthermore the current calculation only works in bipolar mode and the current
scale is of by a factor of 1000.
This patch modifies the driver to report correct offset and scale values in
both unipolar and bipolar mode and to report the raw temperature value
for manual conversions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In bipolar mode there is a a binary offset of 2**(N-1) (with N being the number
of bits) on the reported value. Currently this value is subtracted when doing a
manual read. While this works for manual channel readings it does not work for
buffered mode. So report the offset in the channels offset property, which will
work in both modes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The values reported by the AD7793 are unsigned.
In uniploar mode:
0x000000 is zeroscale
0xffffff is fullscale
In bipolar mode:
0x000000 is negative fullscale
0x800000 is zeroscale
0xffffff is positive fullscale
In bipolar mode there is a binary offset, but the values are still unsigned.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Write to the correct register when setting the ACX bit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Without the break statement we fall right through to the default case and return
an error value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The internal reference for the ad7793 and similar is 1.17V
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Make the "in-in_scale_available" attribute follow the new naming spec and
rename it to "in_voltage-voltage_scale_available".
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The temperature channel uses the internal 1.17V reference with 0.81 mv/C. The
reported temperature is in Kevlin, so we need to add the Kelvin to Celcius
offset when reporting the offset for the temperature channel.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In bipolar mode there is a a binary offset of 2**(N-1) (with N being the number
of bits) on the reported value. Currently this value is subtracted when doing a
manual read. While this works for manual channel readings it does not work for
buffered mode. So report the offset in the channels offset property, which will
work in both modes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The values reported by the AD7793 are unsigned.
In uniploar mode:
0x000000 is zeroscale
0xffffff is fullscale
In bipolar mode:
0x000000 is negative fullscale
0x800000 is zeroscale
0xffffff is positive fullscale
In bipolar mode there is a binary offset, but the values are still unsigned.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Without the break statement we fall right through to the default case and return
an error value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Do not leak memory by updating pointer with potentially NULL realloc return value.
There is no need to preserve data in the buffer,
so replace krealloc() by kfree()-kmalloc() pair.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
With small channel spacing values and high reference frequencies it is
possible to exceed the range of the 10-bit counter.
Workaround by checking the range and widening some constrains.
We don't use the REG1_PHASE value in this case the datasheet recommends to set
it to 1 if not used.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
drivers/staging/iio/adc/ad7298_ring.c:97:37: warning: 'time_ns' may
be used uninitialized in this function [-Wmaybe-uninitialized]
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
kdb <-> kgdb transitioning does not work properly with this UART
driver because the get character routine loops indefinitely as opposed
to returning NO_POLL_CHAR per the expectation of the KDB I/O driver
API.
The symptom is a kernel hang when trying to switch debug modes.
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Without checking if the auart supports the hardware flow control or not,
the old mxs_auart_set_mctrl() asserted the RTS pin blindly.
This will causes the auart receives wrong data in the following case:
The far-end has already started the write operation, and wait for
the auart asserts the RTS pin. Then the auart starts the read operation,
but mxs_auart_set_mctrl() may be called before we set the RTSCTS in the
mxs_auart_settermios(). So the RTS pin is asserted in a wrong situation,
and we get the wrong data in the end.
This bug has been catched when I connect the mx23(DTE) to the mx53(DCE).
This patch also replaces the AUART_CTRL2_RTS with AUART_CTRL2_RTSEN.
We should use the real the hardware flow control, not the software-controled
hardware flow control.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Following a report of a crash during an automount expire I found that
the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong.
Not only is the locking wrong but the function is more complex than it
needs to be.
The function is meant to calculate (and dget) the next entry in the list
of directories contained in the root of an autofs mount point (an autofs
indirect mount to be precise). The main problem was that the d_lock of
the owner of the list was not being taken when walking the list, which
lead to list corruption under load. The only other lock that needs to
be taken is against the next dentry candidate so it can be checked for
usability.
Signed-off-by: Ian Kent <raven@themaw.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQIVvKAAoJECObm247sIsiSv0P/3vTTHqBHhhw9ZAcO+K6xyjo
kccytHuMko1+H+J8G2ovvC1YMZzPF/bp81yTDv+H5xjYEHaE5iDRz91X4x+0oP/z
qAYYdOfufWAXNJqlHL6xNtYKMTnK0jrtqTYkkeKRZbbdyEkvEa0cLbJpHWB16IDW
jECk1sTmVlCifYiN9cgV8GyNOenXM7/fEtnpsbB1kzmAtBW7sXCEzA2KiEuvtL7S
Nnjzchu3lvXkGg26qF9zv5qAj4nMOY8uDsQNNJtCxfbWjdG2W5PylqHjeUbE/g95
C3Kxrw9QZsM8zY/9KO/gGxpQ0S9zMiX9999ySFJtIdy0vcTxlXI5kzJRgiJRlw/y
KhiKrD3lr0Vlf4vb4YaDAeN07VEsXOthH5kkgswK7rfXwAFhhjub/ezn8xePR8/2
tbA9C+koMQTc5AbifbNhEGz+Qzjc5HqislM5zeGAL8wHTsgi9yQYjH1AWljM3dAU
ST/Gqe6rHIXpgrL1YSY0MTpVwaOXpokILVcOcnPpY3HcgatrQMRhNSqdxGMWygmA
NUbfL79kHYVmlkaPIsEymh9tx0wuDe0KyC/hzxm/dWB4MRGzE9AhMc6Hj4N5gXQY
H8qbMA5nPV4kS1xZNUc7wRK9YxRbCi7NKVoQba89yR3PBWwceSnGdKMA57G82gOm
uwe5wfAkno1KCk/m3zXk
=fUJz
-----END PGP SIGNATURE-----
Merge tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio
Pull VFIO fix from Alex Williamson:
"Just a trivial patch to include vfio.h in the installed headers so we
can complete userspace integration into QEMU."
* tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio:
vfio: Include vfio.h in installed headers
* On machines with large MMIO/PCI E820 spaces we fail to boot b/c
we failed to pre-allocate large enough virtual space for extend_brk.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJQKlV9AAoJEFjIrFwIi8fJZh4H/0ZlRrgG+8mqwCM+pcyYY+2a
zqnOrfYUO/aO26oqiOQUrn4quLAElhBuJK19uSj8fckMMZ+sr5rTJTaXmT6b7F7N
pgTXsKQCYAJ2NNGHVSQ73KYjOUeEW3woDSQZo0y/GRzOjiQsxpoFc8PS94ZieUNT
G6a8ECZBRv3fz8nAuJlhGV/suqHGOLJ0pwum1gHGOzaH3ZoZVtaQv5LhGYctJspU
yF5bdeD0qjCbseVtJ72tyxzLxMwLpJtdy2MbSwIv5JGuszj0nRmL4oa7Vc4vYdyv
p+FrNmbDAZ1j61z1PhBZPmgzwba2LTXtIWhR2zsGJgqlJNzMUtlNkff1kT3NeE0=
=Gl6V
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
Pull Xen fix from Konrad Rzeszutek Wilk:
"Way back in v3.5 we added a mechanism to populate back pages that were
released (they overlapped with MMIO regions), but neglected to reserve
the proper amount of virtual space for extend_brk to work properly.
Coincidentally some other commit aligned the _brk space to larger area
so I didn't trigger this until it was run on a machine with more than
2GB of MMIO space."
* On machines with large MMIO/PCI E820 spaces we fail to boot b/c
we failed to pre-allocate large enough virtual space for extend_brk.
* tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
Moved to djbw@fb.com
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Dan Williams <djbw@fb.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
