- 21 2月, 2009 4 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Intel 8257x Ethernet boards have a feature called Serial Over Lan. This feature works by emulating a serial port, and it is detected by kernel as a normal 8250 port. However, this emulation is not perfect, as also noticed on changeset 7500b1f6. Before this patch, the kernel were trying to check if the serial TX is capable of work using IRQ's. This were done with a code similar this: serial_outp(up, UART_IER, UART_IER_THRI); lsr = serial_in(up, UART_LSR); iir = serial_in(up, UART_IIR); serial_outp(up, UART_IER, 0); if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) up->bugs |= UART_BUG_TXEN; This works fine for other 8250 ports, but, on 8250-emulated SoL port, the chip is a little lazy to down UART_IIR_NO_INT at UART_IIR register. Due to that, UART_BUG_TXEN is sometimes enabled. However, as TX IRQ keeps working, and the TX polling is now enabled, the driver miss-interprets the IRQ received later, hanging up the machine until a key is pressed at the serial console. This is the 6 version of this patch. Previous versions were trying to introduce a large enough delay between serial_outp and serial_in(up, UART_IIR), but not taking forever. However, the needed delay couldn't be safely determined. At the experimental tests, a delay of 1us solves most of the cases, but still hangs sometimes. Increasing the delay to 5us was better, but still doesn't solve. A very high delay of 50 ms seemed to work every time. However, poking around with delays and pray for it to be enough doesn't seem to be a good approach, even for a quirk. So, instead of playing with random large arbitrary delays, let's just disable UART_BUG_TXEN for all SoL ports. [akpm@linux-foundation.org: fix warnings] Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Yang Hongyang 提交于
Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dan Carpenter 提交于
The "break" would just result in reusing a free'd pointer. I don't have the cards myself to test it though. :/ Signed-off-by: NDan Carpenter <error27@gmail.com> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ilpo Järvinen 提交于
Caused by 736d5453 (sx.c: fix missed unlock_kernel() on error path in sx_fw_ioctl()). You guys keep breaking things this way in every single kernel release in at least couple of places... :-( Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi> Acked-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 2月, 2009 26 次提交
-
-
由 etienne 提交于
This fixes a regression reported in bug #12613. [airlied: not I tweaked the patch slightly and fixed it by etienne did all the hardwork so gets authorship] Signed-off-by: Netienne <etienne.basset@numericable.fr> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
This fixes potential fault at fault time if the object was unreferenced while the mapping still existed. Now, while the mmap_offset only lives for the lifetime of the object, the object also stays alive while a vma exists that needs it. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Need to do this in case the unref ends up doing a free. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Kristian Høgsberg 提交于
Lifted from the DDX modesetting. Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Kristian Høgsberg 提交于
They used to be different. Now they're identical. Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Kristian Høgsberg 提交于
Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Kristian Høgsberg 提交于
We need to hold the struct_mutex around pinning and the phys object operations. Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Chris Wilson 提交于
Check the error paths within intel_pipe_set_base() to first cleanup and then report back the error. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
We need to skip the connectors with a NULL encoder to match the success path and avoid an OOPS. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
If we fail to create the ringbuffer, then we need to cleanup the allocated hws. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Steve Aarnio 提交于
In the case where no EDID data is read from the device, adding the panel_fixed_mode pointer to the probed modes list causes data corruption. If the panel_fixed_mode pointer is added to the probed modes list at init time, a copy of the mode is added again at drm_get_modes() request time. Then, the panel_fixed_mode pointer is freed because it is seen as a duplicate mode. Unfortunately, this pointer is still stored and used in mode_fixup(). Because the panel_fixed_mode data is copied and returned at drm_get_modes() time, it is unnecessary to add this information at init time. Signed-off-by: NSteve Aarnio <steve.j.aarnio@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Kristian Høgsberg 提交于
Avoids leaking fbs and associated buffers on release. Signed-off-by: NKristian Høgsberg <krh@redhat.com> Tested-by: NTested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
If we fail whilst constructing the fb, then we need to unpin it as well. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
A missing unpin on the error path. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
A missing unpin on the error path. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
A missing unreference and unpin after rejecting the relocation for an invalid memory domain. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
We failed to unlock the mutex after failing to create the mmap offset. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
Set the request alignment to 0, and leave it up to i915_gem_object_pin() to set the appropriate alignment to match the fence covering the object. Eric Anholt mentioned that the pinning code is meant to choose the maximum of the request alignment and that of the fence covering the object... However currently, the pinning code will only apply the fence constraints if the supplied alignment is 0. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
The name table should only hold a single reference, so avoid leaking additional references for secondary calls to flink(). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Roland Dreier 提交于
Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open() (which is called with mmap_sem already held) takes dev->struct_mutex. So this is a potential AB-BA deadlock. The way that i915_gem_execbuffer() triggers a page fault is by doing copy_to_user() when returning new buffer offsets back to userspace; however there is no reason to hold the struct_mutex when doing this copy, since what is being copied is the contents of an array private to i915_gem_execbuffer() anyway. So we can fix the potential deadlock (and get rid of the lockdep warning) by simply moving the copy_to_user() outside of where struct_mutex is held. This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>. Reported-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: NRoland Dreier <rolandd@cisco.com> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
A missing unreference if the user calls pin() a second time on a pinned buffer. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
Also spotted by Owain Ainsworth. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
Ensure that the object is unreferenced if we fail to allocate during drm_gem_flink_ioctl(). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Chris Wilson 提交于
Remove the member from the hash table before we free the structure! Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
由 Tobias Klauser 提交于
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 19 2月, 2009 10 次提交
-
-
由 Heiko Carstens 提交于
Standby memory detected with the sclp interface gets always registered with add_memory calls without considering the limitationt that the "mem=" kernel paramater implies. So fix this and only register standby memory that is below the specified limit. This fixes zfcpdump since it uses "mem=32M". In case there is appr. 2GB standby memory present all of usable memory would be used for the struct pages needed for standby memory. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Peter Oberparleiter 提交于
Handle a malformed hardware response which some versions of the Support Element (SE) may present during SE restart and which otherwise would result in an endless loop in function sclp_dispatch_evbufs. Signed-off-by: NPeter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Roel Kluin 提交于
*ep->reg_udccs is always set to 0. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NEric Miao <eric.miao@marvell.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Michael Buesch 提交于
gpio_get_value() returns 0 or nonzero, but getmiso() expects 0 or 1. Sanitize the value to a 0/1 boolean. Signed-off-by: NMichael Buesch <mb@bu3sch.de> Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Bernhard Walle 提交于
Since I don't work for SUSE any more and the bwalle@suse.de address is invalid, correct it in the copyright headers and documentation. Signed-off-by: NBernhard Walle <bernhard.walle@gmx.de> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Randy Dunlap 提交于
Build breaks when DELL_LAPTOP=y and POWER_SUPPLY=m. DELL_LAPTOP needs to depend on POWER_SUPPLY. dell-laptop.c:(.text+0x1ef3c4): undefined reference to `power_supply_is_system_supplied' dell-laptop.c:(.text+0x1ef45e): undefined reference to `power_supply_is_system_supplied' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Krzysztof Helt 提交于
Submenus of the graphics support "Support for frame buffer devices" and "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" are broken in half after latest changes for Intel 915 mode setting support. The DRM subsection is broken because one option is put outside the choice section it depends on. The frame buffers part is broken then due to circular dependency. Fix this by make Intel frame buffers depend on CONFIG_INTEL_AGP. Kconfigs are broken by d2f59357 ("drm/i915: select framebuffer support automatically"). This is probably not only way to fix this. Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl> Cc: Ingo Molnar <mingo@elte.hu> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Philippe De Muyter 提交于
The floppy driver requests an I/O port it doesn't need, and sometimes this causes a conflict with a motherboard device reported by PNPBIOS. This patch makes the floppy driver request and release only the ports it actually uses. It also factors out the request/release stuff and the io-ports list so they're all in one place now. The current floppy driver uses only these ports: 0x3f2 (FD_DOR) 0x3f4 (FD_STATUS) 0x3f5 (FD_DATA) 0x3f7 (FD_DCR/FD_DIR) but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port 0x3f3. Some BIOSes report 0x3f3 as a motherboard resource. The PNP system driver reserves that, which causes a conflict when the floppy driver requests 0x3f2-0x3f5 later. Philippe reported that this conflict broke the floppy driver between 2.6.11 and 2.6.22. His PNPBIOS reports these devices: $ cat 00:07/id 00:07/resources # motherboard device PNP0c02 state = active io 0x80-0x80 io 0x10-0x1f io 0x22-0x3f io 0x44-0x5f io 0x90-0x9f io 0xa2-0xbf io 0x3f0-0x3f1 io 0x3f3-0x3f3 $ cat 00:03/id 00:03/resources # floppy device PNP0700 state = active io 0x3f4-0x3f5 io 0x3f2-0x3f2 Reference: http://lkml.org/lkml/2009/1/31/162Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NPhilippe De Muyter <phdm@macqel.be> Reported-by: NPhilippe De Muyter <phdm@macqel.be> Tested-by: NPhilippe De Muyter <phdm@macqel.be> Cc: Adam M Belay <abelay@mit.edu> Cc: Robert Hancock <hancockrwd@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Adam Lackorzynski 提交于
I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi International Digi Neo 8 (rev 05) that works with the jsm driver after using the following patch. Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de> Cc: Scott H Kilau <Scott_Kilau@digi.com> Cc: Wendy Xiong <wendyx@us.ibm.com> Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Atsushi Nemoto 提交于
I found a problem of handling of modem status of atmel_serial driver. With the commit 1ecc26 ("atmel_serial: split the interrupt handler"), handling of modem status signal was splitted into two parts. The atmel_tasklet_func() compares new status with irq_status_prev, but irq_status_prev is not correct if signal status was changed while the port is closed. Here is a sequence to cause problem: 1. Remote side sets CTS (and DSR). 2. Local side close the port. 3. Local side clears RTS and DTR. 4. Remote side clears CTS and DSR. 5. Local side reopen the port. hw_stopped becomes 1. 6. Local side sets RTS and DTR. 7. Remote side sets CTS and DSR. Then CTS change interrupt can be received, but since CTS bit in irq_status_prev and new status is same, uart_handle_cts_change() will not be called (so hw_stopped will not be cleared, i.e. cannot send any data). I suppose irq_status_prev should be initialized at somewhere in open sequence. Itai Levi pointed out that we need to initialize atmel_port->irq_status as well here. His analysis is as follows: > Regarding the second part of the patch (which resets irq_status_prev), > it turns out that both versions of the patch (mine and Atsushi's) > still leave enough room for faulty behavior when opening the port. > > This is because we are not resetting both irq_status_prev and > irq_status in atmel_startup() to CSR, which leads faulty behavior in > the following sequences: > > First case: > 1. closing the port while CTS line = 1 (TX not allowed) > 2. setting CTS line = 0 (TX allowed) > 3. opening the port > 4. transmitting one char > 5. Cannot transmit more chars, although CTS line is 0 > > Second case: > 1. closing the port while CTS line = 0 (TX allowed) > 2. setting CTS line = 1 (TX not allowed) > 3. opening the port > 4. receiving some chars > 5. Now we can transmit, although CTS line is 1 > > This reason for this is that the tasklet is scheduled as a result of > TX or RX interrupts (not a status change!), in steps 4 above. Inside > the tasklet, the atmel_port->irq_status (which holds the value from > the previous session) is compared to atmel_port->irq_status_prev. > Hence, a status-change of the CTS line is faultily detected. > > Both cases were verified on 9260 hardware. [haavard.skinnemoen@atmel.com: folded with patch from Itai Levi] Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com> Cc: Remy Bohmer <linux@bohmer.net> Cc: Marc Pignat <marc.pignat@hevs.ch> Cc: Itai Levi <itai.levi.devel@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-