]> git.proxmox.com Git - mirror_ubuntu-bionic-kernel.git/log
mirror_ubuntu-bionic-kernel.git
4 years agonet: ena: fix retrieval of nonadaptive interrupt moderation intervals
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:35 +0000 (14:31 +0300)]
net: ena: fix retrieval of nonadaptive interrupt moderation intervals

BugLink: https://bugs.launchpad.net/bugs/1853180
Nonadaptive interrupt moderation intervals are assigned the value set
by the user in ethtool -C divided by ena_dev->intr_delay_resolution.

Therefore when the user tries to get the nonadaptive interrupt moderation
intervals with ethtool -c the code needs to multiply the saved value
by ena_dev->intr_delay_resolution.

The current code erroneously divides instead of multiplying in ethtool -c.
This patch fixes this.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 0eda847953d8dfb4b713ea62420f66157e230e13)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: fix update of interrupt moderation register
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:34 +0000 (14:31 +0300)]
net: ena: fix update of interrupt moderation register

BugLink: https://bugs.launchpad.net/bugs/1853180
Current implementation always updates the interrupt register with
the smoothed_interval of the rx_ring. However this should be
done only in case of adaptive interrupt moderation. If non-adaptive
interrupt moderation is used, the non-adaptive interrupt moderation
interval should be used. This commit fixes that.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7b8a28787e2ba671eaeb073e3b62fb4786338a09)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: remove all old adaptive rx interrupt moderation code from ena_com
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:33 +0000 (14:31 +0300)]
net: ena: remove all old adaptive rx interrupt moderation code from ena_com

BugLink: https://bugs.launchpad.net/bugs/1853180
Remove previous implementation of adaptive rx interrupt moderation
from ena_com files.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3ced8cbdf7ddb3160ffa714a91040dd18f39a12c)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: remove ena_restore_ethtool_params() and relevant fields
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:32 +0000 (14:31 +0300)]
net: ena: remove ena_restore_ethtool_params() and relevant fields

BugLink: https://bugs.launchpad.net/bugs/1853180
Deleted unused 4 fields from struct ena_adapter and their only user
ena_restore_ethtool_params().

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 64d1fb9dfc6c5d8589312fa847fee14ec14ee12b)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: remove old adaptive interrupt moderation code from ena_netdev
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:31 +0000 (14:31 +0300)]
net: ena: remove old adaptive interrupt moderation code from ena_netdev

BugLink: https://bugs.launchpad.net/bugs/1853180
1. Out of the fields {per_napi_bytes, per_napi_packets} in struct ena_ring,
   only rx_ring->per_napi_packets are used to determine if napi did work
   for dim.
   This commit removes all other uses of these fields.
2. Remove ena_ring->moder_tbl_idx, which is not used by dim.
3. Remove all calls to ena_com_destroy_interrupt_moderation(), since all it
   did was to destroy the interrupt moderation table, which is removed as
   part of removing old interrupt moderation code.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 242d81fd3dd9f301b0c20564aafec8efdb2bbe5b)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: remove code duplication in ena_com_update_nonadaptive_moderation_interval...
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:30 +0000 (14:31 +0300)]
net: ena: remove code duplication in ena_com_update_nonadaptive_moderation_interval _*()

BugLink: https://bugs.launchpad.net/bugs/1853180
Remove code duplication in:
ena_com_update_nonadaptive_moderation_interval_tx()
ena_com_update_nonadaptive_moderation_interval_rx()
functions.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 57e3a5f24bb5bf265988e973a911845abcbf6a00)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: enable the interrupt_moderation in driver_supported_features
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:29 +0000 (14:31 +0300)]
net: ena: enable the interrupt_moderation in driver_supported_features

BugLink: https://bugs.launchpad.net/bugs/1853180
Add driver_supported_features to host_host info which is a new API used to
communicate to the device which features are supported by the driver.

Add the interrupt_moderation bit to host_info->driver_supported_features
and enable it to signal the device that this driver supports interrupt
moderation properly.

Reserved bits are for features implemented in the future

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit bd21b0cc3a63d1c658b230db084b0f392b78cab2)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: reimplement set/get_coalesce()
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:28 +0000 (14:31 +0300)]
net: ena: reimplement set/get_coalesce()

BugLink: https://bugs.launchpad.net/bugs/1853180
1. Remove old adaptive interrupt moderation code from set/get_coalesce()
2. Add ena_update_rx_rings_intr_moderation() function for updating
   nonadaptive interrupt moderation intervals similarly to
   ena_update_tx_rings_intr_moderation().
3. Remove checks of multiple unsupported received interrupt coalescing
   parameters. This makes code cleaner and cancels the need to update
   it every time a new coalescing parameter is invented.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b3db86dc4b82ffc63e33c78dafc09d5c78ac4fe4)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: switch to dim algorithm for rx adaptive interrupt moderation
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:27 +0000 (14:31 +0300)]
net: ena: switch to dim algorithm for rx adaptive interrupt moderation

BugLink: https://bugs.launchpad.net/bugs/1853180
Use the dim library for the rx adaptive interrupt moderation implementation

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 282faf61a053be43910fcc42d86ecf16c0d30123)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agonet: ena: add intr_moder_rx_interval to struct ena_com_dev and use it
Arthur Kiyanovski [Mon, 16 Sep 2019 11:31:26 +0000 (14:31 +0300)]
net: ena: add intr_moder_rx_interval to struct ena_com_dev and use it

BugLink: https://bugs.launchpad.net/bugs/1853180
Add intr_moder_rx_interval to struct ena_com_dev and use it as the
location where the interrupt moderation rx interval is saved, instead
of the interrupt moderation table.

This is done as a first step before removing the old interrupt moderation
code.

Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 15619e722b16aaa40f942b93631aa92581a7b393)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: [Config] Enable ROCKCHIP support for arm64
Po-Hsu Lin [Wed, 20 Nov 2019 06:22:00 +0000 (07:22 +0100)]
UBUNTU: [Config] Enable ROCKCHIP support for arm64

BugLink: https://bugs.launchpad.net/bugs/1825222
We already have this ROCKCHIP support enabled for armhf (bug 1566283),
let's enable it for arm64 as well.

The only difference is arm64=m for CONFIG_CRYPTO_DEV_ROCKCHIP as
requested, it was set to 'n' for armhf.

Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: SAUCE: linux/dim: avoid library object filename clash
Kamal Mostafa [Thu, 7 Nov 2019 18:20:58 +0000 (10:20 -0800)]
UBUNTU: SAUCE: linux/dim: avoid library object filename clash

BugLink: https://bugs.launchpad.net/bugs/1852637
Use dimlib.o (vs. dim.o) as the interim library object filename to avoid
a clash with the actual dim.c which manifests as:

make[2]: Circular lib/dim/dim.o <- lib/dim/dim.o dependency dropped.

Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: linux/dim: import DIMLIB (lib/dim/)
Kamal Mostafa [Thu, 7 Nov 2019 17:52:08 +0000 (09:52 -0800)]
UBUNTU: linux/dim: import DIMLIB (lib/dim/)

BugLink: https://bugs.launchpad.net/bugs/1852637
Import DIMLIB (lib/dim/) from mainline v5.3 as of
commit f8be17b81d44 ("lib/dim: Fix -Wunused-const-variable warnings").

Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: [Config] enable DIMLIB
Kamal Mostafa [Thu, 7 Nov 2019 17:58:12 +0000 (09:58 -0800)]
UBUNTU: [Config] enable DIMLIB

BugLink: https://bugs.launchpad.net/bugs/1852637
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoinclude/linux/bitops.h: introduce BITS_PER_TYPE
Chris Wilson [Wed, 22 Aug 2018 04:57:03 +0000 (21:57 -0700)]
include/linux/bitops.h: introduce BITS_PER_TYPE

BugLink: https://bugs.launchpad.net/bugs/1852637
net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the
number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the macro
to bitops.h, alongside BITS_PER_BYTE, for wider usage.

Link: http://lkml.kernel.org/r/20180706094458.14116-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Andy Gospodarek <gospo@broadcom.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(backported from commit 9144d75e22cad3c89e6b2ccab551db9ee28d250a)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Khaled Elmously <khalid.elmously@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: SAUCE: ALSA: hda: Add Cometlake-S PCI ID
Chiou, Cooper [Mon, 11 Nov 2019 12:35:00 +0000 (13:35 +0100)]
UBUNTU: SAUCE: ALSA: hda: Add Cometlake-S PCI ID

BugLink: https://bugs.launchpad.net/bugs/1852070
Add HD Audio Device PCI ID for the Intel Cometlake-S platform

Signed-off-by: Chiou, Cooper <cooper.chiou@intel.com>
Link: https://lore.kernel.org/r/20191108071349.12840-1-cooper.chiou@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit b73a58549ea37a44434c7afab3c7ad9af210cfd9)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: SAUCE: platform/x86: dell-uart-backlight: add quirk for old platforms
AceLan Kao [Thu, 7 Nov 2019 06:36:00 +0000 (07:36 +0100)]
UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add quirk for old platforms

BugLink: https://bugs.launchpad.net/bugs/1813877
Old platforms do not support DELL_UART_GET_SCALAR command and the
behavior of DELL_UART_GET_FIRMWARE_VER command is different as the new
firmware, so the new way to check if the backlight is controlled by
scalar IC doesn't work on old platforms. We now add them into a list and
use the old way to do the check.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: SAUCE: platform/x86: dell-uart-backlight: add force parameter
AceLan Kao [Thu, 7 Nov 2019 06:36:00 +0000 (07:36 +0100)]
UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add force parameter

BugLink: https://bugs.launchpad.net/bugs/1813877
Add force parameter to force load the driver if the platform doesn't
provide a working scalar status command.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: SAUCE: platform/x86: dell-uart-backlight: load driver by scalar status
AceLan Kao [Thu, 7 Nov 2019 06:36:00 +0000 (07:36 +0100)]
UBUNTU: SAUCE: platform/x86: dell-uart-backlight: load driver by scalar status

BugLink: https://bugs.launchpad.net/bugs/1813877
Leverage the scalar status command to determinate whether the driver
should be loaded or not.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: SAUCE: platform/x86: dell-uart-backlight: add missing status command
AceLan Kao [Thu, 7 Nov 2019 06:36:00 +0000 (07:36 +0100)]
UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add missing status command

BugLink: https://bugs.launchpad.net/bugs/1813877
DELL_UART_GET_SCALAR has been declared in
drivers/platform/x86/dell-uart-backlight.h, but its definition is
missing. It won't lead to issues on old AIO platforms, since this
command is newly introduced and is not supported by all old AIOs.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agofonts: Prefer a bigger font for high resolution screens
Takashi Iwai [Thu, 7 Nov 2019 11:43:58 +0000 (19:43 +0800)]
fonts: Prefer a bigger font for high resolution screens

BugLink: https://bugs.launchpad.net/bugs/1851623
Although we may have multiple fonts in kernel, the small 8x16 font is
chosen as default usually unless user specify the boot option.  This
is suboptimal for monitors with high resolutions.

This patch tries to assign a bigger font for such a high resolution by
calculating some penalty value.  This won't change anything for a
standard monitor like Full HD (1920x1080), but for a high res monitor
like UHD 4K, a bigger font like TER16x32 will be chosen once when
enabled in Kconfig.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit dfd19a5004eff03755967086aa04254c3d91b8ec)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agofonts: Fix coding style
Takashi Iwai [Thu, 7 Nov 2019 11:43:57 +0000 (19:43 +0800)]
fonts: Fix coding style

BugLink: https://bugs.launchpad.net/bugs/1851623
Fix indentation, spaces, and move EXPORT_SYMBOL line to the
appropriate place as a preliminary work.  No actual code change.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit aa1d19f1f96764e72155235ece22461599d0e7ac)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoUBUNTU: SAUCE: x86/intel: Disable HPET on Intel Coffe Lake H platforms
Kai-Heng Feng [Tue, 12 Nov 2019 12:59:37 +0000 (20:59 +0800)]
UBUNTU: SAUCE: x86/intel: Disable HPET on Intel Coffe Lake H platforms

BugLink: https://bugs.launchpad.net/bugs/1852216
Like CFL and ICL, we need to disable HPET on CFL-H.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com>
Acked-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoi40e: Fix crash caused by stress setting of VF MAC addresses
Slawomir Laba [Wed, 13 Nov 2019 13:39:17 +0000 (10:39 -0300)]
i40e: Fix crash caused by stress setting of VF MAC addresses

BugLink: https://bugs.launchpad.net/bugs/1852432
Add update to the VSI pointer passed to the i40e_set_vf_mac function.
If VF is in reset state the driver waits in i40e_set_vf_mac function
for the reset to be complete, yet after reset the vsi pointer
that was passed into this function is no longer valid.

The patch updates local VSI pointer directly from pf->vsi array,
by using the id stored in VF pointer (lan_vsi_idx).

Without this commit the driver might occasionally invoke general
protection fault in kernel and disable the OS entirely.

Signed-off-by: Slawomir Laba <slawomirx.laba@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 9889707b06acfe9bb37a6edcaae627d4a5eacc72)
Signed-off-by: Heitor Alves de Siqueira <halves@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoUBUNTU: upstream stable to v4.14.156, v4.19.86
Kamal Mostafa [Wed, 27 Nov 2019 18:24:58 +0000 (10:24 -0800)]
UBUNTU: upstream stable to v4.14.156, v4.19.86

BugLink: https://bugs.launchpad.net/bugs/1854216
Ignore: yes
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agox86/resctrl: Fix rdt_find_domain() return value and checks
Reinette Chatre [Mon, 10 Dec 2018 22:31:13 +0000 (14:31 -0800)]
x86/resctrl: Fix rdt_find_domain() return value and checks

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 52eb74339a6233c69f4e3794b69ea7c98eeeae1b ]

rdt_find_domain() returns an ERR_PTR() that is generated from a provided
domain id when the value is negative.

Care needs to be taken when creating an ERR_PTR() from this value
because a subsequent check using IS_ERR() expects the error to
be within the MAX_ERRNO range. Using an invalid domain id as an
ERR_PTR() does work at this time since this is currently always -1.
Using this undocumented assumption is fragile since future users of
rdt_find_domain() may not be aware of thus assumption.

Two related issues are addressed:

- Ensure that rdt_find_domain() always returns a valid error value by
forcing the error to be -ENODEV when a negative domain id is provided.

- In a few instances the return value of rdt_find_domain() is just
checked for NULL - fix these to include a check of ERR_PTR.

Fixes: d89b7379015f ("x86/intel_rdt/cqm: Add mon_data")
Fixes: 521348b011d6 ("x86/intel_rdt: Introduce utility to obtain CDP peer")
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: fenghua.yu@intel.com
Cc: gavin.hindman@intel.com
Cc: jithu.joseph@intel.com
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/b88cd4ff6a75995bf8db9b0ea546908fe50f69f3.1544479852.git.reinette.chatre@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoPM / devfreq: Fix static checker warning in try_then_request_governor
Enric Balletbo i Serra [Wed, 13 Mar 2019 12:22:53 +0000 (13:22 +0100)]
PM / devfreq: Fix static checker warning in try_then_request_governor

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit b53b0128052ffd687797d5f4deeb76327e7b5711 ]

The patch 23c7b54ca1cd: "PM / devfreq: Fix devfreq_add_device() when
drivers are built as modules." leads to the following static checker
warning:

    drivers/devfreq/devfreq.c:1043 governor_store()
    warn: 'governor' can also be NULL

The reason is that the try_then_request_governor() function returns both
error pointers and NULL. It should just return error pointers, so fix
this by returning a ERR_PTR to the error intead of returning NULL.

Fixes: 23c7b54ca1cd ("PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoACPI / LPSS: Use acpi_lpss_* instead of acpi_subsys_* functions for hibernate
Hans de Goede [Thu, 18 Apr 2019 11:39:33 +0000 (13:39 +0200)]
ACPI / LPSS: Use acpi_lpss_* instead of acpi_subsys_* functions for hibernate

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit c8afd03486c26accdda4846e5561aa3f8e862a9d ]

Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set.

This means that on resume from hibernate dw_i2c_plat_resume() doesn't get
called by the restore_early callback, acpi_lpss_resume_early(). Instead it
should be called by the restore_noirq callback matching how things are done
when resume_from_noirq is set and we are doing a regular resume.

Change the restore_noirq callback to acpi_lpss_resume_noirq so that
dw_i2c_plat_resume() gets properly called when resume_from_noirq is set
and we are resuming from hibernate.

Likewise also change the poweroff_noirq callback so that
dw_i2c_plat_suspend gets called properly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139
Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq")
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: 4.20+ <stable@vger.kernel.org> # 4.20+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agotcp: start receiver buffer autotuning sooner
Yuchung Cheng [Mon, 1 Oct 2018 22:42:32 +0000 (15:42 -0700)]
tcp: start receiver buffer autotuning sooner

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 041a14d2671573611ffd6412bc16e2f64469f7fb ]

Previously receiver buffer auto-tuning starts after receiving
one advertised window amount of data. After the initial receiver
buffer was raised by patch a337531b942b ("tcp: up initial rmem to
128KB and SYN rwin to around 64KB"), the reciver buffer may take
too long to start raising. To address this issue, this patch lowers
the initial bytes expected to receive roughly the expected sender's
initial window.

Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agohwmon: (k10temp) Support all Family 15h Model 6xh and Model 7xh processors
Guenter Roeck [Sun, 2 Sep 2018 19:02:53 +0000 (12:02 -0700)]
hwmon: (k10temp) Support all Family 15h Model 6xh and Model 7xh processors

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 53dfa0088edd2e2793afa21488532b12eb2dae48 ]

BIOS developer guides refer to Family 15h Models 60h-6fh and Family 15h
Models 70h-7fh. So far the driver only checked for Models 60h and 70h.
However, there are now processors with other model numbers in the same
families. Example is A10-9620P family 15h model 65h. Follow the developer
guides and mask the lower 4 bit of the model number to determine the
registers to use for reading temperatures and temperature limits.

Reported-by: Guglielmo Fanini <g.fanini@gmail.com>
Cc: Guglielmo Fanini <g.fanini@gmail.com>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoscsi: arcmsr: clean up clang warning on extraneous parentheses
Colin Ian King [Sun, 30 Sep 2018 23:03:07 +0000 (00:03 +0100)]
scsi: arcmsr: clean up clang warning on extraneous parentheses

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit ca2ade24157693b4e533ccec69df00ef719d4aad ]

There are extraneous parantheses that are causing clang to produce a
warning so remove these.

Clean up 3 clang warnings:
equality comparison with extraneous parentheses [-Wparentheses-equality]

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Ching Huang <ching2048@areca.com.tw>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agolightnvm: pblk: fix rqd.error return value in pblk_blk_erase_sync
Matias Bjørling [Tue, 9 Oct 2018 11:11:33 +0000 (13:11 +0200)]
lightnvm: pblk: fix rqd.error return value in pblk_blk_erase_sync

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 4b5d56edb8fc565c5db029aecaea598eadfba7f6 ]

rqd.error is masked by the return value of pblk_submit_io_sync.
The rqd structure is then passed on to the end_io function, which
assumes that any error should lead to a chunk being marked
offline/bad. Since the pblk_submit_io_sync can fail before the
command is issued to the device, the error value maybe not correspond
to a media failure, leading to chunks being immaturely retired.

Also, the pblk_blk_erase_sync function prints an error message in case
the erase fails. Since the caller prints an error message by itself,
remove the error message in this function.

Signed-off-by: Matias Bjørling <mb@lightnvm.io>
Reviewed-by: Javier González <javier@cnexlabs.com>
Reviewed-by: Hans Holmberg <hans.holmberg@cnexlabs.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomedia: cx18: Don't check for address of video_dev
Nathan Chancellor [Mon, 1 Oct 2018 15:21:11 +0000 (11:21 -0400)]
media: cx18: Don't check for address of video_dev

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit eb1ca9a428fdc3f98be4898f6cd8bcb803878619 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context.

drivers/media/pci/cx18/cx18-driver.c:1255:23: warning: address of
'cx->streams[i].video_dev' will always evaluate to 'true'
[-Wpointer-bool-conversion]
                if (&cx->streams[i].video_dev)
                ~~   ~~~~~~~~~~~~~~~^~~~~~~~~
1 warning generated.

Check whether v4l2_dev is null, not the address, so that the statement
doesn't fire all the time. This check has been present since 2009,
introduced by commit 21a278b85d3c ("V4L/DVB (11619): cx18: Simplify the
work handler for outgoing mailbox commands")

Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agobcache: account size of buckets used in uuid write to ca->meta_sectors_written
Shenghui Wang [Mon, 8 Oct 2018 12:41:07 +0000 (20:41 +0800)]
bcache: account size of buckets used in uuid write to ca->meta_sectors_written

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 7a55948d38eb9b274cbbdd56dc1dd4b96ebfbe04 ]

UUIDs are considered as metadata. __uuid_write should add the number
of buckets (in sectors) written to disk to ca->meta_sectors_written.
Currently only 1 bucket is used in uuid write.

Steps to test:
1) create a fresh backing device and a fresh cache device separately.
   The backing device didn't attach to any cache set.
2) cd /sys/block/<cache device>/bcache
   cat metadata_written      // record the output value
   cat bucket_size
3) attach the backing device to cache set
4) cat metadata_written
   The output value is almost the same as the value in step 2
   before the change.
   After the change, the value is bigger about 1 bucket size.

Signed-off-by: Shenghui Wang <shhuiw@foxmail.com>
Reviewed-by: Tang Junhui <tang.junhui.linux@gmail.com>
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agofbdev: fix broken menu dependencies
Randy Dunlap [Mon, 8 Oct 2018 10:57:36 +0000 (12:57 +0200)]
fbdev: fix broken menu dependencies

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit aae3394ef0ef90cf00a21133357448385f13a5d4 ]

The framebuffer options and devices menu is unintentionally split
or broken because some items in it do not depend on FB (including
several under omap and mmp).
Fix this by moving FB_CMDLINE, FB_NOTIFY, and FB_CLPS711X_OLD to
just before the FB Kconfig symbol definition and by moving the
omap, omap2, and mmp menus to last, following FB_SM712.

Also, the FB_VIA dependencies are duplicated by both being inside
an "if FB_VIA/endif" block and "depends on FB_VIA", so drop the
"depends on FB_VIA" lines since they are redundant.

Fixes: ea6763c104c9 ("video/fbdev: Always built-in video= cmdline parsing")
Fixes: 5ec9653806ba ("fbdev: Make fb-notify a no-op if CONFIG_FB=n")
Fixes: ef74d46a4ef3 ("video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoatmel_lcdfb: support native-mode display-timings
Sam Ravnborg [Mon, 8 Oct 2018 10:57:35 +0000 (12:57 +0200)]
atmel_lcdfb: support native-mode display-timings

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 60e5e48dba72c6b59a7a9c7686ba320766913368 ]

When a device tree set a display-timing using native-mode
then according to the bindings doc this should:

    native-mode:
    The native mode for the display, in case multiple
    modes are provided.
    When omitted, assume the first node is the native.

The atmel_lcdfb used the last timing subnode and did not
respect the timing mode specified with native-mode.

Introduce use of of_get_videomode() which allowed
a nice simplification of the code while also
added support for native-mode.

As a nice side-effect this fixes a memory leak where the
data used for timings and the display_np was not freed.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agommc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
Niklas Söderlund [Thu, 13 Sep 2018 14:47:08 +0000 (16:47 +0200)]
mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 54541815b43f4e49c82628bf28bbb31d86d2f58a ]

Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
device_dma_parameters structure and filling in the max segment size. The
size used is the result of a discussion with Renesas hardware engineers
and unfortunately not found in the datasheet.

  renesas_sdhi_internal_dmac ee140000.sd: DMA-API: mapping sg segment
  longer than device claims to support [len=126976] [max=65536]

Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[wsa: simplified some logic after validating intended dma_parms life cycle
      and added comment]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoprintk: Correct wrong casting
He Zhe [Sat, 29 Sep 2018 16:45:51 +0000 (00:45 +0800)]
printk: Correct wrong casting

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 51a72ab7372d85c96104e58036f1b49ba11e5d2b ]

log_first_seq and console_seq are 64-bit unsigned integers.
Correct a wrong casting that might cut off the output.

Link: http://lkml.kernel.org/r/1538239553-81805-2-git-send-email-zhe.he@windriver.com
Cc: rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: He Zhe <zhe.he@windriver.com>
[sergey.senozhatsky@gmail.com: More descriptive commit message]
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoclk: samsung: Use NOIRQ stage for Exynos5433 clocks suspend/resume
Marek Szyprowski [Thu, 6 Sep 2018 16:02:35 +0000 (18:02 +0200)]
clk: samsung: Use NOIRQ stage for Exynos5433 clocks suspend/resume

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 70da9ee80228e6d98fd68e3c1db124c4461d283c ]

SoC clock drivers should suspend after every other drivers in the system,
which are using clocks and resume before them. The last stage for calling
suspend device callbacks is NOIRQ stage and there exists driver, which use
that state (dwmmc-exynos), so Exynos5433 clocks driver should also use it.
During the same stage, clocks driver will be always suspended after its
clients as a direct result of proper device probe order (deferred probe
reorders the suspend call sequence).

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sylwester Nawrocki <snawrocki@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoqed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers
Nathan Chancellor [Thu, 4 Oct 2018 16:39:20 +0000 (09:39 -0700)]
qed: Avoid implicit enum conversion in qed_ooo_submit_tx_buffers

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 8fa74e3c49204bdf788d99ef71840490cccc210d ]

Clang warns when one enumerated type is implicitly converted to another.

drivers/net/ethernet/qlogic/qed/qed_ll2.c:799:32: warning: implicit
conversion from enumeration type 'enum core_tx_dest' to different
enumeration type 'enum qed_ll2_tx_dest' [-Wenum-conversion]
                tx_pkt.tx_dest = p_ll2_conn->tx_dest;
                               ~ ~~~~~~~~~~~~^~~~~~~
1 warning generated.

Fix this by using a switch statement to convert between the enumerated
values since they are not 1 to 1, which matches how the rest of the
driver handles this conversion.

Link: https://github.com/ClangBuiltLinux/linux/issues/125
Suggested-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agorpmsg: glink: smem: Support rx peak for size less than 4 bytes
Arun Kumar Neelakantam [Wed, 3 Oct 2018 11:38:20 +0000 (17:08 +0530)]
rpmsg: glink: smem: Support rx peak for size less than 4 bytes

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 928002a5e9dab2ddc1a0fe3e00739e89be30dc6b ]

The current rx peak function fails to read the data if size is
less than 4bytes.

Use memcpy_fromio to support data reads of size less than 4 bytes.

Cc: stable@vger.kernel.org
Fixes: f0beb4ba9b18 ("rpmsg: glink: Remove chunk size word align warning")
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoRDMA/hns: Limit the size of extend sge of sq
Lijun Ou [Sun, 30 Sep 2018 09:00:31 +0000 (17:00 +0800)]
RDMA/hns: Limit the size of extend sge of sq

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 05ad5482a5904c416bcfd74afd7193e206e563ce ]

The hip08 split two hardware version. The version id are 0x20 and 0x21
according to the PCI revison. The max size of extend sge of sq is limited
to 2M for 0x20 version and 8M for 0x21 version. It may be exceeded to 2M
according to the algorithm that compute the product of wqe count and
extend sge number of every wqe. But the product always less than 8M.

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoRDMA/hns: Bugfix for CM test
Lijun Ou [Sun, 30 Sep 2018 09:00:30 +0000 (17:00 +0800)]
RDMA/hns: Bugfix for CM test

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 15fc056fba7b17b9abfbe80a12f188403fc949fb ]

It will print the warning when the MSB bit of SLID is not zero running
cm_req_handler function that test CM. It needs to fixed zero when test
RoCE device.

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoRDMA/hns: Submit bad wr when post send wr exception
Lijun Ou [Sun, 30 Sep 2018 09:00:29 +0000 (17:00 +0800)]
RDMA/hns: Submit bad wr when post send wr exception

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit c80e066100b5fed722c8da67c1bd2312e7bcf129 ]

When user issues a RDMA read and enables sq inline, it needs to report a
bad wr to user.

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoRDMA/hns: Bugfix for reserved qp number
Lijun Ou [Sun, 30 Sep 2018 09:00:28 +0000 (17:00 +0800)]
RDMA/hns: Bugfix for reserved qp number

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 06ef0ee4b569101f3a07ce08335dbf29fd1404ef ]

It needs to include two special qps for every port. The hip08 have four
ports and the all reserved qp numbers are eight.

Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoIB/rxe: avoid srq memory leak
Zhu Yanjun [Sun, 30 Sep 2018 06:27:16 +0000 (02:27 -0400)]
IB/rxe: avoid srq memory leak

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit aae0484e15f062ad2c2502e68e15dfb8b8f84608 ]

In rxe_queue_init, q and q->buf are allocated. In do_mmap_info, q->ip is
allocated. When error occurs, rxe_srq_from_init and the later error
handler do not free these allocated memories.  This will make memory leak.

Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agox86/PCI: Apply VMD's AERSID fixup generically
Jon Derrick [Fri, 7 Sep 2018 19:22:30 +0000 (13:22 -0600)]
x86/PCI: Apply VMD's AERSID fixup generically

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 4f475e8e0a6d4f5d430350d1f74f7e4899fb1692 ]

A root port Device ID changed between simulation and production.  Rather
than match Device IDs which may not be future-proof if left unmaintained,
match all root ports which exist in a VMD domain.

Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoALSA: hda: Fix mismatch for register mask and value in ext controller.
Keyon Jie [Fri, 28 Sep 2018 09:38:59 +0000 (17:38 +0800)]
ALSA: hda: Fix mismatch for register mask and value in ext controller.

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit c32bf867cb6721d6ea04044d33f19c8bd81280c1 ]

E.g. for snd_hdac_ext_bus_link_power_up(), we should set mask to be
AZX_MLCTL_SPA(it was 0), and AZX_MLCTL_SPA as value to power up it,
here correct it and several similar mismatches.

Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoprintk: CON_PRINTBUFFER console registration is a bit racy
Sergey Senozhatsky [Fri, 28 Sep 2018 09:53:04 +0000 (18:53 +0900)]
printk: CON_PRINTBUFFER console registration is a bit racy

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 884e370ea88c109a3b982f4eb9ecd82510a3a1fe ]

CON_PRINTBUFFER console registration requires us to do several
preparation steps:
- Rollback console_seq to replay logbuf messages which were already
  seen on other consoles;
- Set exclusive_console flag so console_unlock() will ->write() logbuf
  messages only to the exclusive_console driver.

The way we do it, however, is a bit racy

logbuf_lock_irqsave(flags);
console_seq = syslog_seq;
console_idx = syslog_idx;
logbuf_unlock_irqrestore(flags);
<< preemption enabled
<< irqs enabled
exclusive_console = newcon;
console_unlock();

We rollback console_seq under logbuf_lock with IRQs disabled, but
we set exclusive_console with local IRQs enabled and logbuf unlocked.
If the system oops-es or panic-s before we set exclusive_console - and
given that we have IRQs and preemption enabled there is such a
possibility - we will re-play all logbuf messages to every registered
console, which may be a bit annoying and time consuming.

Move exclusive_console assignment to the same IRQs-disabled and
logbuf_lock-protected section where we rollback console_seq.

Link: http://lkml.kernel.org/r/20180928095304.9972-1-sergey.senozhatsky@gmail.com
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoprintk: Do not miss new messages when replaying the log
Petr Mladek [Thu, 13 Sep 2018 12:34:06 +0000 (14:34 +0200)]
printk: Do not miss new messages when replaying the log

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit f92b070f2dc89a8ff1a0cc8b608e20abef894c7d ]

The variable "exclusive_console" is used to reply all existing messages
on a newly registered console. It is cleared when all messages are out.

The problem is that new messages might appear in the meantime. These
are then visible only on the exclusive console.

The obvious solution is to clear "exclusive_console" after we replay
all messages that were already proceed before we started the reply.

Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Link: http://lkml.kernel.org/r/20180913123406.14378-1-pmladek@suse.com
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: linux-kernel@vger.kernel.org
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agowatchdog: sama5d4: fix timeout-sec usage
Romain Izard [Fri, 14 Sep 2018 10:13:38 +0000 (12:13 +0200)]
watchdog: sama5d4: fix timeout-sec usage

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 2e0432f8f8ad11b4bd208445360220efa5b37d82 ]

When using watchdog_init_timeout to update the default timeout value,
an error means that there is no "timeout-sec" in the relevant device
tree node.

This should not prevent binding of the driver to the device.

Fixes: 976932e40036 ("watchdog: sama5d4: make use of timeout-secs provided in devicetree")
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Reviewed-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agowatchdog: renesas_wdt: stop when unregistering
Wolfram Sang [Tue, 28 Aug 2018 10:13:48 +0000 (12:13 +0200)]
watchdog: renesas_wdt: stop when unregistering

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 14de99b44b34dbb9d0f64845b1cbb675e047767e ]

We want to go into a sane state when unregistering. Currently, it
happens that the watchdog stops when unbinding because of RuntimePM
stopping the core clock. When rebinding, the core clock gets reactivated
and the watchdog fires even though it hasn't been opened by userspace
yet. Strange scenario, yes, but sane state is much preferred anyhow.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agowatchdog: core: fix null pointer dereference when releasing cdev
Wolfram Sang [Tue, 28 Aug 2018 10:13:47 +0000 (12:13 +0200)]
watchdog: core: fix null pointer dereference when releasing cdev

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 953b9dd7725bad55a922a35e75bff7bebf7b9978 ]

watchdog_stop() calls watchdog_update_worker() which needs a valid
wdd->wd_data pointer. So, when unregistering the cdev, clear the
pointers after we call watchdog_stop(), not before.

Fixes: bb292ac1c602 ("watchdog: Introduce watchdog_stop_on_unregister helper")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoPM / devfreq: stopping the governor before device_unregister()
Vincent Donnefort [Mon, 3 Sep 2018 00:02:07 +0000 (09:02 +0900)]
PM / devfreq: stopping the governor before device_unregister()

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 2f061fd0c2d852e32e03a903fccd810663c5c31e ]

device_release() is freeing the resources before calling the device
specific release callback which is, in the case of devfreq, stopping
the governor.

It is a problem as some governors are using the device resources. e.g.
simpleondemand which is using the devfreq deferrable monitoring work. If it
is not stopped before the resources are freed, it might lead to a use after
free.

Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Reviewed-by: John Einar Reitan <john.reitan@arm.com>
[cw00.choi: Fix merge conflict]
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoPM / devfreq: Fix handling of min/max_freq == 0
Matthias Kaehlcke [Fri, 3 Aug 2018 20:05:09 +0000 (13:05 -0700)]
PM / devfreq: Fix handling of min/max_freq == 0

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit df5cf4a36178c5d4f2b8b9469cb2f722e64cd102 ]

Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the
devfreq device") initializes df->min/max_freq with the min/max OPP when
the device is added. Later commit f1d981eaecf8 ("PM / devfreq: Use the
available min/max frequency") adds df->scaling_min/max_freq and the
following to the frequency adjustment code:

  max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);

With the current handling of min/max_freq this is incorrect:

Even though df->max_freq is now initialized to a value != 0 user space
can still set it to 0, in this case max_freq would be 0 instead of
df->scaling_max_freq as intended. In consequence the frequency adjustment
is not performed:

  if (max_freq && freq > max_freq) {
freq = max_freq;

To fix this set df->min/max freq to the min/max OPP in max/max_freq_store,
when the user passes a value of 0. This also prevents df->max_freq from
being set below the min OPP when df->min_freq is 0, and similar for
min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the
checks for this case can be removed.

Fixes: f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoPM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
Enric Balletbo i Serra [Wed, 4 Jul 2018 08:45:50 +0000 (10:45 +0200)]
PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 23c7b54ca1cd1797ef39169ab85e6d46f1c2d061 ]

When the devfreq driver and the governor driver are built as modules,
the call to devfreq_add_device() or governor_store() fails because the
governor driver is not loaded at the time the devfreq driver loads. The
devfreq driver has a build dependency on the governor but also should
have a runtime dependency. We need to make sure that the governor driver
is loaded before the devfreq driver.

This patch fixes this bug by adding a try_then_request_governor()
function. First tries to find the governor, and then, if it is not found,
it requests the module and tries again.

Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using name)
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoIB/hfi1: Error path MAD response size is incorrect
Michael J. Ruhl [Fri, 28 Sep 2018 14:34:57 +0000 (07:34 -0700)]
IB/hfi1: Error path MAD response size is incorrect

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 935c84ac649a147e1aad2c48ee5c5a1a9176b2d0 ]

If a MAD packet has incorrect header information, the logic uses the reply
path to report the error.  The reply path expects *resp_len to be set
prior to return.  Unfortunately, *resp_len is set to 0 for this path.
This causes an incorrect response packet.

Fix by ensuring that the *resp_len is defaulted to the incoming packet
size (wc->bytes_len - sizeof(GRH)).

Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agof2fs: keep lazytime on remount
Jaegeuk Kim [Fri, 28 Sep 2018 07:24:39 +0000 (00:24 -0700)]
f2fs: keep lazytime on remount

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 095680f24f2673d860fd1d3d2f54f40f330b4c63 ]

This patch fixes losing lazytime when remounting f2fs.

Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq
Hans de Goede [Sun, 23 Sep 2018 13:58:11 +0000 (15:58 +0200)]
ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 48402cee6889fb3fce58e95fea1471626286dc63 ]

On some Cherry Trail systems the GPU ACPI fwnode has power-resources which
point to the PMIC, which is connected over a LPSS I2C controller.

We add a device-link to make sure that the I2C controller is resumed before
the GPU is. But the pci-core changes the power-state of PCI devices from
D3 to D0 at noirq time (to restore the PCI config registers) and before
this commit we were bringing up the I2C controllers from a resume_early
handler which runs later. More specifically the pm-core will first run
all resume_noirq handlers in order and then all resume_early handlers.

So we must not only make sure that the handlers are run in the right order,
but also that the resume of the I2C controller is done at noirq time.

The behavior before this commit, resuming the I2C controller from a
resume_early handler leads to the following errors:

 i2c_designware 808622C1:06: controller timed out
 ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
 ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR
 video LNXVIDEO:00: Failed to change power state to D0

This commit changes the acpi_lpss.c code to resume the BYT/CHT I2C
controllers at resume_noirq time fixing this.

Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agotcp: up initial rmem to 128KB and SYN rwin to around 64KB
Yuchung Cheng [Thu, 27 Sep 2018 18:21:19 +0000 (11:21 -0700)]
tcp: up initial rmem to 128KB and SYN rwin to around 64KB

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit a337531b942bd8a03e7052444d7e36972aac2d92 ]

Previously TCP initial receive buffer is ~87KB by default and
the initial receive window is ~29KB (20 MSS). This patch changes
the two numbers to 128KB and ~64KB (rounding down to the multiples
of MSS) respectively. The patch also simplifies the calculations s.t.
the two numbers are directly controlled by sysctl tcp_rmem[1]:

  1) Initial receiver buffer budget (sk_rcvbuf): while this should
     be configured via sysctl tcp_rmem[1], previously tcp_fixup_rcvbuf()
     always override and set a larger size when a new connection
     establishes.

  2) Initial receive window in SYN: previously it is set to 20
     packets if MSS <= 1460. The number 20 was based on the initial
     congestion window of 10: the receiver needs twice amount to
     avoid being limited by the receive window upon out-of-order
     delivery in the first window burst. But since this only
     applies if the receiving MSS <= 1460, connection using large MTU
     (e.g. to utilize receiver zero-copy) may be limited by the
     receive window.

With this patch TCP memory configuration is more straight-forward and
more properly sized to modern high-speed networks by default. Several
popular stacks have been announcing 64KB rwin in SYNs as well.

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoARM: dts: sun8i: h3: bpi-m2-plus: Fix address for external RGMII Ethernet PHY
Chen-Yu Tsai [Thu, 30 Aug 2018 08:09:24 +0000 (16:09 +0800)]
ARM: dts: sun8i: h3: bpi-m2-plus: Fix address for external RGMII Ethernet PHY

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit db9fd9d13e30fc67737ac9893a82e6b095e85a64 ]

The external RTL8211E RGMII Ethernet PHY is configured via external
resistors to use the address 0x1. The 0x0 address is a broadcast address
for this family of PHYs, and should not be used explicitly.

Fixes: 8c7ba536e709 ("ARM: sun8i: bananapi-m2-plus: Enable dwmac-sun8i")
Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agommc: tmio: fix SCC error handling to avoid false positive CRC error
Takeshi Saito [Wed, 15 May 2019 18:23:46 +0000 (20:23 +0200)]
mmc: tmio: fix SCC error handling to avoid false positive CRC error

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 51b72656bb39fdcb8f3174f4007bcc83ad1d275f ]

If an SCC error occurs during a read/write command execution, a false
positive CRC error message is output.

mmcblk0: response CRC error sending r/w cmd command, card status 0x900

check_scc_error() checks SCC_RVSREQ.RVSERR bit. RVSERR detects a
correction error in the next (up or down) delay tap position. However,
since the command is successful, only retuning needs to be executed.
This has been confirmed by HW engineers.

Thus, on SCC error, set retuning flag instead of setting an error code.

Fixes: b85fb0a1c8ae ("mmc: tmio: Fix SCC error detection")
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
[wsa: updated comment and commit message, removed some braces]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agopowerpc/time: Fix clockevent_decrementer initalisation for PR KVM
Michael Ellerman [Wed, 17 Oct 2018 12:39:41 +0000 (23:39 +1100)]
powerpc/time: Fix clockevent_decrementer initalisation for PR KVM

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit b4d16ab58c41ff0125822464bdff074cebd0fe47 ]

In the recent commit 8b78fdb045de ("powerpc/time: Use
clockevents_register_device(), fixing an issue with large
decrementer") we changed the way we initialise the decrementer
clockevent(s).

We no longer initialise the mult & shift values of
decrementer_clockevent itself.

This has the effect of breaking PR KVM, because it uses those values
in kvmppc_emulate_dec(). The symptom is guest kernels spin forever
mid-way through boot.

For now fix it by assigning back to decrementer_clockevent the mult
and shift values.

Fixes: 8b78fdb045de ("powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agotools: PCI: Fix broken pcitest compilation
Alan Mikhak [Thu, 23 May 2019 21:18:00 +0000 (14:18 -0700)]
tools: PCI: Fix broken pcitest compilation

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 8a5e0af240e07dd3d4897eb8ff52aab757da7fab ]

pcitest is currently broken due to the following compiler error
and related warning. Fix by changing the run_test() function
signature to return an integer result.

pcitest.c: In function run_test:
pcitest.c:143:9: warning: return with a value, in function
returning void
  return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */

pcitest.c: In function main:
pcitest.c:232:9: error: void value not ignored as it ought to be
  return run_test(test);

Fixes: fef31ecaaf2c ("tools: PCI: Fix compilation warnings")
Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Paul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoARM: dts: omap5: Fix dual-role mode on Super-Speed port
Roger Quadros [Wed, 5 Dec 2018 17:27:44 +0000 (19:27 +0200)]
ARM: dts: omap5: Fix dual-role mode on Super-Speed port

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit a763ecc15d0e37c3a15ff6825183061209832685 ]

OMAP5's Super-Speed USB port has a software mailbox register
that needs to be fed with VBUS and ID events from an external
VBUS/ID comparator.

Without this, Host role will not work correctly.

Fixes: 656c1a65ab55 ("ARM: dts: omap5: enable OTG role for DWC3 controller")
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomlxsw: spectrum_switchdev: Check notification relevance based on upper device
Ido Schimmel [Thu, 11 Oct 2018 07:47:52 +0000 (07:47 +0000)]
mlxsw: spectrum_switchdev: Check notification relevance based on upper device

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 5050f6ae253ad1307af3486c26fc4f94287078b7 ]

VxLAN FDB updates are sent with the VxLAN device which is not our upper
and will therefore be ignored by current code.

Solve this by checking whether the upper device (bridge) is our upper.

Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agospi: rockchip: initialize dma_slave_config properly
Huibin Hong [Wed, 10 Oct 2018 09:00:32 +0000 (11:00 +0200)]
spi: rockchip: initialize dma_slave_config properly

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit dd8fd2cbc73f8650f651da71fc61a6e4f30c1566 ]

The rxconf and txconf structs are allocated on the
stack, so make sure we zero them before filling out
the relevant fields.

Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomac80211: minstrel: fix sampling/reporting of CCK rates in HT mode
Felix Fietkau [Sat, 6 Oct 2018 17:35:05 +0000 (19:35 +0200)]
mac80211: minstrel: fix sampling/reporting of CCK rates in HT mode

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 972b66b86f85f4e8201db454f4c3e9d990cf9836 ]

Long/short preamble selection cannot be sampled separately, since it
depends on the BSS state. Because of that, sampling attempts to
currently not used preamble modes are not counted in the statistics,
which leads to CCK rates being sampled too often.

Fix statistics accounting for long/short preamble by increasing the
index where necessary.
Fix excessive CCK rate sampling by dropping unsupported sample attempts.

This improves throughput on 2.4 GHz channels

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomac80211: minstrel: fix CCK rate group streams value
Felix Fietkau [Sat, 6 Oct 2018 17:35:04 +0000 (19:35 +0200)]
mac80211: minstrel: fix CCK rate group streams value

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 80df9be67c44cb636bbc92caeddad8caf334c53c ]

Fixes a harmless underflow issue when CCK rates are actively being used

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomac80211: minstrel: fix using short preamble CCK rates on HT clients
Felix Fietkau [Sat, 6 Oct 2018 17:35:03 +0000 (19:35 +0200)]
mac80211: minstrel: fix using short preamble CCK rates on HT clients

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 37439f2d6e43ae79e22be9be159f0af157468f82 ]

mi->supported[MINSTREL_CCK_GROUP] needs to be updated
short preamble rates need to be marked as supported regardless of
whether it's currently enabled. Its state can change at any time without
a rate_update call.

Fixes: 782dda00ab8e ("mac80211: minstrel_ht: move short preamble check out of get_rate")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomisc: cxl: Fix possible null pointer dereference
zhong jiang [Thu, 4 Oct 2018 05:02:53 +0000 (13:02 +0800)]
misc: cxl: Fix possible null pointer dereference

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 3dac3583bf1a61db6aaf31dfd752c677a4400afd ]

It is not safe to dereference an object before a null test. It is
not needed and just remove them. Ftrace can be used instead.

Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agonetfilter: nft_compat: do not dump private area
Pablo Neira Ayuso [Tue, 9 Oct 2018 18:06:36 +0000 (20:06 +0200)]
netfilter: nft_compat: do not dump private area

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit d701d8117200399d85e63a737d2e4e897932f3b6 ]

Zero pad private area, otherwise we expose private kernel pointer to
userspace. This patch also zeroes the tail area after the ->matchsize
and ->targetsize that results from XT_ALIGN().

Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
Reported-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agohwmon: (ina3221) Fix INA3221_CONFIG_MODE macros
Nicolin Chen [Sat, 29 Sep 2018 21:44:06 +0000 (14:44 -0700)]
hwmon: (ina3221) Fix INA3221_CONFIG_MODE macros

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 791ebc9d34e9d212fc03742c31654b017d385926 ]

The three INA3221_CONFIG_MODE macros are not correctly defined here.
The MODE3-1 bits are located at BIT 2-0 according to the datasheet.

So this patch just fixes them by shifting all of them with a correct
offset. However, this isn't a crital bug fix as the driver does not
use any of them at this point.

Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agohwmon: (pwm-fan) Silence error on probe deferral
Thierry Reding [Fri, 21 Sep 2018 10:10:47 +0000 (12:10 +0200)]
hwmon: (pwm-fan) Silence error on probe deferral

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 9f67f7583e77fe5dc57aab3a6159c2642544eaad ]

Probe deferrals aren't actual errors, so silence the error message in
case the PWM cannot yet be acquired.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agopinctrl: gemini: Fix up TVC clock group
Linus Walleij [Wed, 10 Oct 2018 18:39:18 +0000 (20:39 +0200)]
pinctrl: gemini: Fix up TVC clock group

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit a85c928f6a7856a09e47d9b37faa3407c7ac6a8e ]

The previous fix made the TVC clock get muxed in on the
D-Link DIR-685 instead of giving nagging warnings of this
not working. Not good. We didn't want that, as it breaks
video.

Create a specific group for the TVC CLK, and break out
a specific GPIO group for it on the SL3516 so we can use
that line as GPIO if we don't need the TVC CLK.

Fixes: d17f477c5bc6 ("pinctrl: gemini: Mask and set properly")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoorangefs: rate limit the client not running info message
Colin Ian King [Wed, 5 Sep 2018 14:54:01 +0000 (15:54 +0100)]
orangefs: rate limit the client not running info message

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 2978d873471005577e7b68a528b4f256a529b030 ]

Currently accessing various /sys/fs/orangefs files will spam the
kernel log with the following info message when the client is not
running:

[  491.489284] sysfs_service_op_show: Client not running :-5:

Rate limit this info message to make it less spammy.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoARM: 8802/1: Call syscall_trace_exit even when system call skipped
Timothy E Baldwin [Mon, 8 Oct 2018 18:26:48 +0000 (19:26 +0100)]
ARM: 8802/1: Call syscall_trace_exit even when system call skipped

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit f18aef742c8fbd68e280dff0a63ba0ca6ee8ad85 ]

On at least x86 and ARM64, and as documented in the ptrace man page
a skipped system call will still cause a syscall exit ptrace stop.

Previous to this commit 32-bit ARM did not, resulting in strace
being confused when seccomp skips system calls.

This change also impacts programs that use ptrace to skip system calls.

Fixes: ad75b51459ae ("ARM: 7579/1: arch/allow a scno of -1 to not cause a SIGILL")
Signed-off-by: Timothy E Baldwin <T.E.Baldwin99@members.leeds.ac.uk>
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Kees Cook <keescook@chromium.org>
Tested-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agospi: spidev: Fix OF tree warning logic
Trent Piepho [Thu, 20 Sep 2018 19:18:34 +0000 (19:18 +0000)]
spi: spidev: Fix OF tree warning logic

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 605b3bec73cbd74b4ac937b580cd0b47d1300484 ]

spidev will make a big fuss if a device tree node binds a device by
using "spidev" as the node's compatible property.

However, the logic for this isn't looking for "spidev" in the
compatible, but rather checking that the device is NOT compatible with
spidev's list of devices.

This causes a false positive if a device not named "rohm,dh2228fv", etc.
binds to spidev, even if a means other than putting "spidev" in the
device tree was used.  E.g., the sysfs driver_override attribute.

Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agopinctrl: gemini: Mask and set properly
Linus Walleij [Tue, 9 Oct 2018 08:11:53 +0000 (10:11 +0200)]
pinctrl: gemini: Mask and set properly

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit d17f477c5bc6b4a5dd9f51ae263870da132a8e89 ]

The code was written under the assumption that the
regmap_update_bits() would mask the bits in the mask and
set the bits in the value.

It missed the points that it will not set bits in the value
unless these are also masked in the mask. Set value bits
that are not in the mask will simply be ignored.

Fixes: 06351d133dea ("pinctrl: add a Gemini SoC pin controller")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agospi: fsl-lpspi: Prevent FIFO under/overrun by default
Hieu Tran Dang [Tue, 2 Oct 2018 11:06:36 +0000 (18:06 +0700)]
spi: fsl-lpspi: Prevent FIFO under/overrun by default

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit de8978c388c66b8fca192213ec9f0727e964c652 ]

Certain devices don't work well when a transmit FIFO underrun or
receive FIFO overrun occurs. Example is the SAF400x radio chip when
running at high speed which leads to garbage being sent to/received from
the chip. In which case, it should stall waiting for further data to be
available before proceeding. This patch unset the NOSTALL bit in CFGR1
by default to prevent this issue.

Signed-off-by: Hieu Tran Dang <dangtranhieu2012@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agogpio: syscon: Fix possible NULL ptr usage
Marek Vasut [Wed, 3 Oct 2018 22:52:52 +0000 (00:52 +0200)]
gpio: syscon: Fix possible NULL ptr usage

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 70728c29465bc4bfa7a8c14304771eab77e923c7 ]

The priv->data->set can be NULL while flags contains GPIO_SYSCON_FEAT_OUT
and chip->set is valid pointer. This happens in case the controller uses
the default GPIO setter. Always use chip->set to access the setter to avoid
possible NULL pointer dereferencing.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agox86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
Bjorn Helgaas [Thu, 27 Sep 2018 14:21:55 +0000 (09:21 -0500)]
x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]

The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():

  int crash_load_segments(struct kimage *image)
  {
    ...
    walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
                        image, determine_backup_region);

walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.

KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.

Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9ffff], not [0-0xa0000].

Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Ingo Molnar <mingo@redhat.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: baiyaowei@cmss.chinamobile.com
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
Link: http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.stgit@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomedia: cx231xx: fix potential sign-extension overflow on large shift
Colin Ian King [Sat, 6 Oct 2018 18:01:42 +0000 (14:01 -0400)]
media: cx231xx: fix potential sign-extension overflow on large shift

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 32ae592036d7aeaabcccb2b1715373a68639a768 ]

Shifting the u8 value[3] by an int can lead to sign-extension
overflow. For example, if value[3] is 0xff and the shift is 24 then it
is promoted to int and then the top bit is sign-extended so that all
upper 32 bits are set.  Fix this by casting value[3] to a u32 before
the shift.

Detected by CoverityScan, CID#1016522 ("Unintended sign extension")

Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoGFS2: Flush the GFS2 delete workqueue before stopping the kernel threads
Tim Smith [Mon, 8 Oct 2018 17:15:40 +0000 (12:15 -0500)]
GFS2: Flush the GFS2 delete workqueue before stopping the kernel threads

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 1eb8d7387908022951792a46fa040ad3942b3b08 ]

Flushing the workqueue can cause operations to happen which might
call gfs2_log_reserve(), or get stuck waiting for locks taken by such
operations.  gfs2_log_reserve() can io_schedule(). If this happens, it
will never wake because the only thing which can wake it is gfs2_logd()
which was already stopped.

This causes umount of a gfs2 filesystem to wedge permanently if, for
example, the umount immediately follows a large delete operation.

When this occured, the following stack trace was obtained from the
umount command

[<ffffffff81087968>] flush_workqueue+0x1c8/0x520
[<ffffffffa0666e29>] gfs2_make_fs_ro+0x69/0x160 [gfs2]
[<ffffffffa0667279>] gfs2_put_super+0xa9/0x1c0 [gfs2]
[<ffffffff811b7edf>] generic_shutdown_super+0x6f/0x100
[<ffffffff811b7ff7>] kill_block_super+0x27/0x70
[<ffffffffa0656a71>] gfs2_kill_sb+0x71/0x80 [gfs2]
[<ffffffff811b792b>] deactivate_locked_super+0x3b/0x70
[<ffffffff811b79b9>] deactivate_super+0x59/0x60
[<ffffffff811d2998>] cleanup_mnt+0x58/0x80
[<ffffffff811d2a12>] __cleanup_mnt+0x12/0x20
[<ffffffff8108c87d>] task_work_run+0x7d/0xa0
[<ffffffff8106d7d9>] exit_to_usermode_loop+0x73/0x98
[<ffffffff81003961>] syscall_return_slowpath+0x41/0x50
[<ffffffff815a594c>] int_ret_from_sys_call+0x25/0x8f
[<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Tim Smith <tim.smith@citrix.com>
Signed-off-by: Mark Syms <mark.syms@citrix.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomedia: isif: fix a NULL pointer dereference bug
Wenwen Wang [Thu, 4 Oct 2018 15:44:02 +0000 (11:44 -0400)]
media: isif: fix a NULL pointer dereference bug

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit a26ac6c1bed951b2066cc4b2257facd919e35c0b ]

In isif_probe(), there is a while loop to get the ISIF base address and
linearization table0 and table1 address. In the loop body, the function
platform_get_resource() is called to get the resource. If
platform_get_resource() returns NULL, the loop is terminated and the
execution goes to 'fail_nobase_res'. Suppose the loop is terminated at the
first iteration because platform_get_resource() returns NULL and the
execution goes to 'fail_nobase_res'. Given that there is another while loop
at 'fail_nobase_res' and i equals to 0, one iteration of the second while
loop will be executed. However, the second while loop does not check the
return value of platform_get_resource(). This can cause a NULL pointer
dereference bug if the return value is a NULL pointer.

This patch avoids the above issue by adding a check in the second while
loop after the call to platform_get_resource().

Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoprintk: Give error on attempt to set log buffer length to over 2G
He Zhe [Sat, 29 Sep 2018 16:45:53 +0000 (00:45 +0800)]
printk: Give error on attempt to set log buffer length to over 2G

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit e6fe3e5b7d16e8f146a4ae7fe481bc6e97acde1e ]

The current printk() is ready to handle log buffer size up to 2G.
Give an explicit error for users who want to use larger log buffer.

Also fix printk formatting to show the 2G as a positive number.

Link: http://lkml.kernel.org/r/20181008135916.gg4kkmoki5bgtco5@pathway.suse.cz
Cc: rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: He Zhe <zhe.he@windriver.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
[pmladek: Fixed to the really safe limit 2GB.]
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable
Vignesh R [Sat, 30 Jun 2018 10:33:16 +0000 (16:03 +0530)]
mfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit c974ac771479327b5424f60d58845e31daddadea ]

If a child device like touchscreen is wakeup capable, then keep ADC
interface on, so that a touching resistive screen will generate wakeup
event to the system.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agobacklight: lm3639: Unconditionally call led_classdev_unregister
Nathan Chancellor [Fri, 21 Sep 2018 20:21:31 +0000 (13:21 -0700)]
backlight: lm3639: Unconditionally call led_classdev_unregister

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context.

drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (&pchip->cdev_torch)
        ~~   ~~~~~~~^~~~~~~~~~
drivers/video/backlight/lm3639_bl.c:405:14: warning: address of
'pchip->cdev_flash' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (&pchip->cdev_flash)
        ~~   ~~~~~~~^~~~~~~~~~
2 warnings generated.

These statements have been present since 2012, introduced by
commit 0f59858d5119 ("backlight: add new lm3639 backlight
driver"). Given that they have been called unconditionally since
then presumably without any issues, removing the always true if
statements to fix the warnings without any real world changes.

Link: https://github.com/ClangBuiltLinux/linux/issues/119
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoproc/vmcore: Fix i386 build error of missing copy_oldmem_page_encrypted()
Borislav Petkov [Mon, 8 Oct 2018 08:05:20 +0000 (10:05 +0200)]
proc/vmcore: Fix i386 build error of missing copy_oldmem_page_encrypted()

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit cf089611f4c446285046fcd426d90c18f37d2905 ]

Lianbo reported a build error with a particular 32-bit config, see Link
below for details.

Provide a weak copy_oldmem_page_encrypted() function which architectures
can override, in the same manner other functionality in that file is
supplied.

Reported-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: x86@kernel.org
Link: http://lkml.kernel.org/r/710b9d95-2f70-eadf-c4a1-c3dc80ee4ebb@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agos390/kasan: avoid vdso instrumentation
Vasily Gorbik [Fri, 17 Nov 2017 12:02:36 +0000 (13:02 +0100)]
s390/kasan: avoid vdso instrumentation

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 348498458505e202df41b6b9a78da448d39298b7 ]

vdso is mapped into user space processes, which won't have kasan
shodow mapped.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agomedia: dw9714: Fix error handling in probe function
Rajmohan Mani [Fri, 5 Oct 2018 16:22:17 +0000 (12:22 -0400)]
media: dw9714: Fix error handling in probe function

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit f9a0b14240a2d0bd196d35e8aac73df6eabd6382 ]

Fixed the case where v4l2_async_unregister_subdev()
is called unnecessarily in the error handling path
in probe function.

Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agobcache: recal cached_dev_sectors on detach
Shenghui Wang [Mon, 8 Oct 2018 12:41:15 +0000 (20:41 +0800)]
bcache: recal cached_dev_sectors on detach

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 46010141da6677b81cc77f9b47f8ac62bd1cbfd3 ]

Recal cached_dev_sectors on cached_dev detached, as recal done on
cached_dev attached.

Update the cached_dev_sectors before bcache_device_detach called
as bcache_device_detach will set bcache_device->c to NULL.

Signed-off-by: Shenghui Wang <shhuiw@foxmail.com>
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoreset: Fix potential use-after-free in __of_reset_control_get()
Geert Uytterhoeven [Mon, 8 Oct 2018 11:14:35 +0000 (13:14 +0200)]
reset: Fix potential use-after-free in __of_reset_control_get()

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit b790c8ea5593d6dc3580adfad8e117eeb56af874 ]

Calling of_node_put() decreases the reference count of a device tree
object, and may free some data.

However, the of_phandle_args structure embedding it is passed to
reset_controller_dev.of_xlate() after that, so it may still be accessed.

Move the call to of_node_put() down to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[p.zabel@pengutronix.de: moved of_node_put after mutex_unlock]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agofbdev: sbuslib: integer overflow in sbusfb_ioctl_helper()
Dan Carpenter [Mon, 8 Oct 2018 10:57:36 +0000 (12:57 +0200)]
fbdev: sbuslib: integer overflow in sbusfb_ioctl_helper()

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]

The "index + count" addition can overflow.  Both come directly from the
user.  This bug leads to an information leak.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Peter Malone <peter.malone@gmail.com>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agofbdev: sbuslib: use checked version of put_user()
Dan Carpenter [Mon, 8 Oct 2018 10:57:36 +0000 (12:57 +0200)]
fbdev: sbuslib: use checked version of put_user()

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]

I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check.  I have made all the put_user() and get_user()
calls checked.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Mathieu Malaterre <malat@debian.org>
Cc: Peter Malone <peter.malone@gmail.com>,
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agommc: tmio: Fix SCC error detection
Masaharu Hayakawa [Wed, 29 Aug 2018 23:32:07 +0000 (01:32 +0200)]
mmc: tmio: Fix SCC error detection

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit b85fb0a1c8aeaaa40d08945d51a6656b512173f0 ]

SDR104, HS200 and HS400 need to check for SCC error. If SCC error is
detected, retuning is necessary.

Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
[Niklas: update commit message]
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agox86/fsgsbase/64: Fix ptrace() to read the FS/GS base accurately
Andy Lutomirski [Tue, 18 Sep 2018 23:08:52 +0000 (16:08 -0700)]
x86/fsgsbase/64: Fix ptrace() to read the FS/GS base accurately

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 07e1d88adaaeab247b300926f78cc3f950dbeda3 ]

On 64-bit kernels ptrace can read the FS/GS base using the register access
APIs (PTRACE_PEEKUSER, etc.) or PTRACE_ARCH_PRCTL.

Make both of these mechanisms return the actual FS/GS base.

This will improve debuggability by providing the correct information
to ptracer such as GDB.

[ chang: Rebased and revised patch description. ]
[ mingo: Revised the changelog some more. ]

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Markus T Metzger <markus.t.metzger@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Shankar <ravi.v.shankar@intel.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537312139-5580-2-git-send-email-chang.seok.bae@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoiwlwifi: mvm: don't send keys when entering D3
Sara Sharon [Sun, 1 Jul 2018 11:52:06 +0000 (14:52 +0300)]
iwlwifi: mvm: don't send keys when entering D3

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 8c7fd6a365eb5b2647b2c01918730d0a485b9f85 ]

In the past, we needed to program the keys when entering D3. This was
since we replaced the image. However, now that there is a single
image, this is no longer needed.  Note that RSC is sent separately in
a new command.  This solves issues with newer devices that support PN
offload. Since driver re-sent the keys, the PN got zeroed and the
receiver dropped the next packets, until PN caught up again.

Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoACPI / SBS: Fix rare oops when removing modules
Ronald Tschalär [Mon, 1 Oct 2018 02:53:13 +0000 (19:53 -0700)]
ACPI / SBS: Fix rare oops when removing modules

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit 757c968c442397f1249bb775a7c8c03842e3e0c7 ]

There was a small race when removing the sbshc module where
smbus_alarm() had queued acpi_smbus_callback() for deferred execution
but it hadn't been run yet, so that when it did run hc had been freed
and the module unloaded, resulting in an invalid paging request.

A similar race existed when removing the sbs module with regards to
acpi_sbs_callback() (which is called from acpi_smbus_callback()).

We therefore need to ensure no callbacks are pending or executing before
the cleanups are done and the modules are removed.

Signed-off-by: Ronald Tschalär <ronald@innovation.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoxfrm: use correct size to initialise sp->ovec
Li RongQing [Sun, 7 Oct 2018 02:22:42 +0000 (10:22 +0800)]
xfrm: use correct size to initialise sp->ovec

BugLink: https://bugs.launchpad.net/bugs/1854216
[ Upstream commit f1193e915748291fb205a908db33bd3debece6e2 ]

This place should want to initialize array, not a element,
so it should be sizeof(array) instead of sizeof(element)

but now this array only has one element, so no error in
this condition that XFRM_MAX_OFFLOAD_DEPTH is 1

Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>