Commit 297d716f ("power_supply: Change ownership from driver to
core") inverted the logic in battery_notify().  As an effect already
present battery was re-added on each system suspend or hibernation.

    WARNING: CPU: 0 PID: 303 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
    sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0'
    CPU: 0 PID: 303 Comm: rtcwake Not tainted 4.0.0-ARCH-02621-g07e6253af953 #48
    Call Trace:
      sysfs_create_dir_ns+0x8d/0xa0
      kobject_add_internal+0xb6/0x370
      kobject_add+0x6f/0xd0
      device_add+0x120/0x6c0
      __power_supply_register+0x145/0x290
      power_supply_register_no_ws+0x10/0x20
      sysfs_add_battery+0x84/0xc5 [battery]
      battery_notify+0x45/0x6b [battery]
      notifier_call_chain+0x4f/0x80
      __blocking_notifier_call_chain+0x4b/0x70
      blocking_notifier_call_chain+0x16/0x20
      pm_notifier_call_chain+0x1a/0x40
      pm_suspend+0x3ed/0x4e0
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

pwm_config() must be called with a duty cycle of 0 prior to calling
pwm_disable() to ensure that the pwm signal is set to low.
Reported-by: NMarkus Reichl <m.reichl@fivetechno.de>
Tested-by: NMarkus Reichl <m.reichl@fivetechno.de>
Reviewed-by: NLukasz Majewski <l.majewski@samsung.com>
Reviewed-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NAnand Moon <linux.amoon@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

This reverts commit ecc19d17.

It added a new warning to try to encourage driver writers to set the
device capabities properly, but drivers haven't been updated and in the
meantime it just generaters a scary message that users cannot actually
do anything about.

Warnings like these are appropriate if you actually expect to fix the
code that causes them.  They are not appropriate for releases.
Requested-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add missing directions, residue_granularity,
srd_addr_widths and dst_addr_widths bitfields.

Without those we will see a kernel WARN()
when loading musb on am335x devices.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The code was using an normal completion, but that caused stuck
task errors after a while.  Use an interruptible one to avoid that.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

If ipmi_powernv_recv(...) is called without a current message it
prints a warning and returns. However it fails to release the message
lock causing the system to dead lock during any subsequent IPMI
operations.

This error path should never normally be taken unless there are bugs
elsewhere in the system.
Signed-off-by: NAlistair Popple <alistair@popple.id.au>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Some BMCs don't let you clear the receive irq bit in the global
enables.  This is kind of silly, but they give an error if you
try to clear it.  Compensate for this by detecting the situation
and working around it.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NThomas D <whissi@whissi.de>
Reviewed-by: NThomas D <whissi@whissi.de>

This fixes a oops due to a double list add when adding a reject PDU for
iscsit_allocate_iovecs allocation failures. The cmd has already been
added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call
iscsit_reject_cmd.

Note that for ERL0 the reject PDU is not actually sent, so this patch
is not completely tested. Just verified we do not oops. The problem is the
add reject functions return -1 which is returned all the way up to
iscsi_target_rx_thread which for ERL0 will drop the connection.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

In cases of short transfer times the CPU is spending lots of time
in the interrupt handler and scheduler to reschedule the worker thread.

Measurements show that we have times where it takes 29.32us to between
the last clock change and the time that the worker-thread is running again
returning from wait_for_completion_timeout().

During this time the interrupt-handler is running calling complete()
and then also the scheduler is rescheduling the worker thread.

This time can vary depending on how much of the code is still in
CPU-caches, when there is a burst of spi transfers the subsequent delays
are in the order of 25us, so the value of 30us seems reasonable.

With polling the whole transfer of 4 bytes at 10MHz finishes after 6.16us
(CS down to up) with the real transfer (clock running) taking 3.56us.
So the efficiency has much improved and is also freeing CPU cycles,
reducing interrupts and context switches.

Because of the above 30us seems to be a reasonable limit for polling.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Transforms the bcm-2835 native SPI-chip select to their gpio-cs equivalent.

This allows for some support of some optimizations that are not
possible due to HW-gliches on the CS line - especially filling
the FIFO before enabling SPI interrupts (by writing to CS register)
while the transfer is already in progress (See commit: e3a2be30)

This patch also works arround some issues in bcm2835-pinctrl which does not
set the value when setting the GPIO as output - it just sets up output and
(typically) leaves the GPIO as low.  When a fix for this is merged then this
gpio_set_value can get removed from bcm2835_spi_setup.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

It is not necessary to have regulator init data for a regulator. This
patch removes the necessity of this data and handles a NULL pointer
properly.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Voltage regulators can have (unregulated) current limits too, so we should
probably output both voltage and current for all regulators.

Holding the rdev->mutex actually conflicts with _regulator_get_current_limit
but also is not really necessary, as the global regulator_list_mutex already
protects us from the regulator vanishing while we go through the list.

On the rk3288-firefly the summary now looks like:

 regulator                      use open bypass voltage current     min     max
-------------------------------------------------------------------------------
 vcc_sys                          0   12      0  5000mV     0mA  5000mV  5000mV
    vcc_lan                       1    1      0  3300mV     0mA  3300mV  3300mV
       ff290000.ethernet                                            0mV     0mV
    vcca_33                       0    0      0  3300mV     0mA  3300mV  3300mV
    vcca_18                       0    0      0  1800mV     0mA  1800mV  1800mV
    vdd10_lcd                     0    0      0  1000mV     0mA  1000mV  1000mV
 [...]
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

On modern systems the regulator hierarchy can get quite long and nested
with regulators supplying other regulators. In some cases when debugging
it might be nice to get a tree of these regulators, their consumers
and the regulation constraints in one go.

To achieve this add a regulator_summary sysfs node, similar to
clk_summary in the common clock framework, that walks the regulator
list and creates a tree out of the regulators, their consumers and
core per-regulator settings.

On a rk3288-firefly the regulator_summary would for example look
something like:

 regulator                      use open bypass   value     min     max
-----------------------------------------------------------------------
 vcc_sys                          0   12      0  5000mV  5000mV  5000mV
    vcc_lan                       1    1      0  3300mV  3300mV  3300mV
       ff290000.ethernet                                    0mV     0mV
    vcca_33                       0    0      0  3300mV  3300mV  3300mV
    vcca_18                       0    0      0  1800mV  1800mV  1800mV
    vdd10_lcd                     0    0      0  1000mV  1000mV  1000mV
    vccio_sd                      0    0      0  3300mV  3300mV  3300mV
    vcc_20                        0    3      0  2000mV  2000mV  2000mV
       vcc18_lcd                  0    0      0  1800mV  1800mV  1800mV
       vcc_18                     0    2      0  1800mV  1800mV  1800mV
          ff100000.saradc                                   0mV     0mV
          ff0d0000.dwmmc                                 1650mV  1950mV
       vdd_10                     0    0      0  1000mV  1000mV  1000mV
    vdd_log                       0    0      0  1100mV  1100mV  1100mV
    vcc_io                        0    3      0  3300mV  3300mV  3300mV
       ff0f0000.dwmmc                                    3300mV  3400mV
       vcc_flash                  1    1      0  1800mV  1800mV  1800mV
          ff0f0000.dwmmc                                 1700mV  1950mV
       vcc_sd                     1    1      0  3300mV  3300mV  3300mV
          ff0c0000.dwmmc                                 3300mV  3400mV
    vcc_ddr                       0    0      0  1200mV  1200mV  1200mV
    vdd_gpu                       0    0      0  1000mV   850mV  1350mV
    vdd_cpu                       0    1      0   900mV   850mV  1350mV
       cpu0                                               900mV   900mV
    vcc_5v                        0    2      0  5000mV  5000mV  5000mV
       vcc_otg_5v                 0    0      0  5000mV  5000mV  5000mV
       vcc_host_5v                0    0      0  5000mV  5000mV  5000mV
 regulator-dummy                  0    0      0     0mV     0mV     0mV
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Ran checkpatch.pl on file and removed a warning about an unwanted space before
a tab.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

msleep(USB_RESUME_TIMEOUT) must be done when the controller drives
the resume. This is true after HPRT0_RES is written.
Moreover, restore the delay after controller power is up.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some additional quirks need to be enabled now we support UHS
modes. This avoids some spurious warnings like

"Got data interrupt 0x00000002 even though no data operation was in progress"

Testing on stih410-b2120 board achieves the following speeds
with HS200 eMMC card.

max-frequency = 200Mhz
/dev/mmcblk0p1:
 Timing buffered disk reads: 270 MB in  3.02 seconds =  89.54 MB/sec

max-frequency = 100Mhz
root@debian-armhf:~# hdparm -t /dev/mmcblk0p1
/dev/mmcblk0p1:
 Timing buffered disk reads: 210 MB in  3.00 seconds =  70.00 MB/sec

max-frequency = 50Mhz
root@debian-armhf:~# hdparm -t /dev/mmcblk0p1
/dev/mmcblk0p1:
 Timing buffered disk reads: 118 MB in  3.00 seconds =  39.28 MB/sec

This is better than the 3.10 kernel which achieves 77.59 MB/sec
at 200Mhz clock (same board/soc/eMMC).
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To allow UHS modes to work properly we need to provide the st specific
set_uhs_signaling callback function. This function differs from the
generic sdhci_set_uhs_signaling callback in that we need to configure
the correct delay depending on the UHS mode, and also set the V18_EN
bit.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

STiH407 family SoC's have glue registers in the flashSS subsystem which
are used to configure the Arasan HC. This patch configures these glue
registers according to what has been specified in the DT.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Due to the tight timing constraints in some UHS modes, it is required to have
some delay management in the design. Two types of delay management are supported
in the HW: -

1) Static delay management
2) Dynamic delay management

NB: The delay management is only there when eMMC interface is selected.

1: Static delay management: is used to provide PVT dependent static delay on the
clock/data lines to manage setup/hold requirements of the interface. The maximum
delay possible is 3.25ns. These delays are PVT dependent, and thus delay values
applied are not accurate and vary across provcess voltage and temperature range.
Due to this these delays must not be used on the very time critical paths.

2. Dynamic delay locked loop (DLL): is used to provide dynamic delay management.
The advantage of DLL is that it provides accurate & PVT indepedent delay.

The DLL is used to provide delay on the loopback clock on "Read Path" to capture
read data reliably. On TX path the clock on which output data is transmitted is
delayed, resulting in delay of TX data.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

STiH407 family SoC's can have a reset signal for the controller which needs to
be managed. Also the eMMC controller has some additional 'top' memory mapped
registers which are used to manage the dynamic and static delay required for
UHS modes. This patch adds support for creating the mapping, which will be used
by subsequent patches.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The stih407 family SoC's have additional glue registers in the flashSS which
are used to configure the Arasan controller.

This patch adds macros for the register offsets and bitfields which will be
used by subsequent patches to support stih407 family SoC's.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since commit 20d0189b
in v3.14-rc1 RAID0 has performed incorrect calculations
when the chunksize is not a power of 2.

This happens because "sector_div()" modifies its first argument, but
this wasn't taken into account in the patch.

So restore that first arg before re-using the variable.
Reported-by: NJoe Landman <joe.landman@gmail.com>
Reported-by: NDave Chinner <david@fromorbit.com>
Fixes: 20d0189b
Cc: stable@vger.kernel.org (3.14 and later).
Signed-off-by: NNeilBrown <neilb@suse.de>

Reading both the capability ID and "next" pointer at the same time lets us
parse the list with half the number of config reads.
Signed-off-by: NSean O. Stalley <sean.stalley@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

devm_ioremap_resource() validates the resource it receives, so if we check
for devm_ioremap_resource() failure, we need not check for failure of the
preceding platform_get_resource().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Check for failure from platform_get_resource() (this check actually happens
inside devm_ioremap_resource()) before dereferencing the pointer returned
from platform_get_resource().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Check for failure of devm_ioremap_resource().

devm_ioremap_resource() validates the resource it receives, so if we check
for devm_ioremap_resource() failure, we need not check for failure of the
preceding platform_get_resource().

[bhelgaas: changelog]
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Communications with a hardware vendor confirm that the expected behaviour
on systems that set the FADT ASPM disable bit but which still grant full
PCIe control is for the OS to leave any BIOS configuration intact and
refuse to touch the ASPM bits.  This mimics the behaviour of Windows.
Signed-off-by: NMatthew Garrett <mjg59@coreos.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Feature macros work on sio_data as well, so use them there.
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Currently it is not possible to use 'mmc-pwrseq-simple' property with this
driver because mmc_of_parse() is never called.

mmc_of_parse() calls mmc_pwrseq_alloc() that manages MMC power sequence and
allows passing GPIOs in the devicetree to properly power/reset the Wifi
chipset.

When using mmc_of_parse() we no longer need to have custom code to request
card-detect and write-protect pins, as this can now be handled by the mmc
core.

Tested on a imx6sl-warp board where BT/Wifi is functional and also on a
imx6q-sabresd.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It is possible for the cmd11 interrupt to fire and delete the
cmd11_timer before the cmd11_timer was actually setup.  Let's fix this
race by adding a few spinlocks.  Note that the race wasn't seen in
practice without adding some printk statements, but it still seems
wise to fix.

Fixes: 5c935165 ("mmc: dw_mmc: Add a timeout for sending CMD11")
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If we get an unexpected cmd11 timeout we shouldn't actually treat it
as a timeout (not that we really expect to get an unexpected cmd11
timeout, but still).

Fixes: 5c935165 ("mmc: dw_mmc: Add a timeout for sending CMD11")
Reported-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Although the cmd11 interrupt should come within 2ms, that's a very
short time.  Let's increase the timeout to be really sure that we
don't get an accidnetal timeout.  One case in particular this is
useful is if you've got a serial console and printk in just the right
places.  Under that scenario I've seen delays of up to 130ms before
the interrupt fired.

CMD11 is only sent during card insertion, so this extra timeout
shouldn't be terrible.

Fixes: 5c935165 ("mmc: dw_mmc: Add a timeout for sending CMD11")
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The dw_mmc driver changes to make the IO accesors endian agnostic did not
take into account the fifo accesses do not need to be swapped. To fix this
add a mmci_fifo_read/write wrapper to allow these to be passed through the
IO without being swapped.

Since these are now specific functions, it would be easier just to store
the pointer to the fifo registers in the host block instead of the offset
to them. So change the host->data_offset to host->fifo_reg (which also
means we catch all the places this is read or written).
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The dw_mmc driver does not take into account the processor may be in
big endian when writing the descriptors. Change the descriptors for
the 32bit IDMA to use __le32 and ensure they are suitably swapped
before writing.

Note, this has not been tested as the socfpga driver does not try to
use idma.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The dw_mmc driver does not use endian agnostic IO accessors, so fix
the use of __raw reads and writes to be the relaxed versions.

This fixes the dw_mmc driver initialisation on Altera socfpga in big endian.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Fix
drivers/hwmon/ibmpowernv.c: In function 'get_logical_cpu':
drivers/hwmon/ibmpowernv.c:121:3:
	error: implicit declaration of function 'get_hard_smp_processor_id'

seen for some configurations, possibly if SMP is not configured.

Fixes: 3df2f59f ("hwmon: (ibmpowernv) pretty print labels")
Cc: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Thermal framework may already be ready and cooling policies might
already be functional when we are attempting to register gpio fan as
a cooling device. This can be reproduced by changing probe order in
which registration of various modules are done in a system. In such
a case, kernel generates an oops since the data structures are not
completely populated with the wrong assumption that thermal framework
is not yet ready. Fix this by reordering the thermal framework
registration to occur after hwmon registration of the fan is complete.

Example kernel oops:
[  149.005828] Unable to handle kernel NULL pointer dereference at virtual address 0000008c
[  149.014369] pgd = ecf48000
[  149.017204] [0000008c] *pgd=ac065831, *pte=00000000, *ppte=00000000
[  149.023820] Internal error: Oops: 17 [#1] SMP ARM
[  149.028745] Modules linked in: gpio_fan(+) cpufreq_dt ipv6 evdev leds_gpio led_class omap_wdt phy_omap_usb2 rtc_palmas palmas_pwrbutton tmp102 ti_soc_thermal dwc3_omap thermal_sys extcon rtc_omap rtc_ds1307 hwmon
[  149.048629] CPU: 1 PID: 1183 Comm: modprobe Not tainted 4.0.0-rc7-next-20150407-00002-g7a82da074c99 #3
[  149.058383] Hardware name: Generic DRA74X (Flattened Device Tree)
[  149.064763] task: edec1240 ti: ec0e0000 task.ti: ec0e0000
[  149.070421] PC is at dev_driver_string+0x0/0x38
[  149.075165] LR is at __dev_printk+0x24/0x70
[  149.079540] pc : [<c03d6cd0>]    lr : [<c03d72c4>]    psr: 20000013
[  149.079540] sp : ec0e1c28  ip : edec1240  fp : 00000000
[  149.091568] r10: edf3eee0  r9 : 00000000  r8 : ffffffff
[  149.097040] r7 : edf3eea0  r6 : 00000034  r5 : 00000010  r4 : ec0e1c44
[  149.103871] r3 : ec0e1c4c  r2 : ec0e1c44  r1 : c079d800  r0 : 00000010
[  149.110709] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  149.118182] Control: 10c5387d  Table: acf4806a  DAC: 00000015
[  149.124198] Process modprobe (pid: 1183, stack limit = 0xec0e0218)
[  149.130673] Stack: (0xec0e1c28 to 0xec0e2000)
[  149.135235] 1c20:                   60000013 c05e2ae0 00000000 edf3ec00 ec934a10 c03d73d4
...
[  149.392230] 1fe0: befe1888 befe1878 00019418 b6ea08f0 80000010 00000003 00000000 00000000
[  149.400798] [<c03d6cd0>] (dev_driver_string) from [<c03d72c4>] (__dev_printk+0x24/0x70)
[  149.409193] [<c03d72c4>] (__dev_printk) from [<c03d73d4>] (dev_warn+0x34/0x48)
[  149.416767] [<c03d73d4>] (dev_warn) from [<bf0f54fc>] (get_fan_speed_index+0x94/0xa4 [gpio_fan])
[  149.425980] [<bf0f54fc>] (get_fan_speed_index [gpio_fan]) from [<bf0f5524>] (gpio_fan_get_cur_state+0x18/0x30 [gpio_fan])
[  149.437476] [<bf0f5524>] (gpio_fan_get_cur_state [gpio_fan]) from [<bf02767c>] (thermal_zone_trip_update+0xe8/0x2a4 [thermal_sys])
[  149.449794] [<bf02767c>] (thermal_zone_trip_update [thermal_sys]) from [<bf027844>] (step_wise_throttle+0xc/0x74 [thermal_sys])
[  149.461832] [<bf027844>] (step_wise_throttle [thermal_sys]) from [<bf024ff4>] (handle_thermal_trip+0x5c/0x188 [thermal_sys])
[  149.473603] [<bf024ff4>] (handle_thermal_trip [thermal_sys]) from [<bf0256c4>] (thermal_zone_device_update+0x94/0x108 [thermal_sys])
[  149.486104] [<bf0256c4>] (thermal_zone_device_update [thermal_sys]) from [<bf026470>] (__thermal_cooling_device_register+0x2e8/0x374 [thermal_sys])
[  149.499956] [<bf026470>] (__thermal_cooling_device_register [thermal_sys]) from [<bf0f58e4>] (gpio_fan_probe+0x350/0x4d0 [gpio_fan])
[  149.512438] [<bf0f58e4>] (gpio_fan_probe [gpio_fan]) from [<c03db8a0>] (platform_drv_probe+0x48/0x98)
[  149.522109] [<c03db8a0>] (platform_drv_probe) from [<c03da30c>] (driver_probe_device+0x1b0/0x26c)
[  149.531399] [<c03da30c>] (driver_probe_device) from [<c03da45c>] (__driver_attach+0x94/0x98)
[  149.540238] [<c03da45c>] (__driver_attach) from [<c03d8bb0>] (bus_for_each_dev+0x54/0x88)
[  149.548814] [<c03d8bb0>] (bus_for_each_dev) from [<c03d9a34>] (bus_add_driver+0xdc/0x1d4)
[  149.557381] [<c03d9a34>] (bus_add_driver) from [<c03dac30>] (driver_register+0x78/0xf4)
[  149.565765] [<c03dac30>] (driver_register) from [<c0009784>] (do_one_initcall+0x80/0x1d8)
[  149.574340] [<c0009784>] (do_one_initcall) from [<c00c2278>] (do_init_module+0x5c/0x1b8)
[  149.582833] [<c00c2278>] (do_init_module) from [<c00c3bbc>] (load_module+0x1720/0x1dcc)
[  149.591212] [<c00c3bbc>] (load_module) from [<c00c43d0>] (SyS_finit_module+0x68/0x6c)
[  149.599418] [<c00c43d0>] (SyS_finit_module) from [<c000f3c0>] (ret_fast_syscall+0x0/0x4c)
[  149.607994] Code: 15830000 e1a00006 e28dd008 e8bd8070 (e590307c)

Cc: Eduardo Valentin <edubezval@gmail.com>
Fixes: b5cf88e4 ("(gpio-fan): Add thermal control hooks")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Phong Vo <pvo@apm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tin Huynh <tnhuynh@apm.com>
Cc: Y Vo <yvo@apm.com>
Cc: Toan Le <toanle@apm.com>
Cc: Bjorn Andersson <bjorn@kryo.se>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Link: http://lkml.kernel.org/r/1426676484-21812-4-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Add the required hooks for the internal state of an interrupt
to be exposed to other subsystems.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Phong Vo <pvo@apm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tin Huynh <tnhuynh@apm.com>
Cc: Y Vo <yvo@apm.com>
Cc: Toan Le <toanle@apm.com>
Cc: Bjorn Andersson <bjorn@kryo.se>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Link: http://lkml.kernel.org/r/1426676484-21812-3-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The PCI "ACPI additions for FW latency optimizations" ECN (link below)
defines two functions in the PCI _DSM:

  Function 8, "Reset Delay," applies to the entire hierarchy below a PCI
  host bridge.  If it returns one, the OS may assume that all devices in
  the hierarchy have already completed power-on reset delays.

  Function 9, "Device Readiness Durations," applies only to the object
  where it is located.  It returns delay durations required after various
  events if the device requires less time than the spec requires.  Delays
  from this function take precedence over the Reset Delay function.

Add support for Reset Delay and part of Device Readiness Durations.

[bhelgaas: changelog, comments]
Link: https://www.pcisig.com/specifications/conventional/pci_firmware/ECN_fw_latency_optimization_final.pdfSigned-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>