qla2x00_mem_alloc() returns 1 on success and -ENOMEM on failure. On the
one hand the caller assumes non-zero is success but on the other hand
the caller also assumes that it returns an error code.
I've fixed it to return zero on success and a negative error code on
failure. This matches the documentation as well.
[jejb: checkpatch fix]
Fixes: e315cd28b9 ('[SCSI] qla2xxx: Code changes for qla data structure refactoring')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
isci is needlessly tying libata's hands by returning
SAM_STAT_CHECK_CONDITION to some ata errors. Instead, prefer
SAS_PROTO_RESPONSE to let libata (via sas_ata_task_done()) disposition
the device-to-host fis.
For example isci is triggering an HSM Violation where AHCI is showing a
simple media error for the same bus condition:
isci:
ata7.00: failed command: READ VERIFY SECTOR(S)
ata7.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0
res 01/04:00:00:00:00/00:00:00:00:00/e0 Emask 0x3 (HSM violation)
ahci:
ata6.00: failed command: READ VERIFY SECTOR(S)
ata6.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0
res 51/40:01:00:00:00/00:00:00:00:00/e0 Emask 0x9 (media error)
Note that the isci response matches this from sas_ata_task_done():
/* We saw a SAS error. Send a vague error. */
[..]
dev->sata_dev.fis[3] = 0x04; /* status err */
dev->sata_dev.fis[2] = ATA_ERR;
The end effect is that isci is needlessly triggering hard resets when
they are not necessary.
Reported-by: Xun Ni <xun.ni@intel.com>
Tested-by: Nelson Cheng <nelson.cheng@intel.com>
Acked-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
libsas sometimes short circuits timeouts to force commands into error
recovery. It is misleading to log that the command timed-out in
sas_scsi_timed_out() when in fact it was just queued for error handling.
It's also redundant in the case of a true timeout as libata eh will
detect and report timeouts via it's AC_ERR_TIMEOUT facility.
Given that some environments consider "timeout" errors to be indicative
of impending device failure demote the sas_scsi_timed_out() timeout
message to be disabled by default. This parallels ata_scsi_timed_out().
[jejb: checkpatch fix]
Reported-by: Xun Ni <xun.ni@intel.com>
Tested-by: Nelson Cheng <nelson.cheng@intel.com>
Acked-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Send aborts to the firmware via the request/response queue mechanism.
Signed-off-by: Armen Baloyan <armen.baloyan@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
- Fix interpreting the wrong IOCB type for task management
functions in the response path.
- Merge the task management function handling for various adapters.
Signed-off-by: Armen Baloyan <armen.baloyan@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Allow for the capture of a firmware dump but have a sysfs node
(allow_cna_fw_dump) to allow the feature to be enabled/disabled dynamically.
The default is off.
Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Tell the mid-layer that number of commands we can queue is the available
resources we have minus a small amount for internal commands.
Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
SCSI retry delay upon SAM_STAT_BUSY/_SET_FULL was not being handled
in bnx2fc. This patch adds such handling by returning TARGET_BUSY
to the SCSI ML for the corresponding LUN until the retry timer expires.
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The problem has been identified to be a change in the scsi_remove_device
path where a call to the pm_runtime_set_memalloc_noio was added when
del_gendisk is called in this path. Note that the new pm routine
attempts to cycle through all parent devices from the FC target device
to set the memalloc_noio flag. Because of this new change, a dependency
was created between the FC target device and the parent netdev device
in the destroy path.
In order to synchronized the destroy paths, bnx2fc has been modified
to flush all destroy workqueues in the NETDEV_UNREGISTER return path.
[ 4.123584] BUG: soft lockup - CPU#8 stuck for 22s! [kworker/8:3:8082]
[ 4.123713] Call Trace:
[ 4.123719] [<ffffffff815dfbe0>] klist_next+0x20/0xf0
[ 4.123725] [<ffffffff813e9220>] ? pm_save_wakeup_count+0x70/0x70
[ 4.123731] [<ffffffff813d9e4e>] device_for_each_child+0x4e/0x70
[ 4.123735] [<ffffffff813e9554>] pm_runtime_set_memalloc_noio+0x94/0xf0
[ 4.123740] [<ffffffff812d4d74>] del_gendisk+0x264/0x2a0
[ 4.123747] [<ffffffffa00c6dc9>] sd_remove+0x69/0xb0 [sd_mod]
[ 4.123751] [<ffffffff813de24f>] __device_release_driver+0x7f/0xf0
[ 4.123754] [<ffffffff813de2e3>] device_release_driver+0x23/0x30
[ 4.123757] [<ffffffff813ddab4>] bus_remove_device+0xf4/0x170
[ 4.123760] [<ffffffff813da475>] device_del+0x135/0x1d0
[ 4.123765] [<ffffffff81411b75>] __scsi_remove_device+0xc5/0xd0
[ 4.123768] [<ffffffff81411ba6>] scsi_remove_device+0x26/0x40
[ 4.123770] [<ffffffff81411d40>] scsi_remove_target+0x160/0x210
[ 4.123775] [<ffffffffa0420e4c>] fc_rport_final_delete+0xac/0x1f0 [scsi_transport_fc]
[ 4.123780] [<ffffffff810774ab>] process_one_work+0x17b/0x460
[ 4.123783] [<ffffffff8107825b>] worker_thread+0x11b/0x400
[ 4.123786] [<ffffffff81078140>] ? rescuer_thread+0x3e0/0x3e0
[ 4.123791] [<ffffffff8107e9c0>] kthread+0xc0/0xd0
[ 4.123794] [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
[ 4.123798] [<ffffffff8160ceec>] ret_from_fork+0x7c/0xb0
[ 4.123801] [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
pm80xx_get_gsm_dump() was returning "1" in error case
instead of negative error value.
Signed-off-by: Viswas G <Viswas.G@pmcs.com>
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Removed redundant code snippets in pm8001_hwi.c and
pm8001_ctl.c
Signed-off-by: Viswas G <Viswas.G@pmcs.com>
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
When sample_hold_time is zero (this is the case when DT is not used or if
atmel,adc-sample-hold-time is omitted), then the calculated shtim is large.
Make that 0, which is the default for that register and the ADC will then use a
sane value of 2/ADCCLK or 1/ADCCLK depending on the version.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We can't use "at91_adc" to refer to the at91_adc driver anymore as
the name is used to match an id_table.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We can't use "at91_adc" to refer to the at91_adc driver anymore as the name is
used to match an id_table.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In read integration time function, assign 0 to val.
Because, prevent return inaccurate value when call read integration time.
Cc: Stable@vger.kernel.org
Cc: Kevin Tsai <ktsai@capellamicro.com>
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Document compatible string, required and optional DT properties for
AS3935 chipset driver.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This is a tiny preventative measure to make sure we can't write beyond
PAGE_SIZE on the buffers being used in sysfs for iio. There is currently
no way for this to happen, but the change makes this code more robust
for the future.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When the reserved memory patches hit -next, several legacy (non-DT) boot
failures were detected and bisected down to that commit. There needs to
be some sanity checking whether a DT is even present before parsing the
reserved ranges.
Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Since the last time I've looked more of this stuff sprouted up. Stomp
it down again.
Repeating the original justification for ripping this all out: There's
absolutely no need to deteach connectors before cleaning them up at
driver unload time. And since drm doesn't support hotplugging kms
objects at all it's positively dangerous to attempt this at runtime.
Luckily imx only detachs at driver cleanup time and hence we can
savely remove this.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Eric W. Biederman says:
====================
Don't receive packets when the napi budget == 0
After reading through all 120 drivers supporting netpoll I have found 16
more that process at least received packet when the napi budget == 0.
Processing more packets than your budget has always been a bug but
we haven't cared before so it looks like these drivers slipped through,
and need fixes.
As netpoll will shortly be using a budget of 0 to get the tx queue
processing with the rx queue processing we now care.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Processing any incoming packets with a with a napi budget of 0
is incorrect driver behavior.
This matters as netpoll will shortly call drivers with a budget of 0
to avoid receive packet processing happening in hard irq context.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
