linux/drivers/char, branch mybooklive

gpl-source-mybooklive-010203-update.zip

2014-08-13T21:29:15Z

gpl-source-mybooklive-010002-update.zip

2014-08-13T21:14:13Z

tty: Keep the default buffering to sub-page units

2010-04-01T22:58:30Z

commit d9661adfb8e53a7647360140af3b92284cbe52d4 upstream. We allocate during interrupts so while our buffering is normally diced up small anyway on some hardware at speed we can pressure the VM excessively for page pairs. We don't really need big buffers to be linear so don't try so hard. In order to make this work well we will tidy up excess callers to request_room, which cannot itself enforce this break up. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

tty: Fix the ldisc hangup race

2010-03-15T15:49:54Z

commit 638b9648ab51c9c549ff5735d3de519ef6199df3 upstream. This was noticed by Matthias Urlichs and he proposed a fix. This patch does the fixing a different way to avoid introducing several new race conditions into the code. The problem case is TTY_DRIVER_RESET_TERMIOS = 0. In that case while we abort the ldisc change, the hangup processing has not cleaned up and restarted the ldisc either. We can't restart the ldisc stuff in the set_ldisc as we don't know what the hangup did and may touch stuff we shouldn't as we are no longer supposed to influence the tty at that point in case it has been re-opened before we get rescheduled. Instead do it the simple way. Always re-init the ldisc on the hangup, but use TTY_DRIVER_RESET_TERMIOS to indicate that we should force N_TTY. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

tpm_tis: TPM_STS_DATA_EXPECT workaround

2010-03-15T15:49:42Z

commit 3507d612366a4e81226295f646410130a1f62a5c upstream. Some newer Lenovo models are shipped with a TPM that doesn't seem to set the TPM_STS_DATA_EXPECT status bit when sending it a burst of data, so the code understands it as a failure and doesn't proceed sending the chip the intended data. In this patch we bypass this bit check in case the itpm module parameter was set. This patch is based on Andy Isaacson's one: http://marc.info/?l=linux-kernel&m=124650185023495&w=2 It was heavily discussed how should we deal with identifying the chip in kernel space, but the required patch to do so was NACK'd: http://marc.info/?l=linux-kernel&m=124650186423711&w=2 This way we let the user choose using this workaround or not based on his observations on this code behavior when trying to use the TPM. Fixed a checkpatch issue present on the previous patch, thanks to Daniel Walker. Signed-off-by: Rajiv Andrade Acked-by: Eric Paris Tested-by: Seiji Munetoh Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

devmem: fix kmem write bug on memory holes

2010-02-23T15:37:54Z

commit c85e9a97c4102ce2e83112da850d838cfab5ab13 upstream devmem: fix kmem write bug on memory holes [ cebbert@redhat.com : backport to 2.6.32 ] write_kmem() used to assume vwrite() always return the full buffer length. However now vwrite() could return 0 to indicate memory hole. This creates a bug that "buf" is not advanced accordingly. Fix it to simply ignore the return value, hence the memory hole. Signed-off-by: Wu Fengguang Cc: Andi Kleen Cc: Benjamin Herrenschmidt Cc: Christoph Lameter Cc: Ingo Molnar Cc: Tejun Heo Cc: Nick Piggin Cc: KAMEZAWA Hiroyuki Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

devmem: check vmalloc address on kmem read/write

2010-02-23T15:37:54Z

commit 325fda71d0badc1073dc59f12a948f24ff05796a [ cebbert@redhat.com : backport to 2.6.32 ] devmem: check vmalloc address on kmem read/write Otherwise vmalloc_to_page() will BUG(). This also makes the kmem read/write implementation aligned with mem(4): "References to nonexistent locations cause errors to be returned." Here we return -ENXIO (inspired by Hugh) if no bytes have been transfered to/from user space, otherwise return partial read/write results. Signed-off-by: KAMEZAWA Hiroyuki Signed-off-by: Wu Fengguang Cc: Greg Kroah-Hartman Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

/dev/mem: introduce size_inside_page()

2010-02-23T15:37:54Z

commit f222318e9c3a315723e3524fb9d6566b2430db44 upstream /dev/mem: introduce size_inside_page() [ cebbert@redhat.com : backport to 2.6.32 ] [ subset of original patch, for just /dev/kmem ] Introduce size_inside_page() to replace duplicate /dev/mem code. Also apply it to /dev/kmem, whose alignment logic was buggy. Signed-off-by: Wu Fengguang Acked-by: Andi Kleen Cc: Marcelo Tosatti Cc: Greg Kroah-Hartman Cc: Mark Brown Cc: Johannes Berg Cc: Avi Kivity Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

tpm_infineon: fix suspend/resume handler for pnp_driver

2010-02-23T15:37:52Z

commit 93716b9470fbfd9efdc7d0f2445cb34635de3f6d upstream. When suspending, tpm_infineon calls the generic suspend function of the TPM framework. However, the TPM framework does not return and the system hangs upon suspend. When sending the necessary command "TPM_SaveState" directly within the driver, suspending and resuming works fine. Signed-off-by: Marcel Selhorst Cc: OGAWA Hirofumi Cc: Debora Velarde Cc: Rajiv Andrade Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Fix race in tty_fasync() properly

2010-02-23T15:37:44Z

commit 80e1e823989ec44d8e35bdfddadbddcffec90424 upstream. This reverts commit 703625118069 ("tty: fix race in tty_fasync") and commit b04da8bfdfbb ("fnctl: f_modown should call write_lock_irqsave/ restore") that tried to fix up some of the fallout but was incomplete. It turns out that we really cannot hold 'tty->ctrl_lock' over calling __f_setown, because not only did that cause problems with interrupt disables (which the second commit fixed), it also causes a potential ABBA deadlock due to lock ordering. Thanks to Tetsuo Handa for following up on the issue, and running lockdep to show the problem. It goes roughly like this: - f_getown gets filp->f_owner.lock for reading without interrupts disabled, so an interrupt that happens while that lock is held can cause a lockdep chain from f_owner.lock -> sighand->siglock. - at the same time, the tty->ctrl_lock -> f_owner.lock chain that commit 703625118069 introduced, together with the pre-existing sighand->siglock -> tty->ctrl_lock chain means that we have a lock dependency the other way too. So instead of extending tty->ctrl_lock over the whole __f_setown() call, we now just take a reference to the 'pid' structure while holding the lock, and then release it after having done the __f_setown. That still guarantees that 'struct pid' won't go away from under us, which is all we really ever needed. Reported-and-tested-by: Tetsuo Handa Acked-by: Greg Kroah-Hartman Acked-by: Américo Wang Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman