This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
CC: Vinod Koul <vinod.koul@intel.com>
CC: Dan Williams <djbw@fb.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Some semicolons were left out in the examples.
The #dma-channels and #dma-requests properties have a prefix
that is, by convention, reserved for cell size properties.
Rename those properties to dma-channels and dma-requests.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, "dmaengine: add helper function to request a slave DMA
channel") which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
char *name)
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to easily
support them with regard to device tree. Ideally, these should be migrated
to DMA engine. However, if this is not possible, then they should still be
able to use this binding, the only constaint imposed by this implementation
is that when requesting a DMA channel via of_dma_request_slave_channel(), it
will return a type of dma_chan.
This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
have validated that MMC is working on the PANDA board with this implementation.
My development branch for testing on OMAP can be found here [5].
v6: - minor corrections in DMA binding documentation
v5: - minor update to binding documentation
- added loop to exhaustively search for a slave channel in the case where
there could be alternative channels available
v4: - revert the removal of xlate function from v3
- update the proposed binding format and APIs based upon discussions [3]
v3: - avoid passing an xlate function and instead pass DMA engine parameters
- define number of dma channels and requests in dma-controller node
v2: - remove of_dma_to_resource API
- make property #dma-cells required (no fallback anymore)
- another check in of_dma_xlate_onenumbercell() function
[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
[4] http://pad.linaro.org/arm-mini-summit-2012
[5] https://github.com/jonhunter/linux/tree/dev-dt-dma
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.
With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
call fimd_activate(false) and just returns. Similarily the check in
fimd_resume should not resume if previously runtime_suspended.
Instead the existing check does the opposite. So if fimd was not
runtime suspended, suspend will turn off fimd but resume will not turn
it on. This patch fixes this issue by reversing the condition.
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This fixes a buffer cache leak when creating a directory, introduced
in commit a774f9c20.
Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Tao Ma <boyu.mt@taobao.com>
If checksum fails, we should also release the buffer
read from previous iteration.
Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>-
Cc: stable@vger.kernel.org
--
fs/ext4/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Commit "ext4: Remove CONFIG_EXT4_FS_XATTR" removed the configuration
dependencies for ext4 xattrs from the ext4 ACLs and security labels
configuration options, but did not replace them with a dependency on
ext4 itself. Add back the dependency on ext4 so the options only show
up if ext4 is enabled.
Signed-off-by: Valerie Aurora <val@vaaconsulting.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Tao Ma <boyu.mt@taobao.com>
To be consistent with the set of MMU definitions we should define KMAP_START
and KMAP_END. Future common m68k code will use their values.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Avoid accessing vc_tbl_ref[3], which is one past the end of that array, in
da9052_determine_vc_tbl_index(), by adjusting the loop bound.
(Hint: there is 'i + 1' inside the loop.)
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
use devm_kzalloc and no need of error path and unload frees.
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Use 'platform_device' in kernel messages rather than i2c client device
node. lp8788_update_charger_params() needs additional argument, 'pdev'.
Then, remove unnecessary lp8788 private data in lp8788_irq_register().
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
The lp8788-charger is a platform driver of lp8788-mfd. The platform device
is allocated when mfd_add_devices() is called in lp8788-mfd. On the other
hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc and device kernel message.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Some devices, Buffalo Linkstation LS-XHL and LS-CHLv2 for example,
power-off by restarting to letting u-boot hold the SoC until the user
presses a key. Add a generic driver to implement this. It binds a function
to pm_power_off, which calls arm_pm_restart.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Michael Walle <michael@walle.cc>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
The QNAP NAS boxes have a microcontroller attached to the SoCs second
serial port. By sending it a simple command, it will turn the power for
the board off. This driver registers a function for pm_power_off to send
such a command.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
devm_kzalloc should not be followed by kfree, as this results in a double
free. The problem was found using the following semantic match
(http://coccinelle.lip6.fr/):
// <smpl>
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
// </smpl>
Furthermore, in the remove function, the calls to free_irq are moved up to
prevent a possible reference in the interrupt handler to resources freed by
power_supply_unregister.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
If CONFIG_ARCH_MULTIPLATFORM & CONFIG_ARCH_MVEBU are both enabled,
__v7_pj4b_setup is added between __v7_ca9mp_setup and __v7_setup.
But there's no jump instruction added. If the chip is Cortex A5/A9,
it goes through __v7_pj4b_setup also. It results in system hang.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since commit 62e4d357a (ARM: 7609/1: disable errata work-arounds which access
secure registers) ARM_ERRATA_743622/751472 depends on !ARCH_MULTIPLATFORM.
Since imx has been converted to multiplatform, the following warning happens:
$ make imx_v6_v7_defconfig
warning: (SOC_IMX6Q && ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects
ARM_ERRATA_751472 which has unmet direct dependencies (CPU_V7 &&
!ARCH_MULTIPLATFORM)
warning: (SOC_IMX6Q && ARCH_TEGRA_3x_SOC) selects ARM_ERRATA_743622
which has unmet direct dependencies (CPU_V7 && !ARCH_MULTIPLATFORM)
warning: (SOC_IMX6Q && ARCH_TEGRA_3x_SOC) selects ARM_ERRATA_743622
which has unmet direct dependencies (CPU_V7 && !ARCH_MULTIPLATFORM)
warning: (SOC_IMX6Q && ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects
ARM_ERRATA_751472 which has unmet direct dependencies (CPU_V7 &&
!ARCH_MULTIPLATFORM)
Recommended approach is to remove ARM_ERRATA_743622/751472 from being selected
by SOC_IMX6Q and apply such workarounds into the bootloader.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When a channel fails to initialize, we release all ressources,
including clocks. However, a XOR unit is not necessarily associated to
a clock (some variants of Marvell SoCs have a clock for XOR units,
some don't), so we shouldn't unconditionally be releasing the clock.
Instead, just like we do in the mv_xor_remove() function, we should
check if one clock was found before releasing it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
When mv_xor_channel_add() fails for one XOR channel, we jump to the
err_channel_add label to clean up all previous channels that had been
initialized correctly. Unfortunately, while handling this error
condition, we were disposing the IRQ mapping before calling
mv_xor_channel_remove() (which does the free_irq()), which is
incorrect.
Instead, do things properly in the reverse order of the
initialization: first remove the XOR channel (so that free_irq() is
done), and then dispose the IRQ mapping.
This avoids ugly warnings when for some reason one of the XOR channel
fails to initialize.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The Armada XP MV78230 DT include file is missing a ; at the
end of the cpu node.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
We originally thought that the MV78230 variant of the Armada XP had
four Ethernet interfaces, like the other variants MV78260 and
MV78460. In fact, this is not true, and the MV78230 has only three
Ethernet interfaces.
So, the definitions of the Ethernet interfaces is now done as follows:
* armada-370-xp.dtsi: definitions of the first two interfaces, that
are common to Armada 370 and Armada XP
* armada-xp.dtsi: definition of the third interface, common to all
Armada XP variants.
* armada-xp-mv78260.dtsi and armada-xp-mv78460.dtsi: definition of
the fourth interface.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Contrary to our understanding at the time armada-xp-mv78230.dtsi was
written, the MV78230 variant of the Armada XP SoC has two cores and
not one. This patch updates the .dtsi file to take into account this
reality.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
If the Orion WDT driver is built as a module, an opps occurs during
clk lookup when calling mvebu_clk_gating_get_src(). Remove the
inappropriate __init tag so the function is available for modules
after kernel init.
Signed-off-by: Joshua Coombs <josh.coombs@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
With the change to a DT based pinctrl/gpio driver, using gpio API
calls in board-*.c files no longer works, a dereferenced NULL pointer
exception occurs instead. By converting the GPIO code into a
fixed-regulator which gets probed later once pinctrl/gpio is
available, we avoid the exception.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Stefan Peter <s.peter@mplch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
We moved to declaring clk gates in DT. However, device which do not
yet have a DT binding need to have a clkdev alias. This was missing
for SDIO.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Stefan Peter <s.peter@mplch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Clock Management of kirkwood has moved to DT clock providers.
However, TWSI1 has not yet been done.
This switches TWSI1 of 88f6282 to DT clock providers.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Improve the documentation to clarify level vs edge triggered power off.
Improve the comments for level vs edge triggered power off.
Make use of gpio_is_valid().
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Without the clock being held by a driver, it gets turned off at a bad
time causing the SoC to lockup. This is often during reboot.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Stefan Peter <s.peter@mpl.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The UART controller used in the Armada 370 and Armada XP SoCs is the
Synopsys DesignWare 8250 (aka Synopsys DesignWare ABP UART). The
improper use of the ns16550 can lead to a kernel oops during boot if
a character is sent to the UART before the initialization of the
driver. The DW APB has an extra interrupt that gets raised when
writing to the LCR when busy. This explains why we need to use
dw-apb-uart driver to handle this.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The plat/*.h headers are not available to drivers in multiplatform
kernels. As the header isn't needed, just remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Multistream support for stv0900. For Netup Dual S2 CI with STV0900BAC/AAC.
Signed-off-by: Evgeny Plehov <EvgenyPlehov@ukr.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes this build breakage:
arch/powerpc/kvm/book3s_hv_ras.c: In function ‘kvmppc_realmode_mc_power7’:
arch/powerpc/kvm/book3s_hv_ras.c:126:23: error: ‘struct paca_struct’ has no member named ‘opal_mc_evt’
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Walking rbtree while it's modified is a Bad Idea(tm); besides,
the result of find_vma() can be freed just as it's getting returned
to caller. Fortunately, it's easy to fix - just take ->mmap_sem a bit
earlier (and don't bother with find_vma() at all if virtp >= PAGE_OFFSET -
in that case we don't even look at its result).
While we are at it, what prevents VIDIOC_PREPARE_BUF calling
v4l_prepare_buf() -> (e.g) vb2_ioctl_prepare_buf() -> vb2_prepare_buf() ->
__buf_prepare() -> __qbuf_userptr() -> vb2_vmalloc_get_userptr() -> find_vma(),
AFAICS without having taken ->mmap_sem anywhere in process? The code flow
is bloody convoluted and depends on a bunch of things done by initialization,
so I certainly might've missed something...
Cc: stable@vger.kernel.org [2.6.35]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Archit Taneja <archit@ti.com>
Cc: Prabhakar Lad <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Restore ds3000.c read_signal_strength.
Call tuner get_rf_strength from frontend read_signal_strength.
We are able to do a NULL check and doesn't limit the tuner
attach to the frontend attach area.
At the moment the lmedm04 tuner attach is stuck in frontend
attach area.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a configuration option for v4l2-int-device so it is only compiled when
necessary, which is only by omap24xxcam and tcm825x drivers.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remy Blank reported that audio over USB can be made working for the television
input if .amux is changed from EM28XX_AMUX_LINE_IN to EM28XX_AMUX_VIDEO.
An examination of his devices shows, that it is indeed supplied with an EM202
AC97 audio IC. We also use this setting for the Cinergy 200.
Remy Blank also provided the original version of this patch (many thanks !).
Fixes bug 14126 (see bug report for further device details).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Remy Blank <remy.blank@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We recently pushed the locking down into this function, but there was
an error path where the unlock was missed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When mutex_lock_interruptible is used on paths where a signal can be
pending, the device is not closed properly and cannot be reused.
This usually happens when you start tzap for example and send it a
TERM signal. The signal is pending while tear-down routines are
called. Hence streaming is not properly stopped in that case. And
the device stops working from that moment on.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
