user/sven/linux.git/drivers, branch v3.9.7

tg3: Wait for boot code to finish after power on

2013-06-20T19:01:38Z

commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream. Some systems that don't need wake-on-lan may choose to power down the chip on system standby. Upon resume, the power on causes the boot code to startup and initialize the hardware. On one new platform, this is causing the device to go into a bad state due to a race between the driver and boot code, once every several hundred resumes. The same race exists on open since we come up from a power on. This patch adds a wait for boot code signature at the beginning of tg3_init_hw() which is common to both cases. If there has not been a power-off or the boot code has already completed, the signature will be present and poll_fw() returns immediately. Also return immediately if the device does not have firmware. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

USB: spcp8x5: fix device initialisation at open

2013-06-20T19:01:38Z

commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0 upstream. Do not use uninitialised termios data to determine when to configure the device at open. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

USB: f81232: fix device initialisation at open

2013-06-20T19:01:38Z

commit 21886725d58e92188159731c7c1aac803dd6b9dc upstream. Do not use uninitialised termios data to determine when to configure the device at open. This also prevents stack data from leaking to userspace. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

USB: pl2303: fix device initialisation at open

2013-06-20T19:01:38Z

commit 2d8f4447b58bba5f8cb895c07690434c02307eaf upstream. Do not use uninitialised termios data to determine when to configure the device at open. This also prevents stack data from leaking to userspace in the OOM error path. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

usb: chipidea: fix id change handling

2013-06-20T19:01:38Z

commit 0c3f3dc68bb6e6950e8cd7851e7778c550e8dfb4 upstream. Re-enable chipidea irq even if there's no role changing to do. This is a problem since b183c19f ("USB: chipidea: re-order irq handling to avoid unhandled irqs"); when it manifests, chipidea irq gets disabled for good. Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman

drm/nv50/kms: use dac loadval from vbios, where it's available

2013-06-20T19:01:31Z

commit d40ee48acde16894fb3b241d7e896d5fa84e0f10 upstream. Regression from merging the old nv50/nvd9 code together, and may be needed to fully fix fdo#64904. The value is ignored completely by the hardware starting from nva3. Reported-by: Emil Velikov Signed-off-by: Ben Skeggs

drm/nv50/disp: force dac power state during load detect

2013-06-20T19:01:31Z

commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 upstream. fdo#64904 Reported-by: Gerhard Bräunlich Signed-off-by: Ben Skeggs

md/raid1,raid10: use freeze_array in place of raise_barrier in various places.

2013-06-20T19:01:30Z

commit e2d59925221cd562e07fee38ec8839f7209ae603 upstream. Various places in raid1 and raid10 are calling raise_barrier when they really should call freeze_array. The former is only intended to be called from "make_request". The later has extra checks for 'nr_queued' and makes a call to flush_pending_writes(), so it is safe to call it from within the management thread. Using raise_barrier will sometimes deadlock. Using freeze_array should not. As 'freeze_array' currently expects one request to be pending (in handle_read_error - the only previous caller), we need to pass it the number of pending requests (extra) to ignore. The deadlock was made particularly noticeable by commits 050b66152f87c7 (raid10) and 6b740b8d79252f13 (raid1) which appeared in 3.4, so the fix is appropriate for any -stable kernel since then. This patch probably won't apply directly to some early kernels and will need to be applied by hand. Reported-by: Alexander Lyakas Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid1,5,10: Disable WRITE SAME until a recovery strategy is in place

2013-06-20T19:01:30Z

commit 5026d7a9b2f3eb1f9bda66c18ac6bc3036ec9020 upstream. There are cases where the kernel will believe that the WRITE SAME command is supported by a block device which does not, in fact, support WRITE SAME. This currently happens for SATA drivers behind a SAS controller, but there are probably a hundred other ways that can happen, including drive firmware bugs. After receiving an error for WRITE SAME the block layer will retry the request as a plain write of zeroes, but mdraid will consider the failure as fatal and consider the drive failed. This has the effect that all the mirrors containing a specific set of data are each offlined in very rapid succession resulting in data loss. However, just bouncing the request back up to the block layer isn't ideal either, because the whole initial request-retry sequence should be inside the write bitmap fence, which probably means that md needs to do its own conversion of WRITE SAME to write zero. Until the failure scenario has been sorted out, disable WRITE SAME for raid1, raid5, and raid10. [neilb: added raid5] This patch is appropriate for any -stable since 3.7 when write_same support was added. Signed-off-by: H. Peter Anvin Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.

2013-06-20T19:01:30Z

commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream. Without that fix, the following scenario could happen: - RAID1 with drives A and B; drive B was freshly-added and is rebuilding - Drive A fails - WRITE request arrives to the array. It is failed by drive A, so r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B succeeds in writing it, so the same r1_bio is marked as R1BIO_Uptodate. - r1_bio arrives to handle_write_finished, badblocks are disabled, md_error()->error() does nothing because we don't fail the last drive of raid1 - raid_end_bio_io() calls call_bio_endio() - As a result, in call_bio_endio(): if (!test_bit(R1BIO_Uptodate, &r1_bio->state)) clear_bit(BIO_UPTODATE, &bio->bi_flags); this code doesn't clear the BIO_UPTODATE flag, and the whole master WRITE succeeds, back to the upper layer. So we returned success to the upper layer, even though we had written the data onto the rebuilding drive only. But when we want to read the data back, we would not read from the rebuilding drive, so this data is lost. [neilb - applied identical change to raid10 as well] This bug can result in lost data, so it is suitable for any -stable kernel. Signed-off-by: Alex Lyakas Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman