Have a method to make a couple with alloc_i7core_dev() previously
introduced.  Using in pair will help proper resource handling.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It's nice to have a method for a single purpose.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Since we need to pass the index of the entry, pass the table itself
instead of passing individual members of the table.

While here make it static.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

commit 47251b4d960bdfa648b0d06dbc6d445f41cb3906 have changed
the logic for unexplained reasons.  It looks strange that it
can release i7core_dev without calling i7core_put_devices()
that releases i7core_dev->pdev.

Fix the part.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The legacy PCI probe sometimes cause hangs. Better to have it
disabled by default, and have a parameter to enable it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a nasty bug. Since kobject count will be reduced by zero by
edac_mc_del_mc(), and this triggers the kobj release method, the
mci memory will be freed automatically. So, all we have left is ctl_name,
as shown by enabling debug:

[   80.822186] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 1020: edac_remove_sysfs_mci_device()  remove_link
[   80.832590] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 1024: edac_remove_sysfs_mci_device()  remove_mci_instance
[   80.843776] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 640: edac_mci_control_release() mci instance idx=0 releasing
[   80.855163] EDAC MC: Removed device 0 for i7core_edac.c i7 core #0: DEV 0000:3f:03.0
[   80.862936] EDAC DEBUG: in drivers/edac/i7core_edac.c, line at 2089: (null): free structs
[   80.871134] EDAC DEBUG: in drivers/edac/edac_mc.c, line at 238: edac_mc_free()
[   80.878379] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 726: edac_mc_unregister_sysfs_main_kobj()
[   80.888043] EDAC DEBUG: in drivers/edac/i7core_edac.c, line at 1232: drivers/edac/i7core_edac.c: i7core_put_devices()

Also, kfree(mci) shouldn't happen at the kobj.release, as it happens
when edac_remove_sysfs_mci_device() is called, but the logic is:
	edac_remove_sysfs_mci_device(mci);
	edac_printk(KERN_INFO, EDAC_MC,
		"Removed device %d for %s %s: DEV %s\n", mci->mc_idx,
		mci->mod_name, mci->ctl_name, edac_dev_name(mci));
So, as the edac_printk() needs the mci struct, this generates an OOPS.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is important to track a nasty bug at the free logic.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A very nasty bug were happening on edac core, due to the way mci objects are
freed. mci memory is freed when kobject count reaches zero, by
edac_mci_control_release(). However, from the logs, this is clearly happening
before the final usage of mci struct:

[15799.607454] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 640: edac_mci_control_release() mci instance idx=0 releasing
[15799.618773] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 769: edac_inst_grp_release()
[15799.627326] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 894: edac_remove_mci_instance_attributes() end of seeking for group all_channel_counts
[15799.640887] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 877: edac_remove_mci_instance_attributes() sysfs_attrib = ffffffffa01d7240
[15799.653412] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 1020: edac_remove_sysfs_mci_device()  remove_link
[15799.663753] EDAC DEBUG: in drivers/edac/edac_mc_sysfs.c, line at 1024: edac_remove_sysfs_mci_device()  remove_mci_instance
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make sure we remove groups at the right order
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Otherwise, a NMI may happen causing a race condition and a panic.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are two groups of sysfs attributes: one for rdimm and another
for udimm. Instead of changing dynamically the unique static struct
for handling udimm's, declare two vars and make them constant.

This avoids the risk of having two or more memory controllers, each
needing a different set of attributes.

While here, use const on all places where it is applicable.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

edac_core: use const for constant sysfs arguments
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

While here, don't initialize probed with 0.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With multi-sockets, more than one edac pci handler is enabled. Be sure to
un-register all instances.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the host is slow in reading data or doesn't read data at all,
blocking write calls not only blocked the program that called write()
but the entire guest itself.

To overcome this, let's not block till the host signals it has given
back the virtio ring element we passed it.  Instead, send the buffer to
the host and return to userspace.  This operation then becomes similar
to how non-blocking writes work, so let's use the existing code for this
path as well.

This code change also ensures blocking write calls do get blocked if
there's not enough room in the virtio ring as well as they don't return
-EAGAIN to userspace.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
CC: stable@kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In this code, 0 is returned on memory allocation failure, even though other
failures return -ENOMEM or other similar values.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression ret;
expression x,e1,e2,e3;
@@

ret = 0
... when != ret = e1
*x = \(kmalloc\|kcalloc\|kzalloc\)(...)
... when != ret = e2
if (x == NULL) { ... when != ret = e3
  return ret;
}
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
To: Pat Gefre <pfg@sgi.com>
Cc: kernel-janitors@vger.kernel.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1704/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch reverts the driver to enabling/disabling the NFC interrupt
mask rather than enabling/disabling the system interrupt.  This cleans
up the driver so that it doesn't rely on interrupts being disabled
within the interrupt handler.

For i.MX21 we keep the current behaviour, that is calling
enable_irq/disable_irq_nosync to enable/disable interrupts.  This patch
is based on earlier work by John Ogness.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NJohn Ogness <john.ogness@linutronix.de>
Tested-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

448cd166 ("Input: evdev - rearrange ioctl handling") broke EVIOCSABS by
checking for the wrong direction bit.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Reported-by: NSven Neumann <s.neumann@raumfeld.com>
Tested-by: NSven Neumann <s.neumann@raumfeld.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This fixes a regression introduced by the dynamic allocation of absinfo
for input devices. We need to bail out early for input devices which
don't have absolute axis.

[  929.664303] Pid: 2989, comm: input Not tainted 2.6.36-rc8+ #14 MS-7260/MS-7260
[  929.664318] EIP: 0060:[<c12bdc01>] EFLAGS: 00010246 CPU: 0
[  929.664331] EIP is at evdev_ioctl+0x4f8/0x59f
[  929.664341] EAX: 00000040 EBX: 00000000 ECX: 00000006 EDX: f45a1efc
[  929.664355] ESI: 00000000 EDI: f45a1efc EBP: f45a1f24 ESP: f45a1eb8
[  929.664369]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  929.664402]  f470da74 f6a30e78 f462c240 00000018 bfe4a260 00000000 f45b06fc 00000000
[  929.664429] <0> 000000c4 b769d000 c3544620 f470da74 f45b06fc f45b06fc f45a1f38 c107dd1f
[  929.664458] <0> f4710b74 000000c4 00000000 00000000 00000000 0000029d 00000a74 f4710b74
[  929.664500]  [<c107dd1f>] ? handle_mm_fault+0x2be/0x59a
[  929.664513]  [<c12bd709>] ? evdev_ioctl+0x0/0x59f
[  929.664524]  [<c1099d30>] ? do_vfs_ioctl+0x494/0x4d9
[  929.664538]  [<c10432a1>] ? up_read+0x16/0x29
[  929.664550]  [<c101c818>] ? do_page_fault+0x2ff/0x32d
[  929.664564]  [<c108d048>] ? do_sys_open+0xc5/0xcf
[  929.664575]  [<c1099db6>] ? sys_ioctl+0x41/0x61
[  929.664587]  [<c1002710>] ? sysenter_do_call+0x12/0x36
[  929.684570] ---[ end trace 11b83e923bd8f2bb ]---
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

The i2c_imx_trx_complete() function is using
wait_event_interruptible_timeout() to wait for the I2C controller to
signal that it has completed an I2C bus operation. If the process that
causes the I2C operation receives a signal, the wait will be
interrupted, returning an error. It is better to let the I2C operation
finished before handling the signal (i.e. returning into userspace).

It is safe to use wait_event_timeout() instead, because the timeout
will allow the process to exit if the I2C bus hangs. It's also better
to allow the I2C operation to finish, because unacknowledged I2C
operations can cause the I2C bus to hang.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

This patch is an improvement to 4bba0fd8
which got to mainline a little early.

Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
settings before DXR for correct behaviour, so load MDR first with
STT cleared and later load again with STT set.

Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: NJon Povey <jon.povey@racelogic.co.uk>
Acked-by: NTroy Kisky <troy.kisky@boundarydevices.com>
Tested-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Fixes cursor corruption in certain cases.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Revert commit 54672386
"firewire: ohci: fix up configuration of TI chips".
It caused massive slow-down and data corruption with a TSB82AA2 based
StarTech EC1394B2 ExpressCard and FireWire 800 harddisks.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657081
http://thread.gmane.org/gmane.linux.kernel.firewire.user/4013

The fact that some card EEPROMs do not program these enhancements may be
related to TSB81BA3 phy chip errata, if not to bugs of TSB82AA2 itself.
We could re-add these configuration steps, but only conditional on a
whitelist of cards on which these enhancements bring a proven positive
effect.
Reported-and-tested-by: NEric Shattow <lucent@gmail.com>
Cc: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org> 2.6.35
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The compat code for the VIDIOCSMICROCODE ioctl is totally buggered.
It's only used by the VIDEO_STRADIS driver, and that one is scheduled to
staging and eventually removed unless somebody steps up to maintain it
(at which point it should use request_firmware() rather than some magic
ioctl).  So we'll get rid of it eventually.

But in the meantime, the compatibility ioctl code is broken, and this
tries to get it to at least limp along (even if Mauro suggested just
deleting it entirely, which may be the right thing to do - I don't think
the compatibility translation code has ever worked unless you were very
lucky).
Reported-by: NKees Cook <kees.cook@canonical.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix SDIO suspend/resume regression introduced by 4c2ef25f "mmc: fix
all hangs related to mmc/sd card insert/removal during suspend/resume":

  PM: Syncing filesystems ... done.
  Freezing user space processes ... (elapsed 0.01 seconds) done.
  Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
  Suspending console(s) (use no_console_suspend to debug)
  pm_op(): platform_pm_suspend+0x0/0x5c returns -38
  PM: Device pxa2xx-mci.0 failed to suspend: error -38
  PM: Some devices failed to suspend

4c2ef25f moved the card removal/insertion mechanism out of MMC's
suspend/resume path and into pm notifiers (mmc_pm_notify), and that
broke SDIO's expectation that mmc_suspend_host() will remove the card,
and squash the error, in case -ENOSYS is returned from the bus suspend
handler (mmc_sdio_suspend() in this case).

mmc_sdio_suspend() is using this whenever at least one of the card's SDIO
function drivers does not have suspend/resume handlers - in that case
it is agreed to force removal of the entire card.

This patch fixes this regression by trivially bringing back that part of
mmc_suspend_host(), which was removed by 4c2ef25f.
Reported-and-tested-by: NSven Neumann <s.neumann@raumfeld.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: <stable@kernel.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit 07934481 "DMAENGINE: generic channel status v2" changed the interface for
how dma channel progress is retrieved.  It inadvertently exported an internal
helper function ioat_tx_status() instead of ioat_dma_tx_status().  The latter
polls the hardware to get the latest completion state, while the helper just
evaluates the current state without touching hardware.  The effect is that we
end up waiting for completion timeouts or descriptor allocation errors before
the completion state is updated.

iperf (before fix):
[SUM]  0.0-41.3 sec   364 MBytes  73.9 Mbits/sec

iperf (after fix):
[SUM]  0.0- 4.5 sec   499 MBytes   940 Mbits/sec

This is a regression starting with 2.6.35.

Cc: <stable@kernel.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Maciej Sosnowski <maciej.sosnowski@intel.com>
Reported-by: NRichard Scobie <richard@sauce.co.nz>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Currently we set all skbs with CHECKSUM_UNNECESSARY, even
those whose protocol we don't know. This patch just
add the CHECKSUM_COMPLETE tag for non TCP/UDP packets.
Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

At least one board using the FEC driver does not have a conventional
PHY attached to it, it is directly connected to a somewhat simple
ethernet switch (the board is the SnapGear/LITE, and the attached
4-port ethernet switch is a RealTek RTL8305). This switch does not
present the usual register interface of a PHY, it presents nothing.
So a PHY scan will find nothing - it finds ID's of 0 for each PHY
on the attached MII bus.

After the FEC driver was changed to use phylib for supporting PHYs
it no longer works on this particular board/switch setup.

Add code support to use a fixed phy if no PHY is found on the MII bus.
This is based on the way the cpmac.c driver solved this same problem.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This add the product id of the touch screen found on ACER Aspire 5738PZ.  Works
with hid-cando driver.

Signed-off-by: Francois Jaouen<francois.jaouen@laposte.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This should pass "buf" to bvec_kunmap_irq() instead of "bv".  The api is
like kmap_atomic() instead of kmap().
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NGeoff Levand <geoff@infradead.org>
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

I see the following error message in my kernel log from time to time:
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait

After investigation, it turns out that there's nothing to be afraid of
and everything works as intended. So remove the spurious log message.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Missing parens.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30718Reported-by: NDave Gilbert <freedesktop@treblig.org>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NMatt Turner <mattst88@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make TV standard and DFP table revisions debug only.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

These bits are used for internal communication and should
be left enabled.  This may fix s/r issues on some systems.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.

This patch limit the vram allocation to visible vram until
we have acceleration up and running.

Note that it's more than unlikely that we run into any issue
related to that as when acceleration is not woring userspace
should allocate any object in vram beside front buffer which
should fit in visible vram.

V2 use real_vram_size as mc_vram_size could be bigger than
   the actual amount of vram

[airlied: fixup r700_cp_stop case]
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This device generates ABS_Z and ABS_RX events, while it should be
generating ABS_X and ABS_Y instead. Using the MULTI_INPUT quirk solves
this issue.

Reference: https://bugs.launchpad.net/ubuntu/+bug/620609/Signed-off-by: NPierre BAILLY <pierre@substantiel.fr>
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

commit 511d2224 (tg3: 64 bit stats on all arches), overlooked the
rx_dropped accounting.

We use a full "struct rtnl_link_stats64" to hold rx_dropped value, but
forgot to report it in tg3_get_stats64().

Use an "unsigned long" instead to shrink "struct tg3" by 176 bytes, and
report this value to stats readers.

Increment rx_dropped counter for oversized frames.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
CC: Michael Chan <mchan@broadcom.com>
CC: Matt Carlson <mcarlson@broadcom.com>
Acked-by: NMatt Carlson <mcarlson@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>