In case of scan_bbt() failure, we should better propagate it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
return type of wait_for_completion_timeout is unsigned long not int. The
return variable is renamed to reflect its use and the type adjusted to
unsigned long.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Huang Shijie <shijie.huang@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than adding a additional appropriately typed variable.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Han Xu <han.xu@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
When displaying dev_err() messages it is useful to print the error value.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Han Xu <han.xu@freescale.com>
[Brian: fix up "can not" at the same time]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
These lines were all indented one tab more than they should be.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Two config options exist to define powerpc MPC8xx:
* CONFIG_PPC_8xx
* CONFIG_8xx
In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as
communication co-processor
arch/powerpc/platforms/Kconfig.cputype has contained the following
comment about CONFIG_8xx item for some years:
"# this is temp to handle compat with arch=ppc"
It looks like not many places still have that old CONFIG_8xx used,
so it is likely to be a good time to get rid of it completely ?
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Without this patch the timings are all set to 0 if not specified in the dts.
With this patch the driver falls back to use the defaults that are already
present in the driver and are known to work okay for some (older) boards.
Tested on a custom SPEAr600 based board.
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We know "rc" is set so there is no need to check again.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
If a NAND device is not really present or pin muxes are not correctly
configured we can lock up the kernel waiting infinitely for NAND_STATUS
to be ready.
This can be easily reproduced on TI's DRA7-evm board by booting it
without NAND support in u-boot and disabling NAND pin muxes in the kernel.
Add timeout when waiting for NAND_CMD_RESET completion. As per ONFi v4.0
tRST can be upto 250ms for EZ-NAND and 5ms for raw NAND.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add clock controller for CMU ISP clock domain on Exynos3250,
providing clocks for FIMC-IS subsystem.
[b.michalska: use samsung_cmu_register_one to register
the provider; updated DT binding documentation]
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Beata Michalska <b.michalska@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
[s.nawrocki: added __init attribute which was missing in function
exynos3250_cmu_platform_init() in function, which has been]
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
This patch add CLKOUT driver support for Exynos3250 SoC.
Exynos3250 SoC PMU_DEBUG is the same with Exynos4's PMU_DEBUG
including CLKOUT mux. So we can use the exynos4's clkout init
function for Exynos3250 without the need to add new function.
Signed-off-by: Inha Song <ideal.song@samsung.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The LED name was wrongly interpreted as format string. Stop doing that.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
The LED names are expected to be unique in the system. Use KERN_WARNING log
level to notify the user about the matter.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
In order to shrink the size of bt_skb_cb, this patch moves the HCI
request related variables into their own req_ctrl struct. Additionall
the L2CAP and HCI request structs are placed inside the same union since
they will never be used at the same time for the same skb.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We're getting very close to the maximum possible size of bt_skb_cb. To
prepare to shrink the struct with the help of a union this patch moves
all L2CAP related variables into the l2cap_ctrl struct. To later add
other 'ctrl' structs the L2CAP one is renamed simple 'l2cap' instead
of 'control'.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Turns out sending out layouts to any client is a bad idea if they
can't get at the storage device, so require explicit admin action
to enable pNFS.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Kernel version for new ABI in 4.0 has been documented
as 3.20, since the changes have been merged before the kernel
version number change.
Change kernel version from 3.20 to 4.0.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The current code expected that every LED had an unique name. This is a
legit expectation when the device tree can no be modified or extended.
But with device tree overlays this requirement can be easily broken.
This patch finds out if the name is already in use and adds the suffix
_1, _2... if not.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch fix a spelling typo in MODULE_DESCRIPTION in
leds-lp8860.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This patch fix a spelling typo in MODULE_DESCRIPTION in
leds-lp8501.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Label is used for naming LED class devices. Since ePAPR
doesn't require uniqueness for label properties, it has to be
explicitly required in the LEDs common bindings documentation.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: devicetree@vger.kernel.org
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Add macros for defining boost mode and trigger type properties
of flash LED devices.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
(cooloney@gmail.com: remove unneeded semicolon)
Signed-off-by: Courtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
This adds device tree binding documentation for the WLED ('White' LED)
block on Qualcomm's PM8941 PMICs.
Signed-off-by: Courtney Cavin <courtney.cavin@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Only the name and default_trigger fields are initialized.
Other fields (currently flags only) contain random stack data.
Pre-initialize the led structure completely to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
LED_FLASH_MAX_SYSFS_GROUPS macro had value that was relevant for
previous version of the patches introducing LED Flash class. Currently
it is required to reserve the room for maximum 4 sysfs groups.
Since the last element of the struct attribute_group array passed to
the function device_create_with_groups has to be NULL, the size of the
array has to be greater by one than maximum allowed number of groups.
Therefore, the name of the macro is being changed to
LED_FLASH_SYSFS_GROUPS_SIZE, to make it more accurrate.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Patch derived from one from Yakir Yang. Yakir Yang says:
For Designerware HDMI, the following write sequence is recommended:
1. aud_n3 (set bit ncts_atomic_write if desired)
2. aud_cts3 (set CTS_manual and CTS value if desired/enabled)
3. aud_cts2 (required in CTS_manual)
4. aud_cts1 (required in CTS_manual)
5. aud_n3 (bit ncts_atomic_write with same value as in step 1.)
6. aud_n2
7. aud_n1
However, avoid the ncts_atomic_write_bit and CTS_manual settings in this
patch, both of which are marked reserved in the iMX6 documentation. All
iMX6 code in the wild seems to want CTS_manual cleared.
Having requested clarification from FSL, it appears that neither of
these bits are implemented in their version of the IP.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The HDMI n/cts settings need to be updated whenever the audio sample
rate or the video pixel clock changes. This needs to be protected
against concurrency as there is no synchronisation between these two
operations. Introduce a mutex (called audio_mutex) to protect against
two threads trying to update the video clock rate and pixel clock
simultaneously.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Combine these two functions into a single implementation. These two
functions are called consecutively anyway. Idea from a patch by
Yakir Yang.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Pull libata fixes from Tejun Heo:
"Nothing exciting. Two patches to update queued trim blacklist"
* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata: Blacklist queued TRIM on Samsung SSD 850 Pro
libata: Update Crucial/Micron blacklist
The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The vd->node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
A clean up of the recursive protection code changed
val = this_cpu_read(current_context);
val--;
val &= this_cpu_read(current_context);
to
val = this_cpu_read(current_context);
val &= val & (val - 1);
Which has a duplicate use of '&' as the above is the same as
val = val & (val - 1);
Actually, it would be best to remove that line altogether and
just add it to where it is used.
And Christoph even mentioned that it can be further compacted to
just a single line:
__this_cpu_and(current_context, __this_cpu_read(current_context) - 1);
Link: http://lkml.kernel.org/alpine.DEB.2.11.1503271423580.23114@gentwo.org
Suggested-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Setup the capabilities of the device/driver, so that users of the DMAengine API
can query them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
We shuffled some code around in 8b3444852a ('sata_dwc_460ex: move to
generic DMA driver') an accidentally deleted a tab character here. It
causes a Smatch warning "if statement not indented".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
- Syscon GPIO fix for Keystone DSP GPIOs
- Pin number translation fix for ACPI GPIO
- A smallish compiler warning fix on the mpc8xxx driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVGQHEAAoJEEEQszewGV1zFUwQAMofHNFAtoP80OYsJMktOsaO
u5e+YYaLXgrFc5kE3V5gI8DBDRZRkw4SeNsBosIP3tUU8dmY/z5A8cvlwdeD5nsy
StAWXcBHNlbAZA2AVHI04Q8+A05NMAOPR1Qq5HVmcsm9fFvTIbvfJgxICxPHbRN5
6UNhdSwbdynLH8SUUdDx0/9Yq7xIXVReZX+pS5ksC1TC5nYSGU3txOSEODyHnsRL
S3SNtCKBMTqp7twbpsMf15xff6xtM0I+c7bga+XoY+qydDD0fXkUaiLAAVW/zfUh
ep/8kJiqzL0SgquP7/XunB9b4QejonqzYo2GUxKOw7B+gHmmICFrEMozQ1/w2vTc
jjMAvRkI4jm209KragBK/vI23cMXNfphzW/WTJ39j9TKy25uQ2G/ZvD9c+Q2/RWN
IuN5MFJm/OcVWPWv1GafheMFBQilRRKkl9PTVKScm4hFCbysnikj4++VdkZF9qZz
CAc+waZld2yEX45Xu7zEyMRQPGoUVNJm321WMO9YC5WkYZTZbYPtt9VNgYiBQ2ZR
LK0aQDlaviduujRqPxFv0bA6E6MmlJEWhQfIdFCPFkXfalUIpxgge3JBvuSG09w/
pwVDMr2eGkeDqIHMcyC+upHMZvuJD6+Sw+0c+T4smTtlOt4JOQO74ysyqfzM/795
25xx9hYMSlOzWvsq5WqW
=02eY
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull late GPIO fixes from Linus Walleij:
"Here are the (hopefully) last GPIO fixes for v4.0. Nothing
controversial whatsoever, just fixes:
- syscon GPIO fix for Keystone DSP GPIOs
- pin number translation fix for ACPI GPIO
- a smallish compiler warning fix on the mpc8xxx driver"
* tag 'gpio-v4.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: syscon: reduce message level when direction reg offset not in dt
gpiolib: translate pin number in GPIO ACPI callbacks
gpio: mpc8xxx: remove __initdata annotation for mpc8xxx_gpio_ids[]
As the infrastructure for eventfd has now been merged, report the
ioeventfd capability as being supported.
Signed-off-by: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
[maz: grouped the case entry with the others, fixed commit log]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Currently we have struct kvm_exit_mmio for encapsulating MMIO abort
data to be passed on from syndrome decoding all the way down to the
VGIC register handlers. Now as we switch the MMIO handling to be
routed through the KVM MMIO bus, it does not make sense anymore to
use that structure already from the beginning. So we keep the data in
local variables until we put them into the kvm_io_bus framework.
Then we fill kvm_exit_mmio in the VGIC only, making it a VGIC private
structure. On that way we replace the data buffer in that structure
with a pointer pointing to a single location in a local variable, so
we get rid of some copying on the way.
With all of the virtual GIC emulation code now being registered with
the kvm_io_bus, we can remove all of the old MMIO handling code and
its dispatching functionality.
I didn't bother to rename kvm_exit_mmio (to vgic_mmio or something),
because that touches a lot of code lines without any good reason.
This is based on an original patch by Nikolay.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Cc: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Using the framework provided by the recent vgic.c changes, we
register a kvm_io_bus device on mapping the virtual GICv3 resources.
The distributor mapping is pretty straight forward, but the
redistributors need some more love, since they need to be tagged with
the respective redistributor (read: VCPU) they are connected with.
We use the kvm_io_bus framework to register one devices per VCPU.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Currently we handle the redistributor registers in two separate MMIO
regions, one for the overall behaviour and SPIs and one for the
SGIs/PPIs. That latter forces the creation of _two_ KVM I/O bus
devices for each redistributor.
Since the spec mandates those two pages to be contigious, we could as
well merge them and save the churn with the second KVM I/O bus device.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Make use of the DRM HDMI AVI infoframe helper to construct the AVI
infoframe, rather than coding this up ourselves. This allows DRM
to supply proper aspect ratio information derived from the DRM
display mode structure.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Detection if a pwm channel is supported was wrong on removal,
causing the code to try removing non-existing sysfs attributes.
That didn't matter much because sysfs attribute removal of non-existing
files fails silently, and because the wrong evaluation always returned
false, but should nevertheless be fixed.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
iovec-backed iov_iter instances are assumed to satisfy several properties:
* no more than UIO_MAXIOV elements in iovec array
* total size of all ranges is no more than MAX_RW_COUNT
* all ranges pass access_ok().
The problem is, invariants of data structures should be established in the
primitives creating those data structures, not in the code using those
primitives. And iov_iter_init() violates that principle. For a while we
managed to get away with that, but once the use of iov_iter started to
spread, it didn't take long for shit to hit the fan - missed check in
sys_sendto() had introduced a roothole.
We _do_ have primitives for importing and validating iovecs (both native and
compat ones) and those primitives are almost always followed by shoving the
resulting iovec into iov_iter. Life would be considerably simpler (and safer)
if we combined those primitives with initializing iov_iter.
That gives us two new primitives - import_iovec() and compat_import_iovec().
Calling conventions:
iovec = iov_array;
err = import_iovec(direction, uvec, nr_segs,
ARRAY_SIZE(iov_array), &iovec,
&iter);
imports user vector into kernel space (into iov_array if it fits, allocated
if it doesn't fit or if iovec was NULL), validates it and sets iter up to
refer to it. On success 0 is returned and allocated kernel copy (or NULL
if the array had fit into caller-supplied one) is returned via iovec.
On failure all allocations are undone and -E... is returned. If the total
size of ranges exceeds MAX_RW_COUNT, the excess is silently truncated.
compat_import_iovec() expects uvec to be a pointer to user array of compat_iovec;
otherwise it's identical to import_iovec().
Finally, import_single_range() sets iov_iter backed by single-element iovec
covering a user-supplied range -
err = import_single_range(direction, address, size, iovec, &iter);
does validation and sets iter up. Again, size in excess of MAX_RW_COUNT gets
silently truncated.
Next commits will be switching the things up to use of those and reducing
the amount of iov_iter_init() instances.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
At the beginning of blk_mq_alloc_tag_set(), we have already checked whether
'set->nr_hw_queues' is zero, so here remove this redundant check.
Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Since
commit 17cabf571e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jan 14 11:20:57 2015 +0000
drm/i915: Trim the command parser allocations
we may then try to allocate a zero-sized object and attempt to extract
its pages. Understandably this fails.
Note that the real offender seems to be
commit b9ffd80ed6
Author: Brad Volkin <bradley.d.volkin@intel.com>
Date: Thu Dec 11 12:13:10 2014 -0800
drm/i915: Use batch length instead of object size in command parser
Testcase: igt/gem_exec_nop #ivb,byt,hsw
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[cherry picked from commit 743e78c1d7
from drm-intel-next because 4.0 seems to be affected by this too,
despite that the obvious culprit is definitely not in 4.0. Whatever,
if fixes a bug.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
