RTC core won't allow wakeup alarms to be set if RTC devices' parent (i.e.
i2c_client or spi_device) isn't wakeup capable.

For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass via
board info, and if set, I2C core will initialize wakeup capability.  For
SPI devices there is no such flag at all.

I believe that it's not platform code responsibility to allow or disallow
wakeups, instead, drivers themselves should set the capability if a device
can trigger wakeups.

That's what drivers/base/power/sysfs.c says:

 * It is the responsibility of device drivers to enable (or disable)
 * wakeup signaling as part of changing device power states, respecting
 * the policy choices provided through the driver model.

I2C and SPI RTC devices send wakeup events via interrupt lines, so we
should set the wakeup capability if IRQ is routed.

Ideally we should also check irq for wakeup capability before setting
device's capability, i.e.

	if (can_irq_wake(irq))
		device_set_wakeup_capable(&client->dev, 1);

But there is no can_irq_wake() call exist, and it is not that trivial to
implement it for all interrupts controllers and complex/cascaded setups.

drivers/base/power/sysfs.c also covers these cases:

 * Devices may not be able to generate wakeup events from all power
 * states.  Also, the events may be ignored in some configurations;
 * for example, they might need help from other devices that aren't
 * active

So there is no guarantee that wakeup will actually work, and so I think
there is no point in being pedantic wrt checking IRQ wakeup capability.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add support for the Secure Digital Host Controller Interface found on the
"Hollywood" chipset of the Nintendo Wii video game console.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch breaks down sdhci-of into a core portion and a eSDHC portion,
clearing the path to easily support additional hardware using the same OF
driver.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch renames sdhci-of.c to sdhci-of-core.c before reorganizing the
driver to support additional hardware.

The driver is still built as sdhci-of despite the rename of the file.  No
functional change.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Daniel Drake noticed a crash in the error path of mmc_attach_sdio().  This
bug is discussed at http://dev.laptop.org/ticket/9707.

BUG: unable to handle kernel paging request at 6b6b6c57
IP: [<b066d6e2>] sdio_remove_func+0x9/0x27
Call Trace:
[<b066cfb4>] ? mmc_sdio_remove+0x34/0x65
[<b066d1fc>] ? mmc_attach_sdio+0x217/0x240
[<b066a22f>] ? mmc_rescan+0x1a2/0x20f
[<b042e9a0>] ? worker_thread+0x156/0x1e

We need to accurately track how many SDIO functions have been initialised
(and keep card->sdio_funcs in sync) so that we don't try to remove more
functions than we initialised if we hit the error path in
mmc_attach_sdio().

Without this patch if we hit the error path in mmc_attach_sdio() we run
the risk of deferencing invalid memory in sdio_remove_func(), leading to a
crash.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Cc: Daniel Drake <dsd@laptop.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

sdio_remove_func() needs to be more careful about reference counting.  It
can be called in error paths where sdio_add_func() has never been called
e.g.  mmc_attach_sdio error path --> mmc_sdio_remove --> sdio_remove_func
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Reviewed-by: NMatt Fleming <matt@console-pimps.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

sizeof(viafb_gamma_table) is just the size of the pointer.  This is changed
to the size used when calling kmalloc to initialize the pointer.

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

// <smpl>
@@
expression *x;
expression f;
type T;
@@

*f(...,(T)x,...)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NSamu Onkalo <samu.p.onkalo@nokia.com>
Cc: Éric Piel <eric.piel@tremplin-utc.net>
Cc: Kalhan Trisal <kalhan.trisal@intel.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It doesn't make much sense to have CS5535_MFGPT_DEFAULT_IRQ show up in
configs that cannot have CS5535_MFGPT.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Bryan Wu <cooloney@kernel.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Each SPI controller has exactly one CS line and as such doesn't
provide for multi-cs. We implement a workaround to support
multi-cs by _not_ configuring the mux'ed CS pin for each SPI
controller. The CS mechanism is assumed to be fully machine
specific - the driver doesn't even assume some GPIO pin is used
to control the CS.

The driver selects between DMA and POLLING mode depending upon
the xfer size - DMA mode for xfers bigger than FIFO size, POLLING
mode otherwise.

The driver has been designed to be capable of running SoCs since
s3c64xx and till date, for that reason some of the register fields
have been passed via, SoC specific, platform data.
Signed-off-by: NJassi Brar <jassi.brar@samsung.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

If len > BUFFER_LEN and !xfer->rx_buf we end up calculating the tx buffer
address as

*tx_dma = xfer->tx_dma + xfer->len - BUFFER_SIZE;

which is constant; i.e.  we just send the last BUFFER_SIZE data over again
until we've reached the right number of bytes.

This patch gets around this by using the /requested/ length when
calculating addresses.

Note there's no way len != *plen when we calculate the rx buffer address
but conceptually we should be using *plen and I don't want someone to come
through later, see the calculations for rx and tx are different and "clean
up" back to what we had.
Signed-off-by: NBen Nizette <bn@niasdigital.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Add pseudo-DMA by FIQ to the S3C24XX SPI driver.  This allows the driver
to get DMA-like performance where there are either no free DMA channels or
when doing transfers that required both TX and RX data paths.

Since this patch requires the addition of an assembly file to hold the FIQ
code, we rename the module (instead of adding a rename of the .c file to
this patch).  We expect most users are loading this via udev and thus
there should be no change to the userland configuration.
Signed-off-by: NBen Dooks <ben@simtec.co.uk>
Signed-off-by: NSimtec Linux Team <linux@simtec.co.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Driver for the Designware SPI core, it supports multipul interfaces like
PCI/APB etc.  User can use "dw_apb_ssi_db.pdf" from Synopsys as HW
datasheet.

[randy.dunlap@oracle.com: fix build]
[akpm@linux-foundation.org: build fix]
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The driver already uses __devexit_p() in the structure, but looks like
actual __dev{init,exit} markings were forgotten.

The spidev_spi driver also needs renaming to include a "_driver" suffix to
avoid section mismatch warnings.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This reverts commit 8546e3ce, as it's a
partial duplicate of commit 2f390380
("fbdev: add palette register check to several drivers").

The former went in first through the m68k tree, the latter through Andrew
Morton.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This adds the MacBookPro 5,3 and 5,4 to the DMI tables.
Signed-off-by: NDaniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Add the device to the notify callback's arguments in the PWM backlight 
driver. This brings the notify callback into line with the other 
callbacks defined by this driver.
Signed-off-by: NBen Dooks <ben@simtec.co.uk>
Signed-off-by: NSimtec Linux Team <linux@simtec.co.uk>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Currently the driver leds-pwm doesn't set max_brightness for the led device
although it's platform data proides a maximum brightness. Instead it stores its
own private driver struct. The max_brightness defaults to 255 for led device if
it has not been set.
As a result any leds-pwm device with a different maximum brightness will show
incorrect behavior, as it is posible to either set a longer then period duty
time or not be able to switch the led to full brightness.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

This patch changes the default trigger from "ide-disk"
to "default-on". Users updating from kernels not having this
LED driver will prefer having the same LED behavior as they
used to.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

drivers/leds/leds-ss4200.c: In function 'ich7_lpc_probe':
drivers/leds/leds-ss4200.c:353: warning: 'return' with no value, in function returning non-void
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

This driver provides an interface for controlling LEDs (or vibrators)
connected to PMICs for which there is a regulator framework driver.

This driver can be used, for instance, to control vibrator on all Motorola EZX
phones using the pcap-regulator driver services.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Return the PTR_ERR of the correct pointer.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Use resource_size() for ioremap.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Use resource_size() for ioremap.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

ret should be signed to notice a failure in wm831x_reg_read().
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

This change makes sure all regulator group assignments are cleared on
disable call
Signed-off-by: NJuha Keski-Saari <ext-juha.1.keski-saari@nokia.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

This change implements a basic turnon delay in the regulator enable function
to make it less probable that reg_enable returns before the regulator
output is at target level
Signed-off-by: NJuha Keski-Saari <ext-juha.1.keski-saari@nokia.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

This change ensures the regulator REMAP register configuration is in a known
state so state transitions will function as intended regardless of
possible bootloader effects on it
Signed-off-by: NJuha Keski-Saari <ext-juha.1.keski-saari@nokia.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

This change includes regulator turnon delay values and the REMAP reset
configuration to the twlreg_info struct, since they are basic attributes
of every TWL regulator
Signed-off-by: NJuha Keski-Saari <ext-juha.1.keski-saari@nokia.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Defines VIO, VDD1, VDD2, VPLL1 and VINT* regulators as always_on by default
since they are critical to TWL and its master's functionality and should
be on in all cases where RegFW is used
Signed-off-by: NJuha Keski-Saari <ext-juha.1.keski-saari@nokia.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Define all twl4030 regulators in the twlreg_info table, along with
appropriate VSEL tables for adjustable regulators
Signed-off-by: NJuha Keski-Saari <ext-juha.1.keski-saari@nokia.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

When the mc13783-regulator driver is built in kernel, probing it during
the regulator subsystem initialisation result in a fault.

That is because regulator subsystem is planned to be initialised very early
in the boot process, before the mfd subsystem initialisation.

The mc12783-regulator probing process need to access to the mc13783-core
functionality to read/write mc13783 registers and so must be called after
the mc13783-core driver initialisation.

The way to do this is to let the kernel probe the mc13783-regulator driver when
mc13783-core register his regulator subdevice.
Signed-off-by: NAlberto Panizzo <maramaopercheseimorto@gmail.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>

Currently it is possible for regulator_bulk_{enable,disable} operations to
generate unbalanced regulator_{disable,enable} calls in its error path.
In case of an error only those regulators of the bulk operation which actually
had been enabled/disabled should get their original state restored.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>