This is a fairly serious bug in RAID10.

When a RAID10 array is degraded and a hot-spare is activated, the
spare does not take up the empty slot, but rather replaces the first
working device.
This is likely to make the array non-functional.   It would normally
be possible to recover the data, but that would need care and is not
guaranteed.

This bug was introduced in commit
   2bb77736
which first appeared in 3.1.

Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

Adjust i2c-algo-pca to return fault codes compliant with
Documentation/i2c/fault-codes, rather than the undocumented and
vague -EREMOTEIO.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>

Adjust i2c-algo-bit to return fault codes compliant with
Documentation/i2c/fault-codes, rather than the undocumented and
vague -EREMOTEIO.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

If bus testing fails due to the bus being seen as busy, it might be
helpful for developers to know which line is unexpectedly low.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>

Always failing to register I2C buses when the line testing fails is a
little harsh. While such a failure is definitely a bug in the driver
that exposes the affected I2C bus, things may still work fine if the
missing initialization steps are done later, before the I2C bus is
used. So it seems a better debugging tool to just report the test
failure by default. I introduce bit_test=2 if anyone really misses the
original behavior of bit_test=1.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>

WARNING: drivers/i2c/busses/built-in.o(.data+0x47c8): Section mismatch in reference from the variable scx200_pci_drv to the function .devinit.text:scx200_probe()
The variable scx200_pci_drv references
the function __devinit scx200_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: NHarvey Yang <harvey.huawei.yang@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

On m68k, I get:

drivers/i2c/busses/i2c-elektor.c: In function ‘pcf_isa_init’:
drivers/i2c/busses/i2c-elektor.c:153: error: implicit declaration of function ‘ioport_map’
drivers/i2c/busses/i2c-elektor.c:153: warning: assignment makes pointer from integer without a cast
drivers/i2c/busses/i2c-elektor.c: In function ‘elektor_probe’:
drivers/i2c/busses/i2c-elektor.c:287: error: implicit declaration of function ‘ioport_unmap’

Since commit 82ed223c ("iomap: make IOPORT/PCI
mapping functions conditional"), ioport_map() is only available on platforms
that set HAS_IOPORT.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This patch resolves two sets of race conditions.

	Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> reported the
first, as follows:

The bond_close() calls cancel_delayed_work() to cancel delayed works.
It, however, cannot cancel works that were already queued in workqueue.
The bond_open() initializes work->data, and proccess_one_work() refers
get_work_cwq(work)->wq->flags. The get_work_cwq() returns NULL when
work->data has been initialized. Thus, a panic occurs.

	He included a patch that converted the cancel_delayed_work calls
in bond_close to flush_delayed_work_sync, which eliminated the above
problem.

	His patch is incorporated, at least in principle, into this
patch.  In this patch, we use cancel_delayed_work_sync in place of
flush_delayed_work_sync, and also convert bond_uninit in addition to
bond_close.

	This conversion to _sync, however, opens new races between
bond_close and three periodically executing workqueue functions:
bond_mii_monitor, bond_alb_monitor and bond_activebackup_arp_mon.

	The race occurs because bond_close and bond_uninit are always
called with RTNL held, and these workqueue functions may acquire RTNL to
perform failover-related activities.  If bond_close or bond_uninit is
waiting in cancel_delayed_work_sync, deadlock occurs.

	These deadlocks are resolved by having the workqueue functions
acquire RTNL conditionally.  If the rtnl_trylock() fails, the functions
reschedule and return immediately.  For the cases that are attempting to
perform link failover, a delay of 1 is used; for the other cases, the
normal interval is used (as those activities are not as time critical).

	Additionally, the bond_mii_monitor function now stores the delay
in a variable (mimicing the structure of activebackup_arp_mon).

	Lastly, all of the above renders the kill_timers sentinel moot,
and therefore it has been removed.
Tested-by: NMitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o Updated version number to 5.0.25

o Do not hold onto RESETTING_BIT for entire duration of LED/ beacon test.
  Instead, just checking for RESETTING_BIT not set before sending config_led
  command down to card.

o Take rtnl_lock instead of RESETTING_BIT for beacon test while sending
  config_led command down to make sure interface cannot be brought up/ down.

o Allocate and free resources if interface is down before
  sending the config_led command. This is to make sure config_led
  command sending doesn't fail.

o Clear QLCNIC_LED_ENABLE bit if beacon/ LED test fails to start.
Signed-off-by: NSucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: NAnirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSony Chacko <sony.chacko@qlogic.com>
Signed-off-by: NAnirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If promiscous mode setting fails, reset loopback mode setting in firmware.
Signed-off-by: NSucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: NAnirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In fw reset path, we should consider any change in device state as an
ack from the other driver. When that happens, we don't have to wait for
an explicit ack.
Signed-off-by: NSritej Velaga <sritej.velaga@qlogic.com>
Signed-off-by: NAnirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch updates the normal descriptor structure
to work fine on new GMAC Synopsys chips.

Normal descriptors were designed on the old MAC10/100
databook 1.91 where some bits were reserved: for example
the tx checksum insertion and rx checksum offload.

The patch maintains the back-compatibility with old
MAC devices (tested on STx7109 MAC10/100) and adds new
fields that actually new GMAC devices can use.

For example, STx7109 (MAC10/100) will pass from the platform
  tx_coe = 0, enh_desc = 0, has_gmac = 0.
A platform like Loongson1B (GMAC) will pass:
  tx_coe = 1, enh_desc = 0, has_gmac = 1.

Thanks to Kelvin, he enhanced the normal descriptors for
GMAC (on MIPS Loongson1B platform).
Signed-off-by: NKelvin Cheung <keguang.zhang@gmail.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAngus Clark <angus.clark@st.com>
Acked-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The patch fixes a bug while checking the HW cap reg
on old MAC10/100 where this feature is not available.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Allow for MAC Address change of VF(SR-IOV case) on the fly- First add and then
delete MAC Address to allow for 'out of pool' errors.
When MAC Addr configured from a VM, the MAC on the NIC will aleady have
the supplied MAC,so just copy the supplied MAC to the netdev structure
before returning success to the stack
Signed-off-by: NSomnath Kotur <somnath.kotur@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Moved the .sge. field's population inside be_cmd_hdr_prepare.
Populating wrb->tag0 and tag1 inside be_cmd_hdr_prepare
Signed-off-by: NSomnath Kotur <somnath.kotur@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The FW includes the following fixes:
  1. (iSCSI) Arrival of un-solicited ASYNC message causes
     firmware to abort the connection with RST.
  2. (FCoE) There is a probability that truncated FCoE packet on
     RX path won't get detected which might lead to FW assert.
  3. (iSCSI) Arrival of target-initiated NOP-IN during intense
     ISCSI traffic might lead to FW assert.
  4. (iSCSI) Chip hangs when in case of retransmission not aligned
     to 4-bytes from the beginning of iSCSI PDU.
  5. (FCoE) Arrival of packets beyond task IO size can lead to crash.
Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes a problem in which the host stops receiving data after
restarting the interface. This issue is caused by combination of incorrect
data path tap closure, along with missing MAC reset.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fix solves a problem of no link on 578xx-KR by retrying to link up to
four timer using the periodic function.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adjust blink rate on 578xx to fit its clock rate.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Clean-up MPS debug output to make it a single line and aligned, thus
making it more readable for a large number of buses and devices in a
single system.

Suggested by Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJon Mason <mason@myri.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

When configuring the PCIe settings for "performance", we allow parents
to have a larger Max Payload Size than children and rely on children
Max Read Request Size to not be larger than their own MPS to avoid
having the host bridge generate responses they can't cope with.

However, various drivers in Linux call pci_set_readrq() with arbitrary
values, assuming this to be a simple performance tweak. This breaks
under our "performance" configuration.

Fix that by making sure the value programmed by pcie_set_readrq() is
never larger than the configured MPS for that device.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJon Mason <mason@myri.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Rework the "performance" MPS option to configure the device MPS with the
smaller of the device MPSS or the bridge MPS (which is assumed to be
properly configured at this point to the largest allowable MPS based on
its parent bus).

Also, rework the MRRS setting to report an inability to set the MRRS to
a valid setting.
Signed-off-by: NJon Mason <mason@myri.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Intel 5000 and 5100 series memory controllers have a known issue if read
completion coalescing is enabled and the PCI-E Maximum Payload Size is
set to 256B.  To work around this issue, disable read completion
coalescing in the memory controller and root complexes.  Unfortunately,
it must always be disabled, even if no 256B MPS devices are present, due
to the possibility of one being hotplugged.

Links to erratas:
http://www.intel.com/content/dam/doc/specification-update/5000-chipset-memory-controller-hub-specification-update.pdf
http://www.intel.com/content/dam/doc/specification-update/5100-memory-controller-hub-chipset-specification-update.pdf

Thanks to Jesse Brandeburg and Ben Hutchings for providing insight into
the problem.
Tested-and-Reported-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NJon Mason <mason@myri.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This reverts commit dfadbbdb.

Further upstream discussion between Marek and Thomas decided this wasn't
fully baked and needed further work, so revert it before it hits mainline.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit d3ed7402.

Further upstream discussion between Thomas and Marek decided this needed
more work and driver specifics. So revert before it goes upstream.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Code cleanup, putting all eMMC 4.5 detection cases together.
This patch removes one if-statement and assembles all. And it also
removes variable initialization below else-statement -- all members
of card structure are already set to zero at card-init.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

When device data indicates that multiple block reads are not supported
on a given HSMMC controller instance, log a message to the console, and
pass the appropriate MMC capability flag to the MMC core.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Due to hardware bugs, some MMC host controllers don't support
multiple-block reads[1].  To resolve, add a new MMC capability flag,
MMC_CAP2_NO_MULTI_READ, which can be set by affected host controller
drivers.  When this capability is set, all reads will be issued one
sector at a time.

1. See for example Advisory 2.1.1.128 "MMC: Multiple Block Read
Operation Issue" in _OMAP3530/3525/3515/3503 Silicon Errata_
Revision F (October 2010) (SPRZ278F), available from
http://focus.ti.com/lit/er/sprz278f/sprz278f.pdfSigned-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

run_guest tries to freeze the current process after it has handled
pending interrupts and before it calls lguest_arch_run_guest.
This doesn't work nicely if the task has been killed while being frozen
and when we want to handle that signal as soon as possible.
Let's move try_to_freeze before we check for pending signal so that we
can get out of the loop as soon as possible.
Signed-off-by: NMichal Hocko <mhocko@suse.cz>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We actually can run under KVM, as it doesn't paravirtualize anything we
need to use; reduce the check to checking we are the normal ringlevel.
Reported-by: NStefanos Geraggelos <sgerag@cslab.ece.ntua.gr>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au># HG changeset patch

This adds devicetree binding support to the ARM pl061 driver removing the
platform_data dependency. When DT binding is used, the gpio numbering is
assigned dynamically. For now, interrupts are not supported with DT until
irqdomains learn dynamic irq assignment.

Rather than add another case of -1, updating the driver to use NO_IRQ.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

While trying to suspend the mmc host there could still be
ongoing requests that we need to wait for. At the same time
a device driver must respond to a suspend request rather quickly.

Instead of potentially wait "forever" by claiming the host we now
"try" to claim the host instead. If it fails, -EBUSY is returned.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Table 6-2: CCCR bit Definitions, address 00h.  Part E1 SDIO Simplified
Specification Version 3.00, Feb. 25, 2011.

This patch has been tested with Marvell WLAN device SD8797.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Here is Essential conditions to indicate Version 3.00 Card
(SD_SPEC=2 and SD_SPEC3=1) :
(1) The card shall support CMD6
(2) The card shall support CMD8
(3) The card shall support CMD42
(4) User area capacity shall be up to 2GB (SDSC) or 32GB (SDHC)
    User area capacity shall be more than or equal to 32GB and
    up to 2TB (SDXC)
(5) Speed Class shall be supported (SDHC or SDXC)

So even if SD card doesn't support any of the newly defined
UHS-I bus speed mode, it can advertise itself as SD3.0 cards
as long as it supports all the essential conditions of
SD3.0 cards. Given this, these type of cards should atleast
run in High Speed mode @50MHZ if it supports HS.

But current initialization sequence for SD3.0 cards is
such that these non-UHS-I SD3.0 cards runs in Default
Speed mode @25MHz.

This patch makes sure that these non-UHS-I SD3.0 cards run
in High Speed Mode @50MHz.

Tested this patch with SanDisk Extreme SDHC 8GB Class 10 card.
Reported-by: N"Hiremath, Vaibhav" <hvaibhav@ti.com>
Signed-off-by: NSubhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>