The standard ACPI dock driver can handle the hotplug bays and docks of
the ThinkPads just fine (including batteries) as of 2.6.27, and the
code in thinkpad-acpi for the dock and bay subdrivers is currently
broken anyway...

Userspace needs some love to support the two-stage ejection nicely,
but it is simple enough to do through udev rules (you don't even need
HAL) so this wouldn't justify fixing the dock and bay subdrivers,
either.

That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
as support for the weird dock of the model 570, but since such support
has never left the "experimental" stage, it is also not a strong
enough reason to find a way to fix this code.

Users of ThinkPads with warm-swap bays are urged to request that _EJ3
support be added to the regular ACPI dock driver, if such feature is
indeed useful for them.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently, the ThinkPad-ACPI bay and dock drivers are completely
broken, and cause a NULL pointer derreference in kernel mode (and,
therefore, an OOPS) when they try to issue events (i.e. on dock,
undock, bay ejection, etc).

OTOH, the standard ACPI dock driver can handle the hotplug bays and
docks of the ThinkPads just fine (including batteries) as of 2.6.27.
In fact, it does a much better job of it than thinkpad-acpi ever did.

It is just not worth the hassle to find a way to fix this crap without
breaking the (deprecated) thinkpad-acpi dock/bay ABI.  This is old,
deprecated code that sees little testing or use.

As a quick fix suitable for -stable backports, mark the thinkpad-acpi
bay and dock subdrivers as BROKEN in Kconfig.  The dead code will be
removed by a later patch.

This fixes bugzilla #13669, and should be applied to 2.6.27 and later.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: NJoerg Platte <jplatte@naasa.net>
Cc: stable@kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: NPierre Ossman <pierre@ossman.eu>

the code allready uses flush_kernel_dcache_page(). This patch updates the
driver to the recent sg API changes which require that either SG_MITER_TO_SG
or SG_MITER_FROM_SG is set. SG_MITER_TO_SG calls flush_kernel_dcache_page()
in sg_mitter_stop()
Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Acked-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NPierre Ossman <pierre@ossman.eu>

so the page will be flushed on unmap on ARCH which need it.
Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: NPierre Ossman <pierre@ossman.eu>

I've been doing this for years, and akpm picked me up on it about 12
months ago.  lguest partly serves as example code, so let's do it Right.

Also, remove two unused fields in struct vblk_info in the example launcher.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@redhat.com>

Every so often, after code shuffles, I need to go through and unbitrot
the Lguest Journey (see drivers/lguest/README).  Since we now use RCU in
a simple form in one place I took the opportunity to expand that explanation.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>

I don't really notice it (except to begrudge the extra vertical
space), but Ingo does.  And he pointed out that one excuse of lguest
is as a teaching tool, it should set a good example.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@redhat.com>

This refactors find_vqs, making it more readable and robust, and fixing
two regressions from 2.6.30:
- double free_irq causing BUG_ON on device removal
- probe failure when vq can't be assigned to msi-x vector
  (reported on old host kernels)
Tested-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This makes delete vq the reverse of find vq.
This is required to make it possible to retry find_vqs
after a failure, otherwise the list gets corrupted.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Make vp_free_vectors do the reverse of vq_request_vectors.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

"new" was freed and then dereferenced.  Also the return value wasn't being
used so I modified the caller as well.

Compile tested only.  Found by smatch (http://repo.or.cz/w/smatch.git).

regards,
dan carpenter
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is another alloc_bootmem() -> kzalloc() change, this time to
fix the non-fatal badness caused when booting with a cpm2_uart console.
Signed-off-by: NMark Ware <mware@elphinstone.net>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

drivers/serial/atmel_serial.c: fix compile when CONFIG_SERIAL_ATMEL=Y and CONFIG_SERIAL_ATMEL_CONSOLE=N

When SERIAL_ATMEL_CONSOLE is disabled, ATMEL_CONSOLE_DEVICE is set to
NULL, and trying to access ATMEL_CONSOLE_DEVICE->flags in
atmel_serial_probe makes the compile fail.  This fixes the issue by only
accessing it if CONFIG_SERIAL_ATMEL_CONSOLE is defined
Signed-off-by: NAlbin Tonnerre <albin.tonnerre@free-electrons.com>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since commit 8dfd0374 ("MMC core: limit
minimum initialization frequency to 400kHz") MMC core checks for minimum
frequency, and that causes following messages flood when using eSDHC
controllers:

  ...
  mmc0: Minimum clock frequency too high for identification mode
  mmc0: Minimum clock frequency too high for identification mode
  ...

The warnings are legitimate, since if we'd use 133 MHz clocks for standard
SDHCI controllers, we'd not able to scale frequency down to 400 kHz.

But eSDHC controllers have a non-standard SD clock management, so we can
divide clock by 256 * 16, not just 256.

This patch introduces get_min_clock() callback for sdhci core and
implements it for sdhci-of driver, and thus fixes the issue.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: Matt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

commit d6580a9f ("kexec: sysrq: simplify
sysrq-c handler") changed the behavior of sysrq-c to unconditional
dereference of NULL pointer.  So in cases with CONFIG_KEXEC, where
crash_kexec() was directly called from sysrq-c before, now it can be said
that a step of "real oops" was inserted before starting kdump.

However, in contrast to oops via SysRq-c from keyboard which results in
panic due to in_interrupt(), oops via "echo c > /proc/sysrq-trigger" will
not become panic unless panic_on_oops=1.  It means that even if dump is
properly configured to be taken on panic, the sysrq-c from proc interface
might not start crashdump while the sysrq-c from keyboard can start
crashdump.  This confuses traditional users of kdump, i.e.  people who
expect sysrq-c to do common behavior in both of the keyboard and proc
interface.

This patch brings the keyboard and proc interface behavior of sysrq-c in
line, by forcing panic_on_oops=1 before oops in sysrq-c handler.

And some updates in documentation are included, to clarify that there is
no longer dependency with CONFIG_KEXEC, and that now the system can just
crash by sysrq-c if no dump mechanism is configured.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Brayan Arraes <brayan@yack.com.br>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Under certain circumstances msleep(1) within the loop, which waits for the
EEPROM to be finished, might take longer than the timeout.  On the next
loop the status register might now return to be ready and therefore the
loop finishes.  The following check now tests if a timeout occurred and if
so returns an error although the device reported it was ready.

This fix replaces testing the occurrence of the timeout by testing the
"not ready" bit in the status register.
Signed-off-by: NSebastian Heutling <heutling@who-ing.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NKristoffer Ericson <kristoffer.ericson@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

rtc-cmos has two drivers, one PNP and one platform.  When PNP has not
succeeded probing, platform is registered.  However, it tries to
unregister both drivers unconditionally, instead of only unregistering
those that were successfully registered.  This causes runtime warnings to
be emitted from the driver core code.

Fix this with a boolean variable for each driver indicating whether
registering was successful.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg KH <greg@kroah.com>
Cc: Ozan Caglayan <ozan@pardus.org.tr>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When data is read through DMA, the last element must be read separately
through the RX register.  It cannot be transferred by the DMA.  For
further details see e.g.  OMAP35x TRM (table 19-16).

Without the fix the driver causes extra clocks to be clocked to the bus
after DMA RX operations.  This can cause interesting behaviour with some
devices.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NEero Nurkkala <ext-eero.nurkkala@nokia.com>
[aaro.koskinen@nokia.com: Simplified the patch while keeping the idea.]
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently mcspi wake-ups are not enabled.  This might cause cases where
OMAP is not waking up on mcspi events.
Signed-off-by: NJouni Hogander <jouni.hogander@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixed off-by-one bug in loop indexes - some elements beyond windows' array
were accessed, which might result in memory access violations when
removing/suspending the device.
Signed-off-by: NPawel Osciak <p.osciak@samsung.com>
Reviewed-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Intel X38 MCHBAR is a 64bits register, base from 0x48, so its higher base
is 0x4C.
Signed-off-by: NLu Zhihe <tombowfly@gmail.com>
Signed-off-by: NDoug Thompson <dougthompson@xmission.com>
Cc: <stable@kernel.org>		[2.6.30.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.

Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
if there is NACK | AL, set the appropriate error flags, ack the pending
interrupts and return from the ISR.
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NVikram pandita <vikram.pandita@ti.com>
[ben-linux@fluff.org: fixed mail format and added i2c-omap to subject]
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

In case of a NACK or ARDY or AL interrupt, complete the request.
There is no need to service the RRDY/RDR or XRDY/XDR interrupts.

Refer TRM SWPU114: Figure 18-31.I2C Master Transmitter Mode, Interrupt Method,
in F/S and HS Modes

http://focus.ti.com/pdfs/wtbu/SWPU114T_PrelimFinalEPDF_06_25_2009.pdfSigned-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NVikram pandita <vikram.pandita@ti.com>
[ben-linux@fluff.org: fixed mail format and added i2c-omap to subject]
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Fix bug in reading the I2C_BUFFSTAT register for getting byte count on RX/TX interrupt.

On Interrupt: I2C_STAT[RDR],
	read 'RXSTAT' from I2C_BUFFSTAT[8-13]
On Interrupt: I2C_STAT[XDR]
	read 'TXSTAT' from I2C_BUFFSTAT[0-5]
Signed-off-by: NJagadeesh Pakaravoor <j-pakaravoor@ti.com>
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NVikram pandita <vikram.pandita@ti.com>
[ben-linux@fluff.org: fixed mail format and added i2c-omap to subject]
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Convert the i2c-sh_mobile i2c bus driver to use
subsys_initcall() instead of module_init().

This change makes the driver register a bit earlier which
together with earlier platform data moves the time for probe().
The earlier probe() makes it possible to use i2c_get_adapter()
and i2c_transfer() from device_initcall().

The same strategy is used by other i2c bus drivers such as
i2c-pxa.c and i2c-s3c2410.c.
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
[ben-linux@fluff.org: minor subject updaye]
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

strlcpy() will always null terminate the string.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

s3c24xx_i2c_init() was overwriting the IICLC value set just above in
s3c24xx_i2c_clockrate() with zero, effectively disabling the platform
line control setting.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

We really don't want to mark the pty as a low-latency device, because as
Alan points out, the ->write method can be called from an IRQ (ppp?),
and that means we can't use ->low_latency=1 as we take mutexes in the
low_latency case.

So rather than using low_latency to force the written data to be pushed
to the ldisc handling at 'write()' time, just make the reader side (or
the poll function) do the flush when it checks whether there is data to
be had.

This also fixes the problem with lost data in an emacs compile buffer
(bugzilla 13815), and we can thus revert the low_latency pty hack
(commit 3a542974: "pty: quickfix for the
pty ENXIO timing problems").
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Tested-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
[ Modified to do the tty_flush_to_ldisc() inside input_available_p() so
  that it triggers for both read and poll()  - Linus]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This fixes regression (battery "vanishing" on resume) introduced by
commit d0c71fe7 ("ACPI Suspend: Enable
ACPI during resume if SCI_EN is not set") and also the issue with
the "screaming" IRQ 9.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13745Reported-and-tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: stable@kernel.org
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: NLen Brown <lenb@kernel.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This will allow efi/vesa to handoff to radeon.
Signed-off-by: NDave Airlie <airlied@redhat.com>

DMA32 and highmem are sort of exclusive.

Noticed by AndrewR on #radeon.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The incorrect size caused benchmark results to be inflated by a factor of 4.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If enabled, during initialization BO GTT->VRAM and VRAM->GTT GPU copies are
tested across the whole GTT aperture.

This has helped uncover the benchmark copy size bug and verify the maximum
aperture size supported by the AGP bridge in my PowerBook.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Blocking here isn't something the X server mouse appreciates,
avoid the block and let userspace retry the waits.

libdrm_radeon userspace library is also expecting EBUSY not ERESTART
Signed-off-by: NDave Airlie <airlied@redhat.com>

Temporarily maps highmem pages while flushing to get a valid virtual
address to flush.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For x86 this affected highmem pages only, since they were always kmapped
cache-coherent, and this is fixed using kmap_atomic_prot().

For other architectures that may not modify the linear kernel map we
resort to vmap() for now, since kmap_atomic_prot() generally uses the
linear kernel map for lowmem pages. This of course comes with a
performance impact and should be optimized when possible.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The code was potentially dereferencig a NULL sync object pointer.
At the same time a sync object reference was potentially leaked.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If an rn50/r100/m6/m7 GPU has < 64MB RAM, i.e. 8/16/32, the
aperture used to calculate the MC_FB_LOCATION needs to be worked
out from the CONFIG_APER_SIZE register, and not the actual vram size.

TTM VRAM size was also being initialised wrong, use actual vram size
to initialise it.
Signed-off-by: NDave Airlie <airlied@redhat.com>