linux-toradex.git/drivers, branch v2.6.22.15

libata: kill spurious NCQ completion detection

2007-12-14T18:32:01+00:00

patch 459ad68893a84fb0881e57919340b97edbbc3dc7 in mainline.

Spurious NCQ completion detection implemented in ahci was incorrect.
On AHCI receving and processing FISes and raising interrupts are not
interlocked and spurious interrupts are expected.

For example, if an interrupt occurs while interrupt handler is running
and the running interrupt handler handles the event the new IRQ
indicated, after IRQ handler finishes, it will be executed again
because IRQ pending bit is set by the new interrupt but there won't be
anything to process.

Please read the following message for more information.

  http://article.gmane.org/gmane.linux.ide/26012

This patch...

* Removes all spurious IRQ whining from ahci.  Spurious NCQ completion
  detection was completely wrong.  Spurious D2H Register FIS taught us
  that some early drives send spurious D2H Register FIS with I bit set
  while NCQ commands are in progress but none of recent drives does
  that and even the ones which show such behavior can do NCQ fine.

* Kills all NCQ blacklist entries which were added because of spurious
  NCQ completions.  I tracked down each commit and verified all
  removed ones are actually added because of spurious completions.

  WD740ADFD-00NLR1 wasn't deleted but moved upward because the drive
  not only had spurious NCQ completions but also is slow on sequential
  data transfers if NCQ is enabled.

  Maxtor 7V300F0 was added by 0e3dbc01d53940fe10e5a5cfec15ede3e929c918
  from Alan Cox.  I can only find evidences that the drive only had
  troubles with spuruious completions by searching the mailing list.
  This entry needs to be verified and removed if it doesn't have other
  NCQ related problems.

Signed-off-by: Tejun Heo 
Cc: Alan Cox 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

ATM: [he] initialize lock and tasklet earlier

2007-12-14T18:31:59+00:00

[ATM]: [he] initialize lock and tasklet earlier

[ Upstream commit: 8a8037ac9dbe4eb20ce50aa20244faf77444f4a3 ]

if you are lucky (unlucky?) enough to have shared interrupts, the
interrupt handler can be called before the tasklet and lock are ready
for use.

Signed-off-by: chas williams 
Signed-off-by: Herbert Xu 
Cc: David Miller 
Signed-off-by: Greg Kroah-Hartman

fb_ddc: fix DDC lines quirk

2007-12-14T18:31:57+00:00

patch b64d70825abbf706bbe80be1b11b09514b71f45e in mainline.

The code in fb_ddc_read() is said to be based on the implementation of the
radeon driver:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc5891c8a3ba284f13994d7bc1f1bfa8283982de

However, comparing the old radeon driver code with the new fb_ddc code
reveals some differences.  Most notably, the I2C bus lines are held at the
end of the function, while the original code was releasing them (as the
comment above correctly says.)

There are a few other differences, which appear to be responsible for read
failures on my system.  While tracing low-level I2C code in i2c-algo-bit, I
noticed that the initial attempt to read the EDID always failed.  It takes
one retry for the read to succeed.  As we are about to remove this
automatic retry property from i2c-algo-bit, reading the EDID would really
fail.

As a summary, the I2C lines quirk which is supposedly needed to read EDID
on some older monitors is currently breaking the (first) read on all other
monitors (and might not even work with older ones - did anyone try since
October 2006?)

After applying the patch below, which makes the code in fb_ddc_read()
really similar to what the radeon driver used to have, the first EDID read
succeeds again.

On top of that, as it appears that this code has been broken for one year
now and nobody seems to have complained, I'm curious if it makes sense to
keep this quirk in place.  It makes the code more complex and slower just
for the sake of monitors which I guess nobody uses anymore.  Can't we just
get rid of it?

Signed-off-by: Jean Delvare 
Acked-by: Benjamin Herrenschmidt 
Tested-by: Roger Leigh 
Tested-by: Michael Buesch 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

forcedeth boot delay fix

2007-12-14T18:31:57+00:00

patch 9e555930bd873d238f5f7b9d76d3bf31e6e3ce93 in mainline.

Fix a long boot delay in the forcedeth driver.  During initialization, the
timeout for the handshake between mgmt unit and driver can be very long.
The patch reduces the timeout by eliminating a extra loop around the
timeout logic.

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

Signed-off-by: Ayaz Abdulla 
Cc: Alex Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

forcedeth: new mcp79 pci ids

2007-12-14T18:31:57+00:00

patch 490dde8990c55662596a4be71b5070bd7d382d4a in mainline.

This patch adds new device ids and features for mcp79 devices into the
forcedeth driver.

Signed-off-by: Ayaz Abdulla 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman 

index 92ce2e3..f9ba0ac 100644

I4L: fix isdn_ioctl memory overrun vulnerability

2007-12-14T18:31:56+00:00

patch eafe1aa37e6ec2d56f14732b5240c4dd09f0613a in mainline.

Fix possible memory overrun issue in the isdn ioctl code.  Found by ADLAB


Signed-off-by: Karsten Keil 
Cc: ADLAB 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

isdn: avoid copying overly-long strings

2007-12-14T18:31:56+00:00

patch 0f13864e5b24d9cbe18d125d41bfa4b726a82e40 in mainline.

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

Signed-off-by: Karsten Keil 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

USB: fix up EHCI startup synchronization

2007-12-14T18:31:55+00:00

patch 1cb52658b4f5b10a9e91f8e1c21ca2bcc1b9a3ca in mainline.

A recent patch added software synchronization during EHCI startup,
so ports aren't switched away from the companion controllers after
resets have started.  This patch adds a short delay letting hardware
finish that port switching before any new resets begin ... so both
ends of that hardware race window are closed.

Signed-off-by: David Brownell 
Cc: Dave Miller 
Cc: Dely Sy 
Cc: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: make the microtek driver and HAL cooperate

2007-12-14T18:31:55+00:00

patch 5cf1973a44bd298e3cfce6f6af8faa8c9d0a6d55 in mainline

to make HAL like the microtek driver's devices the parent must be
correctly set.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

Future of Linux 2.6.22.y series

2007-12-14T18:31:54+00:00

commit 5d0360ee96a5ef953dbea45873c2a8c87e77d59b upstream.

We have seen ramdisk based install systems, where some pages of mapped
libraries and programs were suddendly zeroed under memory pressure. This
should not happen, as the ramdisk avoids freeing its pages by keeping
them dirty all the time.

It turns out that there is a case, where the VM makes a ramdisk page
clean, without telling the ramdisk driver.  On memory pressure
shrink_zone runs and it starts to run shrink_active_list.  There is a
check for buffer_heads_over_limit, and if true, pagevec_strip is called.
pagevec_strip calls try_to_release_page. If the mapping has no
releasepage callback, try_to_free_buffers is called. try_to_free_buffers
has now a special logic for some file systems to make a dirty page
clean, if all buffers are clean. Thats what happened in our test case.

The simplest solution is to provide a noop-releasepage callback for the
ramdisk driver. This avoids try_to_free_buffers for ramdisk pages.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Jan Kara 
Acked-by: Nick Piggin 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman