If BIOS invokes _OSI(Linux), the kernel response
depends on what the ACPI DMI list knows about the system,
and that is reflectd in dmesg:

1) System unknown to DMI:

ACPI: BIOS _OSI(Linux) query ignored
ACPI: DMI System Vendor: LENOVO
ACPI: DMI Product Name: 7661W1P
ACPI: DMI Product Version: ThinkPad T61
ACPI: DMI Board Name: 7661W1P
ACPI: DMI BIOS Vendor: LENOVO
ACPI: DMI BIOS Date: 10/18/2007
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org

2) System known to DMI, but effect of OSI(Linux) unknown:

ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org

3) System known to DMI, which disables _OSI(Linux):

ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI

4) System known to DMI, which enable _OSI(Linux):

ACPI: DMI detected: Lenovo ThinkPad T61
ACPI: Added _OSI(Linux)
...
ACPI: BIOS _OSI(Linux) query honored via DMI

cmdline overrides take precidence over the built-in
default and the DMI prescribed default.
cmdline "acpi_osi=Linux" results in:

ACPI: BIOS _OSI(Linux) query honored via cmdline
Signed-off-by: NLen Brown <len.brown@intel.com>

Linux does not want BIOS writers to invoke _OSI(Linux) -
for in the field it causes more Windows incompatibility problems
than it solves.

So when it is seen in the BIOS for an Intel Customer Reference Board,
Linux should ignore its effect by default, and should complain loudly.
Otherwise, the reference BIOS will go unfixed, and the bad BIOS
will spread to the field.

Users of this board can get the old behavior with "acpi_osi=Linux"

As this was the only entry, delete acpi_osl_dmi_table[].
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

A utility routine to print common entries used
for ACPI-related DMI blacklist entries.
Signed-off-by: NLen Brown <len.brown@intel.com>

This simply allows other sub-systems (such as ACPI)
to access and print out slots in static dmi_ident[].
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Fix typo in arch/powerpc/boot/flatdevtree_env.h.
There is no Documentation/networking/ixgbe.txt.

README.cycladesZ is now in Documentation/.
wavelan.p.h is now in drivers/net/wireless/.
HFS.txt is now Documentation/filesystems/hfs.txt.
OSS-files are now in sound/oss/.
Signed-off-by: NJohann Felix Soden <johfel@users.sourceforge.net>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The extra rom[0] check is flagging valid temperatures as invalid when
there is already a CRC data transmission check.

w1_therm_read_bin()
	if (rom[8] == crc && rom[0])
		verdict = 1;

Requiring rom[0] to be non-zero will flag as invalid temperature
conversions when the low byte is zero, specifically the temperatures 0C,
16C, 32C, 48C, -16C, -32C, and -48C.

The CRC check is produced on the device for the previous 8 bytes and is
required to ensure the data integrity in transmission.  I don't see why the
extra check for rom[0] being non-zero is in there.  Evgeniy Polyakov didn't
know either.  Just for a check I unplugged the sensor, executed a
temperature conversion, and read the results.  The read was all ff's, which
also failed the CRC, so it doesn't need to protect against a disconnected
sensor.

I have more extensive patches in the work, but these two trivial ones will
do for today.  I would like to hear from people who use the ds2490 USB to
one wire dongle.  1 if you would be willing to test the patches as I
currently only have the one sensor on a short parisite powered wire, 2 if
there is any cheap sources for the ds2490.
Signed-off-by: NDavid Fries <david@fries.net>
Acked-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Correct the decoding of negative C temperatures.  The code did a binary OR
of two bytes to make a 16 bit value, but assignd it to an integer.  This
caused the value to not be sign extended and to loose that it was a
negative number in the assignment.

Before the patch (in my freezer),
	w1_slave
	ed fe 4b 46 7f ff 03 10 e4 : crc=e4 YES
	ed fe 4b 46 7f ff 03 10 e4 t=4078
With the patch,
	e3 fe 4b 46 7f ff 0d 10 81 : crc=81 YES
	e3 fe 4b 46 7f ff 0d 10 81 t=-17
Signed-off-by: NDavid Fries <david@fries.net>
Acked-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The IT8705F and related parts are Super I/O controllers that contain
many separate devices.

Some BIOSes describe IT8705F I/O port usage under a motherboard device
(PNP0C02) with overlapping regions, e.g., 0x290-0x29f and 0x290-0x294.

The it87 driver supports only the Environment Controller, which requires
only two ISA ports, but it used to request an eight-port range.  If that
range exceeds a range reported by the BIOS, as 0x290-0x297 would, the
request fails, and the it87 driver cannot claim the device.

This patch makes the it87 driver request only the two ports used for the
Environment Controller device.

Systems where this problem has been reported:
    Gigabyte GA-K8N Ultra 9
    Gigabyte M56S-S3
    Gigabyte GA-965G-DS3

Kernel bug reports:
    http://bugzilla.kernel.org/show_bug.cgi?id=9514
    http://lkml.org/lkml/2007/12/4/466

Related change:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7839e960675b549f06209d18283d5cee2ce9261

    The patch above increases the number of PNP port resources we support.
    Prior to this patch, we ignored some port resources, which masked the
    it87 problem.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NMark M. Hoffman <mhoffman@lightlink.com>

Fix line length calculation. var->width is the size of the display in mm. We
like to use the pixel size.

Without this fix, dynamic (fbset) based resolution and depths changes with
s3c2410_fb don't work at all.

Spotted by john cass <johnpcass@yahoo.com>
Signed-off-by: NStefan Schmidt <stefan@openmoko.org>
Signed-off-by: NHarald Welte <laforge@openmoko.org>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Acked-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@akpm@linux-foundation.org>

If we get a data URB back from the hardware after we have put the tty to
bed we go kaboom.  Fortunately all we need to do is process the URB without
trying to ram its contents down the throat of an ex-tty.
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@akpm@linux-foundation.org>

The tc35815-mac platform device used a pci bus number and a devfn to
identify its target device, but the pci bus number may vary if some
bus-bridges are found.  Use irq number which is be unique for embedded
controllers.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

When unregistering the rtnl_link_ops, all existing devices using
the ops are destroyed. With nested devices this may lead to a
use-after-free despite the use of for_each_netdev_safe() in case
the upper device is next in the device list and is destroyed
by the NETDEV_UNREGISTER notifier.

The easy fix is to restart scanning the device list after removing
a device. Alternatively we could add new devices to the front of
the list to avoid having dependant devices follow the device they
depend on. A third option would be to only restart scanning if
dev->iflink of the next device matches dev->ifindex of the current
one. For now this seems like the safest solution.

With this patch, the veth rtnl_link_ops unregistration can use
rtnl_link_unregister() directly since it now also handles destruction
of multiple devices at once.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

EXPORT_SYMBOL'ed code mustn't be __*init.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

EXPORT_SYMBOL'ed code mustn't be __*init.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Several of the Intel ethernet drivers keep an atomic counter used to
manage when to actually hit the hardware with a disable or an enable.

The way the net_rx_work() breakout logic works during a pending
napi_disable() is that it simply unschedules the poll even if it
still has work.

This can potentially leave interrupts disabled, but that is OK
because all of the drivers are about to disable interrupts
anyways in all such code paths that do a napi_disable().

Unfortunately, this trips up the semaphore used here in the Intel
drivers.  If you hit this case, when you try to bring the interface
back up it won't enable interrupts.  A reload of the driver module
fixes it of course.

So what we do is make sure all the sequences now go:

	napi_disable();
	atomic_set(&adapter->irq_sem, 0);
	*_irq_disable();

which makes sure the counter is always in the correct state.

Reported by Robert Olsson.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It was moved to arch/x86/lguest/Kconfig, but I lost the deletion part in a
patch suffle.  My confused one-liner "fix" to turn it on is also reverted:
84f7466eSigned-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The PDC202xx older devices do not support ATAPI DMA via the usual
interfaces. What documentation I have isn't sufficient to support DMA and
it isn't clear if the Windows drivers do this or it is possible at all.
(Neither do the drivers/ide old drivers)

So turn it ATAPI DMA off, these are disk optimised controllers.
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There's currently no way to turn on Lguest guest support; the planned
Kconfig virtualization reorg didn't get into 2.6.25.

This was unnoticed because if you already had CONFIG_LGUEST_GUEST=y in
your config, it worked.  Too bad about new users...

Also, the Kconfig help was wrong now the virtio drivers are merged.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 3ff6eb4a.

the !found check in the for loop allready made sure that only one
device was found.
Signed-Off-By: NPádraig Brady <P@draigBrady.com>
Signed-Off-By: NWim Van Sebroeck <wim@iguana.be>

Please apply this patch since i reverted by mistake
the commit 4e3ab47a
in 6cd043d9Signed-off-by: NMatteo Croce <technoboy85@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

remove an unused union-with-bitfield of the same sort,
add missing conversions in debugging printk
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

same story, different registers...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

broken use of bitfields; FUBAR on big-endian (and not valid C,
strictly speaking).
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

wn3_config is shared by these cards; the way we deal with it is both bad C
(union abuse) and broken on big-endian.  For 3c515 it's less serious (ISA
cards are quite rare outside of little-endian boxen), but 3c574 is a pcmcia
one and that'd better be endian-independent...  Fix is the same in both
cases.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

- Fixed synchronization between scheduling of napi with card reset and close
  by moving the enabling and disabling of napi to card up and card down
  functions respectively instead of open and close.
Signed-off-by: NSurjit Reang <surjit.reang@neterion.com>
Signed-off-by: NRamkrishna Vepa <ram.vepa@neterion.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The driver sets up the hardware to accept a frame with max length
equal to MTU + Ethernet header + FCS + VLAN tag, but we neglect to
add the VLAN tag size to the ingress buffer.  When a VLAN-tagged
frame arrives, the hardware passes it, but bad things happen
because the buffer is too small.  This patch fixes that.

Thanks to David Harris for reporting the bug and testing the fix.
Tested-by: NDavid Harris <david.harris@cpni-inc.com>
Signed-off-by: NJay Cliburn <jacliburn@bellsouth.net>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This reverts commit 84cd2dfb.

Some BIOS's break if Wake On Lan is enabled, and the machine
can't boot. Better to have some user's have to call ethtool to
enable WOL than to break a single user's boot.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

There is no Documentation/networking/e1000e.txt.
Signed-off-by: NJason Uhlenkott <jasonuhl@jasonuhl.org>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Change bond_mii_monitor to not hold any locks when calling rtnl_unlock,
as rtnl_unlock can sleep (when acquring another mutex in netdev_run_todo).

Bug reported by Makito SHIOKAWA <mshiokawa@miraclelinux.com>, who
included a different patch.
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Fix the handling of rtnl and the bonding_rwsem to always be acquired
in a consistent order (rtnl, then bonding_rwsem).

The existing code sometimes acquired them in this order, and sometimes
in the opposite order, which opens a window for deadlock between ifenslave
and sysfs.
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

	A recent change to add an additional hash policy modified
bond_parse_parm, but it now does not correctly match parameters passed in
via sysfs.

	Rewrote bond_parse_parm to handle (a) parameter matches that
are substrings of one another and (b) user input with whitespace (e.g.,
sysfs input often has a trailing newline).
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

	Add a call to bond_release_all in the bonding netdev event
handler for the master.  This releases the slaves for the case of, e.g.,
"echo -bond0 > /sys/class/net/bonding_masters", which otherwise will spin
forever waiting for references to be released.
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

	alb_fasten_mac_swap (actually rlb_teach_disabled_mac_on_primary)
requries RTNL and no other locks.  This could cause dev_set_promiscuity
and/or dev_set_mac_address to be called with improper locking.

	Changed callers to hold only RTNL during calls to alb_fasten_mac_swap
or functions calling it.  Updated header comments in affected functions to
reflect proper reality of locking requirements.
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>