- 18 3月, 2014 5 次提交
-
-
由 Sebastian Reichel 提交于
This is a driver for an A/D converter, which belongs into drivers/iio/adc. Signed-off-by: NSebastian Reichel <sre@debian.org> Acked-by: NJonathan Cameron <jic23@kernel.org> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Sebastian Reichel 提交于
Simplify reading and writing of 16 bit TWL registers in the driver by using twl_i2c_read_u16 and twl_i2c_write_u16. Signed-off-by: NSebastian Reichel <sre@debian.org> Acked-by: NJonathan Cameron <jic23@kernel.org> Tested-by: NMarek Belisko <marek@goldelico.com> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Sebastian Reichel 提交于
Some style fixes in twl4030-madc driver. Reported-by: NJonathan Cameron <jic23@kernel.org> Reported-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NSebastian Reichel <sre@debian.org> Acked-by: NJonathan Cameron <jic23@kernel.org> Tested-by: NMarek Belisko <marek@goldelico.com> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Sebastian Reichel 提交于
This converts twl4030-madc module to use the Industrial IO ADC framework and adds device tree support. Signed-off-by: NSebastian Reichel <sre@debian.org> Tested-by: NMarek Belisko <marek@goldelico.com> Acked-by: NJonathan Cameron <jic23@kernel.org> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Sebastian Reichel 提交于
Update twl4030-madc driver to use managed resources. Signed-off-by: NSebastian Reichel <sre@debian.org> Acked-by: NJonathan Cameron <jic23@kernel.org> Tested-by: NMarek Belisko <marek@goldelico.com> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
- 02 3月, 2014 3 次提交
-
-
由 Alexey Khoroshilov 提交于
vmw_takedown_otable_base() and vmw_mob_unbind() check for potential vmw_fifo_reserve() failure and print error message, but then immediately dereference NULL pointer. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Thomas Hellstrom 提交于
Backing mob contents is propagated to user-space, so make sure backing mobs are cleared when allocated. This also accidently fix rendering errors with celestia when emulating legacy mode. Also update driver date. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
由 Thomas Hellstrom 提交于
These formats are deprecated. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
- 28 2月, 2014 9 次提交
-
-
由 Heinz Mauelshagen 提交于
When remapping a block to the cache's fast device that is larger than 2TB we must not truncate the destination sector to 32bits. The 32bit temporary result of from_cblock() was being overflowed in remap_to_cache() due to the logical left shift. Use an intermediate 64bit type to store the 32bit from_cblock() result to fix the overflow. Signed-off-by: NHeinz Mauelshagen <heinzm@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Now that we disable audio while setting up the audio hw, we should be able to set this up without hangs. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Disable audio around audio hw setup. This may avoid hangs on certain asics. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Properly clear the enable bit when audio disable is requested. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org
-
由 Jerome Glisse 提交于
Need to free the uvd ring. Also reshuffle gart tear down to happen after uvd tear down. Signed-off-by: NJérôme Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Causes display problems. We had already disabled sharing for non-DP displays. Based on a patch from: Niels Ole Salscheider <niels_ole@salscheider-online.de> bug: https://bugzilla.kernel.org/show_bug.cgi?id=58121Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Christian König 提交于
Otherwise we might get a crash here. Signed-off-by: NChristian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Print the supported functions mask in addition to the version. This is useful in debugging PX problems since we can see what functions are available. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Mike Snitzer 提交于
It was always intended that a user could provide a thin metadata device that is larger than the max supported by the on-disk format. The extra space would just go unused. Unfortunately that never worked. If the user attempted to use a larger metadata device on creation they would get an error like the following: device-mapper: space map common: space map too large device-mapper: transaction manager: couldn't create metadata space map device-mapper: thin metadata: tm_create_with_sm failed device-mapper: table: 252:17: thin-pool: Error creating metadata object device-mapper: ioctl: error adding target to table Fix this by allowing the initial metadata space map creation to cap its size at the max number of blocks supported (DM_SM_METADATA_MAX_BLOCKS). get_metadata_dev_size() must also impose DM_SM_METADATA_MAX_BLOCKS (via THIN_METADATA_MAX_SECTORS), otherwise extending metadata would cap at THIN_METADATA_MAX_SECTORS_WARNING (which is larger than supported). Also, the calculation for THIN_METADATA_MAX_SECTORS didn't account for the sizeof the disk_bitmap_header. So the supported maximum metadata size is a bit smaller (reduced from 33423360 to 33292800 sectors). Lastly, remove the "excess space will not be used" warning message from get_metadata_dev_size(); it resulted in printing the warning multiple times. Factor out warn_if_metadata_device_too_big(), call it from pool_ctr() and maybe_resize_metadata_dev(). Signed-off-by: NMike Snitzer <snitzer@redhat.com> Acked-by: NJoe Thornber <ejt@redhat.com>
-
- 27 2月, 2014 3 次提交
-
-
由 Stanislaw Gruszka 提交于
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when threadirqs option is used. To prevent the deadlock use spin_lock_irqsave() in ehci_irq(). This change can be reverted when hrtimer callbacks become threaded. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Cc: stable <stable@vger.kernel.org> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Joerg Dorchain 提交于
Hello, the following patch adds an entry for the PID of a Cressi Leonardo diving computer interface to kernel 3.13.0. It is detected as FT232RL. Works with subsurface. Signed-off-by: NJoerg Dorchain <joerg@dorchain.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lan Tianyu 提交于
acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make sure that the (struct acpi_processor)->acpi_processor_set_throttling() callback will run on the right CPU. However, the function may be called from a worker thread already bound to a different CPU in which case that won't work. Make acpi_processor_set_throttling() use work_on_cpu() as appropriate instead of abusing set_cpus_allowed_ptr(). Reported-and-tested-by: NJiri Olsa <jolsa@redhat.com> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Cc: All applicable <stable@vger.kernel.org> [rjw: Changelog] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 2月, 2014 8 次提交
-
-
由 Christian Engelmayer 提交于
Fix a memory leak in the lp3943_pwm_request_map() error handling path. Make sure already allocated pwm map memory is freed correctly. Detected by Coverity: CID 1162829. Signed-off-by: NChristian Engelmayer <cengelma@gmx.at> Acked-by: NMilo Kim <milo.kim@ti.com> Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
-
由 Hannes Reinecke 提交于
An invalid ioctl will never be valid, irrespective of whether multipath has active paths or not. So for invalid ioctls we do not have to wait for multipath to activate any paths, but can rather return an error code immediately. This fix resolves numerous instances of: udevd[]: worker [] unexpectedly returned with status 0x0100 that have been seen during testing. Signed-off-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
-
由 Sebastian Capella 提交于
During restore, pm_notifier chain are called with PM_RESTORE_PREPARE. The firmware_class driver handler fw_pm_notify does not have a handler for this. As a result, it keeps a reader on the kmod.c umhelper_sem. During freeze_processes, the call to __usermodehelper_disable tries to take a write lock on this semaphore and hangs waiting. Signed-off-by: NSebastian Capella <sebastian.capella@linaro.org> Acked-by: NMing Lei <ming.lei@canonical.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Dirk Brandewie 提交于
Commit fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) introduced a regression on some processor SKUs supported by intel_pstate. This was due to the truncation caused by using integer math to calculate core busy and C0 percentages. On a i7-4770K processor operating at 800Mhz going to 100% utilization the percent busy of the CPU using integer math is 22%, but it actually is 22.85%. This value scaled to the current frequency returned 97 which the PID interpreted as no error and did not adjust the P state. Tested on i7-4770K, i7-2600, i5-3230M. Fixes: fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) References: https://lkml.org/lkml/2014/2/19/626 References: https://bugzilla.kernel.org/show_bug.cgi?id=70941Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Joe Perches 提交于
This 444 should have been octal. Signed-off-by: NJoe Perches <joe@perches.com> Cc: Alessandro Rubini <rubini@gnudd.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joe Perches 提交于
These should have been octal. Signed-off-by: NJoe Perches <joe@perches.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 James Hogan 提交于
Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND cpu_online_mask into the cpumask when picking a CPU to vector the interrupt to. As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't filter out offline CPUs, so without this patch if you offline CPU0 and set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even though it is offline. Reported-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org
-
由 Dan Williams 提交于
Since commit 77873803 "net_dma: mark broken" we no longer pin dma engines active for the network-receive-offload use case. As a result the ->free_chan_resources() that occurs after the driver self test no longer has a NET_DMA induced ->alloc_chan_resources() to back it up. A late firing irq can lead to ksoftirqd spinning indefinitely due to the tasklet_disable() performed by ->free_chan_resources(). Only ->alloc_chan_resources() can clear this condition in affected kernels. This problem has been present since commit 3e037454 "I/OAT: Add support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the NET_DMA use case is deprecated we can revisit moving the driver to use threaded irqs. For now, just tear down the irq and tasklet properly by: 1/ Disable the irq from triggering the tasklet 2/ Disable the irq from re-arming 3/ Flush inflight interrupts 4/ Flush the timer 5/ Flush inflight tasklets References: https://lkml.org/lkml/2014/1/27/282 https://lkml.org/lkml/2014/2/19/672 Cc: Ingo Molnar <mingo@elte.hu> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Reported-by: NMike Galbraith <bitbucket@online.de> Reported-by: NStanislav Fomichev <stfomichev@yandex-team.ru> Tested-by: NMike Galbraith <bitbucket@online.de> Tested-by: NStanislav Fomichev <stfomichev@yandex-team.ru> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 25 2月, 2014 7 次提交
-
-
由 Jean Delvare 提交于
pci_get_device() decrements the reference count of "from" (last argument) so when we break off the loop successfully we have only one device reference - and we don't know which device we have. If we want a reference to each device, we must take them explicitly and let the pci_get_device() walk complete to avoid duplicate references. This is serious, as over-putting device references will cause the device to eventually disappear. Without this fix, the kernel crashes after a few insmod/rmmod cycles. Tested on an Intel S7000FC4UR system with a 7300 chipset. Signed-off-by: NJean Delvare <jdelvare@suse.de> Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: stable@vger.kernel.org Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Jean Delvare 提交于
The reference count changes done by pci_get_device can be a little misleading when the usage diverges from the most common scheme. The reference count of the device passed as the last parameter is always decreased, even if the function returns no new device. So if we are going to try alternative device IDs, we must manually increment the device reference count before each retry. If we don't, we end up decreasing the reference count, and after a few modprobe/rmmod cycles the PCI devices will vanish. In other words and as Alan put it: without this fix the EDAC code corrupts the PCI device list. This fixes kernel bug #50491: https://bugzilla.kernel.org/show_bug.cgi?id=50491Signed-off-by: NJean Delvare <jdelvare@suse.de> Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvareReviewed-by: NAlan Cox <alan@linux.intel.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: stable@vger.kernel.org Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Manu Gupta 提交于
The D-Link DWA-123 REV D1 with USB ID 2001:3310 uses this driver. Signed-off-by: NManu Gupta <manugupt1@gmail.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Venkatesh Srinivas 提交于
The virtio spec requires byte 0 of the virtio-scsi LUN structure to be '1'. Signed-off-by: NVenkatesh Srinivas <venkateshs@google.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Juergen Beisert 提交于
Releasing the touchscreen lets the internal statemachine left in a wrong state. Due to this the release coordinate will be reported again by accident when the next touchscreen event happens. This change sets up the correct state when waiting for the next touchscreen event. This has led to reported issues with calibrating the touchscreen. Bug was introduced somewhere in the series that began with 18da755d Staging/iio/adc/touchscreen/MXS: add proper clock handling in which the way this driver worked was substantially changed to be interrupt driven rather than relying on a busy loop. This was a regression in the 3.13 kernel. Signed-off-by: NJuergen Beisert <jbe@pengutronix.de> Tested-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Cc: stable@vger.kernel.org Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
由 Dr. Greg Wettstein 提交于
A selective retransmission request (SRR) is a fibre-channel protocol control request which provides support for requesting retransmission of a data sequence in response to an issue such as frame loss or corruption. These events are experienced infrequently in fibre-channel based networks which makes it difficult to test and assess codepaths which handle these events. We were fortunate enough, for some definition of fortunate, to have a metro-area single-mode SAN link which, at 10 GBPS sustained load levels, would consistently generate SRR's in a SCST based target implementation using our SCST/in-kernel Qlogic target interface driver. In response to an SRR the in-kernel Qlogic target driver immediately panics resulting in a catastrophic storage failure for serviced initiators. The culprit was a debug statement in the qla_target.c file which does not verify that a pointer to the SCSI CDB is not null. The unchecked pointer dereference results in the kernel panic and resultant system failure. The other two references to the SCSI CDB by the SRR handling code use a ternary operator to verify a non-null pointer is being acted on. This patch simply adds a similar test to the implicated debug statement. This patch is a candidate for any stable kernel being maintained since it addresses a potentially catastrophic event with minimal downside. Signed-off-by: NDr. Greg Wettstein <greg@enjellic.com> Cc: <stable@vger.kernel.org> #3.5+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Mike Snitzer 提交于
dm_pool_close_thin_device() must be called if dm_set_target_max_io_len() fails in thin_ctr(). Otherwise __pool_destroy() will fail because the pool will still have an open thin device: device-mapper: thin metadata: attempt to close pmd when 1 device(s) are still open device-mapper: thin: __pool_destroy: dm_pool_metadata_close() failed. Also, must establish error code if failing thin_ctr() because the pool is in fail_io mode. Signed-off-by: NMike Snitzer <snitzer@redhat.com> Acked-by: NJoe Thornber <ejt@redhat.com> Cc: stable@vger.kernel.org
-
- 24 2月, 2014 5 次提交
-
-
由 Sagi Grimberg 提交于
Because then this sg is passed to sbc_copy_prot which will hit a protection fault in cases we have more than a single sg. Signed-off-by: NSagi Grimberg <sagig@mellanox.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Nicholas Bellinger 提交于
This patch adds the three missing DIF related sense codes within transport_generic_request_failure(), which are required to ensure that the correct ASC/ASQC is generated by the subsequent call to transport_send_check_condition_and_sense(). Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Nicholas Bellinger 提交于
This patch fixes a bug in sbc_dif_copy_prot() where the updated addr offset did not take into account the case where the associated scatterlist had not been incremented. This addresses the case where incoming protection scatterlists may contain a length smaller than PAGE_SIZE across multiple entires, when the target protection scatterlists are always being explicitly filled up to PAGE_SIZE before adding another entry. Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Pekon Gupta 提交于
This patch excludes reserved-marker byte-position from oobfree->length calculation. Thus all bytes from oobfree->offset till end of OOB are free. CC: <stable@vger.kernel.org> # 3.13.x+ Signed-off-by: NPekon Gupta <pekon@ti.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Pekon Gupta 提交于
1) In current implementation, ecclayout->oobfree->offset is calculated with respect to ecclayout->eccpos[0] which is incorrect because ECC bytes may not be stored contiguously in OOB. So, this patch calculates ecclayout->oobfree->offset with respect to last ECC byte-position 'eccpos[ecclayout->eccbytes-1]'. 2) ECC layout of some ecc-schemes expects reserved-markers at specific eccpos[] which should not be over-written by any file-system metadata. So this patch aligns oobfree->offset taking into account of such markers. CC: <stable@vger.kernel.org> # 3.13.x+ Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com> Tested-by: NStefan Roese <sr@denx.de> Signed-off-by: NPekon Gupta <pekon@ti.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-