Commit 7bfec5f35c
md/raid5: If there is a spare and a want_replacement device, start replacement.
cause md_check_recovery to call ->add_disk much more often.
Instead of only when the array is degraded, it is now called whenever
md_check_recovery finds anything useful to do, which includes
updating the metadata for clean<->dirty transition.
This causes unnecessary work, and causes info messages from ->add_disk
to be reported much too often.
So refine md_check_recovery to only do any actual recovery checking
(including ->add_disk) if MD_RECOVERY_NEEDED is set.
This fix is suitable for 3.3.y:
Cc: stable@vger.kernel.org
Reported-by: Jan Ceuleers <jan.ceuleers@computer.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Fix segfault caused by using rdev_for_each instead of rdev_for_each_safe
Commit dafb20fa34 mistakenly replaced a safe
iterator with an unsafe one when making some macro changes.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
For the particular issue of x32, which shares code with i386 in the
handling of compat_siginfo_t, the use of a 64-bit clock_t bumps the
sigchld structure out of alignment, which triggers a messy cascade of
padding.
This was already handled on the kernel compat side, but it needs
handling on the user space side, which uses the generic header. To
make that possible:
1. Allow __kernel_clock_t to be overridden in struct siginfo;
2. Allow there to be attributes added to struct siginfo.
Reported-by: H.J. Lu <hjl.rools@gmail.com>
Cc: Bruce J. Beare <bruce.j.beare@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Link: http://lkml.kernel.org/r/CAMe9rOqF6Kh6-NK7oP0Fpzkd4SBAWU%2BG53hwBbSD4iA2UzyxuA@mail.gmail.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
As of
commit 75294957be
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Tue Feb 14 14:06:57 2012 -0700
irq_domain: Remove 'new' irq_domain in favour of the ppc one
the ARM gic controller uses proper irq domains. Fix the MSM gic
initialization and DT so that it works again.
Signed-off-by: David Brown <davidb@codeaurora.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Check __LP64__ isn't a reliable way to tell if we are compiling for x32
since __LP64__ isnn't specified by x86-64 psABI. Not all x86-64
compilers define __LP64__, which was added to GCC 3.3. The updated x32
psABI:
https://sites.google.com/site/x32abi/documents
definse _ILP32 and __ILP32__ for x32. GCC trunk and 4.7 branch have
been updated to define _ILP32 and __ILP32__ for x32. This patch
replaces __LP64__ check with __ILP32__.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With commit a2ef5c4fd4
"ACPI: Move module parameter gts and bfs to sleep.c" the
wake_sleep_flags is required when calling acpi_enter_sleep_state.
The assembler code in wakeup_*.S did not do that. One solution
is to call it from assembler and stick the wake_sleep_flags on
the stack (for 32-bit) or in %esi (for 64-bit). hpa and rafael
both suggested however to create a wrapper function to call
acpi_enter_sleep_state and call said wrapper function
("acpi_enter_s3") from assembler.
For 32-bit, the acpi_enter_s3 ends up looking as so:
push %ebp
mov %esp,%ebp
sub $0x8,%esp
movzbl 0xc1809314,%eax [wake_sleep_flags]
movl $0x3,(%esp)
mov %eax,0x4(%esp)
call 0xc12d1fa0 <acpi_enter_sleep_state>
leave
ret
And 64-bit:
movzbl 0x9afde1(%rip),%esi [wake_sleep_flags]
push %rbp
mov $0x3,%edi
mov %rsp,%rbp
callq 0xffffffff812e9800 <acpi_enter_sleep_state>
leaveq
retq
Reviewed-by: H. Peter Anvin <hpa@zytor.com>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
[v2: Remove extra assembler operations, per hpa review]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1335150198-21899-3-git-send-email-konrad.wilk@oracle.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
With commit a2ef5c4fd4
"ACPI: Move module parameter gts and bfs to sleep.c" the wake_sleep_flags
is required when calling acpi_enter_sleep_state, which means
that if there are functions outside the sleep.c code they
can't get the wake_sleep_flags values.
This converts the function in to a exported value and converts
the module config operands to a function.
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Lin Ming <ming.m.lin@intel.com>
[v2: Parameters can be turned on/off dynamically]
[v3: unsigned char -> u8]
[v4: val -> kp->arg]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1335150198-21899-2-git-send-email-konrad.wilk@oracle.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
While we need to clean up unused single ended line outputs we don't want
to do this if the outputs are in differential mode.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
I keep getting the following messages on the log buffer:
[ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
From the code comment I understand that this something that can -
and does, quite frequently - happen.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Acked-by: Franky Lin<frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Driver incorrectly validates command completion: instead of waiting
for a command to be acknowledged it continues execution. Most of the
time driver gets acknowledge of the command completion in a tasklet
before it executes the next one. But sometimes it sends the next
command before it gets acknowledge for the previous one. In such a
case one of the following error messages appear in the log:
Failed to send SYSTEM_CONFIG: Already sending a command.
Failed to send ASSOCIATE: Already sending a command.
Failed to send TX_POWER: Already sending a command.
After that you need to reload the driver to get it working again.
This bug occurs during roaming (reported by Sam Varshavchik)
https://bugzilla.redhat.com/show_bug.cgi?id=738508
and machine booting (reported by Tom Gundersen and Mads Kiilerich)
https://bugs.archlinux.org/task/28097https://bugzilla.redhat.com/show_bug.cgi?id=802106
This patch doesn't fix the delay issue during firmware load.
But at least device now works as usual after boot.
Cc: stable@kernel.org
Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ctx->vif is dereferenced in different part of iwlwifi code, so do not
nullify it.
This should address at least one of the possible reasons of WARNING at
iwlagn_mac_remove_interface, and perhaps some random crashes when
firmware reset is performed.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The 'ath9k_hw_update_regulatory_maxpower'
helper function has been introduced by
commit a55f858852
(ath9k_hw: Cleanup TX power calculation for AR9287).
Updating of the max_power_level value has been moved
into the helper function in that change, however the
removed code from 'ath9k_hw_ar9287_set_txpower' has
not been replaced with a call of the new helper
function.
Due to that missing call, retrieving tx power for 2x2
and 3x3 chainmask is not handled properly. During the
calculation of the tx power for 2x2 and 3x3 chainmasks
the values are reduced. Those reductions must be
compensated during retrieving.
Fix this by adding the missing call of the helper
function.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to unifying regulatory limit handling
commit ca2c68cc7b
(ath9k_hw: clean up tx power handling) introduced
a new helper function 'ath9k_hw_apply_txpower',
and the direct calls of 'ah->eep_ops->set_txpower'
has been replaced by a call of the helper function.
This caused a change in the behaviour of the
'ath9k_hw_set_txpowerlimit' function. The purpose
of that function is to calculate and store the
rate txpower table and the regulatory limit without
touching the hardware registers. Before the commit,
the 'test' parameter of the function was passed to
the 'ah->eep_ops->set_txpower'. Now the calling of
the 'set_txpower' function happens indirectly through
'ath9k_hw_apply_txpower', so the 'test' argument of
the 'set_txpower' is always 'false'.
This patch restores the original behaviour of
'ath9k_hw_set_txpowerlimit' by adding a new
argument to 'ath9k_hw_apply_txpower.'
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Richard Kuo <rkuo@codeaurora.org>
This regression has been introduced in
commit f56f821feb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Mar 25 19:47:41 2012 +0200
mm: extend prefault helpers to fault in more than PAGE_SIZE
I have failed to notice this because x86 asm seems to happily compile
things as-is.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The new structs added in struct detailed_data_monitor_range must be
marked with packed attribute although the outer struct itself is
already marked as packed. Otherwise these 7-bytes structs may be
aligned, and give the wrong position and size for the data.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
HD panel (1366x768) found most commonly on laptops can't be represented
exactly in CVT/DMT expression, which leads to 1368x768 instead, because
1366 can't be divided by 8.
Add a hack to convert to 1366x768 manually as an exception.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Slightly larger than normal - the DAPM fix is a "this should always have
worked" type of thing which is very clear and should have no impact on
systems that don't need it. The WM8994 fix is driver specific but
pretty important for that driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJPlURUAAoJEBus8iNuMP3dVL4P/1ynNUPmdBhiDeVT6BrJxeyL
dKGBaqYxv8Sfzu8O+TIaqCyls+qp3++vQO26YgeuZNBnE+OtRaJbbpatIBe7Gmyr
7glYowUih+B/lfLbwlPCKCAs2ahk6oUbY3bFVqgOgzX9Zt4M73MEs7oVTPD2TvtQ
ZkudzzopzvEquh1NT/+wLmdJwSgOGfa2fLyt/+OaD6LCxDaZ3RPsO/wFoEqnSjKp
rdqHeOKAg/vFDSfFMwhnqZ5hGUUTqg8HlZ3urYvGrkKsyNUgPkIeNQKy4e0FxeSP
Lqj/EbKvH0gKWNdQkG6AWQpdN5bpqtWZb0h5BIsZhWqmjy7dEOopjnh/Hrmj+nFQ
ac8SGqq2/2HhbE/irN3y4Z3wOJJq9BEiFdUqIntOq95eT3S1Ib00osLR0SMHLwqe
Sk8UfVAspt9tdzqbzy67enAEjDsNo3OalV7qXIjYzL+csCDs7yPEM+JFxKx45ubW
tz3Wr3zjSlShYIeIYxGF8VuiH0QBhcXFMME/hv/QLAmfT6KvB6JlKlyWvHqJhQYE
mKQLz7AvARBfoaPhwn2+wcXO157FTC22Xt6pKo9TLwCotHNP2YO6lLVPE10GF7rf
aecCJe3QAGAWf3TwAiqcv8vOaR6TaO2f3hSAAPkqEWh6uBVC6wib5fJZzuzOafr2
Grt/dZcdfaiN4Rdpok7F
=oz/g
-----END PGP SIGNATURE-----
Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: updates for 3.4
Slightly larger than normal - the DAPM fix is a "this should always have
worked" type of thing which is very clear and should have no impact on
systems that don't need it. The WM8994 fix is driver specific but
pretty important for that driver.
The QUECVT flag should not prevent conversions from
being granted immediately when the convert queue is
empty.
Signed-off-by: David Teigland <teigland@redhat.com>
The file kernel/irq/debug.h temporarily defines P, PS, PD
and then undefines them. However these names aren't really
"internal" enough, and collide with other more legit users
such as the ones in the xtensa arch, causing:
In file included from kernel/irq/internals.h:58:0,
from kernel/irq/irqdesc.c:18:
kernel/irq/debug.h:8:0: warning: "PS" redefined [enabled by default]
arch/xtensa/include/asm/regs.h:59:0: note: this is the location of the previous definition
Add a handful of underscores to do a better job of hiding these
temporary macros.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Caused by commit 6c03438ede
kernel.h: doesn't explicitly use bug.h, so don't include it.
This header uses bug.h so explicitly include it now that the
implicit presence was removed by 6c03438ed.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Caused by commit 3785006ac3
"xtensa: don't mask signals if we fail to setup signal stack"
It assigns a return value to "ret", but there is no such variable
anywhere in scope. Create one.
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Chris Zankel <chris@zankel.net>
Acked-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Using coherent DMA memory with the OMAP DMA engine results in
unpredictable behaviour due to memory ordering issues; as things stand,
there is no guarantee that data written to coherent DMA memory will be
visible to the DMA hardware.
This is because the OMAP dma_write() accessor contains no barriers,
necessary on ARMv6 and above. The effect of this can be seen in comments
in the OMAP serial driver, which incorrectly talks about cache flushing
for the coherent DMA stuff.
Rather than adding barriers to the accessors, add it in the DMA support
code just before we enable DMA, and just after we disable DMA. This
avoids having barriers for every DMA register access.
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The MMCI driver will not work without two IRQs since this is not
flagged as a single-irq variant. Looking through the complex IRQ
definition for the MMCI on the versatile (including an #if 1
statement forcing MMCI IRQ0 to the VIC) this appears to the the
correct IRQ number for both models.
Cc: Niklas Hernaeus <niklas.hernaeus@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The ARM PCS mandates that the length and stride bits of the fpscr are
cleared on entry to and return from a public interface. Although signal
handlers run asynchronously with respect to the interrupted function,
the handler itself expects to run as though it has been called like a
normal function.
This patch updates the state mirroring the VFP hardware before entry to
a signal handler so that it adheres to the PCS. Furthermore, we disable
VFP to ensure that we trap on any floating point operation performed by
the signal handler and synchronise the hardware appropriately. A check
is inserted after the signal handler to avoid redundant flushing if VFP
was not used.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The user VFP state must be preserved (subject to ucontext modifications)
across invocation of a signal handler and this is currently handled by
vfp_{preserve,restore}_context in signal.c
Since this code requires intimate low-level knowledge of the VFP state,
this patch moves it into vfpmodule.c.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
PL310 errata #588369 and #727915 require writes to the debug registers
of the cache controller to work around known problems. Writing these
registers on L220 may cause deadlock, so ensure that we only perform
this operation when we identify a PL310 at probe time.
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The workaround for PL310 erratum #753970 can lead to deadlock on systems
with an L220 cache controller.
This patch makes the workaround effective only when the cache controller
is identified as a PL310 at probe time.
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Erratum #326103 ("FSR write bit incorrect on a SWP to read-only memory")
only affects the ARM 1136 core prior to r1p0. The workaround
disassembles the faulting instruction to determine whether it was a read
or write access on all v6 cores.
An issue has been reported on the ARM 11MPCore whereby loading the
faulting instruction may happen in parallel with that page being
unmapped, resulting in a deadlock due to the lack of TLB broadcasting
in hardware:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091561.html
This patch limits the workaround so that it is only used on affected
cores, which are known to be UP only. Other v6 cores can rely on the
FSR to indicate the access type correctly.
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
A small fallout from Vinod's conversions to dma_transfer_direction,
this small comparison was done with a dma_data_direction instead.
Fix it by comparing against the correct enum.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
The patch "ARM: amba: Remove AMBA level regulator support" breaks
the DMA40 driver since the <linux/amba/bus.h> header implicitly
included the regulator consumer header. So include it explicitly
and fix the build error.
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
can be directly stopped by issuing a SUSPEND_REQ on the EE
bits. There is no need to suspend the physical channel and
restart it.
Also, the support for pre-V2 hw is discontinued.
EE bits for writing:
00: disable only if AS=11 or AS=00
01: enable
10: suspend_req only if AS=01 & EE=01 or EE=11
11: round / no change for writing
Signed-off-by: Narayanan G <narayanan.gopalakrishnan@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
This ensures a clean startup of the channels, without this change some
use cases could result in issues in a small proportion of cases.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
with this patch, if the memory region is physically non-continuous
then VM_MIXEDMAP is set to vm->vm_flags otherwise VM_PFNMAP.
we had missed this flag setting.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
this patch fixes the problem that the physical memory region to be mapped
to user space could be exceeded. if page fault address was placed at between
buffer start and end then memory region to be mapped would be exceeded.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
the gem was already allocated at gem allocation time but is allocated
at page fault handler so this patch fixes the problem that gem was
allocated one more time.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Remove max_data_size sysfs entry. Otherwise is possible
to have a buffer overrun if its value is increased after
the device is open.
Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Remove custom hack and make use of the notifier chain interfaces for
delivering events from the ports to their associated clients.
Clients that want to receive port events need to register their callbacks
using hsi_register_port_event(). The callbacks can be called in interrupt
context. Use hsi_unregestier_port_event() to undo the registration.
Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
HSI controllers and ports do not belong to the HSI bus.
Those devices are not supposed to have a driver attached to them.
Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
HSI client structure should be freed on error path after
calling device_registration by dropping a reference to it.
Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Use the proper release mechanism for hsi_controller and
hsi_ports structures. Free the structures through their
associated device release callbacks.
Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit a692b0eec5.
Tom reports:
[ 8.741033] ------------[ cut here ]------------
[ 8.741038] WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0xc1/0xf0()
[ 8.741040] Hardware name: To Be Filled By O.E.M.
[ 8.741041] sysfs: cannot create duplicate filename
...and missing 2 out of 4 drives connected to mvsas. Commit a692b0ee
made the assumption that all the phy ids an lldd registers to libsas are
unique. However, in the "multi-chip" case mvsas does a rather annoying
duplication of phy ids in the array passed to libsas. So, for example,
chip0 has phy0-3 at ha phy index 0-3 and chip1 has its phy0-3 at ha phy
index 4-7. The more natural model would be to create a scsi_host (and
sas_ha) per chip (controller), but for now revert the naming fix which
unfortunately means dealing with unpredictable end-device names for a
bit longer.
Cc: Xiangliang Yu <yuxiangl@marvell.com>
Cc: Patrick Thomson <patrick.s.thomson@intel.com>
Reported-by: Tom Rini <trini@ti.com>
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Normalize phy->attached_sas_addr to return a zero-address in the case
when device-type == NO_DEVICE or the linkrate is invalid to handle
expanders that put non-zero sas addresses in the discovery response:
sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device)
sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device)
sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device)
sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device)
Reported-by: Andrzej Jakowski <andrzej.jakowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
NeilBrown