linux-toradex.git/include, branch v2.6.22.9

Fix tc_ematch kbuild

2007-09-26T17:54:43+00:00

commit 09d74cdd88a59a18f2ad7cfa0b6045ed1817b632 in mainline.

Subject: [PATCH] [KBUILD]: Sanitize tc_ematch headers.

The headers in tc_ematch are used by iproute2, so these headers should
be processed.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

PCI: disable MSI on RX790

2007-08-31T06:01:52+00:00

RX790 can't do MSI like its predecessors.  Disable MSI on RX790.

Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

PCI: disable MSI on RD580

2007-08-31T06:01:52+00:00

RD580 can't do MSI like its predecessors.  Disable MSI on RD580.

Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

PCI: disable MSI on RS690

2007-08-31T06:01:52+00:00

RS690 can't do MSI like its predecessors.  Disable MSI on RS690.

Signed-off-by: Tejun Heo 
Cc: Henry Su 
Signed-off-by: Greg Kroah-Hartman

TCP: Do not autobind ports for TCP sockets

2007-08-31T06:01:51+00:00

[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().

As discovered by Evegniy Polyakov, if we try to sendmsg after
a connection reset, we can do incredibly stupid things.

The core issue is that inet_sendmsg() tries to autobind the
socket, but we should never do that for TCP.  Instead we should
just go straight into TCP's sendmsg() code which will do all
of the necessary state and pending socket error checks.

TCP's sendpage already directly vectors to tcp_sendpage(), so this
merely brings sendmsg() in line with that.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Netfilter: Missing Kbuild entry for netfilter

2007-08-31T06:01:50+00:00

Author: Chuck Ebbert 

Add xt_statistic.h to the list of headers to install.

Apparently needed to build newer versions of iptables.

Signed-off-by: Chuck Ebbert 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix soft-fp underflow handling.

2007-08-31T06:01:33+00:00

The underflow exception cases were wrong.

This is one weird area of ieee1754 handling in that the underflow
behavior changes based upon whether underflow is enabled in the trap
enable mask of the FPU control register.  As a specific case the Sparc
V9 manual gives us the following description:

--------------------
If UFM = 0:     Underflow occurs if a nonzero result is tiny and a
                loss of accuracy occurs.  Tininess may be detected
                before or after rounding.  Loss of accuracy may be
                either a denormalization loss or an inexact result.

If UFM = 1:     Underflow occurs if a nonzero result is tiny.
                Tininess may be detected before or after rounding.
--------------------

What this amounts to in the packing case is if we go subnormal,
we set underflow if any of the following are true:

1) rounding sets inexact
2) we ended up rounding back up to normal (this is the case where
   we set the exponent to 1 and set the fraction to zero), this
   should set inexact too
3) underflow is set in FPU control register trap-enable mask

The initially discovered example was "DBL_MIN / 16.0" which
incorrectly generated an underflow.  It should not, unless underflow
is set in the trap-enable mask of the FPU csr.

Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
inexact and underflow.  The cpu implementations and ieee1754
literature is very clear about this.  This is case #2 above.

However, if underflow is set in the trap enable mask, only underflow
should be set and reported as a trap.  That is handled properly by the
prioritization logic in

arch/sparc{,64}/math-emu/math.c:record_exception().

Based upon a report and test case from Jakub Jelinek.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

NET: Share correct feature code between bridging and bonding

2007-08-31T06:01:00+00:00

[NET]: Share correct feature code between bridging and bonding

http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the
bonding driver may produce bogus combinations of the checksum
flags and SG/TSO.

For example, if you bond devices with NETIF_F_HW_CSUM and
NETIF_F_IP_CSUM you'll end up with a bonding device that
has neither flag set.  If both have TSO then this produces
an illegal combination.

The bridge device on the other hand has the correct code to
deal with this.

In fact, the same code can be used for both.  So this patch
moves that logic into net/core/dev.c and uses it for both
bonding and bridging.

In the process I've made small adjustments such as only
setting GSO_ROBUST if at least one constituent device
supports it.

Signed-off-by: Herbert Xu 
Acked-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

AVR32: Fix atomic_add_unless() and atomic_sub_unless()

2007-08-22T23:23:25+00:00

These functions depend on "result" being initalized to 0, but "result"
is not included as an input constraint to the inline assembly block
following its initialization, only as an output constraint. Thus gcc
thinks it doesn't need to initialize it, so result ends up undefined
if the "unless" condition is true.

This fixes an oops in sunrpc where the faulty atomics caused
rpciod_up() to not start the workqueue as it should.

Signed-off-by: Haavard Skinnemoen 
Signed-off-by: Greg Kroah-Hartman

revert "x86, serial: convert legacy COM ports to platform devices"

2007-08-22T23:23:25+00:00

Revert 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26.  It broke Sébastien Dugué's
machine and Jeff said (persuasively)

  This seems like it will break decades-long-working stuff, in favor of
  breaking new ground in our favorite area, "trusting the BIOS."

  It's just not worth it for serial ports, IMO.  Serial ports are something
  that just shouldn't break at this late stage in the game.  My new Intel
  platform boxes don't even have serial ports, so I question the value of
  messing with serial port probing even more...  because...  just wait a year,
  and your box won't have a serial port either!  :)

  I certainly don't object to the use of platform devices (or isa_driver),
  but the probe change seems questionable.  That's sorta analagous to
  rewriting the floppy driver probe routine.  Sure you could do it...  but why
  risk all that damage and go through debugging all over again?

  It seems clear from this report that we cannot, should not, trust BIOS for
  something (a) so simple and (b) that has been working for over a decade.

Much discussion ensued and we've decided to have another go at all of this.

Cc: Sébastien Dugué 
Cc: Bjorn Helgaas 
Cc: Len Brown 
Cc: Adam Belay 
Cc: Matthew Garrett 
Cc: Russell King 
Cc: Jeff Garzik 
Acked-by: Alan Cox 
Cc: Michal Piotrowski 
Cc: Sascha Sommer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman