The device type was stored in sec_pmic_dev state container twice:
 - unsigned long type (initialized from of_device_id or i2c_device_id)
 - int device_type (initialized as above or from board files when there
   is no DTS)

The 'type' field was never used outside of probe so it can be safely
removed.

Change also the device_type in sec_pmic_dev and sec_platform_data to
unsigned long to avoid any casts.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Make sure that we patch the ACCCTL register as the first thing when the
driver loads, thus configuring I2C fast mode and i2c access for dual access
registers.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

In certain boards the source for the clk32k clock can be gated. In these
boards the clk32k clock can be provided to the driver and it is going to be
enabled/disabled when it is needed.
If the clk32k clock is not provided the driver will assume that it is always
running.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

All boards using twl6040 configures the i2c bus to 400KHz. While twl6040's
defaults to normal mode (100KHz). So far twl6040 has no problem with i2c
communication in this configuration it is safer to select fast i2c mode.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If for some reason the boot loader enabled the audpwron GPIO we will have
pending IRQs to be handled. This seams to break twl6040 for some reason
leading to non working i2c communication (i2c timeouts). Clearing the INTID
register after we requested the audpwron GPIO (and set it to low) will
ensure that the chip will operate normally in this case as well.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The supply aliases for the MFD devices were being added using devres but
the device hasn't been added at this point and as such we can't use
devres.

The MFD already has a function that removes devices this patch uses the
non-devres versions of the supply alias functions and adds an unregister
in mfd_remove_devices_fn.
Reported-by: NCarlo Caione <carlo@caione.org>
Reported-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The valid gpio is GPIO0 ~ GPIO58, so ngpio should be 59.
This patch also renames RDC321X_MAX_GPIO to RDC321X_NUM_GPIO because it
actually means the number of available GPIOs.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The rtc-s5m driver does not support all of S2M and S5M chipsets
supported by main MFD sec-core driver. For such chipsets unsupported by
rtc-s5m, the MFD sec-core driver initialized regmap with default config.
This config in such cases wouldn't work at all.

The main MFD sec-core driver shouldn't initialize regmap for child
drivers which is not used by them and even not valid.

Move the allocation of RTC I2C dummy device and initialization of RTC
regmap from main MFD sec-core driver to the rtc-s5m driver. The rtc-s5m
driver will use proper regmap config for supported devices.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This module has always been GPL licensed. It was just missing the explicit
declaration to avoid tainting the kernel.
Signed-off-by: NBill Richardson <wfrichar@chromium.org>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Panther Point PCH GPIO configuration is similar to V5 PCHs.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The isolation control register is required when DCVDD is externally
supplied add this in as a readable register.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

After request_threaded_irq() is called there is a chance that an interrupt
may occur before the 'mc13xxx->lock' is initialized, which will trigger a kernel
oops.

In order to prevent that, move the initialization of 'mc13xxx->lock' prior to
requesting the interrupts.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

On systems with CONFIG_FRAME_WARN=1024, compiler warns the allocation of
an object of struct device on stack. Make the allocation dynamically to
fix the warning. Also change the caller's return type to int so as to
account for error handling.

drivers/mfd/abx500-core.c: In function ‘abx500_dump_all_banks’:
drivers/mfd/abx500-core.c:167:1: warning: the frame size of 1032 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
Signed-off-by: NAurabindo J <mail@aurabindo.in>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This patch adds attributes to the Kontron PLD driver to allow
applications to retrieve firmware information.
Additionally the format has been changed to conform with the
representation in other Kontron software.
Signed-off-by: NMichael Brunner <michael.brunner@kontron.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This is a i2c driver, so uses i2c prefix in modalias.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Add missing mfd_remove_devices() call in remove function.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The TPS658640 has a different set of output voltage for most LDO and
the RTC LDO isn't settable. This chip also report 2 different version
ID, as the datasheet doesn't list the possible values the second ID
has simply been named TPS658640v2.
Signed-off-by: NAlban Bedel <alban.bedel@avionic-design.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add the required definitions and macros to allow easily adding fixed
regulators. This required for the TPS658640 that doesn't allow setting
the LDO_RTC output voltage.
Signed-off-by: NAlban Bedel <alban.bedel@avionic-design.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The only platform using the STMPE expander now boots from
device tree using all-dynamic GPIO and IRQ number assignments, so
remove the mechanism to pass this from the device tree entirely.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The commit e783c51c (ahci: imx: software workaround for phy reset issue
in resume) calls imx_sata_phy_reset() to reset phy immediately after
SATA MPLL is enabled.  It seems working fine mostly, but fails in some
case as below.

...
ahci-imx 2200000.sata: failed to reset phy: -110
ahci-imx: probe of 2200000.sata failed with error -110

After talking to the designer, we learnt that when enabling i.MX6Q SATA
MPLL, we need to wait 100us for it to settle down for safety.  Add this
required delay to fix above failure.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The incorrect register offset is passed to pci_wait_for_pending(), which is
caused by commit 157e876f ("PCI: Add pci_wait_for_pending() (refactor
pci_wait_for_pending_transaction())").

Fixes: 157e876f ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Williamson <alex.williamson@gmail.com>
CC: stable@vger.kernel.org	# v3.14+

On each processed XCOPY command, two "kmalloc-512" memory objects are
leaked. These represent two allocations of struct xcopy_pt_cmd in
target_core_xcopy.c.

The reason for the memory leak is that the cmd_kref field is not
initialized (thus, it is zero because the allocations were done with
kzalloc). When we decrement zero kref in target_put_sess_cmd, the result
is not zero, thus target_release_cmd_kref is not called.

This patch fixes the bug by moving kref initialization from
target_get_sess_cmd to transport_init_se_cmd (this function is called from
target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be
easily verified that all code that calls target_get_sess_cmd also calls
transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce
any new problems.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org	# 3.12+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Commit ee1de406 ("random: simplify accounting logic") simplified
things too much, in that it allows the following to trigger an
overflow that results in a BUG_ON crash:

dd if=/dev/urandom of=/dev/zero bs=67108707 count=1

Thanks to Peter Zihlstra for discovering the crash, and Hannes
Frederic for analyizing the root cause.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Reported-by: NPeter Zijlstra <peterz@infradead.org>
Reported-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Greg Price <price@mit.edu>

The value written to PLLE_AUX was incorrect due to a wrong variable
being used. Without this fix SATA does not work.

Cc: stable@vger.kernel.org
Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: NMikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>
[mturquette@linaro.org: improved changelog]

wdev->ifdev should be set by .change_virtual_intf(). This solves the
problem of WARN() messages on module unload.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Seems it helps some users, but causes issues for other users:
https://bugzilla.redhat.com/show_bug.cgi?id=1089545

So lets drop it for now until we've figured out a better fix.

Fixes: 43d94902 (ACPI / video: Add use_native_backlight quirks for more systems)
References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use a correct pipe type when filling un interrupt urbs. This should
finally take care of the WARN() messages on the console when USB urbs
are submitted.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Just like for pSCSI, if the transport sets get_write_cache, then it is
not valid to enable write cache emulation for it. Return an error.

see https://bugzilla.redhat.com/show_bug.cgi?id=1082675Reviewed-by: NChris Leech <cleech@redhat.com>
Signed-off-by: NAndy Grover <agrover@redhat.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch explicitly disables Immediate + Unsolicited Data for ISER
connections during login in iscsi_login_zero_tsih_s2() when protection
has been enabled for the session by the underlying hardware.

This is currently required because protection / signature memory regions
(MRs) expect T10 PI to occur on RDMA READs + RDMA WRITEs transfers, and
not on a immediate data payload associated with ISCSI_OP_SCSI_CMD, or
unsolicited data-out associated with a ISCSI_OP_SCSI_DATA_OUT.

v2 changes:
  - Add TARGET_PROT_DOUT_INSERT check (Sagi)
  - Add pr_debug noisemaker (Sagi)
  - Add goto to avoid early return from MRDSL check (nab)

Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a free-after-use regression in ft_free_cmd(), where
ft_sess_put() is called with cmd->sess after percpu_ida_free() has
already released the tag.

Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(),
and pass it directly to ft_sess_put().

The regression was originally introduced in v3.13-rc1 commit:

  commit 5f544cfa
  Author: Nicholas Bellinger <nab@daterainc.com>
  Date:   Mon Sep 23 12:12:42 2013 -0700

      tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd
Reported-by: NJun Wu <jwu@stormojo.com>
Cc: Mark Rustad <mark.d.rustad@intel.com>
Cc: Robert Love <robert.w.love@intel.com>
Cc: <stable@vger.kernel.org> #3.13+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch changes an incorrect use of BUG_ON to instead generate a
REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code.  This case
can occur with traditional TCP where a flood of zeros in the data
stream can reach this block for what is presumed to be a NOP-OUT with
a solicited reply, but without a valid iscsi_cmd pointer.

This incorrect BUG_ON was introduced during the v3.11-rc timeframe
with the following commit:

commit 778de368
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Jun 14 16:07:47 2013 -0700

    iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling
Reported-by: NArshad Hussain <arshad.hussain@calsoftinc.com>
Cc: stable@vger.kernel.org # 3.11+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

When the target is in stop stage, iSER transport initiates RDMA disconnects.
The iSER initiator may wish to establish a new connection over the
still existing network portal. In this case iSER transport should not
accept and resume new RDMA connections. In order to learn that, iscsi_np
is added with enabled flag so the iSER transport can check when deciding
weather to accept and resume a new connection request.

The iscsi_np is enabled after successful transport setup, and disabled
before iscsi_np login threads are cleaned up.
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

RDMA CM and iSCSI target flows are asynchronous and completely
uncorrelated. Relying on the fact that iscsi_accept_np will be called
after CM connection request event and will wait for it is a mistake.

When attempting to login to a few targets this flow is racy and
unpredictable, but for parallel login to dozens of targets will
race and hang every time.

The correct synchronizing mechanism in this case is pending on
a semaphore rather than a wait_for_event. We keep the pending
interruptible for iscsi_np cleanup stage.

(Squash patch to remove dead code into parent - nab)
Reported-by: NSlava Shwartsman <valyushash@gmail.com>
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Should be adding list_add_tail($new, $head) and not
the other way around.
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Userspace tools assume if a value is read from configfs, it is valid
and will not cause an error if the same value is written back. The only
valid value for pi_prot_type for backends not supporting DIF is 0, so allow
this particular value to be set without returning an error.
Reported-by: NKrzysztof Chojnowski <frirajder@gmail.com>
Signed-off-by: NAndy Grover <agrover@redhat.com>
Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

When a new device is added below a hotplug bridge, the bridge's secondary
bus speed and the device's bus speed must match.  The shpchp driver
previously checked the bridge's *primary* bus speed, not the secondary bus
speed.

This caused hot-add errors like:

  shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

Check the secondary bus speed instead.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
Fixes: 3749c51a ("PCI: Make current and maximum bus speeds part of the PCI core")
Signed-off-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
CC: stable@vger.kernel.org	# v2.6.34+

On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.

In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.

Increase the WM memory latency values to at least 1.2 usec on SNB.
Hopefully this won't have a significant effect on power consumption.

v2: Increase the latency values regardless of the pixel clock

Cc: Robert N <crshman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254Tested-by: NRobert Navarro <crshman@gmail.com>
Tested-by: NVitaly Minko <vitaly.minko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.

To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by: NNico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This matches the algorithm used by earlier kernels when selecting the
mode for the fbcon. And only if there is no modes at all, do we fall
back to using the BIOS configuration. Seamless transition is still
preserved (from the BIOS configuration to ours) so long as the BIOS has
also chosen what we hope is the native configuration.
Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKnut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[Jani: applied Chris' "Please imagine that I wrote this correctly."]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

There are certain BDW high res eDP machines that regressed due to

commit 38aecea0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Mar 3 11:18:10 2014 +0100

    drm/i915: reverse dp link param selection, prefer fast over wide again

The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
2.7 Gbps on the affected machines. Link training succeeded for both, but
the screen remained blank with the former config. Further investigation
showed that 4 lanes at 5.4 Gbps worked also.

The root cause for the blank screen using 2 lanes remains unknown, but
apparently the driver for a certain other operating system by default
uses the max available lanes. Follow suit on Broadwell eDP, for at least
until we figure out what is going on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>