linux-stable.git/drivers, branch v4.7.6 Linux kernel stable tree iw_cxgb4: stop MPA_REPLY timer when disconnecting 2016-09-30T08:12:48+00:00 Steve Wise swise@opengridcomputing.com 2016-07-29T15:38:44+00:00 c270b18bea75269388a7089b080840884c9d5d5c commit 12eb5137edecfd8fb6d23dacec2a3630e729736f upstream. There exists a race where the application can setup a connection and then disconnect it before iw_cxgb4 processes the fw4_ack message. For passive side connections, the fw4_ack message is used to know when to stop the ep timer for MPA_REPLY messages. If the application disconnects before the fw4_ack is handled then c4iw_ep_disconnect() needs to clean up the timer state and stop the timer before restarting it for the disconnect timer. Failure to do this results in a "timer already started" message and a premature stopping of the disconnect timer. Fixes: e4b76a2 ("RDMA/iw_cxgb4: stop_ep_timer() after MPA negotiation") Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 12eb5137edecfd8fb6d23dacec2a3630e729736f upstream.

There exists a race where the application can setup a connection
and then disconnect it before iw_cxgb4 processes the fw4_ack
message.  For passive side connections, the fw4_ack message is
used to know when to stop the ep timer for MPA_REPLY messages.

If the application disconnects before the fw4_ack is handled then
c4iw_ep_disconnect() needs to clean up the timer state and stop the
timer before restarting it for the disconnect timer.  Failure to do this
results in a "timer already started" message and a premature stopping
of the disconnect timer.

Fixes: e4b76a2 ("RDMA/iw_cxgb4: stop_ep_timer() after MPA negotiation")

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qxl: check for kmap failures 2016-09-30T08:12:48+00:00 Dan Carpenter dan.carpenter@oracle.com 2016-07-11T08:46:33+00:00 cb106d2a2c6b3d1d2459c0807b0d944983cbcc05 commit f4cceb2affcd1285d4ce498089e8a79f4cd2fa66 upstream. If kmap fails, it leads to memory corruption. Fixes: f64122c1f6ad ('drm: add new QXL driver. (v1.4)') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f4cceb2affcd1285d4ce498089e8a79f4cd2fa66 upstream.

If kmap fails, it leads to memory corruption.

Fixes: f64122c1f6ad ('drm: add new QXL driver. (v1.4)')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160711084633.GA31411@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
soc/tegra: pmc: Don't probe PMC if early initialisation fails 2016-09-30T08:12:48+00:00 Jon Hunter jonathanh@nvidia.com 2016-06-28T10:38:28+00:00 3010fb28c8345a9c9d1b807e5d1b62c496d414ad commit a83f1fc3f33930d01e579b9d4de92a045297b402 upstream. Commit 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure') fixes an issue where the PMC base address pointer is not restored on probe failure. However, this fix creates another problem where if early initialisation of the PMC driver fails and an initial mapping for the PMC address space is not created, then when the PMC device is probed, the PMC base address pointer will not be valid and this will cause a crash when tegra_pmc_init() is called and attempts to access a register. Although the PMC address space is mapped a 2nd time during the probe and so this could be fixed by populating the base address pointer earlier during the probe, this adds more complexity to the code. Moreover, the PMC probe also assumes the the soc data pointer is also initialised when the device is probed and if not will also lead to a crash when calling tegra_pmc_init_tsense_reset(). Given that if the early initialisation does fail then something bad has happen, it seems acceptable to allow the PMC device probe to fail as well. Therefore, if the PMC base address pointer or soc data pointer are not valid when probing the PMC device, WARN and return an error. Fixes: 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure') Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a83f1fc3f33930d01e579b9d4de92a045297b402 upstream.

Commit 0259f522e04f ('soc/tegra: pmc: Restore base address on probe
failure') fixes an issue where the PMC base address pointer is not
restored on probe failure. However, this fix creates another problem
where if early initialisation of the PMC driver fails and an initial
mapping for the PMC address space is not created, then when the PMC
device is probed, the PMC base address pointer will not be valid and
this will cause a crash when tegra_pmc_init() is called and attempts
to access a register.

Although the PMC address space is mapped a 2nd time during the probe
and so this could be fixed by populating the base address pointer
earlier during the probe, this adds more complexity to the code.
Moreover, the PMC probe also assumes the the soc data pointer is also
initialised when the device is probed and if not will also lead to a
crash when calling tegra_pmc_init_tsense_reset(). Given that if the
early initialisation does fail then something bad has happen, it seems
acceptable to allow the PMC device probe to fail as well. Therefore, if
the PMC base address pointer or soc data pointer are not valid when
probing the PMC device, WARN and return an error.

Fixes: 0259f522e04f ('soc/tegra: pmc: Restore base address on probe failure')
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
igb: fix adjusting PTP timestamps for Tx/Rx latency 2016-09-30T08:12:48+00:00 Kshitiz Gupta kshitiz.gupta@ni.com 2016-07-16T07:23:45+00:00 3350bf2d7f3aad711a2ae3b29e8cfff26143246c commit 0066c8b6f4050d7c57f6379d6fd4535e2f267f17 upstream. Fix PHY delay compensation math in igb_ptp_tx_hwtstamp() and igb_ptp_rx_rgtstamp. Add PHY delay compensation in igb_ptp_rx_pktstamp(). In the IGB driver, there are two functions that retrieve timestamps received by the PHY - igb_ptp_rx_rgtstamp() and igb_ptp_rx_pktstamp(). The previous commit only changed igb_ptp_rx_rgtstamp(), and the change was incorrect. There are two instances in which PHY delay compensations should be made: - Before the packet transmission over the PHY, the latency between when the packet is timestamped and transmission of the packets, should be an add operation, but it is currently a subtract. - After the packets are received from the PHY, the latency between the receiving and timestamping of the packets should be a subtract operation, but it is currently an add. Signed-off-by: Kshitiz Gupta <kshitiz.gupta@ni.com> Fixes: 3f544d2 (igb: adjust ptp timestamps for tx/rx latency) Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0066c8b6f4050d7c57f6379d6fd4535e2f267f17 upstream.

Fix PHY delay compensation math in igb_ptp_tx_hwtstamp() and
igb_ptp_rx_rgtstamp. Add PHY delay compensation in
igb_ptp_rx_pktstamp().

In the IGB driver, there are two functions that retrieve timestamps
received by the PHY - igb_ptp_rx_rgtstamp() and igb_ptp_rx_pktstamp().
The previous commit only changed igb_ptp_rx_rgtstamp(), and the change
was incorrect.

There are two instances in which PHY delay compensations should be
made:

- Before the packet transmission over the PHY, the latency between
  when the packet is timestamped and transmission of the packets,
  should be an add operation, but it is currently a subtract.

- After the packets are received from the PHY, the latency between
  the receiving and timestamping of the packets should be a subtract
  operation, but it is currently an add.

Signed-off-by: Kshitiz Gupta <kshitiz.gupta@ni.com>
Fixes: 3f544d2 (igb: adjust ptp timestamps for tx/rx latency)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ixgbe: Re-enable ability to toggle VLAN filtering 2016-09-30T08:12:48+00:00 Alexander Duyck alexander.h.duyck@intel.com 2016-08-12T16:53:39+00:00 03c35e10e68d3dafd2a8189a37b20c21695d1e74 commit 3d951822be216d8c6fcfc8abf75e5ed307eeb646 upstream. Back when I submitted the GSO code I messed up and dropped the support for disabling the VLAN tag filtering via the feature bit. This patch re-enables the use of the NETIF_F_HW_VLAN_CTAG_FILTER to enable/disable the VLAN filtering independent of toggling promiscuous mode. Fixes: b83e30104b ("ixgbe/ixgbevf: Add support for GSO partial") Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3d951822be216d8c6fcfc8abf75e5ed307eeb646 upstream.

Back when I submitted the GSO code I messed up and dropped the support for
disabling the VLAN tag filtering via the feature bit.  This patch
re-enables the use of the NETIF_F_HW_VLAN_CTAG_FILTER to enable/disable the
VLAN filtering independent of toggling promiscuous mode.

Fixes: b83e30104b ("ixgbe/ixgbevf: Add support for GSO partial")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ixgbe: Force VLNCTRL.VFE to be set in all VMDq paths 2016-09-30T08:12:48+00:00 Alexander Duyck alexander.h.duyck@intel.com 2016-08-11T21:51:56+00:00 b4cc7dd0636a4bdf2987474dd7063044c262faab commit f60439bc21e3337429838e477903214f5bd8277f upstream. When I was adding the code for enabling VLAN promiscuous mode with SR-IOV enabled I had inadvertently left the VLNCTRL.VFE bit unchanged as I has assumed there was code in another path that was setting it when we enabled SR-IOV. This wasn't the case and as a result we were just disabling VLAN filtering for all the VFs apparently. Also the previous patches were always clearing CFIEN which was always set to 0 by the hardware anyway so I am dropping the redundant bit clearing. Fixes: 16369564915a ("ixgbe: Add support for VLAN promiscuous with SR-IOV") Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f60439bc21e3337429838e477903214f5bd8277f upstream.

When I was adding the code for enabling VLAN promiscuous mode with SR-IOV
enabled I had inadvertently left the VLNCTRL.VFE bit unchanged as I has
assumed there was code in another path that was setting it when we enabled
SR-IOV.  This wasn't the case and as a result we were just disabling VLAN
filtering for all the VFs apparently.

Also the previous patches were always clearing CFIEN which was always set
to 0 by the hardware anyway so I am dropping the redundant bit clearing.

Fixes: 16369564915a ("ixgbe: Add support for VLAN promiscuous with SR-IOV")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: supply: max17042_battery: fix model download bug. 2016-09-30T08:12:48+00:00 Sven Van Asbroeck thesven73@gmail.com 2016-08-12T13:10:27+00:00 1a659cc00489659a654dffb66ff9b76b3b9f102d commit 5381cfb6f0422da24cfa9da35b0433c0415830e0 upstream. The device's model download function returns the model data as an array of u32s, which is later compared to the reference model data. However, since the latter is an array of u16s, the comparison does not happen correctly, and model verification fails. This in turn breaks the POR initialization sequence. Fixes: 39e7213edc4f3 ("max17042_battery: Support regmap to access device's registers") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sven Van Asbroeck <TheSven73@googlemail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5381cfb6f0422da24cfa9da35b0433c0415830e0 upstream.

The device's model download function returns the model data as
an array of u32s, which is later compared to the reference
model data. However, since the latter is an array of u16s,
the comparison does not happen correctly, and model verification
fails. This in turn breaks the POR initialization sequence.

Fixes: 39e7213edc4f3 ("max17042_battery: Support regmap to access device's registers")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sven Van Asbroeck <TheSven73@googlemail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power_supply: tps65217-charger: fix missing platform_set_drvdata() 2016-09-30T08:12:47+00:00 Wei Yongjun weiyj.lk@gmail.com 2016-07-26T14:49:04+00:00 ed3bab5299d8f82cfae121e8cda2a3a7083f396b commit 33e7664a0af6e9a516f01014f39737aaa119b6d9 upstream. Add missing platform_set_drvdata() in tps65217_charger_probe(), otherwise calling platform_get_drvdata() in remove returns NULL. This is detected by Coccinelle semantic patch. Fixes: 3636859b280c ("power_supply: Add support for tps65217-charger") Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 33e7664a0af6e9a516f01014f39737aaa119b6d9 upstream.

Add missing platform_set_drvdata() in tps65217_charger_probe(), otherwise
calling platform_get_drvdata() in remove returns NULL.

This is detected by Coccinelle semantic patch.

Fixes: 3636859b280c ("power_supply: Add support for tps65217-charger")
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended 2016-09-30T08:12:46+00:00 Sudeep Holla Sudeep.Holla@arm.com 2016-08-25T11:23:39+00:00 4b37b0ca71844614ada140b88dcee7fc2e8d1680 commit 331dcf421c34d227784d07943eb01e4023a42b0a upstream. If the i2c device is already runtime suspended, if qup_i2c_suspend is executed during suspend-to-idle or suspend-to-ram it will result in the following splat: WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90 Modules linked in: CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 #14 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) PC is at clk_core_unprepare+0x80/0x90 LR is at clk_unprepare+0x28/0x40 pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145 Call trace: clk_core_unprepare+0x80/0x90 qup_i2c_disable_clocks+0x2c/0x68 qup_i2c_suspend+0x10/0x20 platform_pm_suspend+0x24/0x68 ... This patch fixes the issue by executing qup_i2c_pm_suspend_runtime conditionally in qup_i2c_suspend. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 331dcf421c34d227784d07943eb01e4023a42b0a upstream.

If the i2c device is already runtime suspended, if qup_i2c_suspend is
executed during suspend-to-idle or suspend-to-ram it will result in the
following splat:

WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90
Modules linked in:

CPU: 3 PID: 1593 Comm: bash Tainted: G        W       4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145
Call trace:
 clk_core_unprepare+0x80/0x90
 qup_i2c_disable_clocks+0x2c/0x68
 qup_i2c_suspend+0x10/0x20
 platform_pm_suspend+0x24/0x68
 ...

This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
conditionally in qup_i2c_suspend.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: mux: pca954x: retry updating the mux selection on failure 2016-09-30T08:12:46+00:00 Peter Rosin peda@axentia.se 2016-09-14T13:24:12+00:00 9bdb254d4d7a829a36047780e308e287cea70abb commit 463e8f845cbf1c01e4cc8aeef1703212991d8e1e upstream. The cached value of the last selected channel prevents retries on the next call, even on failure to update the selected channel. Fix that. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 463e8f845cbf1c01e4cc8aeef1703212991d8e1e upstream.

The cached value of the last selected channel prevents retries on the
next call, even on failure to update the selected channel. Fix that.

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>