- 31 5月, 2008 2 次提交
-
-
由 Seokmann Ju 提交于
Initialize all proper structure members in order to support work-list vport processing. This code also properly acquires the correct (physical hardware_lock) lock during work submission. Signed-off-by: NSeokmann Ju <seokmann.ju@qlogic.com> Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Seokmann Ju 提交于
This reverts commit bd2a1846. The original (prior to the reverted commit) code was correct. Additionally, the vp_idx should be checked during MBA_PORT_UPDATE in order for proper handling to take place for a given vport. Signed-off-by: NSeokmann Ju <seokmann.ju@qlogic.com> Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 28 5月, 2008 1 次提交
-
-
由 Brian King 提交于
Some versions of the Virtual I/O Server on Power return 0x99 in the non-SCSI error status field as success, rather than 0. This fixes the ibmvscsi driver to treat this response as success. Signed-off-by: NBrian King <brking@linux.vnet.ibm.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 27 5月, 2008 1 次提交
-
-
由 Michael Reed 提交于
Following a hard reset of a SAS raid, one of the raid targets is occasionally missing. I tracked this down to a pretty obscure little bug. The LSI fusion drivers for SAS and Fibre Channel both use their respective transport layers. Those transport layers increment the target number assigned to new targets. The routine __scsi_scan_target uses the "this_id" element of the Scsi_Host structure to avoid scanning the scsi host adapter. Both fusion drivers set "this_id" from a value returned in a firmware PortFacts response. For my particular test case (SAS) the firmware id assigned to the initiator was 173. After enough raid resets to cause the raid targets to go and come a sufficient number of times, the id assigned by the transport to a raid target would match the id assigned by the host adapter to the "this_id" field, resulting in that target not being scanned. Fix by not assigning this_id and not checking it in slave_configure. Signed-off-by: NMichael Reed <mdr@sgi.com> Acked-by: N"Moore, Eric" <Eric.Moore@lsi.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 24 5月, 2008 1 次提交
-
-
由 James Bottomley 提交于
Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com> > BUG: unable to handle kernel paging request at e6f17fac > IP: [<c02604d6>] scsi_bus_uevent+0x1/0x17 > *pde = 2714b163 *pte = 26f17160 > Oops: 0000 [#1] DEBUG_PAGEALLOC > last sysfs file: > > Pid: 1, comm: swapper Not tainted (2.6.26-rc2-next-20080516skw #30) > EIP: 0060:[<c02604d6>] EFLAGS: 00010282 CPU: 0 > EIP is at scsi_bus_uevent+0x1/0x17 > EAX: e6f18014 EBX: e6f18014 ECX: c02604d5 EDX: e7173000 > ESI: e7173000 EDI: e7173000 EBP: e7851ca0 ESP: e7851c90 > DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 The problem is caused by: commit b0ed4336 Author: Hannes Reinecke <hare@suse.de> Date: Tue Mar 18 14:32:28 2008 +0100 [SCSI] add scsi_host and scsi_target to scsi_bus which added scsi_bus_type to the struct scsi_target device. This causes both the scsi_device and scsi_target to fire scsi_bus_uevents. However, the actualy scsi_bus_uevent() call assumes blindly that it's a struct scsi_device. Check for this and return immediately if it isn't. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 15 5月, 2008 35 次提交
-
-
由 Andrew Vasquez 提交于
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Vasquez 提交于
This reverts commit 8084fe16. The midlayer should be given the oppotunity to interpret the check-condition and based on scsi_cmnd->resid determine if a transfer should be retried or failed. Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Vasquez 提交于
Matthew Wilcox <matthew@wil.cx> reported the following lockdep warning: > ================================= > [INFO:inconsistentlockstate] > 2.6.26-rc1-00115-g0340eda-dirty#60 > --------------------------------- > inconsistent{hardirq-on-W}->{in-hardirq-W}usage. > swapper/1[HC1[1]:SC0[0]:HE0:SE1]takes: > (&ha->hardware_lock){+-..},at:[<c035495d>]qla2300_intr_handler+0x35/0x1f5 > {hardirq-on-W}statewasregisteredat: > [<c0139a16>]__lock_acquire+0x459/0xb1d > [<c013a091>]__lock_acquire+0xad4/0xb1d > [<c013a142>]lock_acquire+0x68/0x82 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c0506da5>]_spin_lock+0x24/0x4d > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c01391e4>]trace_hardirqs_on+0xe7/0x10e > [<c034f0a6>]qla2x00_mailbox_command+0x1c6/0x433 ... > other info that might help us debug this: > no locks held by swapper/1. > > stack backtrace: > Pid:1,comm:swapperNottainted2.6.26-rc1-00115-g0340eda-dirty#60 > [<c0138121>]print_usage_bug+0x100/0x10a > [<c0138d37>]mark_lock+0xaa/0x395 > [<c01399af>]__lock_acquire+0x3f2/0xb1d > [<c013a091>]__lock_acquire+0xad4/0xb1d > [<c013a142>]lock_acquire+0x68/0x82 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c0506da5>]_spin_lock+0x24/0x4d > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c014a37b>]handle_IRQ_event+0x13/0x3d > [<c014b366>]handle_fasteoi_irq+0x76/0xab Which shows that lockdep is detecting the driver's interrupt-handler is run in both process and interrupt context with irqs-enabled in the former case. During init-time and error-recovery (after a RISC reset), the driver disables interrupts and 'polls' for completions by calling qla2x00_poll(): static inline void qla2x00_poll(scsi_qla_host_t *ha) { ha->isp_ops->intr_handler(0, ha); } which in-turn calls the ISP registered interrupt handler. This patch corrects it by disabling local interrupts during polling. Reviewed-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Vasquez 提交于
The user-initiated dump can be a useful tool in triaging complex ISP and FC issues. Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Vasquez 提交于
Recent firmwares no longer return the 'number of buffers' in mailbox6. The original code may result in a potential panic during a FW-dump process due to the driver misinterpreting the size of the allocated buffer. Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 matthias@kaehlcke.net 提交于
The semaphore vport_sem is used as a mutex. Convert it to the mutex API. Signed-off-by: NMatthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Daniel Walker 提交于
Signed-off-by: NDaniel Walker <dwalker@mvista.com> Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Vasquez 提交于
Both MSI-X vector handlers attempt to acquire the HA's hardware_lock. This though requires that interrupts be disabled/enabled during acquisition and release of the spinlock. Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Vasquez 提交于
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Shyam Sundar 提交于
For Vports, the port_type should be set to FC_PORTTYPE_NPIV. Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Andrew Morton 提交于
May 11 09:42:27 [kernel] [ 1104.496819] rarian-sk-get-c[5630]: segfault at 0 ip 7f478556caf0 sp 7fff8e3fe338 error 4 in libc-2.6.1.so[7f47854f9000+136000] May 11 10:59:48 [kernel] [ 2494.165792] May 11 10:59:48 [kernel] [ 2494.165794] ======================================================= May 11 10:59:48 [kernel] [ 2494.165801] [ INFO: possible circular locking dependency detected ] May 11 10:59:48 [kernel] [ 2494.165805] 2.6.26-rc1-00007-g91b3a7a #217 May 11 10:59:48 [kernel] [ 2494.165807] ------------------------------------------------------- May 11 10:59:48 [kernel] [ 2494.165809] less/7053 is trying to acquire lock: May 11 10:59:48 [kernel] [ 2494.165812] (tasklist_lock){..??}, at: [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50 May 11 10:59:48 [kernel] [ 2494.165821] May 11 10:59:48 [kernel] [ 2494.165822] but task is already holding lock: May 11 10:59:48 [kernel] [ 2494.165824] (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110 May 11 10:59:48 [kernel] [ 2494.165831] May 11 10:59:48 [kernel] [ 2494.165832] which lock already depends on the new lock. May 11 10:59:48 [kernel] [ 2494.165833] May 11 10:59:48 [kernel] [ 2494.165835] May 11 10:59:48 [kernel] [ 2494.165836] the existing dependency chain (in reverse order) is: May 11 10:59:48 [kernel] [ 2494.165838] May 11 10:59:48 [kernel] [ 2494.165839] -> #2 (&tty->ctrl_lock){....}: May 11 10:59:48 [kernel] [ 2494.165843] [<ffffffff80253796>] __lock_acquire+0xf86/0x1080 May 11 10:59:48 [kernel] [ 2494.165851] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.165858] [<ffffffff804deee0>] _spin_lock_irqsave+0x40/0x60 May 11 10:59:48 [kernel] [ 2494.165866] [<ffffffff803d31b5>] __proc_set_tty+0x35/0xe0 May 11 10:59:48 [kernel] [ 2494.165873] [<ffffffff803d76d4>] tty_ioctl+0xbf4/0xfe0 May 11 10:59:48 [kernel] [ 2494.165880] [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90 May 11 10:59:48 [kernel] [ 2494.165888] [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0 May 11 10:59:48 [kernel] [ 2494.165895] [<ffffffff802a095a>] sys_ioctl+0x4a/0x80 May 11 10:59:48 [kernel] [ 2494.165902] [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80 May 11 10:59:48 [kernel] [ 2494.165910] [<ffffffffffffffff>] 0xffffffffffffffff May 11 10:59:48 [kernel] [ 2494.165924] May 11 10:59:48 [kernel] [ 2494.165925] -> #1 (&sighand->siglock){++..}: May 11 10:59:48 [kernel] [ 2494.165929] [<ffffffff80253796>] __lock_acquire+0xf86/0x1080 May 11 10:59:48 [kernel] [ 2494.165936] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.165943] [<ffffffff804dec1f>] _spin_lock+0x2f/0x40 May 11 10:59:48 [kernel] [ 2494.165951] [<ffffffff8022d5a3>] copy_process+0x973/0x1210 May 11 10:59:48 [kernel] [ 2494.165959] [<ffffffff8022df12>] do_fork+0x82/0x2f0 May 11 10:59:48 [kernel] [ 2494.165967] [<ffffffff8020bfe1>] kernel_thread+0x81/0xde May 11 10:59:48 [kernel] [ 2494.165974] [<ffffffff8020c048>] child_rip+0xa/0x12 May 11 10:59:48 [kernel] [ 2494.165981] [<ffffffffffffffff>] 0xffffffffffffffff May 11 10:59:48 [kernel] [ 2494.166038] May 11 10:59:48 [kernel] [ 2494.166039] -> #0 (tasklist_lock){..??}: May 11 10:59:48 [kernel] [ 2494.166043] [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080 May 11 10:59:48 [kernel] [ 2494.166050] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.166057] [<ffffffff804dede2>] _read_lock+0x32/0x50 May 11 10:59:48 [kernel] [ 2494.166063] [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50 May 11 10:59:48 [kernel] [ 2494.166071] [<ffffffff803d5f80>] tty_check_change+0xb0/0x110 May 11 10:59:48 [kernel] [ 2494.166078] [<ffffffff803dac5f>] set_termios+0x1f/0x4c0 May 11 10:59:48 [kernel] [ 2494.166085] [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0 May 11 10:59:48 [kernel] [ 2494.166092] [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260 May 11 10:59:48 [kernel] [ 2494.166100] [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0 May 11 10:59:48 [kernel] [ 2494.166107] [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90 May 11 10:59:48 [kernel] [ 2494.166114] [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0 May 11 10:59:48 [kernel] [ 2494.166121] [<ffffffff802a095a>] sys_ioctl+0x4a/0x80 May 11 10:59:48 [kernel] [ 2494.166128] [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80 May 11 10:59:48 [kernel] [ 2494.166135] [<ffffffffffffffff>] 0xffffffffffffffff May 11 10:59:48 [kernel] [ 2494.166142] May 11 10:59:48 [kernel] [ 2494.166143] other info that might help us debug this: May 11 10:59:48 [kernel] [ 2494.166144] May 11 10:59:48 [kernel] [ 2494.166146] 1 lock held by less/7053: May 11 10:59:48 [kernel] [ 2494.166148] #0: (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110 May 11 10:59:48 [kernel] [ 2494.166155] May 11 10:59:48 [kernel] [ 2494.166156] stack backtrace: May 11 10:59:48 [kernel] [ 2494.166159] Pid: 7053, comm: less Not tainted 2.6.26-rc1-00007-g91b3a7a #217 May 11 10:59:48 [kernel] [ 2494.166161] May 11 10:59:48 [kernel] [ 2494.166162] Call Trace: May 11 10:59:48 [kernel] [ 2494.166168] [<ffffffff80251223>] print_circular_bug_tail+0x83/0x90 May 11 10:59:48 [kernel] [ 2494.166172] [<ffffffff80250889>] ? print_circular_bug_entry+0x49/0x60 May 11 10:59:48 [kernel] [ 2494.166178] [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080 May 11 10:59:48 [kernel] [ 2494.166184] [<ffffffff80232e95>] ? is_current_pgrp_orphaned+0x15/0x50 May 11 10:59:48 [kernel] [ 2494.166189] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.166206] [<ffffffff803d5f80>] tty_check_change+0xb0/0x110 May 11 10:59:48 [kernel] [ 2494.166211] [<ffffffff803dac5f>] set_termios+0x1f/0x4c0 May 11 10:59:48 [kernel] [ 2494.166216] [<ffffffff803d3423>] ? tty_ldisc_try+0x23/0x60 May 11 10:59:48 [kernel] [ 2494.166220] [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60 May 11 10:59:48 [kernel] [ 2494.166224] [<ffffffff804df2c5>] ? _spin_unlock_irqrestore+0x65/0x80 May 11 10:59:48 [kernel] [ 2494.166230] [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0 May 11 10:59:48 [kernel] [ 2494.166234] [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60 May 11 10:59:48 [kernel] [ 2494.166239] [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260 May 11 10:59:48 [kernel] [ 2494.166244] [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0 May 11 10:59:48 [kernel] [ 2494.166249] [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080 May 11 10:59:48 [kernel] [ 2494.166256] [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080 May 11 10:59:48 [kernel] [ 2494.166263] [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080 May 11 10:59:48 [kernel] [ 2494.166269] [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90 May 11 10:59:48 [kernel] [ 2494.166274] [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0 May 11 10:59:48 [kernel] [ 2494.166280] [<ffffffff802a095a>] sys_ioctl+0x4a/0x80 May 11 10:59:48 [kernel] [ 2494.166286] [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80 May 11 10:59:48 [kernel] [ 2494.166292] Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Neil Brown 提交于
As setting and clearing queue flags now requires that we hold a spinlock on the queue, and as blk_queue_stack_limits is called without that lock, get the lock inside blk_queue_stack_limits. For blk_queue_stack_limits to be able to find the right lock, each md personality needs to set q->queue_lock to point to the appropriate lock. Those personalities which didn't previously use a spin_lock, us q->__queue_lock. So always initialise that lock when allocated. With this in place, setting/clearing of the QUEUE_FLAG_PLUGGED bit will no longer cause warnings as it will be clear that the proper lock is held. Thanks to Dan Williams for review and fixing the silly bugs. Signed-off-by: NNeilBrown <neilb@suse.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Alistair John Strachan <alistair@devzero.co.uk> Cc: Nick Piggin <npiggin@suse.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Jacek Luczak <difrost.kernel@gmail.com> Cc: Prakash Punnoor <prakash@punnoor.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
Select FW_LOADER since moxa needs it, otherwise we face link problems such as: drivers/built-in.o: In function moxa_pci_probe':moxa.c:(.devinit.text+0x76d8): undefined reference to request_firmware' :moxa.c:(.devinit.text+0x7e6e): undefined reference to release_firmware' make: *** [.tmp_vmlinux1] Error 1 Reported-by: NPhilippe Roussel <p.o.roussel@free.fr> Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Harvey Harrison 提交于
Add a common hex array in hexdump.c so everyone can use it. Add a common hi/lo helper to avoid the shifting masking that is done to get the upper and lower nibbles of a byte value. Pull the pack_hex_byte helper from kgdb as it is opencoded many places in the tree that will be consolidated. Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Acked-by: NPaul Mundt <lethal@linux-sh.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Robin Getz 提交于
This art design is beautiful, isn't it? And you can watch our demo on YouTube: http://youtube.com/watch?v=fKyQOntPEFsSigned-off-by: NRobin Getz <robin.getz@analog.com> Signed-off-by: NBryan Wu <cooloney@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Nate Case 提交于
The current OF probing assumes that the resource is IORESOURCE_MEM. This checks for the IORESOURCE_IO flag and behaves appropriately. An I/O resource can exist with an ipmi device node on a legacy ISA bus. Signed-off-by: NNate Case <ncase@xes-inc.com> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Rene Herman 提交于
The AD181x and AZT230 chips don't support an IRQ-less MPU401 option but work fine without one. This adds (priority functional) IRQ-less options for each port option to help systems with few available IRQs. The AD1815 quirk can't use pnp_register_irq_resource() due to doubly penalizing the IRQ. Also, while not a practical issue due to no IRQ option being present for the dependents, this needs to add in front, not back. Doesn't use pnp_register_port_resource() for symetry with above. This does not delete the AD1815 independent option even though it should be empty after the IRQ transfer due to AD1816 coming with an empty but still present independent option by default. Was tested on AD1815, AD1816 and AZT2320. The ALSA snd-ad1818a driver also support the AZT2002 ID for MPU401 but this doesn't as I was unable to test it. Signed-off-by: NRene Herman <rene.herman@gmail.com> Tested-by: NUwe Bugla <uwe.bugla@gmx.de> Acked-by: NUwe Bugla <uwe.bugla@gmx.de> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Len Brown <len.brown@intel.com Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Rene Herman 提交于
The subsequent AD181x quirk patch would like this as part of the API. pnp_register_dependent_option() adds to the same dependent chain the quirk is walking which is fairly unclean. This enables a private option chain build which it can then just add onto the end when done. Signed-off-by: NRene Herman <rene.herman@gmail.com> Tested-by: NUwe Bugla <uwe.bugla@gmx.de> Acked-by: NUwe Bugla <uwe.bugla@gmx.de> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Len Brown <len.brown@intel.com Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Rene Herman 提交于
Make it look a bit more like pci_fixup_device/pci_do_fixups. Also print the PnP ID and delete the () from the "foo+0x0/0x1234()". Signed-off-by: NRene Herman <rene.herman@gmail.com> Tested-by: NUwe Bugla <uwe.bugla@gmx.de> Acked-by: NUwe Bugla <uwe.bugla@gmx.de> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Len Brown <len.brown@intel.com Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jens Rottmann 提交于
The following patch caused a regression with OLPC panels: commit 3888d463 lxfb: extend PLL table to support dotclocks below 25 MHz Extends the PLL frequency table of the AMD Geode-LX frame buffer driver to make use of the DIV4 bit, thus adding support for dotclocks between 6 and 25 MHz. These are needed for small LCDs (e.g. 320x240). Also inserts some intermediate steps between pre-existing frequencies. The problem was the insertion of intermediate steps into the frequency table; they would cause the wrong frequency to be matched. This patch drops those intermediate frequencies while keeping the sub-25MHz frequencies. Signed-off-by: NAndres Salomon <dilinger@debian.org> Signed-off-by: NJens Rottmann <JRottmann@LiPPERT-AT.de> Tested-by: NAndres Salomon <dilinger@debian.org> Acked-by: NJordan Crouse <jordan.crouse@amd.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Eric Dumazet 提交于
Alignment was previously requested because cpu_buffer was an [NR_CPUS] array, to avoid cache line sharing between CPUS. After commit 608dfddd (oprofile: change cpu_buffer from array to per_cpu variable ), we dont need to force an alignement anymore since cpu_buffer sits in per_cpu zone. Signed-off-by: NEric Dumazet <dada1@cosmosbay.com> Cc: Mike Travis <travis@sgi.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Sebastian Siewior 提交于
Schedule a removal for this driver. Alternative driver is available for a while now. Signed-off-by: NSebastian Siewior <bigeasy@linutronix.de> Acked-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NAlan Cox <alan@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Grant Likely 提交于
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NDavid Brownell <david-b@pacbell.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
Disable Virtual DMA support for now (it causes system hangs). Thanks to TAKADA Yoshihito for the help with debugging the problem. Reported-by: NTAKADA Yoshihito <takada@mbf.nifty.com> Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
* Don't ask to enable no longer existing config options ("Use DMA by default when available" and "Special UDMA Feature"). * PIIX host driver doesn't support Victory66 chipset. * "ide0=cmd640_vlb" -> "cmd640.probe_vlb" * "ide=doubler" -> "gayle.doubler" * Amiga IDE doubler support is a feature for gayle host driver not a separate host driver. * Remove Andre's mail. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
There is "wdc_udma" module parameter now. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
Add "wdc_udma" module parameter for allowing UDMA transfers on M1543C-E chipset for WDC disks. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
Remove commented out code and stale comment. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
由 Adrian Bunk 提交于
SELECT_MASK() can now become static. [bart: remove space between function name and open parenthesis] Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
由 Maciej W. Rozycki 提交于
Following recent changes to ide_hwif_t update the SWARM IDE driver to use hw_regs_t to initialize port mapping. Plus minor layout adjustments along the lines of other drivers. Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org> Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
由 Dave Young 提交于
because of the class_device was removed, now do the children list removing Signed-off-by: NDave Young <hidave.darkstar@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 David Brownell 提交于
Various fixes to Atmel's high speed UDC driver. * Issue some missing disconnect() calls. Currently they are only made when VBUS power goes away (on boards where the driver can sense such changes), but that's not enough for gadget drivers to clean out all the state that's needed. Missing calls were: - After USB reset, before starting enumeration. - When unregistering a gadget driver, before unbind(). * Don't assume gadget drivers provide disconnect callbacks; make sure to not call through a null pointer! * When the driver doesn't provide an unbind() callback, refuse to unregister it. Also remove two bogus "error" messages: * Related to mis-handling of disconnect() ... don't emit error messages for disconnect() handlers that disable endpoints. All of them should be doing that; the problem is (unfixed) oddness in atmel_usba_udc. * Don't emit a diagnostic for a curious and transient nonfatal error that shows up sometimes with EP0. Those messages spammed syslog, for no good reason. Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Robert Jarzmik 提交于
Minor fixes to pxa27x udc driver : - don't clobber driver model bus_id field - wrong endianess fix (no functional change; cpu is little-endian) - double udc disable fix - resume/suspend fix (OTG hold bit) - make driver pxa27x dependant (check cpu at runtime) Signed-off-by: NRobert Jarzmik <rjarzmik@free.fr> Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Marcin Slusarz 提交于
On Mon, May 12, 2008 at 01:02:22AM -0700, David Brownell wrote: > On Sunday 11 May 2008, Marcin Slusarz wrote: > > > > test_ctrl_queue expects (?) positive and negative errnos. > > what is going on here? > > The sign is just a way to flag something: > > /* some faults are allowed, not required */ > > The negative ones are required. Positive codes are optional, > in the sense that, depending on how the peripheral happens > to be implemented, they won't necessarily be triggered. > > For example, the test to fetch a device qualifier desriptor > must succeed if the device is running at high speed. So that > test is marked as negative. But when it's full speed, it > could legitimately fail; marked as positive. And so on for > other tests. > > Look at how the codes are *interpreted* to see it work. Lets document it. Based on comment from David Brownell <david-b@pacbell.net>. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-