| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Cc: James Hogan <james.hogan@imgtec.com>
Cc: kvm@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7015/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Cc: James Hogan <james.hogan@imgtec.com>
Cc: kvm@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7011/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
For para-virtualized guests running under KVM or other equivalent
hypervisor.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Cc: James Hogan <james.hogan@imgtec.com>
Cc: kvm@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7004/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
- prep refactoring for execlists (Oscar Mateo)
- corner-case fixes for runtime pm (Imre)
- tons of vblank improvements from Ville
- prep work for atomic plane/sprite updates (Ville)
- more chv code, now almost complete (tons of different people)
- refactoring and improvements for drm_irq.c merged through drm-intel-next
- g4x/ilk reset improvements (Ville)
- removal of encoder->mode_set
- moved audio state tracking into pipe_config
- shuffled fb pinning out of the platform crtc modeset callbacks into core code
- userptr support (Chris)
- OOM handling improvements from Chris, with now have a neat oom notifier which
jumps additional debug information.
- topdown allocation of ppgtt PDEs (Ben)
- fixes and small improvements all over
* tag 'drm-intel-next-2014-05-23' of git://anongit.freedesktop.org/drm-intel: (187 commits)
drm/i915: Kill private_default_ctx off
drm/i915: s/i915_hw_context/intel_context
drm/i915: Split the ringbuffers from the rings (3/3)
drm/i915: Split the ringbuffers from the rings (2/3)
drm/i915: Split the ringbuffers from the rings (1/3)
drm/i915: s/intel_ring_buffer/intel_engine_cs
drm/i915: disable GT power saving early during system suspend
drm/i915: fix possible RPM ref leaking during RPS disabling
drm/i915: remove user GTT mappings early during runtime suspend
drm/i915: Implement WaVcpClkGateDisableForMediaReset:ctg, elk
drm/i915: Fix gen2 and hsw+ scanline counter
drm/i915: Draw a picture about video timings
drm/i915: Improve gen3/4 frame counter
drm/i915: Add a small adjustment to the pixel counter on interlaced modes
drm/i915: Hold CRTC lock whilst freezing the planes
drm/i915: Only discard backing storage on releasing the last ref
drm/i915: Wait for pending page flips before enabling/disabling the primary plane
drm/i915: grab the audio power domain when enabling audio on HSW+
drm/i915: don't read HSW_AUD_PIN_ELD_CP_VLD when the power well is off
drm/i915: move bsd dispatch index somewhere better
...
|
|
Remove the option to provide DMA configuration as platform data,
enforce it through DT.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Roland Stigge <stigge@antcom.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
|
|
The device which identifies itself as a "USB Keykoard" (no typo) with VID:PID
1a2c:0023 does not seem to be handling the reports initialization very well.
This results in a "usb_submit_urb(ctrl) failed: -1" message from the kernel
when connected, and a delay before its initialization. This patch adds the
quirk for this device, which causes the delay to disappear.
[jkosina@suse.cz: remove superfluous comment and fix ordering]
Signed-off-by: Daniel Kamil Kozar <dkk089@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The SDMA sometimes doesn't seem to work reliable.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
|
|
Only necessary if we don't use the same engine for buffer moves and table updates.
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
Use GFP_ATOMIC allocations when sending removal notifications of
anonymous sets from rcu callback context. Sleeping in that context
is illegal.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Three changes to allow the deletion of several objects with dependencies
in one transaction, they are:
1) Introduce speculative counter increment/decrement that is undone in
the abort path if required, thus we avoid hitting -EBUSY when deleting
the chain. The counter updates are reverted in the abort path.
2) Increment/decrement table/chain use counter for each set/rule. We need
this to fully rely on the use counters instead of the list content,
eg. !list_empty(&chain->rules) which evaluate true in the middle of the
transaction.
3) Decrement table use counter when an anonymous set is bound to the
rule in the commit path. This avoids hitting -EBUSY when deleting
the table that contains anonymous sets. The anonymous sets are released
in the nf_tables_rule_destroy path. This should not be a problem since
the rule already bumped the use counter of the chain, so the bound
anonymous set reflects dependencies through the rule object, which
already increases the chain use counter.
So the general assumption after this patch is that the use counters are
bumped by direct object dependencies.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
There's no rbtree rcu version yet, so let's fall back on the spinlock
to protect the concurrent access of this structure both from user
(to update the set content) and kernel-space (in the packet path).
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The patch c7c32e7 ("netfilter: nf_tables: defer all object release via
rcu") indicates that we always release deleted objects in the reverse
order, but that is only needed in the abort path. These are the two
possible scenarios when releasing objects:
1) Deletion scenario in the commit path: no need to release objects in
the reverse order since userspace already ensures that dependencies are
fulfilled), ie. userspace tells us to delete rule -> ... -> rule ->
chain -> table. In this case, we have to release the objects in the
*same order* as userspace provided.
2) Deletion scenario in the abort path: we have to iterate in the reverse
order to undo what it cannot be added, ie. userspace sent us a batch
that includes: table -> chain -> rule -> ... -> rule, and that needs to
be partially undone. In this case, we have to release objects in the
reverse order to ensure that the set and chain objects point to valid
rule and table objects.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The transaction needs to be placed at the end of the commit list,
otherwise event notifications are reordered and we may crash when
releasing object via call_rcu.
This problem was introduced in 60319eb ("netfilter: nf_tables: use new
transaction infrastructure to handle elements").
Reported-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Only relevant if we got VM_BLOCK_SIZE>9, but better save than sorry.
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
Allocation of memory need only to happen once, that is
after the proper checks on the NFACCT_FLAGS have been
done. Otherwise the code can return without freeing
already allocated memory.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
__constant_cpu_to_be16 converted to cpu_to_be16
This patch fixes checkpatch warnings:
"WARNING: __constant_cpu_to_be16 should be cpu_to_be16"
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Ack-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
shows like this:
[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1
[ 9641.234116] [<c0011a6c>] (unwind_backtrace+0x0/0x12c) from [<c000d0b0>] (show_stack+0x20/0x24)
[ 9641.234137] [<c000d0b0>] (show_stack+0x20/0x24) from [<c0311134>] (dump_stack+0x20/0x28)
[ 9641.234188] [<c0311134>] (dump_stack+0x20/0x28) from [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs])
[ 9641.234265] [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs])
[ 9641.234307] [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [<c00cdad8>] (shrink_slab+0x1d4/0x2f8)
[ 9641.234327] [<c00cdad8>] (shrink_slab+0x1d4/0x2f8) from [<c00d03d0>] (do_try_to_free_pages+0x300/0x544)
[ 9641.234344] [<c00d03d0>] (do_try_to_free_pages+0x300/0x544) from [<c00d0a44>] (try_to_free_pages+0x2d0/0x398)
[ 9641.234363] [<c00d0a44>] (try_to_free_pages+0x2d0/0x398) from [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8)
[ 9641.234382] [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8) from [<c00f62d8>] (new_slab+0x78/0x238)
[ 9641.234400] [<c00f62d8>] (new_slab+0x78/0x238) from [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c)
[ 9641.234419] [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c) from [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188)
[ 9641.234459] [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188) from [<bf227908>] (do_readpage+0x168/0x468 [ubifs])
[ 9641.234553] [<bf227908>] (do_readpage+0x168/0x468 [ubifs]) from [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs])
[ 9641.234606] [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs]) from [<c00c17c0>] (filemap_fault+0x304/0x418)
[ 9641.234638] [<c00c17c0>] (filemap_fault+0x304/0x418) from [<c00de694>] (__do_fault+0xd4/0x530)
[ 9641.234665] [<c00de694>] (__do_fault+0xd4/0x530) from [<c00e10c0>] (handle_pte_fault+0x480/0xf54)
[ 9641.234690] [<c00e10c0>] (handle_pte_fault+0x480/0xf54) from [<c00e2bf8>] (handle_mm_fault+0x140/0x184)
[ 9641.234716] [<c00e2bf8>] (handle_mm_fault+0x140/0x184) from [<c0316688>] (do_page_fault+0x150/0x3ac)
[ 9641.234737] [<c0316688>] (do_page_fault+0x150/0x3ac) from [<c000842c>] (do_DataAbort+0x3c/0xa0)
[ 9641.234759] [<c000842c>] (do_DataAbort+0x3c/0xa0) from [<c0314e38>] (__dabt_usr+0x38/0x40)
After analyzing the code, I found a condition that may cause this failed
in correct operations. Thus, I think this assertion is wrong and should be
removed.
Suppose there are two clean znodes and one dirty znode in TNC. So the
per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
on this znode. We clear COW bit and DIRTY bit in write_index() without
@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
comments in write_index() shows, if another process hold @tnc_mutex and
dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
free_obsolete_znodes() to keep it right.
If shrink_tnc() performs between decrease and increase, it will release
other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
soon correct @clean_zn_cnt and no harm to fs in this case, I think this
assertion could be removed.
2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2
Thread A (commit) Thread B (write or others) Thread C (shrinker)
->write_index
->clear_bit(DIRTY_NODE)
->clear_bit(COW_ZNODE)
@clean_zn_cnt == 2
->mutex_locked(&tnc_mutex)
->dirty_cow_znode
->!ubifs_zn_cow(znode)
->!test_and_set_bit(DIRTY_NODE)
->atomic_dec(&clean_zn_cnt)
->mutex_unlocked(&tnc_mutex)
@clean_zn_cnt == 1
->mutex_locked(&tnc_mutex)
->shrink_tnc
->destroy_tnc_subtree
->atomic_sub(&clean_zn_cnt, 2)
->ubifs_assert <- hit
->mutex_unlocked(&tnc_mutex)
@clean_zn_cnt == -1
->mutex_lock(&tnc_mutex)
->free_obsolete_znodes
->atomic_inc(&clean_zn_cnt)
->mutux_unlock(&tnc_mutex)
@clean_zn_cnt == 0 (correct after shrink)
Signed-off-by: hujianyang <hujianyang@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
|
|
Fix a long standing bug where, for ARMv6+, we don't fully ensure that
the C code sets the same cache policy as the assembly code. This was
introduced partially by commit 11179d8ca28d ([ARM] 4497/1: Only allow
safe cache configurations on ARMv6 and later) and also by adding SMP
support.
This patch sets the default cache policy based on the flags used by the
assembly code, and then ensures that when a cache policy command line
argument is used, we verify that on ARMv6, it matches the initial setup.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
We can use the alignment_trap assembly macro here too.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
cr_no_alignment is really only used by the alignment code. Since we no
longer change the setting of cr_alignment after boot, we can localise
this to alignment.c
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
alignment.c will not be built unless CPU_CP15 is set:
config CPU_CP15
bool
config CPU_CP15_MMU
bool
select CPU_CP15
config ALIGNMENT_TRAP
bool
depends on CPU_CP15_MMU
So there's no point having conditionals on CPU_CP15 within this code.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
adjust_cr() is not used anymore, so let's get rid of it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Keep all bits of alignment handling together.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Several places open-code this manipulation, let's consolidate this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable ret
unused; remove it.
This fixes the following compilation warning:
drivers/staging/imx-drm/imx-tve.c: In function ‘imx_tve_connector_mode_valid’:
drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’ [-Wunused-variable]
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
With this commit:
2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range
If clflushopt is available on the system, we use it instead of clflush
in drm_clflush_virt_range. There were two calls to clflush in this
function, but only one was changed to clflushopt. This patch changes
the other clflush call to clflushopt.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: H Peter Anvin <h.peter.anvin@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Code should be indented using tabs rather than spaces (see CodingStyle)
and the canonical form to declare a constant static variable is using
"static const" rather than "const static". Fixes the following warnings
from checkpatch:
$ scripts/checkpatch.pl -f drivers/gpu/drm/drm_plane_helper.c
WARNING: storage class should be at the beginning of the declaration
#40: FILE: drivers/gpu/drm/drm_plane_helper.c:40:
+const static uint32_t safe_modeset_formats[] = {
WARNING: please, no spaces at the start of a line
#41: FILE: drivers/gpu/drm/drm_plane_helper.c:41:
+ DRM_FORMAT_XRGB8888,$
WARNING: please, no spaces at the start of a line
#42: FILE: drivers/gpu/drm/drm_plane_helper.c:42:
+ DRM_FORMAT_ARGB8888,$
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Include the drm_plane_helper.h header file to fix the following sparse
warnings:
CHECK drivers/gpu/drm/drm_plane_helper.c
drivers/gpu/drm/drm_plane_helper.c:102:5: warning: symbol 'drm_primary_helper_update' was not declared. Should it be static?
drivers/gpu/drm/drm_plane_helper.c:219:5: warning: symbol 'drm_primary_helper_disable' was not declared. Should it be static?
drivers/gpu/drm/drm_plane_helper.c:233:6: warning: symbol 'drm_primary_helper_destroy' was not declared. Should it be static?
drivers/gpu/drm/drm_plane_helper.c:241:30: warning: symbol 'drm_primary_helper_funcs' was not declared. Should it be static?
drivers/gpu/drm/drm_plane_helper.c:259:18: warning: symbol 'drm_primary_helper_create_plane' was not declared. Should it be static?
Doing that makes gcc complain as follows:
CC drivers/gpu/drm/drm_plane_helper.o
drivers/gpu/drm/drm_plane_helper.c:260:19: error: conflicting types for 'drm_primary_helper_create_plane'
struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
^
In file included from drivers/gpu/drm/drm_plane_helper.c:29:0:
include/drm/drm_plane_helper.h:42:19: note: previous declaration of 'drm_primary_helper_create_plane' was here
struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
^
drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_create_plane':
drivers/gpu/drm/drm_plane_helper.c:274:11: warning: assignment discards 'const' qualifier from pointer target type
formats = safe_modeset_formats;
^
In file included from include/linux/linkage.h:6:0,
from include/linux/kernel.h:6,
from include/drm/drmP.h:45,
from drivers/gpu/drm/drm_plane_helper.c:27:
drivers/gpu/drm/drm_plane_helper.c: At top level:
drivers/gpu/drm/drm_plane_helper.c:289:15: error: conflicting types for 'drm_primary_helper_create_plane'
EXPORT_SYMBOL(drm_primary_helper_create_plane);
^
include/linux/export.h:57:21: note: in definition of macro '__EXPORT_SYMBOL'
extern typeof(sym) sym; \
^
drivers/gpu/drm/drm_plane_helper.c:289:1: note: in expansion of macro 'EXPORT_SYMBOL'
EXPORT_SYMBOL(drm_primary_helper_create_plane);
^
In file included from drivers/gpu/drm/drm_plane_helper.c:29:0:
include/drm/drm_plane_helper.h:42:19: note: previous declaration of 'drm_primary_helper_create_plane' was here
struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
^
Which can easily be fixed by making the signatures of the implementation
and the prototype match.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The recent commit [3ea87855: drm/helper: lock all around force mode
restore] introduced drm_modeset_lock_all() in
drm_helper_resume_force_mode() itself, while exynos driver takes this
lock before calling it. Move the function call outside the lock for
avoiding a deadlock.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The recent commit [3ea87855: drm/helper: lock all around force mode
restore] introduced drm_modeset_lock_all() in
drm_helper_resume_force_mode() itself, while ast driver still takes
this lock before calling it. Remove the caller side lock for avoid a
fatal deadlock.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Only gma500 is still using this, once that's converted we can kill all
this code. If that conversion doesn't happen soonish I think we should
just move this helper code into the gma500 driver itself to avoid
abuse from new drivers.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Make return value an int instead of an unsigned char so that
we do not lose negative error return values.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Webb Scales <webb.scales@hp.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
They are annoying and do not help anyone.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Justin Lindley <justin.lindley@hp.com>
Reviewed-by: Mike Miller <michael.miller@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
It shouldn't happen that we get a check condition with no sense data, but if it
does, we shouldn't just drop the check condition on the floor.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Justin Lindley <justin.lindley@hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Justin Lindley <justin.lindley@hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
CTLR_STATE_CHANGE_EVENT and CTLR_STATE_CHANGE_EVENT_REDUNDANT_CNTRL
do not require rescans to be initiated. Current firmware filters out
these events already, but some out of date firmware doesn't, so the
driver needs to filter them out too. Without this change and with out
of date firmware you may see the driver spending a lot of time
scanning devices unnecessarily on some Smart Arrays.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Justin Lindley <justin.lindley@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
There's nothing the user can or should do about these messages,
the commands are retried down the normal RAID path, and the
messages just flood the logs and sap performance.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Joe Handzik <joseph.t.handzik@hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Joe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Joe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
for controllers which support either of the ioaccel transport methods.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Joe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Avoid excessive locking by using per-cpu variable for lockup_detected
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Scott Teel <scott.teel@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Scott Teel <scott.teel@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Now that we can allocate more than 4 reply queues (up to 64)
we shouldn't try to make them share the same allocation but
should allocate them separately.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Scott Teel <scott.teel@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
No sense having 8 or 16 reply queues if you only have 4 cpus,
and likewise no sense limiting to 8 reply queues if you have
many more cpus.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Scott Teel <scott.teel@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
They are not completely free of cost when disabled and
when enabled emitting debug output for every command
submitted produces far too much output to be useful.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Webb Scales <webb.scales@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Webb Scales <webb.scales@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
After 3.22 firmware, PMC firmware guys tell us the
previous 5 second delay after a reset now needs to
be 10 secs to avoid a PCIe error due to the driver
looking at the controller too soon after the reset.
Signed-off-by: Justin Lindley <justin.lindley@hp.com>
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
Treat the the data direction bits as a bit mask allowing both
READ and WRITE at the same time instead of testing for equality
to see if it's a exclusively a READ or a WRITE.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Webb Scales <webb.scales@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
The fields "major", "max_outstanding", and "usage_count"
of struct ctlr_info were not used for anything.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: Mike Miller <michael.miller@canonical.com>
Reviewed-by: Webb Scales <webb.scales@hp.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
