The wmb() inside fw_load_abort is not necessary, since
complete() and wait_on_completion() has implied one pair
of memory barrier.
Also wmb() isn't a correct usage, so just remove it.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes two races in loading firmware:
1, FW_STATUS_DONE should be set before waking up the task waitting
on _request_firmware_load, otherwise FW_STATUS_ABORT may be
thought as DONE mistakenly.
2, Inside _request_firmware_load(), there is a small window between
wait_for_completion() and mutex_lock(&fw_lock), and 'echo 1 > loading'
still may happen during the period, so this patch checks FW_STATUS_DONE
to prevent pages' buffer completed from being freed in firmware_loading_store.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch doesn't transfer ownership of pages' buffer to the
instance of firmware until the firmware loading is completed,
which will simplify firmware_loading_store a lot, so help
to introduce the following cache_firmware and uncache_firmware
mechanism during system suspend-resume cycle.
In fact, this patch fixes one bug: if writing data into
firmware loader device is bypassed between writting 1 and 0 to
'loading', OOPS will be triggered without the patch.
Also handle the vmap failure case, and add some comments to make
code more readable.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perlcritic complains about $kconfig being reused in the foreach loop
at the end of read_kconfig. Change it to a my variable.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Convert remaining open calls to use the perl's preferred 3 parameter
open.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Change find_config function to read_config. It now finds the config,
reads the config into an array, and returns the array. This makes it
a little cleaner and changes the open to use perl's 3 option open.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Running streamline_config.pl as it's shown it in the comment header,
you will get a warning about $ksource being uninitialized. This is
because $ksource is set to ARGV[0], but the examples don't require any
arguments. Fix by setting ksource to . if no ARGV[0] is given.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
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>
The only Computone support left in the kernel is in
drivers/tty/serial/8250/8250_pci.c. CONFIG_COMPUTONE is no longer a valid
option. Therefore, remove firmware, documentation, and the last vestiges
of this driver.
Cc: Rob Landley <rob@landley.net>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: James Bottomley <JBottomley@Parallels.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
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>
This driver is very basic. It supports userland trigger, buffer and
raw access to channels. The support for delay channels is missing
altogether.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Juergen Beisert <jbe@pengutronix.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Wolfgang Denk <wd@denx.de>
Add unsigned 32bit-wide reads into the generic-buffer.c
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Juergen Beisert <jbe@pengutronix.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Wolfgang Denk <wd@denx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.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>
This driver is a replacement for a MAX3107 driver with a lot of
improvements and new features.
The main differences from the old version:
- Using the regmap.
- Using devm_XXX-related functions.
- The use of threaded IRQ with IRQF_ONESHOT flag allows the driver to
the hardware that supports only level IRQ.
- Improved error handling of serial port, improved FIFO handling,
improved hardware & software flow control.
- Advanced flags allows turn on RS-485 mode (Auto direction control).
- Ability to load multiple instances of drivers.
- Added support for MAX3108.
- GPIO support.
- Driver is quite ready for adding I2C support and support other ICs
with compatible registers set (MAX3109, MAX14830).
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OMAP hardware doesn't provide a phyisical DTR line, but
some configurations may need a DTR line which tracks whether
the device is open or not.
So allow a gpio to be configured as the DTR line.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported by coccinelle:
drivers/tty/serial/pch_uart.c:979:1-14: alloc with no test, possible model on line 994
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the following compile breakage:
CC drivers/tty/serial/sc26xx.o
drivers/tty/serial/sc26xx.c: In function 'read_sc_port':
drivers/tty/serial/sc26xx.c💯 error: implicit declaration of function 'readb'
drivers/tty/serial/sc26xx.c: In function 'write_sc_port':
drivers/tty/serial/sc26xx.c:105: error: implicit declaration of function 'writeb'
drivers/tty/serial/sc26xx.c: In function 'sc26xx_probe':
drivers/tty/serial/sc26xx.c:652: error: implicit declaration of function 'ioremap_nocache'
drivers/tty/serial/sc26xx.c:652: warning: assignment makes pointer from integer without a cast
make[3]: *** [drivers/tty/serial/sc26xx.o] Error 1
make[2]: *** [drivers/tty/serial] Error 2
make[1]: *** [drivers/tty] Error 2
make: *** [drivers] Error 2
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We changed these from alloc_tty_driver() to tty_alloc_driver() so the
error handling needs to modified to check for IS_ERR() instead of NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Uplink (TX) network data will go through gsm_dlci_data_output_framed
there is a bug where if memory allocation fails, the skb which
has already been pulled off the list will be lost.
In addition TX skbs were being processed in LIFO order
Fixed the memory leak, and changed to FIFO order processing
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Tested-by: Kappel, LaurentX <laurentx.kappel@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Showjumping <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers are supposed to use the dev_* versions of the kfree_skb
interfaces. In a couple of cases we were called with IRQs
disabled as well which kfree_skb() does not expect.
Replaced kfree_skb calls w/ dev_kfree_skb and dev_kfree_skb_any
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Grooming <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gsm_data_kick was recently modified to allow messages on the
tx queue bound for DLCI0 to flow even during FCOFF conditions.
Unfortunately we introduced a bug discovered by code inspection
where subsequent list traversers can access freed memory if
the DLCI0 messages were not all at the head of the list.
Replaced singly linked tx list w/ a list_head and used
provided interfaces for traversing and deleting members.
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Riding School <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There were some locking holes in the management of the MUX's
message queue for 2 code paths:
1) gsmld_write_wakeup
2) receipt of CMD_FCON flow-control message
In both cases gsm_data_kick is called w/o locking so it can collide
with other other instances of gsm_data_kick (pulling messages tx_tail)
or potentially other instances of __gsm_data_queu (adding messages to tx_head)
Changed to take the tx_lock in these 2 cases
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Riding School <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The design of uplink flow control in the mux driver is
that for constipated channels data will backup into the
per-channel fifos, and any messages that make it to the
outbound message queue will still go out.
Code was added to also stop messages that were in the outbound
queue but this requires filtering through all the messages on the
queue for stopped dlcis and changes some of the mux logic unneccessarily.
The message fiiltering was removed to be in line w/ the original design
as the message filtering does not provide any solution.
Extra debug messages used during investigation were also removed.
Signed-off-by: samix.lebsir <samix.lebsir@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Dressage <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Correcting handling of FCon/FCoff in order to respect 27.010 spec
- Consider FCon/off will overide all dlci flow control except for
dlci0 as we must be able to send control frames.
- Dlci constipated handling according to FC, RTC and RTR values.
- Modifying gsm_dlci_data_kick and gsm_dlci_data_sweep according
to dlci constipated value
Signed-off-by: Frederic Berat <fredericx.berat@intel.com>
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gsm_dlci_data_kick will not call any output function if tx_bytes > THRESH_LO
furthermore it will call the output function only once if tx_bytes == 0
If the size of the IP writes are on the order of THRESH_LO
we can get into a situation where skbs accumulate on the outbound list
being starved for events to call the output function.
gsm_dlci_data_kick now calls the sweep function when tx_bytes==0
Signed-off-by: Russ Gorby <russ.gorby@intel.com>
Tested-by: Kappel, LaurentX <laurentx.kappel@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Hay and Water <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The call to platform_get_resource(pdev, IORESOURCE_MEM, 0) is moved coser
to the call to devm_request_and_ioremap, which is th first use of the
result of platform_get_resource.
This does not use devm_request_irq to ensure that free_irq is executed
before its idev argument is freed.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In 3GPP27.010 5.8.1, it defined:
The TE multiplexer initiates the establishment of the multiplexer control channel by sending a SABM frame on DLCI 0 using the procedures of clause 5.4.1.
Once the multiplexer channel is established other DLCs may be established using the procedures of clause 5.4.1.
This patch implement 5.8.1 in MUX level, it make sure DLC0 is the first channel to be setup.
[or for those not familiar with the specification: it was possible to try
and open a data connection while the control channel was not yet fully
open, which is a spec violation and confuses some modems]
Signed-off-by: xiaojin <jin.xiao@intel.com>
Tested-by: Yin, Fengwei <fengwei.yin@intel.com>
[tweaked the order we check things and error code]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: The Horsebox <stable@vger.kernel.org>
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>
Change the BUG_ON to WARN_ON and return in case of tty->read_buf==NULL. We want to track a
couple of long standing reports of this but at the same time we can avoid killing the box.
Signed-off-by: Stanislav Kozina <skozina@redhat.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Horses <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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
It's only used locally, no need to pollute global namespace.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
