This reverts commit 93ad7c07.

http://bugzilla.kernel.org/show_bug.cgi?id=9798Signed-off-by: NLen Brown <len.brown@intel.com>

The "DEBUG" symbol needs to be defined before #including <linux/kernel.h> to
get the pr_debug() working.
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add leading zeros to pr_debug() calls. For example if x=0x0a, the format
"0x%2x" will result the string "0x a", the format "0x%2.2x" will result "0x0a".
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NLen Brown <len.brown@intel.com>

Return OBF_1 optimization workaround

http://bugzilla.kernel.org/show_bug.cgi?id=8459Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

This DMI blacklist reduces the console messages
on systems which have a BIOS that invokes OSI(Linux).

As the DMI blacklist already knows about these systems,
the request for DMI info itself is disabled.

Further, if OSI(Linux) has already been determined
to have no beneift, we disable the console message
requesting acpi_osi=Linux test results.
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_osi=Linux helps sound on these systems.
Signed-off-by: NLen Brown <len.brown@intel.com>

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>

E7221 chipset is a server version of the i915.
Signed-off-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The E7221 chipset is a 915 rebadged for the Intel server line.
Signed-off-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I've verified (on my Initio 9100 with a DAT drive) that the
2.6.24-rc8-git6 initio module still hangs on loading.

These fixes (other than the printk) are needed to get the module to load
ok (and work correctly) with my adapter & tape drive.

a) printk cosmetic fix

b) cblk->sglen needs setting for later DMA I/O routines to use

c) host->bios_addr needs setting for debug output correctness

d) semaph & semaph_lock initialisation had got lost since 2.6.22

e) since 2.6.22 the bios data address was truncated to 16 bits (needs 20
when shifted left)
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

sis190_tx_timeout
-> sis190_hw_start
   -> sis190_soft_reset
      -> msleep *splat*

PCI transactions are correctly flushed here.
The msleep() is probably useless.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: K.M. Liu <kmliu@sis.com.tw>

i ranges from 0 to 100 in the 'for' loop a few lines above.

Reported by davem.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: K.M. Liu <kmliu@sis.com.tw>

It is already done in sis190_init_one.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: K.M. Liu <kmliu@sis.com.tw>

More work is needed to handle correctly the PHY of the new devices
when connected to a 10Mb link but this change already helps some
users as is.

Fix for:
http://bugzilla.kernel.org/show_bug.cgi?id=9467Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: K.M. Liu <kmliu@sis.com.tw>
Cc: J. Gleacher <jgleacher@yahoo.com>
Cc: Alexandre Penasso Teixeira <alexandre@keepsoftware.com>
Cc: Arliton Rocha <arliton@gmail.com>
Cc: Juan Jose Pablos <juanjo@apertus.es>
Cc: Wipat Srutiprom <wipat.s@psu.ac.th>

This fixes a NULL pointer dereference that can occur when the
ucode is not loaded at the time __iwl_up is called.

The problem was reported at http://kerneloops.org/raw.php?rawid=2765&msgid=Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Changeset 16b110c3 (dmfe warning fix)
bothed up the offsets read from the SROM so that it doesn't read the
same datums it used to.

The change made transformations like turning:

	"srom + 34"

into

	"(__le32 *)srom + 34/4"

which doesn't work because 4 does not divide evenly
into 34 so we're using a different pointer offset
than in the original code.

I've changed theses cases in dmfe_parse_srom() to
consistently use "(type *)(srom + offset)" preserving
the offsets from the original code.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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>

With a sparc64 defconfig modified to set CONFIG_HOTPLUG=n
the following error happened during link of vmlinux:

local symbol 0: discarded in section `.devexit.text' from drivers/built-in.o
local symbol 1: discarded in section `.devexit.text' from drivers/built-in.o

(The error message above is from kbuild.git but it happens in mainline too)

The error happens becase there is a reference from .text/.data to a
function marked __devexit. With CONFIG_HOTPLUG=n all code marked
__devexit are discarded and the linker complains.

It was tracked down to sparcspkr.c which were missing __devexit_p()
around the function pointers.

Unfortunately modpost did not catch this since modpost do not warn
about references from .data to .devexit from variables named *_driver.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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>