Make sure we do not try to parse a structure we do not
understand.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Now that we use "normal" error codes, improve the reporting and response
to error codes in the core.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Convert the MMC layer to use standard error codes and not its own,
incompatible values.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

In a desparate attempt to fix the suspend/resume problem on Andrews
VAIO I added a workaround which enforced the broadcast of the oneshot
timer on resume. This was actually resolving the problem on the VAIO
but was just a stupid workaround, which was not tackling the root
cause: the assignement of lower idle C-States in the ACPI processor_idle
code. The cpuidle patches, which utilize the dynamic tick feature and
go faster into deeper C-states exposed the problem again. The correct
solution is the previous patch, which prevents lower C-states across
the suspend/resume.

Remove the enforcement code, including the conditional broadcast timer
arming, which helped to pamper over the real problem for quite a time.
The oneshot broadcast flag for the cpu, which runs the resume code can
never be set at the time when this code is executed. It only gets set,
when the CPU is entering a lower idle C-State.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

device_suspend() calls ACPI suspend functions, which seems to have undesired
side effects on lower idle C-states. It took me some time to realize that
especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
show this effect. I'm quite sure that other bug reports against suspend/resume
about turning the system into a brick have the same root cause.

After fishing in the dark for quite some time, I realized that removing the ACPI
processor module before suspend (this removes the lower C-state functionality)
made the problem disappear. Interestingly enough the propability of having a
bricked box is influenced by various factors (interrupts, size of the ram image,
...). Even adding a bunch of printks in the wrong places made the problem go
away. The previous periodic tick implementation simply pampered over the
problem, which explains why the dyntick / clockevents changes made this more
prominent.

We avoid complex functionality during the boot process and we have to do the
same during suspend/resume. It is a similar scenario and equaly fragile.

Add suspend / resume functions to the ACPI processor code and disable the lower
idle C-states across suspend/resume. Fall back to the default idle
implementation (halt) instead.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  ACPI: suspend: consolidate handling of Sx states addendum
  ACPI: suspend: consolidate handling of Sx states.
  ACPI: video: remove dmesg spam
  ACPI: video: _DOS=0 by default to prevent hotkey hang

* 'for-linus' of git://oss.sgi.com:8090/xfs/xfs-2.6:
  [XFS] fix valid but harmless sparse warning
  [XFS] fix filestreams on 32-bit boxes

What guest drivers?

Cc: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: NAvi Kivity <avi@qumranet.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make the S0 state be always reported as supported

Signed-off: Frans Pop <elendil@planet.nl>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

* master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] 4569/1: ep93xx_gpio_irq_type(): fix spurious enumeration offset for FGPIO handling
  [ARM] 4568/1: fix l2x0 cache invalidate handling of unaligned addresses

This reverts commit 34feb2c8.

Suresh Siddha points out that this one breaks the fundamental
requirement that you cannot free page table pages before the TLB caches
are flushed.  The quicklists do not give the same kinds of guarantees
that the mmu_gather structure does, at least not in NUMA configurations.
Requested-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: NAndi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] BCM1480: include <linux/init.h>.
  [MIPS] BCM1480: Export zbbus_mhz.

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Symbol is required by the ZBus profiler.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2:
  ocfs2: Pack vote message and response structures
  ocfs2: Don't double set write parameters
  ocfs2: Fix pos/len passed to ocfs2_write_cluster
  ocfs2: Allow smaller allocations during large writes

Strictly it's only needed for eax.

It actually does a little more than strictly needed -- the other registers
are already zero extended.

Also remove the now unnecessary and non functional compat task check
in ptrace.

This is CVE-2007-4573

Found by Wojciech Purczynski
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Recent changes to sleep initialization in ACPI dropped reporting of supported Sx
states above S3. Fix that and also move S5 init into same file as other Sx.
The only functional change is adding printk() for S4 and S5 cases.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

The ocfs2_vote_msg and ocfs2_response_msg structs needed to be
packed to ensure similar sizeofs in 32-bit and 64-bit arches. Without this,
we had inadvertantly broken 32/64 bit cross mounts.
Signed-off-by: NSunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>

The target page offsets were being incorrectly set a second time in
ocfs2_prepare_page_for_write(), which was causing problems on a 16k page
size kernel. Additionally, ocfs2_write_failure() was incorrectly using those
parameters instead of the parameters for the individual page being cleaned
up.
Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>

This was broken for file systems whose cluster size is greater than page
size. Pos needs to be incremented as we loop through the descriptors, and
len needs to be capped to the size of a single cluster.
Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>

The ocfs2 write code loops through a page much like the block code, except
that ocfs2 allocation units can be any size, including larger than page
size. Typically it's equal to or larger than page size - most kernels run 4k
pages, the minimum ocfs2 allocation (cluster) size.

Some changes introduced during 2.6.23 changed the way writes to pages are
handled, and inadvertantly broke support for > 4k page size. Instead of just
writing one cluster at a time, we now handle the whole page in one pass.

This means that multiple (small) seperate allocations might happen in the
same pass. The allocation code howver typically optimizes by getting the
maximum which was reserved. This triggered a BUG_ON in the extend code where
it'd ask for a single bit (for one part of a > 4k page) and get back more
than it asked for.

Fix this by providing a variant of the high level allocation function which
allows the caller to specify a maximum. The traditional function remains and
just calls the new one with a maximum determined from the initial
reservation.
Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  [libata] ahci: add ATI SB800 PCI IDs
  libata-sff: Fix documentation
  libata: Update the blacklist with a few more devices

This simplifies signalfd code, by avoiding it to remain attached to the
sighand during its lifetime.

In this way, the signalfd remain attached to the sighand only during
poll(2) (and select and epoll) and read(2).  This also allows to remove
all the custom "tsk == current" checks in kernel/signal.c, since
dequeue_signal() will only be called by "current".

I think this is also what Ben was suggesting time ago.

The external effect of this, is that a thread can extract only its own
private signals and the group ones.  I think this is an acceptable
behaviour, in that those are the signals the thread would be able to
fetch w/out signalfd.
Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since
then we get the message

lockd: too many open TCP sockets, consider increasing the number of nfsd threads
lockd: last TCP connect from ^\\236^\É^D

These random characters in the second line are caused by a bug in
svc_tcp_accept.

(Note: there are two previous __svc_print_addr(sin, buf, sizeof(buf))
calls in this function, either of which would initialize buf correctly;
but both are inside "if"'s and are not necessarily executed.  This is
less obvious in the second case, which is inside a dprintk(), which is a
macro which expands to an if statement.)
Signed-off-by: NWolfgang Walter <wolfgang.walter@studentenwerk.mhn.de>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ATI/AMD SB800 shares some device IDs with SB700,
and SB800 adds two more device IDs:0x4394,0x4395.
Signed-off-by: Nhenry su <henry.su.ati@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Code moved to ioread/iowrite but the comment didn't
Also note a posting issue
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [BNX2]: Add PHY workaround for 5709 A1.
  [PPP] L2TP: Fix skb handling in pppol2tp_xmit
  [PPP] L2TP: Fix skb handling in pppol2tp_recv_core
  [PPP] L2TP: Disallow non-UDP datagram sockets
  [PPP] pppoe: Fix double-free on skb after transmit failure
  [PKT_SCHED]: Fix 'SFQ qdisc crashes with limit of 2 packets'
  [NETFILTER]: MAINTAINERS update
  [NETFILTER]: nfnetlink_log: fix sending of multipart messages

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
  sky2: version 1.18
  sky2: receive FIFO checking
  sky2: fe+ chip support
  sky2: reorganize chip revision features
  sky2: ethtool speed report bug
  sky2: fix VLAN receive processing (resend)
  phy: export phy_mii_ioctl
  myri10ge: Add support for PCI device id 9

Update version number
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

A driver writer from another operating system hinted that
the versions of Yukon 2 chip with rambuffer (EC and XL) have
a hardware bug that if the FIFO ever gets completely full it
will hang. Sounds like a classic ring full vs ring empty wrap around
bug.

As a workaround, use the existing watchdog timer to check for
ring full lockup.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Add support for newest Marvell chips.
The Yukon FE plus chip is found in some not yet released laptops.
Tested on hardware evaluation boards.

This version of the patch is for 2.6.23. It supersedes
the two previous patches that are sitting in netdev-2.6 (upstream branch).
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This patch should cause no functional changes in driver behaviour.
There are (too) many revisions of the Yukon 2 chip now. Instead of
adding more conditionals based on chip revision; rerganize into a
set of feature flags so adding new versions is less problematic.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

On 100mbit versions, the driver always reports gigabit speed
available. The correct modes are already computed, then overwritten.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Signed-off-by: NPierre-Yves Ritschard <pyr@spootnik.org>
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Initialization of ohci1394 was broken according to one reporter if the
driver was statically linked, i.e. not built as loadable module.  Dmesg:

  PCI: Device 0000:02:07.0 not available because of resource collisions
  ohci1394: Failed to enable OHCI hardware.

This was reported for a Toshiba Satellite 5100-503.  The cause is commit
8df4083c in Linux 2.6.19-rc1 which only
served purposes of early remote debugging via FireWire.  This
functionality is better provided by the currently out-of-tree driver
ohci1394_earlyinit.  Reversal of the commit was OK'd by Andi Kleen.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Add the DIS_EARLY_DAC PHY workaround for 5709 A1.  Without it, link
sometimes does not come up.

Update version to 1.6.5.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch makes pppol2tp_xmit call skb_cow_head so that we don't modify
cloned skb data.  It also gets rid of skb2 we only need to preserve the
original skb for congestion notification, which is only applicable for
ppp_async and ppp_sync.

The other semantic change made here is the removal of socket accounting
for data tranmitted out of pppol2tp_xmit.  The original code leaked any
existing socket skb accounting.  We could fix this by dropping the
original skb owner.  However, this is undesirable as the packet has not
physically left the host yet.

In fact, all other tunnels in the kernel do not account skb's passing
through to their own socket.  In partciular, ESP over UDP does not do
so and it is the closest tunnel type to PPPoL2TP.  So this patch simply
removes the socket accounting in pppol2tp_xmit.  The accounting still
applies to control packets of course.

I've also added a reminder that the outgoing checksum here doesn't work.
I suppose existing deployments don't actually enable checksums.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>