aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts
diff options
context:
space:
mode:
Diffstat (limited to 'tools/perf/scripts')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-02 23:30:49 +0000
g in tty_wait_until_sent. Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30USB: musb_gadget: fix STALL handlingSergei Shtylyov1-45/+34 The driver incorrectly cancels the mass-storage device CSW request (which leads to device reset) due to giving back URB at the head of endpoint's queue after sending each STALL handshake; stop doing that and start checking for the queue being non-empty before stalling an endpoint and disallowing stall in such case in musb_gadget_set_halt() like the other gadget drivers do. Moreover, the driver starts Rx request despite of the endpoint being halted -- fix this by moving the SendStall bit check from musb_g_rx() to rxstate(). And we also sometimes get into rxstate() with DMA still active after clearing an endpoint's halt (not clear why), so bail out in this case, similarly to what txstate() does... While at it, also do the following changes : - in musb_gadget_set_halt(), remove pointless Tx FIFO flushing (the driver does not allow stalling with non-empty Tx FIFO anyway); - in rxstate(), stop pointlessly zeroing the 'csr' variable; - in musb_gadget_set_halt(), move the 'done' label to a more proper place; - in musb_g_rx(), eliminate the 'done' label completely... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30USB: EHCI: don't send Clear-TT-Buffer following a STALLAlan Stern2-3/+15 This patch (as1304) fixes a regression in ehci-hcd. Evidently some hubs don't handle Clear-TT-Buffer requests correctly, so we should avoid sending them when they don't appear to be absolutely necessary. The reported symptom is that output on a downstream audio device cuts out because the hub stops relaying isochronous packets. The patch prevents Clear-TT-Buffer requests from being sent following a STALL handshake. In theory a STALL indicates either that the downstream device sent a STALL or that no matching TT buffer could be found. In either case, the transfer is completed and the TT buffer does not remain busy, so it doesn't need to be cleared. Also, the patch fixes a minor flaw in the code that actually sends the Clear-TT-Buffer requests. Although the pipe direction isn't really used for control transfers, it should be a Send rather than a Receive. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Javier Kohen <jkohen@users.sourceforge.net> CC: David Brownell <david-b@pacbell.net> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30Staging: update TODO filesBartlomiej Zolnierkiewicz4-10/+6 Remove my mail address. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30Staging: hv: Fix some missing author namesHaiyang Zhang5-0/+5 Fix some missing author names. They were accidentally removed by someone within Microsoft before the files were sent for inclusion in the kernel. 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> 2009-11-30Staging: hv: Fix vmbus event handler bugHaiyang Zhang2-13/+5 The flag ENABLE_POLLING is always enabled in original Makefile, but accidently removed during porting to mainline kernel. The patch fixes this bug which can cause stalled network communication. Credit needs to go to Eric Sesterhenn <eric.sesterhenn@lsexperts.de> For pointing out a typo in the original code as well. 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> 2009-11-30Staging: hv: Fix argument order in incorrect memset invocations in hyperv ↵Dave Jones1-5/+5 driver. Nearly every invocation of memset in drivers/staging/hv/StorVsc.c has its arguments the wrong way around. Signed-off-by: Dave Jones <davej@redhat.com> Cc: Hank Janssen <hjanssen@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30tty/of_serial: add missing ns16550a idMichal Simek1-0/+1 Many boards have a bug-free ns16550 compatible serial port, which we should register as PORT_16550A. This introduces a new value "ns16550a" for the compatible property of of_serial to let a firmware choose that model instead of using the crippled PORT_16550 mode. Reported-by: Alon Ziv <alonz@nolaviz.org> Signed-off-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30bcm63xx_uart: Fix serial driver compile breakage.Maxime Bizon1-2/+2 The driver missed a small API change while sitting in Ralf's tree, this patch makes it compile again. Signed-off-by: Maxime Bizon <mbizon@freebox.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-11-30tty_port: handle the nonblocking open of a dead port corner caseAlan Cox1-2/+5 Some drivers allow O_NDELAY of a dead port (eg for setserial to work). In that situation we must not try to raise the carrier. Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2009-12-01powerpc: Fix DEBUG_HIGHMEM build break from d4515646699Becky Bruce1-0/+11 Code was added to mm/higmem.c that depends on several kmap types that powerpc does not support. We add dummy invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE. According to list discussion, this fix should not be needed anymore starting with 2.6.33. The code is commented to this effect so hopefully we will remember to remove this. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2009-11-30jffs2: Fix memory corruption in jffs2_read_inode_range()David Woodhouse1-3/+6 In 2.6.23 kernel, commit a32ea1e1f925399e0d81ca3f7394a44a6dafa12c ("Fix read/truncate race") fixed a race in the generic code, and as a side effect, now do_generic_file_read() can ask us to readpage() past the i_size. This seems to be correctly handled by the block routines (e.g. block_read_full_page() fills the page with zeroes in case if somebody is trying to read past the last inode's block). JFFS2 doesn't handle this; it assumes that it won't be asked to read pages which don't exist -- and thus that there will be at least _one_ valid 'frag' on the page it's being asked to read. It will fill any holes with the following memset: memset(buf, 0, min(end, frag->ofs + frag->size) - offset); When the 'closest smaller match' returned by jffs2_lookup_node_frag() is actually on a previous page and ends before 'offset', that results in: memset(buf, 0, <huge unsigned negative>); Hopefully, in most cases the corruption is fatal, and quickly causing random oopses, like this: root@10.0.0.4:~/ltp-fs-20090531# ./testcases/kernel/fs/ftest/ftest01 Unable to handle kernel paging request for data at address 0x00000008 Faulting instruction address: 0xc01cd980 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c01cd980] rb_insert_color+0x38/0x184 LR [c0043978] enqueue_hrtimer+0x88/0xc4 Call Trace: [c6c63b60] [c004f9a8] tick_sched_timer+0xa0/0xe4 (unreliable) [c6c63b80] [c0043978] enqueue_hrtimer+0x88/0xc4 [c6c63b90] [c0043a48] __run_hrtimer+0x94/0xbc [c6c63bb0] [c0044628] hrtimer_interrupt+0x140/0x2b8 [c6c63c10] [c000f8e8] timer_interrupt+0x13c/0x254 [c6c63c30] [c001352c] ret_from_except+0x0/0x14 --- Exception: 901 at memset+0x38/0x5c LR = jffs2_read_inode_range+0x144/0x17c [c6c63cf0] [00000000] (null) (unreliable) This patch fixes the issue, plus fixes all LTP tests on NAND/UBI with JFFS2 filesystem that were failing since 2.6.23 (seems like the bug above also broke the truncation). Reported-By: Anton Vorontsov <avorontsov@ru.mvista.com> Tested-By: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2009-11-30fbdev: Migrate mailing lists to vgerGeert Uytterhoeven2-18/+16 The fbdev mailing lists at SourceForge have been migrated to a single mailing list at kernel.org: linux-fbdev@vger.kernel.org. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2009-11-30arch/alpha/kernel: Add kmalloc NULL testsJulia Lawall2-0/+4 Check that the result of kmalloc is not NULL before passing it to other functions. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression *x; identifier f; constant char *C; @@ x = \(kmalloc\|kcalloc\|kzalloc\)(...); ... when != x == NULL when != x != NULL when != (x || ...) ( kfree(x) f(...,C,...,x,...) | *f(...,x,...) | *x->f ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Matt Turner <mattst88@gmail.com> 2009-11-30arch/alpha/kernel/sys_ruffian.c: Use DIV_ROUND_CLOSESTJulia Lawall1-1/+1 The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @haskernel@ @@ @depends on haskernel@ expression x,__divisor; @@ - (((x) + ((__divisor) / 2)) / (__divisor)) + DIV_ROUND_CLOSEST(x,__divisor) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Matt Turner <mattst88@gmail.com> 2009-11-30V4L/DVB (13372): staging/go7007: fix mutex function usage for s2250Pete Eberlein1-2/+2 Fix mutex function usage, which was overlooked in a previous patch. Signed-off-by: Pete Eberlein <pete@sensoray.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>