Jaegeuk Kim [Sat, 14 Dec 2019 02:32:16 +0000 (18:32 -0800)]
f2fs: free sysfs kobject
[ Upstream commit
820d366736c949ffe698d3b3fe1266a91da1766d ]
Detected kmemleak.
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jaegeuk Kim [Sat, 7 Dec 2019 00:59:58 +0000 (16:59 -0800)]
f2fs: set I_LINKABLE early to avoid wrong access by vfs
[ Upstream commit
5b1dbb082f196278f82b6a15a13848efacb9ff11 ]
This patch moves setting I_LINKABLE early in rename2(whiteout) to avoid the
below warning.
[ 3189.163385] WARNING: CPU: 3 PID: 59523 at fs/inode.c:358 inc_nlink+0x32/0x40
[ 3189.246979] Call Trace:
[ 3189.248707] f2fs_init_inode_metadata+0x2d6/0x440 [f2fs]
[ 3189.251399] f2fs_add_inline_entry+0x162/0x8c0 [f2fs]
[ 3189.254010] f2fs_add_dentry+0x69/0xe0 [f2fs]
[ 3189.256353] f2fs_do_add_link+0xc5/0x100 [f2fs]
[ 3189.258774] f2fs_rename2+0xabf/0x1010 [f2fs]
[ 3189.261079] vfs_rename+0x3f8/0xaa0
[ 3189.263056] ? tomoyo_path_rename+0x44/0x60
[ 3189.265283] ? do_renameat2+0x49b/0x550
[ 3189.267324] do_renameat2+0x49b/0x550
[ 3189.269316] __x64_sys_renameat2+0x20/0x30
[ 3189.271441] do_syscall_64+0x5a/0x230
[ 3189.273410] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 3189.275848] RIP: 0033:0x7f270b4d9a49
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 15 Jan 2020 17:46:04 +0000 (20:46 +0300)]
ALSA: usb-audio: unlock on error in probe
[ Upstream commit
a3afa29942b84b4e2548beacccc3a68b8d77e3dc ]
We need to unlock before we returning on this error path.
Fixes:
73ac9f5e5b43 ("ALSA: usb-audio: Add boot quirk for MOTU M Series")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200115174604.rhanfgy4j3uc65cx@kili.mountain
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Will Deacon [Wed, 15 Jan 2020 15:21:47 +0000 (15:21 +0000)]
iommu/arm-smmu-v3: Use WRITE_ONCE() when changing validity of an STE
[ Upstream commit
d71e01716b3606a6648df7e5646ae12c75babde4 ]
If, for some bizarre reason, the compiler decided to split up the write
of STE DWORD 0, we could end up making a partial structure valid.
Although this probably won't happen, follow the example of the
context-descriptor code and use WRITE_ONCE() to ensure atomicity of the
write.
Reported-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masahiro Yamada [Fri, 10 Jan 2020 05:02:24 +0000 (14:02 +0900)]
kbuild: remove *.tmp file when filechk fails
[ Upstream commit
88fe89a47153facd8cb2d06d5c8727f7224c43c2 ]
Bartosz Golaszewski reports that when "make {menu,n,g,x}config" fails
due to missing packages, a temporary file is left over, which is not
ignored by git.
For example, if GTK+ is not installed:
$ make gconfig
*
* Unable to find the GTK+ installation. Please make sure that
* the GTK+ 2.0 development package is correctly installed.
* You need gtk+-2.0 gmodule-2.0 libglade-2.0
*
scripts/kconfig/Makefile:208: recipe for target 'scripts/kconfig/gconf-cfg' failed
make[1]: *** [scripts/kconfig/gconf-cfg] Error 1
Makefile:567: recipe for target 'gconfig' failed
make: *** [gconfig] Error 2
$ git status
HEAD detached at v5.4
Untracked files:
(use "git add <file>..." to include in what will be committed)
scripts/kconfig/gconf-cfg.tmp
nothing added to commit but untracked files present (use "git add" to track)
This is because the check scripts are run with filechk, which misses
to clean up the temporary file on failure.
When the line
{ $(filechk_$(1)); } > $@.tmp;
... fails, it exits immediately due to the 'set -e'. Use trap to make
sure to delete the temporary file on exit.
For extra safety, I replaced $@.tmp with $(dot-target).tmp to make it
a hidden file.
Reported-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Wed, 15 Jan 2020 13:25:26 +0000 (07:25 -0600)]
usb: musb: omap2430: Get rid of musb .set_vbus for omap2430 glue
[ Upstream commit
91b6dec32e5c25fbdbb564d1e5af23764ec17ef1 ]
We currently have musb_set_vbus() called from two different paths. Mostly
it gets called from the USB PHY via omap_musb_set_mailbox(), but in some
cases it can get also called from musb_stage0_irq() rather via .set_vbus:
(musb_set_host [musb_hdrc])
(omap2430_musb_set_vbus [omap2430])
(musb_stage0_irq [musb_hdrc])
(musb_interrupt [musb_hdrc])
(omap2430_musb_interrupt [omap2430])
This is racy and will not work with introducing generic helper functions
for musb_set_host() and musb_set_peripheral(). We want to get rid of the
busy loops in favor of usleep_range().
Let's just get rid of .set_vbus for omap2430 glue layer and let the PHY
code handle VBUS with musb_set_vbus(). Note that in the follow-up patch
we can completely remove omap2430_musb_set_vbus(), but let's do it in a
separate patch as this change may actually turn out to be needed as a
fix.
Reported-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Link: https://lore.kernel.org/r/20200115132547.364-5-b-liu@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leonard Crestez [Tue, 14 Jan 2020 20:25:46 +0000 (22:25 +0200)]
perf/imx_ddr: Fix cpu hotplug state cleanup
[ Upstream commit
9ee68b314e9aa63ed11b98beb8a68810b8234dcf ]
This driver allocates a dynamic cpu hotplug state but never releases it.
If reloaded in a loop it will quickly trigger a WARN message:
"No more dynamic states available for CPU hotplug"
Fix by calling cpuhp_remove_multi_state on remove like several other
perf pmu drivers.
Also fix the cleanup logic on probe error paths: add the missing
cpuhp_remove_multi_state call and properly check the return value from
cpuhp_state_add_instant_nocalls.
Fixes:
9a66d36cc7ac ("drivers/perf: imx_ddr: Add DDR performance counter support to perf")
Acked-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Navid Emamdoost [Wed, 25 Sep 2019 04:37:58 +0000 (23:37 -0500)]
drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add
[ Upstream commit
40efb09a7f53125719e49864da008495e39aaa1e ]
In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
for cres should be released.
Fixes:
18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Boyd [Tue, 14 Jan 2020 23:11:03 +0000 (15:11 -0800)]
gpiolib: Set lockdep class for hierarchical irq domains
[ Upstream commit
c34f6dc8c9e6bbe9fba1d53acd6d9a3889599da3 ]
I see the following lockdep splat in the qcom pinctrl driver when
attempting to suspend the device.
============================================
WARNING: possible recursive locking detected
5.4.2 #2 Tainted: G S
--------------------------------------------
cat/6536 is trying to acquire lock:
ffffff814787ccc0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
but task is already holding lock:
ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by cat/6536:
#0:
ffffff8140e0c420 (sb_writers#7){.+.+}, at: vfs_write+0xc8/0x19c
#1:
ffffff8121eec480 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x1f4
#2:
ffffff8147cad668 (kn->count#263){.+.+}, at: kernfs_fop_write+0x130/0x1f4
#3:
ffffffd011446000 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x354
#4:
ffffff814302b970 (&dev->mutex){....}, at: __device_suspend+0x16c/0x420
#5:
ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
#6:
ffffff81479b8c10 (&pctrl->lock){....}, at: msm_gpio_irq_set_wake+0x48/0x7c
stack backtrace:
CPU: 4 PID: 6536 Comm: cat Tainted: G S 5.4.2 #2
Call trace:
dump_backtrace+0x0/0x174
show_stack+0x20/0x2c
dump_stack+0xdc/0x144
__lock_acquire+0x52c/0x2268
lock_acquire+0x1dc/0x220
_raw_spin_lock_irqsave+0x64/0x80
__irq_get_desc_lock+0x64/0x94
irq_set_irq_wake+0x40/0x144
msm_gpio_irq_set_wake+0x5c/0x7c
set_irq_wake_real+0x40/0x5c
irq_set_irq_wake+0x70/0x144
cros_ec_rtc_suspend+0x38/0x4c
platform_pm_suspend+0x34/0x60
dpm_run_callback+0x64/0xcc
__device_suspend+0x314/0x420
dpm_suspend+0xf8/0x298
dpm_suspend_start+0x84/0xb4
suspend_devices_and_enter+0xbc/0x628
pm_suspend+0x214/0x354
state_store+0xb0/0x108
kobj_attr_store+0x14/0x24
sysfs_kf_write+0x4c/0x64
kernfs_fop_write+0x158/0x1f4
__vfs_write+0x54/0x18c
vfs_write+0xdc/0x19c
ksys_write+0x7c/0xe4
__arm64_sys_write+0x20/0x2c
el0_svc_common+0xa8/0x160
el0_svc_compat_handler+0x2c/0x38
el0_svc_compat+0x8/0x10
This is because the msm_gpio_irq_set_wake() function calls
irq_set_irq_wake() as a backup in case the irq comes in during the path
to idle. Given that we're calling irqchip functions from within an
irqchip we need to set the lockdep class to be different for this child
controller vs. the default one that the parent irqchip gets.
This used to be done before this driver was converted to hierarchical
irq domains in commit
e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in
hierarchy") via the gpiochip_irq_map() function. With hierarchical irq
domains this function has been replaced by
gpiochip_hierarchy_irq_domain_alloc(). Therefore, set the lockdep class
like was done previously in the irq domain path so we can avoid this
lockdep warning.
Fixes:
fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains")
Cc: Thierry Reding <treding@nvidia.com>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200114231103.85641-1-swboyd@chromium.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mikulas Patocka [Mon, 13 Jan 2020 20:04:37 +0000 (15:04 -0500)]
dm thin: don't allow changing data device during thin-pool reload
[ Upstream commit
873937e75f9a8ea231a502c3d29d9cb6ad91b3ef ]
The existing code allows changing the data device when the thin-pool
target is reloaded.
This capability is not required and only complicates device lifetime
guarantees. This can cause crashes like the one reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1788596
where the kernel tries to issue a flush bio located in a structure that
was already freed.
Take the first step to simplifying the thin-pool's data device lifetime
by disallowing changing it. Like the thin-pool's metadata device, the
data device is now set in pool_create() and it cannot be changed for a
given thin-pool.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Skeggs [Tue, 14 Jan 2020 20:34:21 +0000 (06:34 +1000)]
drm/nouveau/fault/gv100-: fix memory leak on module unload
[ Upstream commit
633cc9beeb6f9b5fa2f17a2a9d0e2790cb6c3de7 ]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Fri, 10 Jan 2020 07:28:37 +0000 (15:28 +0800)]
drm/nouveau/drm/ttm: Remove set but not used variable 'mem'
[ Upstream commit
2e4534a22794746b11a794b2229b8d58797eccce ]
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new:
drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:
drivers/gpu/drm/nouveau/nouveau_ttm.c:106:22: warning: variable mem set but not used [-Wunused-but-set-variable]
They are not used any more, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Fri, 10 Jan 2020 06:32:01 +0000 (14:32 +0800)]
drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
[ Upstream commit
1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ]
Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.
Fixes:
0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Skeggs [Thu, 9 Jan 2020 01:46:15 +0000 (11:46 +1000)]
drm/nouveau/gr/gk20a,gm200-: add terminators to method lists read from fw
[ Upstream commit
7adc77aa0e11f25b0e762859219c70852cd8d56f ]
Method init is typically ordered by class in the FW image as ThreeD,
TwoD, Compute.
Due to a bug in parsing the FW into our internal format, we've been
accidentally sending Twod + Compute methods to the ThreeD class, as
well as Compute methods to the TwoD class - oops.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 8 Jan 2020 05:46:01 +0000 (08:46 +0300)]
drm/nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new()
[ Upstream commit
3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ]
We accidentally set "psb" which is a no-op instead of "*psb" so it
generates a static checker warning. We should probably set it before
the first error return so that it's always initialized.
Fixes:
923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Tue, 7 Jan 2020 20:05:43 +0000 (21:05 +0100)]
vme: bridges: reduce stack usage
[ Upstream commit
7483e7a939c074d887450ef1c4d9ccc5909405f8 ]
With CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, the stack usage in vme_fake
grows above the warning limit:
drivers/vme/bridges/vme_fake.c: In function 'fake_master_read':
drivers/vme/bridges/vme_fake.c:610:1: error: the frame size of 1160 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/vme/bridges/vme_fake.c: In function 'fake_master_write':
drivers/vme/bridges/vme_fake.c:797:1: error: the frame size of 1160 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
The problem is that in some configurations, each call to
fake_vmereadX() puts another variable on the stack.
Reduce the amount of inlining to get back to the previous state,
with no function using more than 200 bytes each.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200107200610.3482901-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Li RongQing [Fri, 10 Jan 2020 01:04:37 +0000 (09:04 +0800)]
bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map
[ Upstream commit
0a29275b6300f39f78a87f2038bbfe5bdbaeca47 ]
A negative value should be returned if map->map_type is invalid
although that is impossible now, but if we run into such situation
in future, then xdpbuff could be leaked.
Daniel Borkmann suggested:
-EBADRQC should be returned to stay consistent with generic XDP
for the tracepoint output and not to be confused with -EOPNOTSUPP
from other locations like dev_map_enqueue() when ndo_xdp_xmit is
missing and such.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/1578618277-18085-1-git-send-email-lirongqing@baidu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Mon, 13 Jan 2020 20:56:20 +0000 (14:56 -0600)]
ASoC: SOF: Intel: hda-dai: fix compilation warning in pcm_prepare
[ Upstream commit
d873997192ddcacb5333575502be2f91ea4b47b8 ]
Fix GCC warning with W=1, previous cleanup did not remove unnecessary
variable.
sound/soc/sof/intel/hda-dai.c: In function ‘hda_link_pcm_prepare’:
sound/soc/sof/intel/hda-dai.c:265:31: warning: variable ‘hda_stream’
set but not used [-Wunused-but-set-variable]
265 | struct sof_intel_hda_stream *hda_stream;
| ^~~~~~~~~~
Fixes:
a3ebccb52efdf ("ASoC: SOF: Intel: hda: reset link DMA state in prepare")
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200113205620.27285-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Fri, 6 Dec 2019 13:22:19 +0000 (14:22 +0100)]
driver core: Print device when resources present in really_probe()
[ Upstream commit
7c35e699c88bd60734277b26962783c60e04b494 ]
If a device already has devres items attached before probing, a warning
backtrace is printed. However, this backtrace does not reveal the
offending device, leaving the user uninformed. Furthermore, using
WARN_ON() causes systems with panic-on-warn to reboot.
Fix this by replacing the WARN_ON() by a dev_crit() message.
Abort probing the device, to prevent doing more damage to the device's
resources.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191206132219.28908-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Simon Schwartz [Tue, 10 Dec 2019 22:41:37 +0000 (17:41 -0500)]
driver core: platform: Prevent resouce overflow from causing infinite loops
[ Upstream commit
39cc539f90d035a293240c9443af50be55ee81b8 ]
num_resources in the platform_device struct is declared as a u32. The
for loops that iterate over num_resources use an int as the counter,
which can cause infinite loops on architectures with smaller ints.
Change the loop counters to u32.
Signed-off-by: Simon Schwartz <kern.simon@theschwartz.xyz>
Link: https://lore.kernel.org/r/2201ce63a2a171ffd2ed14e867875316efcf71db.camel@theschwartz.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Tue, 7 Jan 2020 20:29:40 +0000 (21:29 +0100)]
visorbus: fix uninitialized variable access
[ Upstream commit
caf82f727e69b647f09d57a1fc56e69d22a5f483 ]
The setup_crash_devices_work_queue function only partially initializes
the message it sends to chipset_init, leading to undefined behavior:
drivers/visorbus/visorchipset.c: In function 'setup_crash_devices_work_queue':
drivers/visorbus/visorchipset.c:333:6: error: '((unsigned char*)&msg.hdr.flags)[0]' is used uninitialized in this function [-Werror=uninitialized]
if (inmsg->hdr.flags.response_expected)
Set up the entire structure, zero-initializing the 'response_expected'
flag.
This was apparently found by the patch that added the -O3 build option
in Kconfig.
Fixes:
12e364b9f08a ("staging: visorchipset driver to provide registration and other services")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200107202950.782951-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luc Van Oostenryck [Mon, 9 Dec 2019 21:36:55 +0000 (22:36 +0100)]
misc: xilinx_sdfec: fix xsdfec_poll()'s return type
[ Upstream commit
fa4e7fc1386078edcfddd8848cb0374f4af74fe7 ]
xsdfec_poll() is defined as returning 'unsigned int' but the
.poll method is declared as returning '__poll_t', a bitwise type.
Fix this by using the proper return type and using the EPOLL
constants instead of the POLL ones, as required for __poll_t.
CC: Derek Kiernan <derek.kiernan@xilinx.com>
CC: Dragan Cvetic <dragan.cvetic@xilinx.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Dragan Cvetic <dragan.cvetic@xilinx.com>
Link: https://lore.kernel.org/r/20191209213655.57985-1-luc.vanoostenryck@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 18 Dec 2019 02:39:13 +0000 (19:39 -0700)]
tty: synclink_gt: Adjust indentation in several functions
[ Upstream commit
446e76873b5e4e70bdee5db2f2a894d5b4a7d081 ]
Clang warns:
../drivers/tty/synclink_gt.c:1337:3: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
if (C_CRTSCTS(tty)) {
^
../drivers/tty/synclink_gt.c:1335:2: note: previous statement is here
if (I_IXOFF(tty))
^
../drivers/tty/synclink_gt.c:2563:3: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
if (I_BRKINT(info->port.tty) || I_PARMRK(info->port.tty))
^
../drivers/tty/synclink_gt.c:2561:2: note: previous statement is here
if (I_INPCK(info->port.tty))
^
../drivers/tty/synclink_gt.c:3221:3: warning: misleading indentation;
statement is not part of the previous 'else' [-Wmisleading-indentation]
set_signals(info);
^
../drivers/tty/synclink_gt.c:3219:2: note: previous statement is here
else
^
3 warnings generated.
The indentation on these lines is not at all consistent, tabs and spaces
are mixed together. Convert to just using tabs to be consistent with the
Linux kernel coding style and eliminate these warnings from clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/822
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20191218023912.13827-1-natechancellor@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 18 Dec 2019 02:47:20 +0000 (19:47 -0700)]
tty: synclinkmp: Adjust indentation in several functions
[ Upstream commit
1feedf61e7265128244f6993f23421f33dd93dbc ]
Clang warns:
../drivers/tty/synclinkmp.c:1456:3: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
if (C_CRTSCTS(tty)) {
^
../drivers/tty/synclinkmp.c:1453:2: note: previous statement is here
if (I_IXOFF(tty))
^
../drivers/tty/synclinkmp.c:2473:8: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
info->port.tty->hw_stopped = 0;
^
../drivers/tty/synclinkmp.c:2471:7: note: previous statement is here
if ( debug_level >= DEBUG_LEVEL_ISR )
^
../drivers/tty/synclinkmp.c:2482:8: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
info->port.tty->hw_stopped = 1;
^
../drivers/tty/synclinkmp.c:2480:7: note: previous statement is here
if ( debug_level >= DEBUG_LEVEL_ISR )
^
../drivers/tty/synclinkmp.c:2809:3: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
if (I_BRKINT(info->port.tty) || I_PARMRK(info->port.tty))
^
../drivers/tty/synclinkmp.c:2807:2: note: previous statement is here
if (I_INPCK(info->port.tty))
^
../drivers/tty/synclinkmp.c:3246:3: warning: misleading indentation;
statement is not part of the previous 'else' [-Wmisleading-indentation]
set_signals(info);
^
../drivers/tty/synclinkmp.c:3244:2: note: previous statement is here
else
^
5 warnings generated.
The indentation on these lines is not at all consistent, tabs and spaces
are mixed together. Convert to just using tabs to be consistent with the
Linux kernel coding style and eliminate these warnings from clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/823
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20191218024720.3528-1-natechancellor@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhengyuan Liu [Fri, 20 Dec 2019 02:21:27 +0000 (10:21 +0800)]
raid6/test: fix a compilation warning
[ Upstream commit
5e5ac01c2b8802921fee680518a986011cb59820 ]
The compilation warning is redefination showed as following:
In file included from tables.c:2:
../../../include/linux/export.h:180: warning: "EXPORT_SYMBOL" redefined
#define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "")
In file included from tables.c:1:
../../../include/linux/raid/pq.h:61: note: this is the location of the previous definition
#define EXPORT_SYMBOL(sym)
Fixes:
69a94abb82ee ("export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols")
Signed-off-by: Zhengyuan Liu <liuzhengyuan@kylinos.cn>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Zhou [Mon, 13 Jan 2020 13:32:42 +0000 (21:32 +0800)]
ASoC: atmel: fix build error with CONFIG_SND_ATMEL_SOC_DMA=m
[ Upstream commit
8fea78029f5e6ed734ae1957bef23cfda1af4354 ]
If CONFIG_SND_ATMEL_SOC_DMA=m, build error:
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
(.text+0x7cd): undefined reference to `atmel_pcm_dma_platform_register'
Function atmel_pcm_dma_platform_register is defined under
CONFIG SND_ATMEL_SOC_DMA, so select SND_ATMEL_SOC_DMA in
CONFIG SND_ATMEL_SOC_SSC, same to CONFIG_SND_ATMEL_SOC_PDC.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Link: https://lore.kernel.org/r/20200113133242.144550-1-chenzhou10@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexander Tsoy [Sun, 12 Jan 2020 10:23:58 +0000 (13:23 +0300)]
ALSA: usb-audio: Add boot quirk for MOTU M Series
[ Upstream commit
73ac9f5e5b43a5dbadb61f27dae7a971f7ec0d22 ]
Add delay to make sure that audio urbs are not sent too early.
Otherwise the device hangs. Windows driver makes ~2s delay, so use
about the same time delay value.
snd_usb_apply_boot_quirk() is called 3 times for my MOTU M4, which
is an overkill. Thus a quirk that is called only once is implemented.
Also send two vendor-specific control messages before and after
the delay. This behaviour is blindly copied from the Windows driver.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200112102358.18085-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johan Jonker [Fri, 10 Jan 2020 13:44:20 +0000 (14:44 +0100)]
ARM: dts: rockchip: add reg property to brcmf sub node for rk3188-bqedison2qc
[ Upstream commit
cf206bca178cd5b5a436494b2e0cea75295944f4 ]
An experimental test with the command below gives this error:
rk3188-bqedison2qc.dt.yaml: dwmmc@
10218000: wifi@1:
'reg' is a required property
So fix this by adding a reg property to the brcmf sub node.
Also add #address-cells and #size-cells to prevent more warnings.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200110134420.11280-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johan Jonker [Fri, 10 Jan 2020 14:21:28 +0000 (15:21 +0100)]
arm64: dts: rockchip: add reg property to brcmf sub-nodes
[ Upstream commit
96ff264bccb22175bbe2185a1eb5204ca3c5f03f ]
An experimental test with the command below gives this error:
rk3399-firefly.dt.yaml: dwmmc@
fe310000: wifi@1:
'reg' is a required property
rk3399-orangepi.dt.yaml: dwmmc@
fe310000: wifi@1:
'reg' is a required property
rk3399-khadas-edge.dt.yaml: dwmmc@
fe310000: wifi@1:
'reg' is a required property
rk3399-khadas-edge-captain.dt.yaml: dwmmc@
fe310000: wifi@1:
'reg' is a required property
rk3399-khadas-edge-v.dt.yaml: dwmmc@
fe310000: wifi@1:
'reg' is a required property
So fix this by adding a reg property to the brcmf sub node.
Also add #address-cells and #size-cells to prevent more warnings.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200110142128.13522-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johan Jonker [Fri, 10 Jan 2020 16:12:00 +0000 (17:12 +0100)]
arm64: dts: rockchip: fix dwmmc clock name for px30
[ Upstream commit
7f2147350291569acd1df5a26dcdfc573916016f ]
An experimental test with the command below gives this error:
px30-evb.dt.yaml: dwmmc@
ff390000: clock-names:2:
'ciu-drive' was expected
'ciu-drv' is not a valid dwmmc clock name,
so fix this by changing it to 'ciu-drive'.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200110161200.22755-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bartosz Golaszewski [Fri, 10 Jan 2020 17:16:41 +0000 (18:16 +0100)]
clocksource: davinci: only enable clockevents once tim34 is initialized
[ Upstream commit
cea931c25104e6bddc42eb067f58193f355dbdd7 ]
The DM365 platform has a strange quirk (only present when using ancient
u-boot - mainline u-boot v2013.01 and later works fine) where if we
enable the second half of the timer in periodic mode before we do its
initialization - the time won't start flowing and we can't boot.
When using more recent u-boot, we can enable the timer, then reinitialize
it and all works fine.
To work around this issue only enable clockevents once tim34 is
initialized i.e. move clockevents_config_and_register() below tim34
initialization.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Sun, 12 Jan 2020 12:04:42 +0000 (13:04 +0100)]
wan: ixp4xx_hss: fix compile-testing on 64-bit
[ Upstream commit
504c28c853ec5c626900b914b5833daf0581a344 ]
Change the driver to use portable integer types to avoid
warnings during compile testing:
drivers/net/wan/ixp4xx_hss.c:863:21: error: cast to 'u32 *' (aka 'unsigned int *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast]
memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4);
^
drivers/net/wan/ixp4xx_hss.c:979:12: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'dma_addr_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
&port->desc_tab_phys)))
^~~~~~~~~~~~~~~~~~~~
include/linux/dmapool.h:27:20: note: passing argument to parameter 'handle' here
dma_addr_t *handle);
^
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 11 Jan 2020 12:54:27 +0000 (20:54 +0800)]
x86/nmi: Remove irq_work from the long duration NMI handler
[ Upstream commit
248ed51048c40d36728e70914e38bffd7821da57 ]
First, printk() is NMI-context safe now since the safe printk() has been
implemented and it already has an irq_work to make NMI-context safe.
Second, this NMI irq_work actually does not work if a NMI handler causes
panic by watchdog timeout. It has no chance to run in such case, while
the safe printk() will flush its per-cpu buffers before panicking.
While at it, repurpose the irq_work callback into a function which
concentrates the NMI duration checking and makes the code easier to
follow.
[ bp: Massage. ]
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200111125427.15662-1-changbin.du@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Lemon [Thu, 9 Jan 2020 19:35:42 +0000 (11:35 -0800)]
bnxt: Detach page from page pool before sending up the stack
[ Upstream commit
3071c51783b39d6a676d02a9256c3b3f87804285 ]
When running in XDP mode, pages come from the page pool, and should
be freed back to the same pool or specifically detached. Currently,
when the driver re-initializes, the page pool destruction is delayed
forever since it thinks there are oustanding pages.
Fixes:
322b87ca55f2 ("bnxt_en: add page_pool support")
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Philipp Zabel [Fri, 10 Jan 2020 01:03:21 +0000 (17:03 -0800)]
Input: edt-ft5x06 - work around first register access error
[ Upstream commit
e112324cc0422c046f1cf54c56f333d34fa20885 ]
The EP0700MLP1 returns bogus data on the first register read access
(reading the threshold parameter from register 0x00):
edt_ft5x06 2-0038: crc error: 0xfc expected, got 0x40
It ignores writes until then. This patch adds a dummy read after which
the number of sensors and parameter read/writes work correctly.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul E. McKenney [Sat, 9 Nov 2019 17:42:13 +0000 (09:42 -0800)]
rcu: Use WRITE_ONCE() for assignments to ->pprev for hlist_nulls
[ Upstream commit
860c8802ace14c646864795e057349c9fb2d60ad ]
Eric Dumazet supplied a KCSAN report of a bug that forces use
of hlist_unhashed_lockless() from sk_unhashed():
------------------------------------------------------------------------
BUG: KCSAN: data-race in inet_unhash / inet_unhash
write to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 1:
__hlist_nulls_del include/linux/list_nulls.h:88 [inline]
hlist_nulls_del_init_rcu include/linux/rculist_nulls.h:36 [inline]
__sk_nulls_del_node_init_rcu include/net/sock.h:676 [inline]
inet_unhash+0x38f/0x4a0 net/ipv4/inet_hashtables.c:612
tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249
tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854
tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56
tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479
tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599
tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619
call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786
__do_softirq+0x115/0x33f kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0xbb/0xe0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x1af/0x280 kernel/sched/idle.c:263
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
start_secondary+0x208/0x260 arch/x86/kernel/smpboot.c:264
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
read to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 0:
sk_unhashed include/net/sock.h:607 [inline]
inet_unhash+0x3d/0x4a0 net/ipv4/inet_hashtables.c:592
tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249
tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854
tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56
tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479
tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599
tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619
call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786
__do_softirq+0x115/0x33f kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0xbb/0xe0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x1af/0x280 kernel/sched/idle.c:263
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
rest_init+0xec/0xf6 init/main.c:452
arch_call_rest_init+0x17/0x37
start_kernel+0x838/0x85e init/main.c:786
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490
x86_64_start_kernel+0x72/0x76 arch/x86/kernel/head64.c:471
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc6+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
------------------------------------------------------------------------
This commit therefore replaces C-language assignments with WRITE_ONCE()
in include/linux/list_nulls.h and include/linux/rculist_nulls.h.
Reported-by: Eric Dumazet <edumazet@google.com> # For KCSAN
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Fri, 3 Jan 2020 11:39:46 +0000 (12:39 +0100)]
efi/x86: Don't panic or BUG() on non-critical error conditions
[ Upstream commit
e2d68a955e49d61fd0384f23e92058dc9b79be5e ]
The logic in __efi_enter_virtual_mode() does a number of steps in
sequence, all of which may fail in one way or the other. In most
cases, we simply print an error and disable EFI runtime services
support, but in some cases, we BUG() or panic() and bring down the
system when encountering conditions that we could easily handle in
the same way.
While at it, replace a pointless page-to-virt-phys conversion with
one that goes straight from struct page to physical.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Matthew Garrett <mjg59@google.com>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-14-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Osipenko [Wed, 18 Dec 2019 18:23:03 +0000 (21:23 +0300)]
soc/tegra: fuse: Correct straps' address for older Tegra124 device trees
[ Upstream commit
2d9ea1934f8ef0dfb862d103389562cc28b4fc03 ]
Trying to read out Chip ID before APBMISC registers are mapped won't
succeed, in a result Tegra124 gets a wrong address for the HW straps
register if machine uses an old outdated device tree.
Fixes:
297c4f3dcbff ("soc/tegra: fuse: Restrict legacy code to 32-bit ARM")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mike Marciniszyn [Mon, 6 Jan 2020 13:42:35 +0000 (08:42 -0500)]
IB/hfi1: Add RcvShortLengthErrCnt to hfi1stats
[ Upstream commit
2c9d4e26d1ab27ceae2ded2ffe930f8e5f5b2a89 ]
This counter, RxShrErr, is required for error analysis and debug.
Fixes:
7724105686e7 ("IB/hfi1: add driver files")
Link: https://lore.kernel.org/r/20200106134235.119356.29123.stgit@awfm-01.aw.intel.com
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@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>
Mike Marciniszyn [Mon, 6 Jan 2020 13:42:28 +0000 (08:42 -0500)]
IB/hfi1: Add software counter for ctxt0 seq drop
[ Upstream commit
5ffd048698ea5139743acd45e8ab388a683642b8 ]
All other code paths increment some form of drop counter.
This was missed in the original implementation.
Fixes:
82c2611daaf0 ("staging/rdma/hfi1: Handle packets with invalid RHF on context 0")
Link: https://lore.kernel.org/r/20200106134228.119356.96828.stgit@awfm-01.aw.intel.com
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@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>
Arnd Bergmann [Sat, 4 Jan 2020 21:48:21 +0000 (22:48 +0100)]
staging: rtl8188: avoid excessive stack usage
[ Upstream commit
c497ae2077c055b85c1bf04f3d182a84bd8f365b ]
The rtl8188 copy of the os_dep support code causes a
warning about a very significant stack usage in the translate_scan()
function:
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c: In function 'translate_scan':
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:306:1: error: the frame size of 1560 bytes is larger than 1400 bytes [-Werror=frame-larger-than=]
Use the same trick as in the rtl8723bs copy of the same function, and
allocate it dynamically.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200104214832.558198-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yongqiang Niu [Fri, 13 Dec 2019 07:28:51 +0000 (15:28 +0800)]
drm/mediatek: Add gamma property according to hardware capability
[ Upstream commit
4cebc1de506fa753301266a5a23bb21bca52ad3a ]
If there is no gamma function in the crtc
display path, don't add gamma property
for crtc
Fixes:
2f3f4dda747c ("drm/mediatek: Add gamma correction.")
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Kara [Tue, 7 Jan 2020 15:36:49 +0000 (16:36 +0100)]
udf: Fix free space reporting for metadata and virtual partitions
[ Upstream commit
a4a8b99ec819ca60b49dc582a4287ef03411f117 ]
Free space on filesystems with metadata or virtual partition maps
currently gets misreported. This is because these partitions are just
remapped onto underlying real partitions from which keep track of free
blocks. Take this remapping into account when counting free blocks as
well.
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shuah Khan [Thu, 9 Jan 2020 01:24:16 +0000 (18:24 -0700)]
usbip: Fix unsafe unaligned pointer usage
[ Upstream commit
585c91f40d201bc564d4e76b83c05b3b5363fe7e ]
Fix unsafe unaligned pointer usage in usbip network interfaces. usbip tool
build fails with new gcc -Werror=address-of-packed-member checks.
usbip_network.c: In function ‘usbip_net_pack_usb_device’:
usbip_network.c:79:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
79 | usbip_net_pack_uint32_t(pack, &udev->busnum);
Fix with minor changes to pass by value instead of by address.
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200109012416.2875-1-skhan@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Benjamin Gaignard [Wed, 8 Jan 2020 13:26:47 +0000 (14:26 +0100)]
ARM: dts: stm32: Add power-supply for DSI panel on stm32f469-disco
[ Upstream commit
0ff15a86d0c5a3f004fee2e92d65b88e56a3bc58 ]
Add a fixed regulator and use it as power supply for DSI panel.
Fixes:
18c8866266 ("ARM: dts: stm32: Add display support on stm32f469-disco")
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Torokhov [Fri, 13 Dec 2019 17:46:23 +0000 (09:46 -0800)]
usb: dwc3: use proper initializers for property entries
[ Upstream commit
5eb5afb07853d6e90d3a2b230c825e028e948f79 ]
We should not be reaching into property entries and initialize them by
hand, but rather use proper initializer macros. This way we can alter
internal representation of property entries with no visible changes to
their users.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dingchen Zhang [Mon, 10 Jun 2019 13:47:51 +0000 (09:47 -0400)]
drm: remove the newline for CRC source name.
[ Upstream commit
72a848f5c46bab4c921edc9cbffd1ab273b2be17 ]
userspace may transfer a newline, and this terminating newline
is replaced by a '\0' to avoid followup issues.
'len-1' is the index to replace the newline of CRC source name.
v3: typo fix (Sam)
v2: update patch subject, body and format. (Sam)
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Dingchen Zhang <dingchen.zhang@amd.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610134751.14356-1-dingchen.zhang@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wenpeng Liang [Mon, 6 Jan 2020 12:21:10 +0000 (20:21 +0800)]
RDMA/hns: Avoid printing address of mtt page
[ Upstream commit
eca44507c3e908b7362696a4d6a11d90371334c6 ]
Address of a page shouldn't be printed in case of security issues.
Link: https://lore.kernel.org/r/1578313276-29080-2-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Sat, 4 Jan 2020 21:51:44 +0000 (22:51 +0100)]
mlx5: work around high stack usage with gcc
[ Upstream commit
42ae1a5c76691928ed217c7e40269db27f5225e9 ]
In some configurations, gcc tries too hard to optimize this code:
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function 'mlx5e_grp_sw_update_stats':
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:302:1: error: the frame size of 1336 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
As was stated in the bug report, the reason is that gcc runs into a corner
case in the register allocator that is rather hard to fix in a good way.
As there is an easy way to work around it, just add a comment and the
barrier that stops gcc from trying to overoptimize the function.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Felix Kuehling [Fri, 20 Dec 2019 03:36:55 +0000 (22:36 -0500)]
drm/amdkfd: Fix permissions of hang_hws
[ Upstream commit
2bdac179e217a0c0b548a8c60524977586621b19 ]
Reading from /sys/kernel/debug/kfd/hang_hws would cause a kernel
oops because we didn't implement a read callback. Set the permission
to write-only to prevent that.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: shaoyunl <shaoyun.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jacob Pan [Thu, 2 Jan 2020 00:18:09 +0000 (08:18 +0800)]
iommu/vt-d: Avoid sending invalid page response
[ Upstream commit
5f75585e19cc7018bf2016aa771632081ee2f313 ]
Page responses should only be sent when last page in group (LPIG) or
private data is present in the page request. This patch avoids sending
invalid descriptors.
Fixes:
5d308fc1ecf53 ("iommu/vt-d: Add 256-bit invalidation descriptor support")
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jacob Pan [Thu, 2 Jan 2020 00:18:04 +0000 (08:18 +0800)]
iommu/vt-d: Match CPU and IOMMU paging mode
[ Upstream commit
79db7e1b4cf2a006f556099c13de3b12970fc6e3 ]
When setting up first level page tables for sharing with CPU, we need
to ensure IOMMU can support no less than the levels supported by the
CPU.
It is not adequate, as in the current code, to set up 5-level paging
in PASID entry First Level Paging Mode(FLPM) solely based on CPU.
Currently, intel_pasid_setup_first_level() is only used by native SVM
code which already checks paging mode matches. However, future use of
this helper function may not be limited to native SVM.
https://lkml.org/lkml/2019/11/18/1037
Fixes:
437f35e1cd4c8 ("iommu/vt-d: Add first level page table interface")
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jason Ekstrand [Thu, 2 Jan 2020 20:27:54 +0000 (14:27 -0600)]
ACPI: button: Add DMI quirk for Razer Blade Stealth 13 late 2019 lid switch
[ Upstream commit
0528904926aab19bffb2068879aa44db166c6d5f ]
Running evemu-record on the lid switch event shows that the lid reports
the first "close" but then never reports an "open". This causes systemd
to continuously re-suspend the laptop every 30s. Resetting the _LID to
"open" fixes the issue.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sam McNally [Fri, 3 Jan 2020 01:50:19 +0000 (12:50 +1100)]
ASoC: Intel: sof_rt5682: Ignore the speaker amp when there isn't one.
[ Upstream commit
d4b74e218a8d0d6cf58e546627ab9d4d4f2645ab ]
Some members of the Google_Hatch family include a rt5682 jack codec, but
no speaker amplifier. This uses the same driver (sof_rt5682) as a
combination of rt5682 jack codec and max98357a speaker amplifier. Within
the sof_rt5682 driver, these cases are not currently distinguishable,
relying on a DMI quirk to decide the configuration. This causes an
incorrect configuration when only the rt5682 is present on a
Google_Hatch device.
For CML, the jack codec is used as the primary key when matching,
with a possible speaker amplifier described in quirk_data. The two cases
of interest are the second and third
10EC5682 entries in
snd_soc_acpi_intel_cml_machines[]. The second entry matches the
combination of rt5682 and max98357a, resulting in the quirk_data field
in the snd_soc_acpi_mach being non-null, pointing at
max98357a_spk_codecs, the snd_soc_acpi_codecs for the matched speaker
amplifier. The third entry matches just the rt5682, resulting in a null
quirk_data.
The sof_rt5682 driver's DMI data matching identifies that a speaker
amplifier is present for all Google_Hatch family devices. Detect cases
where there is no speaker amplifier by checking for a null quirk_data in
the snd_soc_acpi_mach and remove the speaker amplifier bit in that case.
Signed-off-by: Sam McNally <sammc@chromium.org>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200103124921.v3.1.Ib87c4a7fbb3fc818ea12198e291b87dc2d5bc8c2@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexey Kardashevskiy [Mon, 23 Dec 2019 01:09:27 +0000 (12:09 +1100)]
vfio/spapr/nvlink2: Skip unpinning pages on error exit
[ Upstream commit
338b4e10f939a71194d8ecef7ece205a942cec05 ]
The nvlink2 subdriver for IBM Witherspoon machines preregisters
GPU memory in the IOMMI API so KVM TCE code can map this memory
for DMA as well. This is done by mm_iommu_newdev() called from
vfio_pci_nvgpu_regops::mmap.
In an unlikely event of failure the data->mem remains NULL and
since mm_iommu_put() (which unregisters the region and unpins memory
if that was regular memory) does not expect mem=NULL, it should not be
called.
This adds a check to only call mm_iommu_put() for a valid data->mem.
Fixes:
7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrey Zhizhikin [Wed, 11 Dec 2019 08:01:09 +0000 (08:01 +0000)]
tools lib api fs: Fix gcc9 stringop-truncation compilation error
[ Upstream commit
6794200fa3c9c3e6759dae099145f23e4310f4f7 ]
GCC9 introduced string hardening mechanisms, which exhibits the error
during fs api compilation:
error: '__builtin_strncpy' specified bound 4096 equals destination size
[-Werror=stringop-truncation]
This comes when the length of copy passed to strncpy is is equal to
destination size, which could potentially lead to buffer overflow.
There is a need to mitigate this potential issue by limiting the size of
destination by 1 and explicitly terminate the destination with NULL.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andriin@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Link: http://lore.kernel.org/lkml/20191211080109.18765-1-andrey.zhizhikin@leica-geosystems.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Torokhov [Fri, 3 Jan 2020 01:03:19 +0000 (17:03 -0800)]
net: phy: fixed_phy: fix use-after-free when checking link GPIO
[ Upstream commit
d266f19f3ae7fbcaf92229639b78d2110ae44f33 ]
If we fail to locate GPIO for any reason other than deferral or
not-found-GPIO, we try to print device tree node info, however if might
be freed already as we called of_node_put() on it.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Sun, 5 Jan 2020 14:48:23 +0000 (15:48 +0100)]
ALSA: sh: Fix compile warning wrt const
[ Upstream commit
f1dd4795b1523fbca7ab4344dd5a8bb439cc770d ]
A long-standing compile warning was seen during build test:
sound/sh/aica.c: In function 'load_aica_firmware':
sound/sh/aica.c:521:25: warning: passing argument 2 of 'spu_memload' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
Fixes:
198de43d758c ("[ALSA] Add ALSA support for the SEGA Dreamcast PCM device")
Link: https://lore.kernel.org/r/20200105144823.29547-69-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Sun, 5 Jan 2020 08:11:19 +0000 (09:11 +0100)]
ALSA: hda/realtek - Apply mic mute LED quirk for Dell E7xx laptops, too
[ Upstream commit
5fab5829674c279839a7408ab30c71c6dfe726b9 ]
Dell E7xx laptops have also mic mute LED that is driven by the
dell-laptop platform driver. Bind it with the capture control as
already done for other models.
A caveat is that the fixup hook for the mic mute LED has to be applied
at last, otherwise it results in the invalid override of the callback.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205529
Link: https://lore.kernel.org/r/20200105081119.21396-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kunihiko Hayashi [Fri, 27 Dec 2019 01:42:05 +0000 (10:42 +0900)]
clk: uniphier: Add SCSSI clock gate for each channel
[ Upstream commit
1ec09a2ec67a0baa46a3ccac041dbcdbc6db2cb9 ]
SCSSI has clock gates for each channel in the SoCs newer than Pro4,
so this adds missing clock gates for channel 1, 2 and 3. And more, this
moves MCSSI clock ID after SCSSI.
Fixes:
ff388ee36516 ("clk: uniphier: add clock frequency support for SPI")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lkml.kernel.org/r/1577410925-22021-1-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Boyd [Mon, 30 Dec 2019 18:29:35 +0000 (10:29 -0800)]
clk: Use parent node pointer during registration if necessary
[ Upstream commit
9011f92622e5ef2d075f45e5fa818776d4feb8c0 ]
Sometimes clk drivers are attached to devices which are children of a
parent device that is connected to a node in DT. This happens when
devices are MFD-ish and the parent device driver mostly registers child
devices to match against drivers placed in their respective subsystem
directories like drivers/clk, drivers/regulator, etc. When the clk
driver calls clk_register() with a device pointer, that struct device
pointer won't have a device_node associated with it because it was
created purely in software as a way to partition logic to a subsystem.
This causes problems for the way we find parent clks for the clks
registered by these child devices because we look at the registering
device's device_node pointer to lookup 'clocks' and 'clock-names'
properties. Let's use the parent device's device_node pointer if the
registering device doesn't have a device_node but the parent does. This
simplifies clk registration code by avoiding the need to assign some
device_node to the device registering the clk.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lkml.kernel.org/r/20191230190455.141339-1-sboyd@kernel.org
[sboyd@kernel.org: Fixup kernel-doc notation]
Reviewed-by: Niklas Cassel <nks@flawful.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Sat, 4 Jan 2020 11:00:57 +0000 (12:00 +0100)]
ALSA: sh: Fix unused variable warnings
[ Upstream commit
5da116f164ce265e397b8f59af5c39e4a61d61a5 ]
Remove unused variables that are left over after the conversion of new
PCM ops:
sound/sh/sh_dac_audio.c:166:26: warning: unused variable 'runtime'
sound/sh/sh_dac_audio.c:186:26: warning: unused variable 'runtime'
sound/sh/sh_dac_audio.c:205:26: warning: unused variable 'runtime'
Fixes:
1cc2f8ba0b3e ("ALSA: sh: Convert to the new PCM ops")
Link: https://lore.kernel.org/r/20200104110057.13875-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Icenowy Zheng [Sat, 4 Jan 2020 06:35:03 +0000 (22:35 -0800)]
clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock
[ Upstream commit
ec97faff743b398e21f74a54c81333f3390093aa ]
The A64 PLL_CPU clock has the same instability if some factor changed
without the PLL gated like other SoCs with sun6i-style CCU, e.g. A33,
H3.
Add the mux and pll notifiers for A64 CPU clock to workaround the
problem.
Fixes:
c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiewei Ke [Fri, 27 Dec 2019 11:36:13 +0000 (19:36 +0800)]
RDMA/rxe: Fix error type of mmap_offset
[ Upstream commit
6ca18d8927d468c763571f78c9a7387a69ffa020 ]
The type of mmap_offset should be u64 instead of int to match the type of
mminfo.offset. If otherwise, after we create several thousands of CQs, it
will run into overflow issues.
Link: https://lore.kernel.org/r/20191227113613.5020-1-kejiewei.cn@gmail.com
Signed-off-by: Jiewei Ke <kejiewei.cn@gmail.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Rosin [Tue, 27 Aug 2019 11:09:16 +0000 (11:09 +0000)]
fbdev: fix numbering of fbcon options
[ Upstream commit
fd933c00ebe220060e66fb136a7050a242456566 ]
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes:
efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console documentation")
Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190827110854.12574-2-peda@axentia.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Thu, 2 Jan 2020 19:59:52 +0000 (13:59 -0600)]
ASoC: soc-topology: fix endianness issues
[ Upstream commit
72bbeda0222bcd382ee33b3aff71346074410c21 ]
Sparse complains about a series of easy warnings, fix.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200102195952.9465-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kunihiko Hayashi [Fri, 29 Nov 2019 04:19:19 +0000 (13:19 +0900)]
reset: uniphier: Add SCSSI reset control for each channel
[ Upstream commit
f4aec227e985e31d2fdc5608daf48e3de19157b7 ]
SCSSI has reset controls for each channel in the SoCs newer than Pro4,
so this adds missing reset controls for channel 1, 2 and 3. And more, this
moves MCSSI reset ID after SCSSI.
Fixes:
6b39fd590aeb ("reset: uniphier: add reset control support for SPI")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Wed, 18 Dec 2019 19:48:10 +0000 (20:48 +0100)]
pinctrl: sh-pfc: sh7269: Fix CAN function GPIOs
[ Upstream commit
02aeb2f21530c98fc3ca51028eda742a3fafbd9f ]
pinmux_func_gpios[] contains a hole due to the missing function GPIO
definition for the "CTX0&CTX1" signal, which is the logical "AND" of the
first two CAN outputs.
A closer look reveals other issues:
- Some functionality is available on alternative pins, but the
PINMUX_DATA() entries is using the wrong marks,
- Several configurations are missing.
Fix this by:
- Renaming CTX0CTX1CTX2_MARK, CRX0CRX1_PJ22_MARK, and
CRX0CRX1CRX2_PJ20_MARK to CTX0_CTX1_CTX2_MARK, CRX0_CRX1_PJ22_MARK,
resp. CRX0_CRX1_CRX2_PJ20_MARK for consistency with the
corresponding enum IDs,
- Adding all missing enum IDs and marks,
- Use the right (*_PJ2x) variants for alternative pins,
- Adding all missing configurations to pinmux_data[],
- Adding all missing function GPIO definitions to pinmux_func_gpios[].
See SH7268 Group, SH7269 Group User’s Manual: Hardware, Rev. 2.00:
[1] Table 1.4 List of Pins
[2] Figure 23.29 Connection Example when Using Channels 0 and 1 as One
Channel (64 Mailboxes × 1 Channel) and Channel 2 as One Channel
(32 Mailboxes × 1 Channel),
[3] Figure 23.30 Connection Example when Using Channels 0, 1, and 2 as
One Channel (96 Mailboxes × 1 Channel),
[4] Table 48.3 Multiplexed Pins (Port B),
[5] Table 48.4 Multiplexed Pins (Port C),
[6] Table 48.10 Multiplexed Pins (Port J),
[7] Section 48.2.4 Port B Control Registers 0 to 5 (PBCR0 to PBCR5).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191218194812.12741-5-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
Manasi Navare [Wed, 11 Dec 2019 21:24:33 +0000 (13:24 -0800)]
drm/fbdev: Fallback to non tiled mode if all tiles not present
[ Upstream commit
f25c7a006cd1c07254780e3406e45cee4842b933 ]
In case of tiled displays, if we hotplug just one connector,
fbcon currently just selects the preferred mode and if it is
tiled mode then that becomes a problem if rest of the tiles are
not present.
So in the fbdev driver on hotplug when we probe the client modeset,
if we dont find all the connectors for all tiles, then on a connector
with one tile, just fallback to the first available non tiled mode
to display over a single connector.
On the hotplug of the consecutive tiled connectors, if the tiled mode
no longer exists because of fbcon size limitation, then return
no modes for consecutive tiles but retain the non tiled mode
on the 0th tile.
Use the same logic in case of connected boot case as well.
This has been tested with Dell UP328K tiled monitor.
v2:
* Set the modes on consecutive hotplugged tiles to no mode
if tiled mode is pruned (Dave)
v1:
* Just handle the 1st connector hotplug case
* v1 Reviewed-by: Dave Airlie <airlied@redhat.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Dave Airlie <airlied@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113222952.9231-1-manasi.d.navare@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chanwoo Choi [Thu, 12 Dec 2019 02:20:30 +0000 (11:20 +0900)]
PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency
[ Upstream commit
eff5d31f7407fa9d31fb840106f1593399457298 ]
To build test, add COMPILE_TEST depedency to both ARM_RK3399_DMC_DEVFREQ
and DEVFREQ_EVENT_ROCKCHIP_DFI configuration. And ARM_RK3399_DMC_DEVFREQ
used the SMCCC interface so that add HAVE_ARM_SMCCC dependency to prevent
the build break.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Tue, 22 Oct 2019 14:26:48 +0000 (16:26 +0200)]
PM / devfreq: exynos-ppmu: Fix excessive stack usage
[ Upstream commit
d4556f5e99d5f603913bac01adaff8670cb2d08b ]
Putting a 'struct devfreq_event_dev' object on the stack is generally
a bad idea and here it leads to a warnig about potential stack overflow:
drivers/devfreq/event/exynos-ppmu.c:643:12: error: stack frame size of 1040 bytes in function 'exynos_ppmu_probe' [-Werror,-Wframe-larger-than=]
There is no real need for the device structure, only the string inside
it, so add an internal helper function that simply takes the string
as its argument and remove the device structure.
Fixes:
1dd62c66d345 ("PM / devfreq: events: extend events by type of counted data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[cw00.choi: Fix the issue from 'desc->name' to 'desc[j].name']
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Valdis Klētnieks [Fri, 6 Dec 2019 02:36:07 +0000 (21:36 -0500)]
x86/vdso: Provide missing include file
[ Upstream commit
bff47c2302cc249bcd550b17067f8dddbd4b6f77 ]
When building with C=1, sparse issues a warning:
CHECK arch/x86/entry/vdso/vdso32-setup.c
arch/x86/entry/vdso/vdso32-setup.c:28:28: warning: symbol 'vdso32_enabled' was not declared. Should it be static?
Provide the missing header file.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/36224.1575599767@turing-police
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vinay Kumar Yadav [Thu, 19 Dec 2019 10:51:48 +0000 (16:21 +0530)]
crypto: chtls - Fixed memory leak
[ Upstream commit
93e23eb2ed6c11b4f483c8111ac155ec2b1f3042 ]
Freed work request skbs when connection terminates.
enqueue_wr()/ dequeue_wr() is shared between softirq
and application contexts, should be protected by socket
lock. Moved dequeue_wr() to appropriate file.
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Thu, 26 Dec 2019 18:51:47 +0000 (19:51 +0100)]
net: phy: realtek: add logging for the RGMII TX delay configuration
[ Upstream commit
3aec743d69822d22d4a5b60deb9518ed8be6fa67 ]
RGMII requires a delay of 2ns between the data and the clock signal.
There are at least three ways this can happen. One possibility is by
having the PHY generate this delay.
This is a common source for problems (for example with slow TX speeds or
packet loss when sending data). The TX delay configuration of the
RTL8211F PHY can be set either by pin-strappping the RXD1 pin (HIGH
means enabled, LOW means disabled) or through configuring a paged
register. The setting from the RXD1 pin is also reflected in the
register.
Add debug logging to the TX delay configuration on RTL8211F so it's
easier to spot these issues (for example if the TX delay is enabled for
both, the RTL8211F PHY and the MAC).
This is especially helpful because there is no public datasheet for the
RTL8211F PHY available with all the RX/TX delay specifics.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hechao Li [Tue, 24 Dec 2019 01:17:42 +0000 (17:17 -0800)]
bpf: Print error message for bpftool cgroup show
[ Upstream commit
1162f844030ac1ac7321b5e8f6c9badc7a11428f ]
Currently, when bpftool cgroup show <path> has an error, no error
message is printed. This is confusing because the user may think the
result is empty.
Before the change:
$ bpftool cgroup show /sys/fs/cgroup
ID AttachType AttachFlags Name
$ echo $?
255
After the change:
$ ./bpftool cgroup show /sys/fs/cgroup
Error: can't query bpf programs attached to /sys/fs/cgroup: Operation
not permitted
v2: Rename check_query_cgroup_progs to cgroup_has_attached_progs
Signed-off-by: Hechao Li <hechaol@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20191224011742.3714301-1-hechaol@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sascha Hauer [Mon, 16 Dec 2019 10:53:28 +0000 (11:53 +0100)]
dmaengine: imx-sdma: Fix memory leak
[ Upstream commit
02939cd167095f16328a1bd5cab5a90b550606df ]
The current descriptor is not on any list of the virtual DMA channel.
Once sdma_terminate_all() is called when a descriptor is currently
in flight then this one is forgotten to be freed. We have to call
vchan_terminate_vdesc() on this descriptor to re-add it to the lists.
Now that we also free the currently running descriptor we can (and
actually have to) remove the current descriptor from its list also
for the cyclic case.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Robin Gong <yibin.gong@nxp.com>
Tested-by: Robin Gong <yibin.gong@nxp.com>
Link: https://lore.kernel.org/r/20191216105328.15198-10-s.hauer@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Logan Gunthorpe [Mon, 16 Dec 2019 19:01:16 +0000 (12:01 -0700)]
dmaengine: Store module owner in dma_device struct
[ Upstream commit
dae7a589c18a4d979d5f14b09374e871b995ceb1 ]
dma_chan_to_owner() dereferences the driver from the struct device to
obtain the owner and call module_[get|put](). However, if the backing
device is unbound before the dma_device is unregistered, the driver
will be cleared and this will cause a NULL pointer dereference.
Instead, store a pointer to the owner module in the dma_device struct
so the module reference can be properly put when the channel is put, even
if the backing device was destroyed first.
This change helps to support a safer unbind of DMA engines.
If the dma_device is unregistered in the driver's remove function,
there's no guarantee that there are no existing clients and a users
action may trigger the WARN_ONCE in dma_async_device_unregister()
which is unlikely to leave the system in a consistent state.
Instead, a better approach is to allow the backing driver to go away
and fail any subsequent requests to it.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://lore.kernel.org/r/20191216190120.21374-2-logang@deltatee.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Tue, 24 Sep 2019 12:39:52 +0000 (14:39 +0200)]
clk: actually call the clock init before any other callback of the clock
[ Upstream commit
f6fa75ca912be6021335de63a32aa4d295f3c524 ]
__clk_init_parent() will call the .get_parent() callback of the clock
so .init() must run before.
Fixes:
541debae0adf ("clk: call the clock init() callback before any other ops callback")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lkml.kernel.org/r/20190924123954.31561-2-jbrunet@baylibre.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qian Cai [Fri, 22 Nov 2019 19:16:54 +0000 (14:16 -0500)]
iommu/iova: Silence warnings under memory pressure
[ Upstream commit
944c9175397476199d4dd1028d87ddc582c35ee8 ]
When running heavy memory pressure workloads, this 5+ old system is
throwing endless warnings below because disk IO is too slow to recover
from swapping. Since the volume from alloc_iova_fast() could be large,
once it calls printk(), it will trigger disk IO (writing to the log
files) and pending softirqs which could cause an infinite loop and make
no progress for days by the ongoimng memory reclaim. This is the counter
part for Intel where the AMD part has already been merged. See the
commit
3d708895325b ("iommu/amd: Silence warnings under memory
pressure"). Since the allocation failure will be reported in
intel_alloc_iova(), so just call dev_err_once() there because even the
"ratelimited" is too much, and silence the one in alloc_iova_mem() to
avoid the expensive warn_alloc().
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
slab_out_of_memory: 66 callbacks suppressed
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: iommu_iova, object size: 40, buffer size: 448, default order:
0, min order: 0
node 0: slabs: 1822, objs: 16398, free: 0
node 1: slabs: 2051, objs: 18459, free: 31
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: iommu_iova, object size: 40, buffer size: 448, default order:
0, min order: 0
node 0: slabs: 1822, objs: 16398, free: 0
node 1: slabs: 2051, objs: 18459, free: 31
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: iommu_iova, object size: 40, buffer size: 448, default order:
0, min order: 0
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 0: slabs: 697, objs: 4182, free: 0
node 0: slabs: 697, objs: 4182, free: 0
node 0: slabs: 697, objs: 4182, free: 0
node 0: slabs: 697, objs: 4182, free: 0
node 1: slabs: 381, objs: 2286, free: 27
node 1: slabs: 381, objs: 2286, free: 27
node 1: slabs: 381, objs: 2286, free: 27
node 1: slabs: 381, objs: 2286, free: 27
node 0: slabs: 1822, objs: 16398, free: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 1: slabs: 2051, objs: 18459, free: 31
node 0: slabs: 697, objs: 4182, free: 0
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
node 1: slabs: 381, objs: 2286, free: 27
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 0: slabs: 697, objs: 4182, free: 0
node 1: slabs: 381, objs: 2286, free: 27
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
warn_alloc: 96 callbacks suppressed
kworker/11:1H: page allocation failure: order:0,
mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0-1
CPU: 11 PID: 1642 Comm: kworker/11:1H Tainted: G B
Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS U19
12/27/2015
Workqueue: kblockd blk_mq_run_work_fn
Call Trace:
dump_stack+0xa0/0xea
warn_alloc.cold.94+0x8a/0x12d
__alloc_pages_slowpath+0x1750/0x1870
__alloc_pages_nodemask+0x58a/0x710
alloc_pages_current+0x9c/0x110
alloc_slab_page+0xc9/0x760
allocate_slab+0x48f/0x5d0
new_slab+0x46/0x70
___slab_alloc+0x4ab/0x7b0
__slab_alloc+0x43/0x70
kmem_cache_alloc+0x2dd/0x450
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
alloc_iova+0x33/0x210
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 0: slabs: 697, objs: 4182, free: 0
alloc_iova_fast+0x62/0x3d1
node 1: slabs: 381, objs: 2286, free: 27
intel_alloc_iova+0xce/0xe0
intel_map_sg+0xed/0x410
scsi_dma_map+0xd7/0x160
scsi_queue_rq+0xbf7/0x1310
blk_mq_dispatch_rq_list+0x4d9/0xbc0
blk_mq_sched_dispatch_requests+0x24a/0x300
__blk_mq_run_hw_queue+0x156/0x230
blk_mq_run_work_fn+0x3b/0x40
process_one_work+0x579/0xb90
worker_thread+0x63/0x5b0
kthread+0x1e6/0x210
ret_from_fork+0x3a/0x50
Mem-Info:
active_anon:2422723 inactive_anon:361971 isolated_anon:34403
active_file:2285 inactive_file:1838 isolated_file:0
unevictable:0 dirty:1 writeback:5 unstable:0
slab_reclaimable:13972 slab_unreclaimable:453879
mapped:2380 shmem:154 pagetables:6948 bounce:0
free:19133 free_pcp:7363 free_cma:0
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Suravee Suthikulpanit [Wed, 20 Nov 2019 13:55:49 +0000 (07:55 -0600)]
iommu/amd: Only support x2APIC with IVHD type 11h/40h
[ Upstream commit
966b753cf3969553ca50bacd2b8c4ddade5ecc9e ]
Current implementation for IOMMU x2APIC support makes use of
the MMIO access to MSI capability block registers, which requires
checking EFR[MsiCapMmioSup]. However, only IVHD type 11h/40h contain
the information, and not in the IVHD type 10h IOMMU feature reporting
field. Since the BIOS in newer systems, which supports x2APIC, would
normally contain IVHD type 11h/40h, remove the IOMMU_FEAT_XTSUP_SHIFT
check for IVHD type 10h, and only support x2APIC with IVHD type 11h/40h.
Fixes:
66929812955b ('iommu/amd: Add support for X2APIC IOMMU interrupts')
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Suravee Suthikulpanit [Wed, 20 Nov 2019 13:55:48 +0000 (07:55 -0600)]
iommu/amd: Check feature support bit before accessing MSI capability registers
[ Upstream commit
813071438e83d338ba5cfe98b3b26c890dc0a6c0 ]
The IOMMU MMIO access to MSI capability registers is available only if
the EFR[MsiCapMmioSup] is set. Current implementation assumes this bit
is set if the EFR[XtSup] is set, which might not be the case.
Fix by checking the EFR[MsiCapMmioSup] before accessing the MSI address
low/high and MSI data registers via the MMIO.
Fixes:
66929812955b ('iommu/amd: Add support for X2APIC IOMMU interrupts')
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bjorn Andersson [Wed, 13 Nov 2019 23:22:45 +0000 (15:22 -0800)]
arm64: dts: qcom: db845c: Enable ath10k 8bit host-cap quirk
[ Upstream commit
2e198c395a084ff3015d71896e35de049c40e3a4 ]
The WiFi firmware used on db845c implements the 8bit host-capability
message, so enable the quirk for this.
Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20191113232245.4039932-1-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Wed, 18 Dec 2019 23:58:00 +0000 (15:58 -0800)]
scsi: lpfc: Fix: Rework setting of fdmi symbolic node name registration
[ Upstream commit
df9166bfa7750bade5737ffc91fbd432e0354442 ]
This patch reworks the fdmi symbolic node name data for the following two
issues:
- Correcting extraneous periods following the DV and HN fdmi data fields.
- Avoiding buffer overflow issues when formatting the data.
The fix to the fist issue is to just remove the characters.
The fix to the second issue has all data being staged in temporary storage
before being moved to the real buffer.
Link: https://lore.kernel.org/r/20191218235808.31922-3-jsmart2021@gmail.com
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jaihind Yadav [Tue, 17 Dec 2019 11:55:47 +0000 (17:25 +0530)]
selinux: ensure we cleanup the internal AVC counters on error in avc_update()
[ Upstream commit
030b995ad9ece9fa2d218af4429c1c78c2342096 ]
In AVC update we don't call avc_node_kill() when avc_xperms_populate()
fails, resulting in the avc->avc_cache.active_nodes counter having a
false value. In last patch this changes was missed , so correcting it.
Fixes:
fa1aa143ac4a ("selinux: extended permissions for ioctls")
Signed-off-by: Jaihind Yadav <jaihindyadav@codeaurora.org>
Signed-off-by: Ravi Kumar Siddojigari <rsiddoji@codeaurora.org>
[PM: merge fuzz, minor description cleanup]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Wed, 11 Dec 2019 13:52:21 +0000 (14:52 +0100)]
ARM: dts: r8a7779: Add device node for ARM global timer
[ Upstream commit
8443ffd1bbd5be74e9b12db234746d12e8ea93e2 ]
Add a device node for the global timer, which is part of the Cortex-A9
MPCore.
The global timer can serve as an accurate (4 ns) clock source for
scheduling and delay loops.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergei Shtylyov [Fri, 27 Sep 2019 18:09:21 +0000 (21:09 +0300)]
clk: renesas: rcar-gen3: Allow changing the RPC[D2] clocks
[ Upstream commit
0d67c0340a60829c5c1b7d09629d23bbd67696f3 ]
I was unable to get clk_set_rate() setting a lower RPC-IF clock frequency
and that issue boiled down to me not passing CLK_SET_RATE_PARENT flag to
clk_register_composite() when registering the RPC[D2] clocks...
Fixes:
db4a0073cc82 ("clk: renesas: rcar-gen3: Add RPC clocks")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Link: https://lore.kernel.org/r/be27a344-d8bf-9e0c-8950-2d1b48498496@cogentembedded.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bibby Hsieh [Tue, 10 Dec 2019 05:05:21 +0000 (13:05 +0800)]
drm/mediatek: handle events when enabling/disabling crtc
[ Upstream commit
411f5c1eacfebb1f6e40b653d29447cdfe7282aa ]
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brendan Higgins [Wed, 11 Dec 2019 19:27:39 +0000 (11:27 -0800)]
crypto: inside-secure - add unspecified HAS_IOMEM dependency
[ Upstream commit
6dc0e310623fdcb27a1486eb436f0118c45e95a5 ]
Currently CONFIG_CRYPTO_DEV_SAFEXCEL=y implicitly depends on
CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get
the following build error:
ld: drivers/crypto/inside-secure/safexcel.o: in function `safexcel_probe':
drivers/crypto/inside-secure/safexcel.c:1692: undefined reference to `devm_platform_ioremap_resource'
Fix the build error by adding the unspecified dependency.
Reported-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 18 Dec 2019 01:42:20 +0000 (18:42 -0700)]
scsi: aic7xxx: Adjust indentation in ahc_find_syncrate
[ Upstream commit
4dbc96ad65c45cdd4e895ed7ae4c151b780790c5 ]
Clang warns:
../drivers/scsi/aic7xxx/aic7xxx_core.c:2317:5: warning: misleading
indentation; statement is not part of the previous 'if'
[-Wmisleading-indentation]
if ((syncrate->sxfr_u2 & ST_SXFR) != 0)
^
../drivers/scsi/aic7xxx/aic7xxx_core.c:2310:4: note: previous statement
is here
if (syncrate == &ahc_syncrates[maxsync])
^
1 warning generated.
This warning occurs because there is a space amongst the tabs on this
line. Remove it so that the indentation is consistent with the Linux kernel
coding style and clang no longer warns.
This has been a problem since the beginning of git history hence no fixes
tag.
Link: https://github.com/ClangBuiltLinux/linux/issues/817
Link: https://lore.kernel.org/r/20191218014220.52746-1-natechancellor@gmail.com
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Can Guo [Tue, 26 Nov 2019 06:53:33 +0000 (22:53 -0800)]
scsi: ufs: Complete pending requests in host reset and restore path
[ Upstream commit
2df74b6985b51e77756e2e8faa16c45ca3ba53c5 ]
In UFS host reset and restore path, before probe, we stop and start the
host controller once. After host controller is stopped, the pending
requests, if any, are cleared from the doorbell, but no completion IRQ
would be raised due to the hba is stopped. These pending requests shall be
completed along with the first NOP_OUT command (as it is the first command
which can raise a transfer completion IRQ) sent during probe. Since the
OCSs of these pending requests are not SUCCESS (because they are not yet
literally finished), their UPIUs shall be dumped. When there are multiple
pending requests, the UPIU dump can be overwhelming and may lead to
stability issues because it is in atomic context. Therefore, before probe,
complete these pending requests right after host controller is stopped and
silence the UPIU dump from them.
Link: https://lore.kernel.org/r/1574751214-8321-5-git-send-email-cang@qti.qualcomm.com
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Tested-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Wed, 18 Dec 2019 19:57:23 +0000 (14:57 -0500)]
nfsd: Clone should commit src file metadata too
[ Upstream commit
57f64034966fb945fc958f95f0c51e47af590344 ]
vfs_clone_file_range() can modify the metadata on the source file too,
so we need to commit that to stable storage as well.
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Acked-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erik Kaneda [Tue, 17 Dec 2019 19:35:20 +0000 (11:35 -0800)]
ACPICA: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1
[ Upstream commit
5ddbd77181dfca61b16d2e2222382ea65637f1b9 ]
ACPICA commit
29cc8dbc5463a93625bed87d7550a8bed8913bf4
create_buffer_field is a deferred op that is typically processed in
load pass 2. However, disassembly of control method contents walk the
parse tree with ACPI_PARSE_LOAD_PASS1 and AML_CREATE operators are
processed in a later walk. This is a problem when there is a control
method that has the same name as the AML_CREATE object. In this case,
any use of the name segment will be detected as a method call rather
than a reference to a buffer field. If this is detected as a method
call, it can result in a mal-formed parse tree if the control methods
have parameters.
This change in processing AML_CREATE ops earlier solves this issue by
inserting the named object in the ACPI namespace so that references
to this name would be detected as a name string rather than a method
call.
Link: https://github.com/acpica/acpica/commit/29cc8dbc
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
Tested-by: Elia Geretto <elia.f.geretto@gmail.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jeffrey Hugo [Tue, 17 Dec 2019 16:54:09 +0000 (08:54 -0800)]
clk: qcom: smd: Add missing bimc clock
[ Upstream commit
87ec9adcca71801a44ddb311185b17df09839ab5 ]
It turns out booting the modem is dependent on a bimc vote from Linux on
msm8998. To make the modem happy, add the bimc clock to rely on the
default vote from rpmcc. Once we have interconnect support, bimc should
be controlled properly.
Fixes:
6131dc81211c ("clk: qcom: smd: Add support for MSM8998 rpm clocks")
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Link: https://lkml.kernel.org/r/20191217165409.4919-1-jeffrey.l.hugo@gmail.com
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Monk Liu [Tue, 17 Dec 2019 10:16:44 +0000 (18:16 +0800)]
drm/amdgpu: fix KIQ ring test fail in TDR of SRIOV
[ Upstream commit
5a7489a7e189ee2be889485f90c8cf24ea4b9a40 ]
issues:
MEC is ruined by the amdkfd_pre_reset after VF FLR done
fix:
amdkfd_pre_reset() would ruin MEC after hypervisor finished the VF FLR,
the correct sequence is do amdkfd_pre_reset before VF FLR but there is
a limitation to block this sequence:
if we do pre_reset() before VF FLR, it would go KIQ way to do register
access and stuck there, because KIQ probably won't work by that time
(e.g. you already made GFX hang)
so the best way right now is to simply remove it.
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aditya Pakki [Sun, 15 Dec 2019 19:58:58 +0000 (13:58 -0600)]
orinoco: avoid assertion in case of NULL pointer
[ Upstream commit
c705f9fc6a1736dcf6ec01f8206707c108dca824 ]
In ezusb_init, if upriv is NULL, the code crashes. However, the caller
in ezusb_probe can handle the error and print the failure message.
The patch replaces the BUG_ON call to error return.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Phong Tran [Tue, 26 Nov 2019 17:55:29 +0000 (00:55 +0700)]
rtlwifi: rtl_pci: Fix -Wcast-function-type
[ Upstream commit
cb775c88da5d48a85d99d95219f637b6fad2e0e9 ]
correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Phong Tran [Tue, 26 Nov 2019 17:55:28 +0000 (00:55 +0700)]
iwlegacy: Fix -Wcast-function-type
[ Upstream commit
da5e57e8a6a3e69dac2937ba63fa86355628fbb2 ]
correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Phong Tran [Tue, 26 Nov 2019 17:55:27 +0000 (00:55 +0700)]
ipw2x00: Fix -Wcast-function-type
[ Upstream commit
ebd77feb27e91bb5fe35a7818b7c13ea7435fb98 ]
correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Phong Tran [Tue, 26 Nov 2019 17:55:26 +0000 (00:55 +0700)]
b43legacy: Fix -Wcast-function-type
[ Upstream commit
475eec112e4267232d10f4afe2f939a241692b6c ]
correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Sewart [Tue, 10 Dec 2019 22:25:40 +0000 (16:25 -0600)]
PCI: Add DMA alias quirk for PLX PEX NTB
[ Upstream commit
7b90dfc4873b87c468cc6046538f46a531c1d785 ]
The PLX PEX NTB forwards DMA transactions using Requester IDs that don't
exist as PCI devices. The devfn for a transaction is used as an index into
a lookup table storing the origin of a transaction on the other side of the
bridge.
Alias all possible devfns to the NTB device so that any transaction coming
in is governed by the mappings for the NTB.
Signed-off-by: James Sewart <jamessewart@arista.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>