linux-toradex.git/drivers/char, branch v2.6.31.3

TTY: fix typos

2009-10-07T21:30:44+00:00

commit 1f5c13fad4ec5617b610e12205902c06298c096a upstream.

This patch (as1282) fixes some obvious typos in the TTY core.

Signed-off-by: Alan Stern 
CC: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: USB serial termios bits

2009-10-05T16:32:37+00:00

commit fe1ae7fdd2ee603f2d95f04e09a68f7f79045127 upstream.

Various drivers have hacks to mangle termios structures. This stems from
the fact there is no nice setup hook for configuring the termios settings
when the port is created

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: Add a full port_close function

2009-10-05T16:32:34+00:00

commit 7ca0ff9ab3218ec443a7a9ad247e4650373ed41e upstream.

Now we are extracting out methods for shutdown and the like we can add a
proper tty_port_close method that knows all the innards of the tty closing
process and hides the lot from the caller.

At some point in the future this will be paired with a similar open()
helper and the drivers can stick to hardware management.

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

pty_write: don't do a tty_wakeup() when the buffers are full

2009-10-05T16:32:22+00:00

commit 202c4675c55ddf6b443c7e057d2dff6b42ef71aa upstream.

Commit ac89a9174 ("pty: don't limit the writes to 'pty_space()' inside
'pty_write()'") removed the pty_space() checking, in order to let the
regular tty buffer code limit the buffering itself.

That was all good, but as a subtle side effect it meant that we'd be
doing a tty_wakeup() even in the case where the buffers were all filled
up, and didn't actually make any progress on the write.

Which sounds innocuous, but it interacts very badly with the ppp_async
code, which has an infinite loop in ppp_async_push() that tries to push
out data to the tty.  When we call tty_wakeup(), that loop ends up
thinking that progress was made (see the subtle interactions between
XMIT_WAKEUP and 'tty_stuffed' for details).  End result: one unhappy ppp
user.

Fixed by noticing when tty_insert_flip_string() didn't actually do
anything, and then not doing any more processing (including, very much
not calling tty_wakeup()).

Bisected-and-tested-by: Peter Volkov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

agp/intel: Fix the pre-9xx chipset flush.

2009-10-05T16:32:12+00:00

commit e517a5e97080bbe52857bd0d7df9b66602d53c4d upstream.

Ever since we enabled GEM, the pre-9xx chipsets (particularly 865) have had
serious stability issues.  Back in May a wbinvd was added to the DRM to
work around much of the problem.  Some failure remained -- easily visible
by dragging a window around on an X -retro desktop, or by looking at bugzilla.

The chipset flush was on the right track -- hitting the right amount of
memory, and it appears to be the only way to flush on these chipsets, but the
flush page was mapped uncached.  As a result, the writes trying to clear the
writeback cache ended up bypassing the cache, and not flushing anything!  The
wbinvd would flush out other writeback data and often cause the data we wanted
to get flushed, but not always.  By removing the setting of the page to UC
and instead just clflushing the data we write to try to flush it, we get the
desired behavior with no wbinvd.

This exports clflush_cache_range(), which was laying around and happened to
basically match the code I was otherwise going to copy from the DRM.

Signed-off-by: Eric Anholt 
Signed-off-by: Brice Goglin 
Signed-off-by: Greg Kroah-Hartman

agp/intel: remove restore in resume

2009-09-24T15:43:57+00:00

commit 121264827656f5f06328b17983c796af17dc5949 upstream.

As early pci resume has already restored config for host
bridge and graphics device, don't need to restore it again,
This removes an original order hack for graphics device restore.

This fixed the resume hang issue found by Alan Stern on 845G,
caused by extra config restore on graphics device.

Cc: Alan Stern 
Signed-off-by: Zhenyu Wang 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

TPM: Fixup boot probe timeout for tpm_tis driver

2009-09-24T15:43:52+00:00

commit ec57935837a78f9661125b08a5d08b697568e040 upstream.

When probing the device in tpm_tis_init the call request_locality
uses timeout_a, which wasn't being initalized until after
request_locality. This results in request_locality falsely timing
out if the chip is still starting. Move the initialization to before
request_locality.

This probably only matters for embedded cases (ie mine), a BIOS likely
gets the TPM into a state where this code path isn't necessary.

Signed-off-by: Jason Gunthorpe 
Acked-by: Rajiv Andrade 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

2009-09-07T18:38:30+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
  agp/intel: support for new chip variant of IGDNG mobile
  drm/i915: Unref old_obj on get_fence_reg() error path
  drm/i915: increase default latency constant (v2 w/comment)

pty: don't limit the writes to 'pty_space()' inside 'pty_write()'

2009-09-05T20:27:10+00:00

The whole write-room thing is something that is up to the _caller_ to
worry about, not the pty layer itself.  The total buffer space will
still be limited by the buffering routines themselves, so there is no
advantage or need in having pty_write() artificially limit the size
somehow.

And what happened was that the caller (the n_tty line discipline, in
this case) may have verified that there is room for 2 bytes to be
written (for NL -> CRNL expansion), and it used to then do those writes
as two single-byte writes.  And if the first byte written (CR) then
caused a new tty buffer to be allocated, pty_space() may have returned
zero when trying to write the second byte (LF), and then incorrectly
failed the write - leading to a lost newline character.

This should finally fix

	http://bugzilla.kernel.org/show_bug.cgi?id=14015

Reported-by: Mikael Pettersson 
Acked-by: Alan Cox 
Signed-off-by: Linus Torvalds

n_tty: do O_ONLCR translation as a single write

2009-09-05T19:46:07+00:00

When translating CR to CRNL in the n_tty line discipline, we did it as
two tty_put_char() calls.  Which works, but is stupid, and has caused
problems before too with bad interactions with the write_room() logic.
The generic USB serial driver had that problem, for example.

Now the pty layer had similar issues after being moved to the generic
tty buffering code (in commit d945cb9cce20ac7143c2de8d88b187f62db99bdc:
"pty: Rework the pty layer to use the normal buffering logic").

So stop doing the silly separate two writes, and do it as a single write
instead.  That's what the n_tty layer already does for the space
expansion of tabs (XTABS), and it means that we'll now always have just
a single write for the CRNL to match the single 'tty_write_room()' test,
which hopefully means that the next time somebody screws up buffering,
it won't cause weeks of debugging.

Signed-off-by: Linus Torvalds