- Jun 29, 2011
-
-
Kim Phillips authored
setkey allocates 16 bytes (CAAM_CMD_SZ * DESC_AEAD_SHARED_TEXT_LEN) shy of what is needed to store the shared descriptor, resulting in memory corruption. Fix this. Signed-off-by:
Kim Phillips <kim.phillips@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- Jun 24, 2011
-
-
Paweł Drewniak authored
This patch enables support for Marvell IDE PATA controllers found on Asus P8P67LE motherboard. The formatting has been corrected and I also received a report from two users of this motherboard that the patch works. Signed-off-by:
Paweł Drewniak <czajernia@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
-
Alex Deucher authored
A voltage value of 0xff01 requires that the driver look up the max voltage for the board based using the atom SetVoltage command table. Setting the proper voltage should fix stability on some newer asics. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Alex Deucher authored
The field is encoded: 0 = 4 banks 1 = 8 banks 2 = 16 banks Signed-off-by:
-
Nicholas Bellinger authored
This patch fixes the following conversion specification warning for size_t drivers/target/tcm_fc/tfc_io.c: In function ‘ft_queue_data_in’: drivers/target/tcm_fc/tfc_io.c:209: warning: format ‘%x’ expects type ‘unsigned int’, but argument 5 has type ‘size_t’ Reported-by:
Randy Dunlap <randy.dunlap@oracle.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org>
-
Dan Carpenter authored
There is a typo here, it should be an unlock instead of a lock. The original code will deadlock. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Kiran Patil authored
This patch fixes a bug in ft_send_tm() that was incorrectly calling ft_get_lun_for_cmd() -> transport_get_lun_for_cmd(), instead of using transport_get_lun_for_tmr() for the proper struct se_lun lookup that was triggering an OOPs in the se_cmd->tmr_req failure path. This patch fixes the issue by re-arranging the codepath where transport_get_lun_for_tmr() is called after tmr request is allocated and made it available as part of se_cmd. It also drops the now unnecessary ft_get_lun_for_cmd() unpacking code, and uses scsilun_to_int() directly ahead of transport_get_lun_for_cmd() and transport_get_lun_for_tmr() usage. Signed-off-by:
Patil, Kiran <kiran.patil@intel.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
-
Dan Carpenter authored
This patch fixes a number of cases in target core using an incorrectly if (strlen(foo) > SOME_MAX_SIZE) As strlen() returns the number of characters in the string not counting the NULL character at the end. So if you do something like: char buf[10]; if (strlen("0123456789") > 10) return -ETOOLONG; snprintf(buf, 10, "0123456789"); printf("%s\n", buf); then the last "9" gets chopped off and only "012345678" is printed. Plus I threw in one small related cleanup. Signed-off-by: -
Dan Carpenter authored
In the original code, there were several places inside the target_fabric_configfs_init() function that returned NULL on error and one place the returned an ERR_PTR. There are two places that call this function and they only check for NULL returns; they don't check for ERR_PTRs. So I've changed the ERR_PTR so now the function only returns NULL on error. Signed-off-by:
-
Dan Carpenter authored
transport_init_session() and core_tmr_alloc_req() never return NULL, they only return ERR_PTRs on error. v2: Fix patch to return PTR_ERR(tl_nexus->se_sess) from Ankit Jain's feedback. Signed-off-by:
Ankit Jain <jankit@suse.de> Signed-off-by:
-
- Jun 23, 2011
-
-
Roland Dreier authored
This patch converts transport_deregister_session_configfs() to save/restore spinlock IRQ state for struct se_node_acl->nacl_sess_lock access as tcm_qla2xxx logic expects to call transport_deregister_session_configfs() code with irq save already held for struct qla_hw_data. Reported-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Nicholas Bellinger authored
This patch fixes two possible NULL pointer dereferences in target v4.0 code where se_tmr release path in core_tmr_release_req() can OOPs upon transport_get_lun_for_tmr() failure by attempting to access se_device or se_tmr->tmr_list without a valid member of se_device->tmr_list during transport_free_se_cmd() release. This patch moves the se_tmr->tmr_dev pointer assignment in transport_get_lun_for_tmr() until after possible -ENODEV failures during unpacked_lun lookup. This addresses an OOPs originally reported with LIO v4.1 upstream on .39 code here: TARGET_CORE[qla2xxx]: Detected NON_EXISTENT_LUN Access for 0x00000000 BUG: unable to handle kernel NULL pointer dereference at 0000000000000550 IP: [<ffffffff81035ec4>] __ticket_spin_trylock+0x4/0x20 PGD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/system/cpu/cpu23/cache/index2/shared_cpu_map CPU 1 Modules linked in: netconsole target_core_pscsi target_core_file tcm_qla2xxx target_core_iblock tcm_loop target_core_mod configfs ipmi_devintf ipmi_si ipmi_msghandler serio_raw i7core_edac ioatdma dca edac_core ps_bdrv ses enclosure usbhid usb_storage ahci qla2xxx hid uas e1000e mpt2sas libahci mlx4_core scsi_transport_fc scsi_transport_sas raid_class scsi_tgt [last unloaded: netconsole] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.39+ #1 Xyratex Storage Server RIP: 0010:[<ffffffff81035ec4>] [<ffffffff81035ec4>]__ticket_spin_trylock+0x4/0x20 RSP: 0018:ffff88063e803c08 EFLAGS: 00010286 RAX: ffff880619ab45e0 RBX: 0000000000000550 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000550 RBP: ffff88063e803c08 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000568 R13: 0000000000000001 R14: 0000000000000000 R15: ffff88060cd96a20 FS: 0000000000000000(0000) GS:ffff88063e800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000550 CR3: 0000000001a03000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/0:0 (pid: 0, threadinfo ffff880619ab8000, task ffff880619ab45e0) Stack: ffff88063e803c28 ffffffff812cf039 0000000000000550 0000000000000568 ffff88063e803c58 ffffffff8157071e ffffffffa028a1dc ffff88060f7e4600 0000000000000550 ffff880616961480 ffff88063e803c78 ffffffffa028a1dc Call Trace: <IRQ> [<ffffffff812cf039>] do_raw_spin_trylock+0x19/0x50 [<ffffffff8157071e>] _raw_spin_lock+0x3e/0x70 [<ffffffffa028a1dc>] ? core_tmr_release_req+0x2c/0x60 [target_core_mod] [<ffffffffa028a1dc>] core_tmr_release_req+0x2c/0x60 [target_core_mod] [<ffffffffa028d0d2>] transport_free_se_cmd+0x22/0x50 [target_core_mod] [<ffffffffa028d120>] transport_release_cmd_to_pool+0x20/0x40 [target_core_mod] [<ffffffffa028e525>] transport_generic_free_cmd+0xa5/0xb0 [target_core_mod] [<ffffffffa0147cc4>] tcm_qla2xxx_handle_tmr+0xc4/0xd0 [tcm_qla2xxx] [<ffffffffa0191ba3>] __qla24xx_handle_abts+0xd3/0x150 [qla2xxx] [<ffffffffa0197651>] qla_tgt_response_pkt+0x171/0x520 [qla2xxx] [<ffffffffa0197a2d>] qla_tgt_response_pkt_all_vps+0x2d/0x220 [qla2xxx] [<ffffffffa0171dd3>] qla24xx_process_response_queue+0x1a3/0x670 [qla2xxx] [<ffffffffa0196281>] ? qla24xx_atio_pkt+0x81/0x120 [qla2xxx] [<ffffffffa0174025>] ? qla24xx_msix_default+0x45/0x2a0 [qla2xxx] [<ffffffffa0174198>] qla24xx_msix_default+0x1b8/0x2a0 [qla2xxx] [<ffffffff810dadb4>] handle_irq_event_percpu+0x54/0x210 [<ffffffff810dafb8>] handle_irq_event+0x48/0x70 [<ffffffff810dd5ee>] ? handle_edge_irq+0x1e/0x110 [<ffffffff810dd647>] handle_edge_irq+0x77/0x110 [<ffffffff8100d362>] handle_irq+0x22/0x40 [<ffffffff8157b28d>] do_IRQ+0x5d/0xe0 [<ffffffff81571413>] common_interrupt+0x13/0x13 <EOI> [<ffffffff813003f7>] ? intel_idle+0xd7/0x130 [<ffffffff813003f0>] ? intel_idle+0xd0/0x130 [<ffffffff8144832b>] cpuidle_idle_call+0xab/0x1c0 [<ffffffff8100a26b>] cpu_idle+0xab/0xf0 [<ffffffff81566c59>] start_secondary+0x1cb/0x1d2 Reported-by: -
Alexey Charkov authored
Now that the generic code handles UIE mode irqs via periodic alarm interrupts, no one calls the rtc_class_ops->update_irq_enable() method anymore. Further the rtc_class_ops doesn't have a update_irq_enable element anymore, so this causes a build error. This patch removes the driver hooks and implementations of update_irq_enable and the associated setup. [wsa: updated commit-message and removed update_irq_enable-function, too] [jstultz: improve commit message, clarifying build issue] Signed-off-by:
Alexey Charkov <alchark@gmail.com> Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
John Stultz <john.stultz@linaro.org>
-
Nishanth Aravamudan authored
On 16.06.2011 [08:28:39 -0500], Brian King wrote: > On 06/16/2011 02:51 AM, Tejun Heo wrote: > > On Wed, Jun 15, 2011 at 04:34:17PM -0700, Nishanth Aravamudan wrote: > >>> That looks like the right thing to do. For ipr's usage of > >>> libata, we don't have the concept of a port frozen state, so this flag > >>> should really never get set. The alternate way to fix this would be to > >>> only set ATA_PFLAG_FROZEN in ata_port_alloc if ap->ops->error_handler > >>> is not NULL. > >> > >> It seemed like ipr is as you say, but I wasn't sure if it was > >> appropriate to make the change above in the common libata-scis code or > >> not. I don't want to break some other device on accident. > >> > >> Also, I tried your suggestion, but I don't think that can happen in > >> ata_port_alloc? ata_port_alloc is allocated ap itself, and it seems like > >> ap->ops typically gets set only after ata_port_alloc returns? > > > > Maybe we can test error_handler in ata_sas_port_start()? > > Good point. Since libsas is converted to the new eh now, we would need to have > this test. Commit 7b3a24c5 ("ahci: don't enable port irq before handler is registered") caused a regression for CD-ROMs attached to the IPR SATA bus on Power machines: ata_port_alloc: ENTER ata_port_probe: ata1: bus probe begin ata1.00: ata_dev_read_id: ENTER ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40) ata1.00: ata_dev_read_id: ENTER ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40) ata1.00: limiting speed to UDMA7:PIO5 ata1.00: ata_dev_read_id: ENTER ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40) ata1.00: disabled ata_port_probe: ata1: bus probe end scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured The FROZEN flag added in that commit is only cleared by the new EH code, which is not used by ipr. Clear this flag in the SAS code if we don't support new EH. Reported-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by:
Jeff Garzik <jgarzik@pobox.com>
-
Tejun Heo authored
regardless of firmware revision It's unlikely NOSETXFER works for a revision of drive but doesn't for another and pioneer doesn't seem to be fixing firmwares for the affected drives. Apply NOSETXFER to the affected pioneer drives regardless of firmware revision. http://article.gmane.org/gmane.linux.ide/49734 Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
<fl-00@gmx.de> Signed-off-by:
-
Justin P. Mattock authored
The patch below fixes a typo. Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Signed-off-by:
-
Mika Westerberg authored
The driver went to initialize its waitqueue at the start of the main processing thread. However, it is possible that this thread is not scheduled on a CPU before the write function is called which leads to a following error: BUG: spinlock bad magic on CPU#1, swapper/1 lock: f5f3ebdc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 Pid: 1, comm: swapper Not tainted 3.0.0-rc2+ #67 Call Trace: [<c1289663>] spin_bug+0xa3/0xf0 [<c12897ad>] do_raw_spin_lock+0x7d/0x150 [<c14963de>] _raw_spin_lock_irqsave+0x4e/0x60 [<c102f2bb>] __wake_up+0x1b/0x50 [<c12d3715>] serial_m3110_con_write+0x55/0x60 [<c1041575>] __call_console_drivers+0x75/0x90 [<c10415d9>] _call_console_drivers+0x49/0x80 [<c1041baa>] console_unlock+0xca/0x1f0 [<c10420ef>] vprintk+0x18f/0x4f0 [<c14928a3>] printk+0x18/0x1a [<c1042730>] register_console+0x2e0/0x350 [<c12d098e>] uart_add_one_port+0x33e/0x3d0 [<c1485ba6>] serial_m3110_probe+0x1c2/0x1df [<c1303db7>] spi_drv_probe+0x17/0x20 ... Fix this by initializing the waitqueue before the main thread is created. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
William Douglas authored
Change print message to notice instead of error to clean up non critical messages showing on startup. The MAX3111 not being present is a normal path for end user systems. Signed-off-by:
William Douglas <william.douglas@intel.com> [rebased on 3.0, switched to dev_dbg()] Signed-off-by:
-
- Jun 22, 2011
-
-
Ben Widawsky authored
The lock must be held for the saving and restoring of VGA state. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> CC: Alexander Zhaunerchyk <alex.vizor@gmail.com> CC: Andrey Rahmatullin <wrar@wrar.name> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
- Jun 21, 2011
-
-
Rafael J. Wysocki authored
After commit e8665002 (PM: Allow pm_runtime_suspend() to succeed during system suspend) it is possible that a device resumed by the pm_runtime_resume(dev) in pci_pm_prepare() will be suspended immediately from a work item, timer function or otherwise, defeating the very purpose of calling pm_runtime_resume(dev) from there. To prevent that from happening it is necessary to increment the runtime PM usage counter of the device by replacing pm_runtime_resume() with pm_runtime_get_sync(). Moreover, the incremented runtime PM usage counter has to be decremented by the corresponding pci_pm_complete(), via pm_runtime_put_sync(). Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Cc: stable@kernel.org Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Rafael J. Wysocki authored
Commit 85eb8c8d (PM / Runtime: Generic clock manipulation rountines for runtime PM (v6)) converted the shmobile platform to using generic code for runtime PM clock management, but it changed the behavior for CONFIG_PM_RUNTIME unset incorrectly. Specifically, for CONFIG_PM_RUNTIME unset pm_runtime_clk_notify() should enable clocks for action equal to BUS_NOTIFY_BIND_DRIVER and it should disable them for action equal to BUS_NOTIFY_UNBOUND_DRIVER (instead of BUS_NOTIFY_ADD_DEVICE and BUS_NOTIFY_DEL_DEVICE, respectively). Make this function behave as appropriate. Signed-off-by:
Magnus Damm <damm@opensource.se>
-
Alan Stern authored
The PM core doesn't handle suspend failures correctly when it comes to asynchronously suspended devices. These devices are moved onto the dpm_suspended_list as soon as the corresponding async thread is started up, and they remain on the list even if they fail to suspend or the sleep transition is cancelled before they get suspended. As a result, when the PM core unwinds the transition, it tries to resume the devices even though they were never suspended. This patch (as1474) fixes the problem by adding a new "is_suspended" flag to dev_pm_info. Devices are resumed only if the flag is set. [rjw: * Moved the dev->power.is_suspended check into device_resume(), because we need to complete dev->power.completion and clear dev->power.is_prepared too for devices whose dev->power.is_suspended flags are unset. * Fixed __device_suspend() to avoid setting dev->power.is_suspended if async_error is different from zero.] Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
This patch (as1473) renames the "in_suspend" field in struct dev_pm_info to "is_prepared", in preparation for an upcoming change. The new name is more descriptive of what the field really means. Signed-off-by:
-
Eric Anholt authored
This reverts commit 4a684a41. Userland has always been required to set the object's domain to GTT before using it through a GTT mapping, it's not something that the kernel is supposed to enforce. (The pagefault support is so that we can handle multiple mappings without userland having to pin across them, not so that userland can use GTT after GPU domains without telling the kernel). Fixes 19.2% +/- 0.8% (n=6) performance regression in cairo-gl firefox-talos-gfx on my T420 latop. Signed-off-by:
-
Chris Wilson authored
...we need to apply exactly the same workaround for missing interrupts from BSD as for the BLT ring, apparently. See also commit 498e720b (drm/i915: Fix gen6 (SNB) missed BLT ring interrupts). Reported-and-tested-by:
<nkalkhof@web.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38529 Signed-off-by:
-
Keith Packard authored
This change got placed in the ironlake path instead of the 9xx path during a recent code shuffle. Signed-off-by:
-
- Jun 20, 2011
-
-
Alex Deucher authored
0xff01 is not an actual voltage value, but a flag for the driver. If the power state as that value, skip setting the voltage. Signed-off-by:
-
Richard Cochran authored
Because the socket buffer is freed in the completion interrupt, it is not safe to access it after submitting it to the hardware. Cc: stable@kernel.org Cc: Sachin Sanap <ssanap@marvell.com> Cc: Zhangfei Gao <zgao6@marvell.com> Cc: Philip Rakity <prakity@marvell.com> Signed-off-by:
Richard Cochran <richard.cochran@omicron.at> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
As soon as skb is given to hardware, TX completion can free skb under us. Therefore, we should update dev stats before kicking the device. Signed-off-by:
-
Dave Airlie authored
this printk isn't really useful, just drop it for now. Signed-off-by: -
Dave Airlie authored
Since we were calling the wptr function before checking if the IH was even enabled, or the GPU wasn't shutdown, we'd get spam in the logs when the GPU readback 0xffffffff. This reorders things so we return early in the no IH and GPU shutdown cases. Reported-and-tested-by: ManDay on #radeon Reviewed-by:
-
- Jun 19, 2011
-
-
Alex Deucher authored
This is used during phy init to set up the phy for DP. This may fix DP problems on DCE3.2 cards. Signed-off-by:
-
Alex Deucher authored
Certain revisions of the vbios on DCE3.2 cards have a bug in the transmitter control table which prevents duallink from being enabled properly on some cards. The action switch statement jumps to the wrong offset for the OUTPUT_ENABLE action. The fix is to use the ENABLE action rather than the OUTPUT_ENABLE action on the affected cards. In fixed version of the vbios, both actions jump to the same offset, so the change should be safe. Reported-and-tested-by:
-
Eric Dumazet authored
Its illegal to dereference skb after dev_kfree_skb(skb) Signed-off-by:
-
Eric Dumazet authored
As soon as skb is given to hardware and spinlock released, TX completion can free skb under us. Therefore, we should update netdev stats before spinlock release. Signed-off-by:
-
WANG Cong authored
Otherwise we will not see the name of the slave dev in error message: [ 388.469446] (null): doesn't support polling, aborting. Signed-off-by:
WANG Cong <amwang@redhat.com> Signed-off-by:
-
- Jun 18, 2011
-
-
Magnus Damm authored
According to the data sheet for G4, AP4 and AG5 KEYSC MODE_6 is 8x8 keys. Bump up MAXKEYS to 64 too. Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru>
-
Janusz Krzysztofik authored
Otherwise the updated evdev driver (commit cdda911c, "Input: evdev - only signal polls on full packets") no longer works on top of omap-keypad. Tested on Amstrad Delta. Signed-off-by:
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Reviewed-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
-
Dmitry Torokhov authored
We should only wake waiters on the event device when we actually post an EV_SYN/SYN_REPORT to the queue. Otherwise we end up making waiting threads runnable only to go right back to sleep because the device still isn't readable. Reported-by:
Jeffrey Brown <jeffbrown@android.com> Signed-off-by:
-
Guenter Roeck authored
Initialize dynamically allocated sysfs attributes before device_create_file() call to suppress lockdep_init_map() warning if lockdep debugging is enabled. Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Acked-by:
Jean Delvare <khali@linux-fr.org> Cc: stable@kernel.org # 2.6.34+
-
