linux-yocto-4.4 - Linux 4.4 Embedded Kernel

Age	Commit message (Collapse)	Author
2006-09-29	[PATCH] Fix locking for tty drivers when doing urgent characters	Alan Cox
	If you send a priority character (as is done for flow control) then the tty driver can either have its own method for "jumping the queue" or the characrer can be queued normally. In the latter case we call the write method but without the atomic_write_lock taken elsewhere. Make this consistent. Note that the send_xchar method if implemented remains outside of the lock as it can jump ahead of a current write so must not be locked out by it. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-09-29	[PATCH] tty: make termios_sem a mutex	Arjan van de Ven
	[akpm@osdl.org: fix] Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-08-27	[PATCH] tty layer comment the locking assumptions and functions somewhat	Alan Cox
	Doesn't fix them but does show up some interesting areas that need review and fixing. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28	[PATCH] coverity: tty_ldisc_ref return null check	KAMBAROV, ZAUR
	We add a check of the return value of tty_ldisc_ref(), which is checked 7 out of 8 times, e.g.: 149 ld = tty_ldisc_ref(tty); 150 if (ld != NULL) { 151 if (ld->set_termios) 152 (ld->set_termios)(tty, &old_termios); 153 tty_ldisc_deref(ld); 154 } This defect was found automatically by Coverity Prevent, a static analysis tool. (akpm: presumably `ld' is never NULL. Oh well) Signed-off-by: Zaur Kambarov <zkambarov@coverity.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16	Linux-2.6.12-rc2v2.6.12-rc2	Linus Torvalds
	Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!