- cleanup debug calls
- shorten function names
- cleanup error exit paths
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

amd64_check_ecc_enabled() returns non-zero status when ECC
checking/correcting is disabled and this fails further loading of the
driver even when 'ecc_enable_override' boot param is used.

Fix that by clearing return status in that case.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Checking whether the machine is using ECC enabled DRAM is done through
testing the DimmEccEn bit in the DRAM Cfg Low register (F2x[1,0]90). Do
that instead of testing all bits from the DimmEccEn upwards.

Also, remove mci->edac_cap assignment and use value returned from
amd64_determine_edac_cap().
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:

Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc00000000001af64
Oops: Kernel access of bad area, sig: 11 [#1]

The wrong usage of "(void *)__pa(&temperature)" in rtas_call() is
removed by using the function rtas_get_sensor() which does the
right thing.
Signed-off-by: NAdrian Reber <adrian@lisas.de>
Acked-by: NUtz Bacher <utz.bacher@de.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
> On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
> > Sonny Rao writes:
> >
> > > Fix the BSR driver to allow small BSR devices, which are limited to a
> > > single 4k space, on a 64k page kernel.  Previously the driver would
> > > reject the mmap since the size was smaller than PAGESIZE (or because
> > > the size was greater than the size of the device).  Now, we check for
> > > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
> > > as the remap_pfn functions will do this for us.
> >
> > Thanks.
> >
> > Do we know that the BSR size will always be 4k if it's not a multiple
> > of 64k?  Is it possible that we could get 8k, 16k or 32k or BSRs?
> > If it is possible, what does the user need to be able to do?  Do they
> > just want to map 4k, or might then want to map the whole thing?
>
>
> Hi Paul, I took a look at changing the driver to reject a request for
> mapping more than a single 4k page, however the only indication we get
> of the requested size in the mmap function is the vma size, and this
> is always one page at minimum.  So, it's not possible to determine if
> the user wants one 4k page or more.  As I noted in my first response,
> there is only one case where this is even possible and I don't think
> it is a significant concern.
>
> I did notice that I left out the check to see if the user is trying to
> map more than the device length, so I fixed that.  Here's the revised
> patch.

Alright, I've reworked this now so that if we get one of these cases
where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only
advertise that it is a 4k BSR to userspace.  I think this is the best
solution since user programs are only supposed to look at sysfs to
determine how much can be mapped, and libbsr does this as well.

Please consider for 2.6.31 as a fix, thanks.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Add a 4096 byte BSR size which will be used on new machines.  Also, remove
the warning when we run into an unknown size, as this can spam the kernel
log excessively.
Signed-off-by: NSonny Rao <sonnyrao@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The macio_dev's created to map devices inside the MacIO ASICs
don't have proper dma_ops. This causes crashes on some machines
since the SCSI code calls dma_map_* on our behalf using the
device we hang from.

This fixes it by copying the parent PCI device dma_ops into
the macio_dev when creating it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468

When the ACPI video driver initializes, it does a namespace walk
looking for for supported devices. When we find an appropriate
handle, we walk up the ACPI tree looking for a PCI root bus, and
then walk back down the PCI bus, assuming that every device
inbetween is a P2P bridge.

This assumption is not correct, and is reported broken on at
least:

	Dell Latitude E6400
	ThinkPad X61
	Dell XPS M1330

Add a NULL deref check to prevent boot panics.
Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: NTroy Moure <twmoure@szypr.net>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJanne Grunau <j@jannau.net>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

CMSG is an ACPI method used to find features available on
an Eee PC. But some features are never repported, even if present.

If the getter of a feature is present, this patch will set
the corresponding bit in cmsg.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

If there is there is no getter defined, get_acpi()
will return -ENODEV.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Refactor rfkill code, because we'll add another
rfkill for wwan3g later.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert the unusual printk(EEEPC_<level> uses to
the more standard pr_fmt and pr_<level>(.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Tested-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This commit 335f8514 has stopped
properly checking if there is any usb serial associated with the tty in
the close function. It happens the close function is called by releasing
the terminal right after opening the device fails.

As an example, open fails with a non-existing device, when probe has
never been called, because the device has never been plugged. This is
common in systems with static modules and no udev.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This commit 10077d4a has stopped
checking if there was a valid acm device associated to the tty, which is
not true right after open fails and tty subsystem tries to close the
device.

As an example, open fails with a non-existing device, when probe has
never been called, because the device has never been plugged. This is
common in systems with static modules and no udev.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is required, otherwise a user will get a EINVAL while opening a
non-existing device, instead of ENODEV.

This is what I get with this patch applied now instead of an "Invalid
argument".

  cascardo@vespa:~$ cat /dev/ttyACM0
  cat: /dev/ttyACM0: No such device
  cascardo@vespa:~$
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This build error triggers on x86:

 drivers/built-in.o: In function `i2c_dw_init':
 i2c-designware.c:(.text+0x4e37ca): undefined reference to `clk_get_rate'
 drivers/built-in.o: In function `dw_i2c_probe':
 i2c-designware.c:(.devinit.text+0x51f5e): undefined reference to `clk_get'
 i2c-designware.c:(.devinit.text+0x51f76): undefined reference to `clk_enable'
 i2c-designware.c:(.devinit.text+0x520ff): undefined reference to `clk_disable'
 i2c-designware.c:(.devinit.text+0x52108): undefined reference to `clk_put'

Because this new driver uses the clk_*() facilities which is an
ARM-only thing currently.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The existing code had the following race:

Thread-1                       Thread-2

inc/read in_use
                               inc/read in_use
inc tx_free_list[qos].len
                               inc tx_free_list[qos].len

The actual in_use value was incremented twice, but thread-1 is going
to free memory based on its stale value, and will free one too many
times.  The result is that memory is freed back to the kernel while
its packet is still in the transmit buffer.  If the memory is
overwritten before it is transmitted, the hardware will put a valid
checksum on it and send it out (just like it does with good packets).
If by chance the TCP flags are clobbered but not the addresses or
ports, the result can be a broken TCP stream.

The fix is to track the number of freed packets in a single location
(a Fetch-and-Add Unit register).  That way it can never get out of sync
with itself.

We try to free up to MAX_SKB_TO_FREE (currently 10) buffers at a time.
If fewer are available we adjust the free count with the difference.
The action of claiming buffers to free is atomic so two threads cannot
claim the same buffers.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Convert the driver to use net_device_ops as it is now mandatory.

Also compensate for the removal of struct sk_buff's dst field.

The changes are mostly mechanical, the content of ethernet-common.c
was moved to ethernet.c and ethernet-common.{c,h} are removed.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch does not change actual behaviour since dma_unmap_page is just
an alias of dma_unmap_single on MIPS.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The kernel oopses if this flag is set.

[and neither driver should set it as they call tty_flip_buffer_push from IRQ
 paths so have always been buggy]
Signed-off-by: NChuck Ebbert <cebbert@redhat.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since commit 3e3b5c08 ("tty: use
prepare/finish_wait"), tty_port_block_til_ready() is using
prepare_to_wait()/finish_wait().  Those functions require that the
wait_queue_t be initialised with .func=autoremove_wake_function, via
DEFINE_WAIT().

But the conversion from DECLARE_WAITQUEUE() to DEFINE_WAIT() was not made,
so this code will oops in finish_wait().
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use the newly introduced pci_ioremap_bar() function in drivers/serial.
pci_ioremap_bar() just takes a pci device and a bar number, with the goal
of making it really hard to get wrong, while also having a central place
to stick sanity checks.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix race condition when adding transmit data to active DMA buffer ring
that can cause transmit stall.

Update transmit timeout when adding data to active DMA buffer ring.
Base transmit timeout on amount of buffered data instead of using fixed
value.
Signed-off-by: NPaul Fulghum <paulkf@microgate.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove unneeded casts.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Implement the serial polling hooks for the serial_txx9 uart for use with
kgdboc.

This patch once got SOB from Jason on Jul 2008 and (perhaps) merged into
kgdb-next branch, but lost somewhere then.  I resend it now with Jason's
Acked-by.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Acked-by: NJason Wessel <jason.wessel@windriver.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In 86ccf37c the driver was modified
to deal with the removal of the pciirq argument to ide_pci_setup_ports().

But in the conversion only the first port's IRQ gets setup.

Inspired by a patch by Bartlomiej Zolnierkiewicz., and with help from
Alan Cox.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Make hwif->rq point to PM request during PM sequence and do not allow
any other types of requests to slip in (the old comment was never correct
as there should be no such requests generated during PM sequence).
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are some broken devices that report multiple DMA xfer modes
enabled at once (ATA spec doesn't allow it) but otherwise work fine
with DMA so just delete ide_id_dma_bug().

[ As discovered by detective work by Frans and Bart, due to how
  handling of the ID block was handled before commit c4199930
  ("ide-iops: only clear DMA words on setting DMA mode") this
  check was always seeing zeros in the fields or other similar
  garbage.  Therefore this check wasn't actually checking anything.
  Now that the tests actually check the real bits, all we see are
  devices that trigger the check yet work perfectly fine, therefore
  killing this useless check is the best thing to do. -DaveM ]
Reported-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently the error gets repeated too frequently, for example each
time HAL polls the device when a disc is present. Avoid that by using
printk_once instead of printk.

Also join the error and corrective action messages into a single line.
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NBorislav Petkov <petkovbb@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Frans Pop reported that his CDROM drive reports a blocksize of 2352,
and this causes new warnings due to commit
e8e7b9eb ("ide-cd: fix oops when using
growisofs").

What we're trying to do is make sure that "blocklen >> SECTOR_BITS"
is something the block layer won't choke on.

And for Frans' case "2352 >> SECTOR_BITS" is equal to
"2048 >> SECTOR_BITS", and thats "4".

So warning in this case gives no real benefit.
Reported-by: NFrans Pop <elendil@planet.nl>
Tested-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add ide_host_enable_irqs() helper and use it in ide_host_register()
before registering ports.  Then remove no longer needed IRQ unmasking
from in init_irq().

This should fix the problem with "screaming" shared IRQ on the first
port (after request_irq() call while we have the unexpected IRQ pending
on the second port) which was uncovered by my rework of the serialized
interfaces support.
Reported-by: NFrans Pop <elendil@planet.nl>
Tested-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I found a little bug.

When configure in ifcfg-eth* is ONBOOT=no,
the behavior of ethtool command is wrong.

    # grep ONBOOT /etc/sysconfig/network-scripts/ifcfg-eth2
    ONBOOT=no
    # ethtool eth2 | tail -n1
            Link detected: yes

I think "Link detected" should be "no".
Signed-off-by: NOoiwa Naohiro <nooiwa@miraclelinux.com>
Acked-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove unused #include <linux/version.h>('s) in
 drivers/gpu/drm/ttm/ttm_bo_util.c
 drivers/gpu/drm/ttm/ttm_bo_vm.c
 drivers/gpu/drm/ttm/ttm_tt.c
Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Tested-by: NMichael Pyne <mpyne@kde.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
which messes us up otherwise.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>