Correct a spelling mistake in the Sixaxis HID descriptor comment.

Add an explanation as to why the Sixaxis has so many analog axes and why
some of them are seen as multi-touch axes.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Directly set the initial LED states in the device state struct instead
of copying them from a temporary array.

This allows for the removal of a redundant "x = x" copy loop in
sony_set_leds() that was taking place any time an LED was updated.

It also allows for the simplifying of the parameters in functions dealing
with LED initialization and updates since only a pointer to the sony_sc
struct is needed now.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Rearrange Sony controller devices into alphabetical order in the hardware
device list.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add a fixed-up HID descriptor for the Sony motion controller and enable
controls for the LED light as well as force-feedback.

The LED is multi-colored (red, green, blue).

The motion controller has a single rumble motor so the higher of the left
and right values is used to set the speed.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Adds the PID for the Sony motion controller to the hardware ID list.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

sony_allocate_output_report() was being called before sony_set_device_id()
which meant that an unallocated ida value was was freed if the output
report allocation failed and the probe function jumped to err_stop.

Do the device ID allocation before the output report allocation to avoid
freeing an unallocated value in case of a failure.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

HID Sensor Spec defines two usage ids for custom sensors

	HID_USAGE_SENSOR_TYPE_OTHER_CUSTOM (0x09, 0xE1)
	HID_USAGE_SENSOR_TYPE_OTHER_GENERIC(0x09, 0xE2)

	In addition the standard also defines usage ids for custom fields.
The purpose of these sensors is to extend the functionality or provide a way to
obfuscate the data being communicated by a sensor. Without knowing the mapping
between the data and its encapsulated form, it is difficult for an driver to
determine what data is being communicated by the sensor.  This allows some
differentiating use cases, where vendor can provide applications.  Since these
can't be represented by standard sensor interfaces like IIO, we present these
as fields with

- type (input/output)
- units
- min/max
- get/set value

In addition an dev interface to transfer report events. Details about this
interface is described in /Documentation/hid/hid-sensor.txt.  Manufacturers
should not use these ids for any standard sensors, otherwise the the
product/vendor id can be added to black list.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

In the unlikely case of hdev vanishing while hid_debug_events_read() was
sleeping, we can't really break out of the case switch as with other cases,
as on the way out we'll try to remove ourselves from the hdev waitqueue.

Fix this by taking a shortcut exit path and avoiding cleanup that doesn't
make sense in case hdev doesn't exist any more anyway.
Reported-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>