aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAge
* SCSI: Retry commands with UNIT_ATTENTION sense codes to fix ext3/ext4 I/O errorJames Bottomley2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | commit 77a4229719e511a0d38d9c355317ae1469adeb54 upstream. There's nastyness in the way we currently handle barriers (and discards): They're effectively filesystem commands, but they get processed as BLOCK_PC commands. Unfortunately BLOCK_PC commands are taken by SCSI to be SG_IO commands and the issuer expects to see and handle any returned errors, however trivial. This leads to a huge problem, because the block layer doesn't expect this to happen and any trivially retryable error on a barrier causes an immediate I/O error to the filesystem. The only real way to hack around this is to take the usual class of offending errors (unit attentions) and make them all retryable in the case of a REQ_HARDBARRIER. A correct fix would involve a rework of the entire block and SCSI submit system, and so is out of scope for a quick fix. Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Enable retries for SYNCRONIZE_CACHE commands to fix I/O errorHannes Reinecke2010-05-12
| | | | | | | | | | | | | | | commit c213e1407be6b04b144794399a91472e0ef92aec upstream. Some arrays are giving I/O errors with ext3 filesystems when SYNCHRONIZE_CACHE gets a UNIT_ATTENTION. What is happening is that these commands have no retries, so the UNIT_ATTENTION causes the barrier to fail. We should be enable retries here to clear any transient error and allow the barrier to succeed. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* scsi_debug: virtual_gb ignores sector_sizeDouglas Gilbert2010-05-12
| | | | | | | | | | | | | commit 5447ed6c968e7270b656afa273c2b79d15d82edd upstream. In the scsi_debug driver, the virtual_gb option ignores the sector_size, implicitly assuming that is 512 bytes. So if 'virtual_gb=1 sector_size=4096' the result is an 8 GB (virtual) disk. Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* SCSI: libiscsi: regression: fix header digest errorsMike Christie2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | commit 96b1f96dcab87756c0a1e7ba76bc5dc2add82b88 upstream. This fixes a regression introduced with this commit: commit d3305f3407fa3e9452079ec6cc8379067456e4aa Author: Mike Christie <michaelc@cs.wisc.edu> Date: Thu Aug 20 15:10:58 2009 -0500 [SCSI] libiscsi: don't increment cmdsn if cmd is not sent in 2.6.32. When I moved the hdr->cmdsn after init_task, I added a bug when header digests are used. The problem is that the LLD may calculate the header digest in init_task, so if we then set the cmdsn after the init_task call we change what the digest will be calculated by the target. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* SCSI: fix locking around blk_abort_request()Tejun Heo2010-05-12
| | | | | | | | | | | | | | | commit 70b25f890ce9f0520c64075ce9225a5b020a513e upstream. blk_abort_request() expects queue lock to be held by the caller. Grab it before calling the function. Lack of this synchronization led to infinite loop on corrupt q->timeout_list. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cpuidle: Fix incorrect optimizationArjan van de Ven2010-05-12
| | | | | | | | | | | | | | | | | | | | | | commit 1c6fe0364fa7bf28248488753ee0afb6b759cd04 upstream. commit 672917dcc78 ("cpuidle: menu governor: reduce latency on exit") added an optimization, where the analysis on the past idle period moved from the end of idle, to the beginning of the new idle. Unfortunately, this optimization had a bug where it zeroed one key variable for new use, that is needed for the analysis. The fix is simple, zero the variable after doing the work from the previous idle. During the audit of the code that found this issue, another issue was also found; the ->measured_us data structure member is never set, a local variable is always used instead. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Corrado Zoccolo <czoccolo@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ACPI: sleep: init_set_sci_en_on_resume for Dell Studio 155xKamal Mostafa2010-05-12
| | | | | | | | | | | | | | | commit ea5bc73f4f56449b2d450068d492bcd17a675d7a upstream. Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume' list to fix hang on resume. BugLink: http://bugs.launchpad.net/bugs/553498 Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* power_meter: acpi_device_class "power_meter_resource" too longDan Carpenter2010-05-12
| | | | | | | | | | | | | | | | | commit 18262714ca0fb65c290b8ea1807b2b02bb52d0e3 upstream. acpi_device_class can only be 19 characters and a NULL terminator. The current code has a buffer overflow in acpi_power_meter_add(): strcpy(acpi_device_class(device), ACPI_POWER_METER_CLASS); Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: Len Brown <lenb@kernel.org> Cc: "Darrick J. Wong" <djwong@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPadsAlex Chiang2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 07bedca29b0973f36a6b6db36936deed367164ed upstream. Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can successfully suspend/resume once, and then hang on the second s/r cycle. We got confirmation that this was due to a BIOS defect. The BIOS did not properly set SCI_EN coming out of S3. The BIOS guys hinted that The Other Leading OS ignores the fact that hardware owns the bit and sets it manually. In any case, an existing DMI table exists for machines where this defect is a known problem. Lenovo promise to fix their BIOS, but for folks who either won't or can't upgrade their BIOS, allow Linux to workaround the issue. https://bugzilla.kernel.org/show_bug.cgi?id=15407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374 Confirmed by numerous testers in the launchpad bug that using acpi_sleep=sci_force_enable fixes the issue. We add the machines to acpisleep_dmi_table[] to automatically enable this workaround. Cc: Colin King <colin.king@canonical.com> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"Bjørn Mork2010-05-12
| | | | | | | | | | | | | | | | | | | | | | commit 6f550dc08369ee0bc6402963c377e65f0f2e3b71 upstream. Never call dvb_frontend_detach if we failed to attach a frontend. This fixes the following oops, which will be triggered by a missing stv090x module: [ 8.172997] DVB: registering new adapter (TT-Budget S2-1600 PCI) [ 8.209018] adapter has MAC addr = 00:d0:5c:cc:a7:29 [ 8.328665] Intel ICH 0000:00:1f.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 8.328753] Intel ICH 0000:00:1f.5: setting latency timer to 64 [ 8.562047] DVB: Unable to find symbol stv090x_attach() [ 8.562117] BUG: unable to handle kernel NULL pointer dereference at 000000ac [ 8.562239] IP: [<e08b04a3>] dvb_frontend_detach+0x4/0x67 [dvb_core] Ref http://bugs.debian.org/575207 Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* md/raid6: Fix raid-6 read-error correction in degraded stateGabriele A. Trombetti2010-05-12
| | | | | | | | | | | | | | | commit 87aa63000c484bfb9909989316f615240dfee018 upstream. Fix: Raid-6 was not trying to correct a read-error when in singly-degraded state and was instead dropping one more device, going to doubly-degraded state. This patch fixes this behaviour. Tested-by: Janos Haar <janos.haar@netcenter.hu> Signed-off-by: Gabriele A. Trombetti <g.trombetti.lkrnl1213@logicschema.com> Reported-by: Janos Haar <janos.haar@netcenter.hu> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* virtio: initialize earlierStijn Tintel2010-05-12
| | | | | | | | | | | | | | | commit e2dbe06c271f3bb2a495627980aad3d1d8ccef2a upstream. Move initialization of the virtio framework before the initialization of mtd, so that block2mtd can be used on virtio-based block devices. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15644 Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* md: restore ability of spare drives to spin down.NeilBrown2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1176568de7e066c0be9e46c37503b9fd4730edcf upstream. Some time ago we stopped the clean/active metadata updates from being written to a 'spare' device in most cases so that it could spin down and say spun down. Device failure/removal etc are still recorded on spares. However commit 51d5668cb2e3fd1827a55 broke this 50% of the time, depending on whether the event count is even or odd. The change log entry said: This means that the alignment between 'odd/even' and 'clean/dirty' might take a little longer to attain, how ever the code makes no attempt to create that alignment, so it could take arbitrarily long. So when we find that clean/dirty is not aligned with odd/even, force a second metadata-update immediately. There are already cases where a second metadata-update is needed immediately (e.g. when a device fails during the metadata update). We just piggy-back on that. Reported-by: Joe Bryant <tenminjoe@yahoo.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* WAN: flush tx_queue in hdlc_ppp to prevent panic on rmmod hw_driver.Krzysztof Halasa2010-05-12
| | | | | | | | | | | | | | | [ Upstream commit 31f634a63de7068c6a5dcb0d7b09b24b61a5cf88 ] tx_queue is used as a temporary queue when not allowed to queue skb directly to the hw device driver (which may sleep). Most paths flush it before returning, but ppp_start() currently cannot. Make sure we don't leave skbs pointing to a non-existent device. Thanks to Michael Barkowski for reporting this problem. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tun: orphan an skb on txMichael S. Tsirkin2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0110d6f22f392f976e84ab49da1b42f85b64a3c5 ] The following situation was observed in the field: tap1 sends packets, tap2 does not consume them, as a result tap1 can not be closed. This happens because tun/tap devices can hang on to skbs undefinitely. As noted by Herbert, possible solutions include a timeout followed by a copy/change of ownership of the skb, or always copying/changing ownership if we're going into a hostile device. This patch implements the second approach. Note: one issue still remaining is that since skbs keep reference to tun socket and tun socket has a reference to tun device, we won't flush backlog, instead simply waiting for all skbs to get transmitted. At least this is not user-triggerable, and this was not reported in practice, my assumption is other devices besides tap complete an skb within finite time after it has been queued. A possible solution for the second issue would not to have socket reference the device, instead, implement dev->destructor for tun, and wait for all skbs to complete there, but this needs some thought, probably too risky for 2.6.34. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Yan Vugenfirer <yvugenfi@redhat.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cdc_ether: fix autosuspend for mbm devicesTorgny Johansson2010-05-12
| | | | | | | | | | | | | | | [ Upstream commit 55964d72d63b15df49a5df11ef91dc8601270815 ] Autosuspend works until you bring the wwan interface up, then the device does not enter autosuspend anymore. The following patch fixes the problem by setting the .manage_power field in the mbm_info struct to the same as in the cdc_info struct (cdc_manager_power). Signed-off-by: Torgny Johansson <torgny.johansson@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* bnx2: Fix lost MSI-X problem on 5709 NICs.Michael Chan2010-05-12
| | | | | | | | | | | | | | | | | | | | commit c441b8d2cb2194b05550a558d6d95d8944e56a84 upstream. It has been reported that under certain heavy traffic conditions in MSI-X mode, the driver can lose an MSI-X vector causing all packets in the associated rx/tx ring pair to be dropped. The problem is caused by the chip dropping the write to unmask the MSI-X vector by the kernel (when migrating the IRQ for example). This can be prevented by increasing the GRC timeout value for these register read and write operations. Thanks to Dell for helping us debug this problem. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tg3: Fix INTx fallback when MSI failsAndre Detsch2010-05-12
| | | | | | | | | | | | | | | | | | | | | commit dc8bf1b1a6edfc92465526de19772061302f0929 upstream. tg3: Fix INTx fallback when MSI fails MSI setup changes the value of irq_vec in struct tg3 *tp. This attribute must be taken into account and restored before we try to do a new request_irq for INTx fallback. In powerpc, the original code was leading to an EINVAL return within request_irq, because the driver was trying to use the disabled MSI virtual irq number instead of tp->pdev->irq. Signed-off-by: Andre Detsch <adetsch@br.ibm.com> Acked-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Brandon Philips <bphilips@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* skip sense logging for some ATA PASS-THROUGH cdbsDouglas Gilbert2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e7efe5932b1d3916c79326a4221693ea90a900e2 upstream. Further to the lsml thread titled: "does scsi_io_completion need to dump sense data for ata pass through (ck_cond = 1) ?" This is a patch to skip logging when the sense data is associated with a SENSE_KEY of "RECOVERED_ERROR" and the additional sense code is "ATA PASS-THROUGH INFORMATION AVAILABLE". This only occurs with the SAT ATA PASS-THROUGH commands when CK_COND=1 (in the cdb). It indicates that the sense data contains ATA registers. Smartmontools uses such commands on ATA disks connected via SAT. Periodic checks such as those done by smartd cause nuisance entries into logs that are: - neither errors nor warnings - pointless unless the cdb that caused them are also logged Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ath9k: reorder ieee80211_free_hw behind ath9k_uninit_hw to avoid oopsJohn W. Linville2010-05-12
| | | | | | | This code only exists in 2.6.33 -- 2.6.32 and 2.6.34 are not affected. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* r8169: more broken register writes workaroundfrançois romieu2010-05-12
| | | | | | | | | | | | commit 908ba2bfd22253f26fa910cd855e4ccffb1467d0 upstream. 78f1cd02457252e1ffbc6caa44a17424a45286b8 ("fix broken register writes") does not work for Al Viro's r8169 (XID 18000000). Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* r8169: fix broken register writesFrancois Romieu2010-05-12
| | | | | | | | | | | | | | | | | | | commit 78f1cd02457252e1ffbc6caa44a17424a45286b8 upstream. This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7 though said registers are not even documented as 64-bit registers - as opposed to the initial TxDescStartAddress ones - but as single bytes which must be combined into 32 bits at the MMIO read/write level before being merged into a 64 bit logical entity. Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR registers (aka "multicast is broken for ages on ARM) and to Timo Teräs <timo.teras@iki.fi> for the MAC registers. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* r8169: use correct barrier between cacheable and non-cacheable memoryDavid Dillow2010-05-12
| | | | | | | | | | | | | | | | commit 4c020a961a812ffae9846b917304cea504c3a733 upstream. r8169 needs certain writes to be visible to other CPUs or the NIC before touching the hardware, but was using smp_wmb() which is only required to order cacheable memory access. Switch to wmb() which is required to order both cacheable and non-cacheable memory. Noticed by Catalin Marinas and Paul Mackerras. Signed-off-by: David Dillow <dave@thedillows.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* drivers/net/wireless/p54/txrx.c Fix off by one errorDarren Jenkins2010-05-12
| | | | | | | | | | | | | commit 088ea189c4c75cdf211146faa4b341a0f7476be6 upstream. fix off by one error in the queue size check of p54_tx_qos_accounting_alloc() Coverity CID: 13314 Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Ensure we re-enable devices on resumeMatthew Garrett2010-05-12
| | | | | | | | | | | | | | | | | | | commit cc2893b6af5265baa1d68b17b136cffca9e40cfa upstream. If the firmware puts a device back into D0 state at resume time, we'll update its state in resume_noirq and thus skip the platform resume code. Calling that code twice should be safe and we ought to avoid getting to that point anyway, so remove the check and also allow the platform pci code to be called for D0. Fixes USB not being powered after resume on recent Lenovo machines. Acked-by: Alex Chiang <achiang@canonical.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86, k8 nb: Fix boot crash: enable k8_northbridges unconditionally on AMD ↵Borislav Petkov2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | systems commit 0e152cd7c16832bd5cadee0c2e41d9959bc9b6f9 upstream. de957628ce7c84764ff41331111036b3ae5bad0f changed setting of the x86_init.iommu.iommu_init function ptr only when GART IOMMU is found. One side effect of it is that num_k8_northbridges is not initialized anymore if not explicitly called. This resulted in uninitialized pointers in <arch/x86/kernel/cpu/intel_cacheinfo.c:amd_calc_l3_indices()>, for example, which uses the num_k8_northbridges thing through node_to_k8_nb_misc(). Fix that through an initcall that runs right after the PCI subsystem and does all the scanning. Then, remove initialization in gart_iommu_init() which is a rootfs_initcall and we're running before that. What is more, since num_k8_northbridges is being used in other places beside GART IOMMU, include it whenever we add AMD CPU support. The previous dependency chain in kconfig contained K8_NB depends on AGP_AMD64|GART_IOMMU which was clearly incorrect. The more natural way in terms of hardware dependency should be AGP_AMD64|GART_IOMMU depends on K8_NB depends on CPU_SUP_AMD && PCI. Make it so Number One! Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Joerg Roedel <joerg.roedel@amd.com> LKML-Reference: <20100312144303.GA29262@aftab> Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* edac, mce: Fix wrong mask and macro usageBorislav Petkov2010-05-12
| | | | | | | | | | | | commit 35d824b28fc5544d1eb7c1e3db15a1740df8ec4b upstream. Correct two mishaps which prevented reporting error type (CECC vs UECC) and extended error description. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* p54pci: fix bugs in p54p_check_tx_ringHans de Goede2010-05-12
| | | | | | | | | | | | | | | | | commit 0250ececdf6813457c98719e2d33b3684881fde0 upstream. Hans de Goede identified a bug in p54p_check_tx_ring: there are two ring indices. 1 => tx data and 3 => tx management. But the old code had a constant "1" and this resulted in spurious dma unmapping failures. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623 Bug-Identified-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* dm9601: fix phy/eeprom write routinePeter Korsgaard2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | commit e9162ab1610531d6ea6c1833daeb2613e44275e8 upstream. Use correct bit positions in DM_SHARED_CTRL register for writes. Michael Planes recently encountered a 'KY-RS9600 USB-LAN converter', which came with a driver CD containing a Linux driver. This driver turns out to be a copy of dm9601.c with symbols renamed and my copyright stripped. That aside, it did contain 1 functional change in dm_write_shared_word(), and after checking the datasheet the original value was indeed wrong (read versus write bits). On Michaels HW, this change bumps receive speed from ~30KB/s to ~900KB/s. On other devices the difference is less spectacular, but still significant (~30%). Reported-by: Michael Planes <michael.planes@free.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Revert "memory-hotplug: add 0x prefix to HEX block_size_bytes"Linus Torvalds2010-05-12
| | | | | | | | | | | | | | | | | commit 4dc86ae1f925b2121d4e75058675895f83e54c71 upstream. This reverts commit ba168fc37dea145deeb8fa9e7e71c748d2e00d74. It changes user-visible sysfs interfaces, and breaks some existing user space applications which apparently rely on the fact that the output does not contain the "0x" prefix. Requested-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: 8250_pnp - add Fujitsu Wacom devicePing Cheng2010-05-12
| | | | | | | | | | | commit d9901660b53b92f0f3551c06588b8be38224b245 upstream. Add Fujitsu Wacom 1FGT Tablet PC device Signed-off-by: Ping Cheng <pingc@wacom.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* i2c: Fix probing of FSC hardware monitoring chipsJean Delvare2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | commit b1d4b390ea4bb480e65974ce522a04022608a8df upstream. Some FSC hardware monitoring chips (Syleus at least) doesn't like quick writes we typically use to probe for I2C chips. Use a regular byte read instead for the address they live at (0x73). These are the only known chips living at this address on PC systems. For clarity, this fix should not be needed for kernels 2.6.30 and later, as we started instantiating the hwmon devices explicitly based on DMI data. Still, this fix is valuable in the following two cases: * Support for recent FSC chips on older kernels. The DMI-based device instantiation is more difficult to backport than the device support itself. * Case where the DMI-based device instantiation fails, whatever the reason. We fall back to probing in that case, so it should work. This fixes kernel bug #15634: https://bugzilla.kernel.org/show_bug.cgi?id=15634 Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Staging: hv: name network device ethX rather than sethXStephen Hemminger2010-05-12
| | | | | | | | | | | | | | | commit 546d9e101e7a71e6202f47a13ddcd9b8fb05a52e upstream. This patch makes the HyperV network device use the same naming scheme as other virtual drivers (Xen, KVM). In an ideal world, userspace tools would not care what the name is, but some users and applications do care. Vyatta CLI is one of the tools that does depend on what the name is. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Cc: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Staging: hv: Fix up memory leak on HvCleanupCyrill Gorcunov2010-05-12
| | | | | | | | | | | | commit fa8ad0257ea256381126ecf447694622216c600f upstream. Don't assign NULL too early Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Hank Janssen <hjanssen@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Staging: hv: Fix a bug affecting IPv6Haiyang Zhang2010-05-12
| | | | | | | | | | | | | commit 95beae90aa4afce57fb28e6f8238b78217bd7c98 upstream. Fix a bug affecting IPv6 Added the multicast flag for proper IPv6 function. Reported-by: Toshikazu Sakai <toshikas@microsoft.com> Signed-off-by: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: properly set endpoint context fields for periodic eps.Sarah Sharp2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9238f25d5d32a435277eb234ec82bacdd5daed41 upstream. For periodic endpoints, we must let the xHCI hardware know the maximum payload an endpoint can transfer in one service interval. The xHCI specification refers to this as the Maximum Endpoint Service Interval Time Payload (Max ESIT Payload). This is used by the hardware for bandwidth management and scheduling of packets. For SuperSpeed endpoints, the maximum is calculated by multiplying the max packet size by the number of bursts and the number of opportunities to transfer within a service interval (the Mult field of the SuperSpeed Endpoint companion descriptor). Devices advertise this in the wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor. For high speed devices, this is taken by multiplying the max packet size by the "number of additional transaction opportunities per microframe" (the high bits of the wMaxPacketSize field in the endpoint descriptor). For FS/LS devices, this is just the max packet size. The other thing we must set in the endpoint context is the Average TRB Length. This is supposed to be the average of the total bytes in the transfer descriptor (TD), divided by the number of transfer request blocks (TRBs) it takes to describe the TD. This gives the host controller an indication of whether the driver will be enqueuing a scatter gather list with many entries comprised of small buffers, or one contiguous buffer. It also takes into account the number of extra TRBs you need for every TD. This includes No-op TRBs and Link TRBs used to link ring segments together. Some drivers may choose to chain an Event Data TRB on the end of every TD, thus increasing the average number of TRBs per TD. The Linux xHCI driver does not use Event Data TRBs. In theory, if there was an API to allow drivers to state what their bandwidth requirements are, we could set this field accurately. For now, we set it to the same number as the Max ESIT payload. The Average TRB Length should also be set for bulk and control endpoints, but I have no idea how to guess what it should be. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: properly set the "Mult" field of the endpoint context.Sarah Sharp2010-05-12
| | | | | | | | | | | | | | | | | | | | | commit 1cf62246c0e394021e494e0a8f1013e80db1a1a9 upstream. A SuperSpeed interrupt or isochronous endpoint can define the number of "burst transactions" it can handle in a service interval. This is indicated by the "Mult" bits in the bmAttributes of the SuperSpeed Endpoint Companion Descriptor. For example, if it has a max packet size of 1024, a max burst of 11, and a mult of 3, the host may send 33 1024-byte packets in one service interval. We must tell the xHCI host controller the number of multiple service opportunities (mults) the device can handle when the endpoint is installed. We do that by setting the Mult field of the Endpoint Context before a configure endpoint command is sent down. The Mult field is invalid for control or bulk SuperSpeed endpoints. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: OHCI: don't look at the root hub to get the number of portsAlan Stern2010-05-12
| | | | | | | | | | | | | | commit fcf7d2141f4a363a4a8454c4a0f26bb69e766c5f upstream. This patch (as1371) fixes a small bug in ohci-hcd. The HCD already knows how many ports the controller has; there's no need to go looking at the root hub's usb_device structure to find out. Especially since the root hub's maxchild value is set correctly only while the root hub is bound to the hub driver. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: don't choose configs with no interfacesAlan Stern2010-05-12
| | | | | | | | | | | | | | | | commit 62f9cfa3ece58268b3e92ca59c23b175f86205aa upstream. This patch (as1372) fixes a bug in the routine that chooses the default configuration to install when a new USB device is detected. The algorithm is supposed to look for a config whose first interface is for a non-vendor-specific class. But the way it's currently written, it will also accept a config with no interfaces at all, which is not very useful. (Believe it or not, such things do exist.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Andrew Victor <avictor.za@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: fix testing the wrong variable in fs_create_by_name()Dan Carpenter2010-05-12
| | | | | | | | | | | | commit fa7fe7af146a7b613e36a311eefbbfb5555325d1 upstream. There is a typo here. We should be testing "*dentry" which was just assigned instead of "dentry". This could result in dereferencing an ERR_PTR inside either usbfs_mkdir() or usbfs_create(). Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: don't read past config->interface[] if usb_control_msg() fails in ↵Roel Kluin2010-05-12
| | | | | | | | | | | | | | | | | | | | | | usb_reset_configuration() commit e4a3d94658b5760fc947d7f7185c57db47ca362a upstream. While looping over the interfaces, if usb_hcd_alloc_bandwidth() fails it calls hcd->driver->reset_bandwidth(), so there was no need to reinstate the interface again. If no break occurred, the index equals config->desc.bNumInterfaces. A subsequent usb_control_msg() failure resulted in a read from config->interface[config->desc.bNumInterfaces] at label reset_old_alts. In either case the last interface should be skipped. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: Add id for HP ev2210 a.k.a Sierra MC5725 miniPCI-e Cell Modem.William Lightning2010-05-12
| | | | | | | | commit cfbaa39347b34837f26e01fe8f4f8dbbae60b520 upstream. Signed-off-by: William Lightning <kassah@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: fix remote wakeup settings during system sleepAlan Stern2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | This is a backport of commit 5f677f1d45b2bf08085bbba7394392dfa586fa8e. Some of the functionality had to be removed, but it should still fix the webcam problem. This patch (as1363b) changes the way USB remote wakeup is handled during system sleeps. It won't be enabled unless an interface driver specifically needs it. Also, it won't be enabled during the FREEZE or QUIESCE phases of hibernation, when the system doesn't respond to wakeup events anyway. This will fix problems people have reported with certain USB webcams that generate wakeup requests when they shouldn't, and as a result cause system suspends to fail. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515109 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* staging: usbip: Fix deadlockEric Lescouet2010-05-12
| | | | | | | | | | | | | | | | | commit d01f42a22ef381ba973958e977209ac9a8667d57 upstream. When detaching a port from the client side (usbip --detach 0), the event thread, on the server side, is going to deadlock. The "eh" server thread is getting USBIP_EH_RESET event and calls: -> stub_device_reset() -> usb_reset_device() the USB framework is then calling back _in the same "eh" thread_ : -> stub_disconnect() -> usbip_stop_eh() -> wait_for_completion() the "eh" thread is being asleep forever, waiting for its own completion. This patch checks if "eh" is the current thread, in usbip_stop_eh(). Signed-off-by: Eric Lescouet <eric@lescouet.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sfc: Change falcon_probe_board() to fail for unsupported boardsBen Hutchings2010-05-12
| | | | | | | | | | | | | commit e41c11ee0cc602bcde68916be85fb97d1a484324 upstream. The driver needs specific PHY and board support code for each SFC4000 board; there is no point trying to continue if it is missing. Currently unsupported boards can trigger an 'oops'. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sfc: Always close net device at the end of a disabling resetBen Hutchings2010-05-12
| | | | | | | | | | | | | commit f49a4589e9e25ef525da449b1ce5597cb659bbb5 upstream. This fixes a regression introduced by commit eb9f6744cbfa97674c13263802259b5aa0034594 "sfc: Implement ethtool reset operation". Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* sfc: Wait at most 10ms for the MC to finish reading out MAC statisticsBen Hutchings2010-05-12
| | | | | | | | | | | commit aabc5649078310094cbffb430fcbf9c25b6268f9 upstream. The original code would wait indefinitely if MAC stats DMA failed. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* w1: w1 temp: fix negative termperature calculationIan Dall2010-05-12
| | | | | | | | | | | | | | | | | | | | | | commit 9a6a1ecd9e9b5d046a236da2f7eb6b6812f04229 upstream. Fix regression caused by commit 507e2fbaaacb6f164b4125b87c5002f95143174b ("w1: w1 temp calculation overflow fix") whereby negative temperatures for the DS18B20 are not converted properly. When the temperature exceeds 32767 milli-degrees the temperature overflows to -32768 millidegrees. These are both well within the -55 - +125 degree range for the sensor. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=12646 Signed-of-by: Ian Dall <ian@beware.dropbear.id.au> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Tested-by: Karsten Elfenbein <kelfe@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* libata: ensure NCQ error result taskfile is fully initialized before ↵Jeff Garzik2010-05-12
| | | | | | | | | | returning it via qc->result_tf. commit a09bf4cd53b8ab000197ef81f15d50f29ecf973c upstream. Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* libata: fix locking around blk_abort_request()Tejun Heo2010-05-12
| | | | | | | | | | | | | | | | commit fa41efdae7de61191a7bda3a00e88ef69afb5bb9 upstream. blk_abort_request() expectes queue lock to be held by the caller. Grab it before calling the function. Lack of this synchronization led to infinite loop on corrupt q->timeout_list. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-03 18:22:25 -0500