2020-01-24 10:55:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 000/102] 5.4.15-stable review

This is the start of the stable review cycle for the 5.4.15 release.
There are 102 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.4.15-rc1

Sumit Garg <[email protected]>
optee: Fix multi page dynamic shm pool alloc

Jonas Karlman <[email protected]>
phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz

Arnd Bergmann <[email protected]>
gpio: aspeed: avoid return type warning

Jouni Hogander <[email protected]>
net-sysfs: Call dev_hold always in netdev_queue_add_kobject

Julian Wiedmann <[email protected]>
s390/qeth: fix dangling IO buffers after halt/clear

Justin Tee <[email protected]>
block: fix memleak of bio integrity data

Wen Yang <[email protected]>
platform/chrome: wilco_ec: fix use after free issue

Toke Høiland-Jørgensen <[email protected]>
xdp: Fix cleanup on map free for devmap_hash map type

Sam Bobroff <[email protected]>
drm/radeon: fix bad DMA from INTERRUPT_CNTL2

Chuhong Yuan <[email protected]>
dmaengine: ti: edma: fix missed failure handling

zhengbin <[email protected]>
afs: Remove set but not used variables 'before', 'after'

Christoph Hellwig <[email protected]>
dma-direct: don't check swiotlb=force in dma_direct_map_resource

Lorenzo Bianconi <[email protected]>
mt76: mt76u: rely on usb_interface instead of usb_dev

Vincent Guittot <[email protected]>
sched/cpufreq: Move the cfs_rq_util_change() call to cpufreq_update_util()

Chuck Lever <[email protected]>
SUNRPC: Fix another issue with MIC buffer space

Sebastian Andrzej Siewior <[email protected]>
workqueue: Add RCU annotation for pwq list walk

Jens Wiklander <[email protected]>
tee: optee: fix device enumeration error handling

Sumit Garg <[email protected]>
tee: optee: Fix dynamic shm pool allocations

H. Nikolaus Schaller <[email protected]>
mmc: core: fix wl1251 sdio quirks

H. Nikolaus Schaller <[email protected]>
mmc: sdio: fix wl1251 vendor id

Sudeep Holla <[email protected]>
firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BIT

Hewenliang <[email protected]>
kselftests: cgroup: Avoid the reuse of fd after it is deallocated

Alain Volmat <[email protected]>
i2c: stm32f7: report dma error during probe

Eric Dumazet <[email protected]>
packet: fix data-race in fanout_flow_is_huge()

Colin Ian King <[email protected]>
rtc: bd70528: fix module alias to autoload module

Kees Cook <[email protected]>
selftests: gen_kselftest_tar.sh: Do not clobber kselftest/

Wei Yongjun <[email protected]>
net: axienet: Fix error return code in axienet_probe()

Eric Dumazet <[email protected]>
net: neigh: use long type to store jiffies delta

Daniel Golle <[email protected]>
rt2800: remove errornous duplicate condition

Stephen Hemminger <[email protected]>
hv_netvsc: flag software created hash value

Tonghao Zhang <[email protected]>
net: openvswitch: don't unlock mutex when changing the user_features fails

Bean Huo <[email protected]>
scsi: ufs: delete redundant function ufshcd_def_desc_sizes()

Madalin Bucur <[email protected]>
dpaa_eth: avoid timestamp read on error paths

Madalin Bucur <[email protected]>
dpaa_eth: perform DMA unmapping before read

Dan Carpenter <[email protected]>
rcu: Fix uninitialized variable in nocb_gp_wait()

Andrii Nakryiko <[email protected]>
libbpf: Don't use kernel-side u32 type in xsk.c

Daniel Baluta <[email protected]>
firmware: imx: Remove call to devm_of_platform_populate

Matti Vaittinen <[email protected]>
power: supply: bd70528: Add MODULE_ALIAS to allow module auto loading

Dan Carpenter <[email protected]>
drm/amdgpu/vi: silence an uninitialized variable warning

Matti Vaittinen <[email protected]>
regulator: bd70528: Add MODULE_ALIAS to allow module auto loading

Ondrej Jirman <[email protected]>
pwm: sun4i: Fix incorrect calculation of duty_cycle/period

Andy Shevchenko <[email protected]>
ACPI: platform: Unregister stale platform devices

Ilias Apalodimas <[email protected]>
net: netsec: Correct dma sync for XDP_TX frames

Geert Uytterhoeven <[email protected]>
drm: rcar_lvds: Fix color mismatches on R-Car H2 ES2.0 and later

Kefeng Wang <[email protected]>
PCI: mobiveil: Fix csr_read()/write() build issue

Sakari Ailus <[email protected]>
software node: Get reference to parent swnode in get_parent op

Douglas Anderson <[email protected]>
drm/rockchip: Round up _before_ giving to the clock framework

Ioana Radulescu <[email protected]>
dpaa2-eth: Fix minor bug in ethtool stats reporting

Tony Lindgren <[email protected]>
hwrng: omap3-rom - Fix missing clock by probing with device tree

yu kuai <[email protected]>
drm/amdgpu: remove excess function parameter description

Dan Carpenter <[email protected]>
drm: panel-lvds: Potential Oops in probe error handling

Steven Price <[email protected]>
drm/panfrost: Add missing check for pfdev->regulator

Ping-Ke Shih <[email protected]>
rtw88: fix error handling when setup efuse info

Yan-Hsuan Chuang <[email protected]>
rtw88: fix beaconing mode rsvd_page memory violation issue

Andy Shevchenko <[email protected]>
gpiolib: No need to call gpiochip_remove_pin_ranges() twice

Peter Zijlstra <[email protected]>
sched/core: Further clarify sched_class::set_next_task()

Navid Emamdoost <[email protected]>
ipmi: Fix memory leak in __ipmi_bmc_register

Shuiqing Li <[email protected]>
watchdog: sprd: Fix the incorrect pointer getting from driver data

Luc Van Oostenryck <[email protected]>
soc: aspeed: Fix snoop_file_poll()'s return type

Geert Uytterhoeven <[email protected]>
soc: renesas: Add missing check for non-zero product register address

Stephen Boyd <[email protected]>
soc: qcom: llcc: Name regmaps to avoid collisions

Thierry Reding <[email protected]>
soc/tegra: pmc: Fix crashes for hierarchical interrupts

Jean-Jacques Hiblot <[email protected]>
leds: tlc591xx: update the maximum brightness

Arnaldo Carvalho de Melo <[email protected]>
perf map: No need to adjust the long name of modules

Corentin Labbe <[email protected]>
crypto: sun4i-ss - fix big endian issues

Christian Lamparter <[email protected]>
crypto: amcc - restore CRYPTO_AES dependency

Patrick Steinhardt <[email protected]>
nfsd: depend on CRYPTO_MD5 for legacy client tracking

Heiko Carstens <[email protected]>
s390/pkey: fix memory leak within _copy_apqns_from_user()

Jesse Brandeburg <[email protected]>
ice: fix stack leakage

Lorenzo Bianconi <[email protected]>
mt7601u: fix bbp version check in mt7601u_wait_bbp_ready

Lorenzo Bianconi <[email protected]>
mt76: mt76u: fix endpoint definition order

Grygorii Strashko <[email protected]>
phy: ti: gmii-sel: fix mac tx internal delay for rgmii-rxid

Florian Fainelli <[email protected]>
net: phy: broadcom: Fix RGMII delays configuration for BCM54210E

Wei Yongjun <[email protected]>
phy: lantiq: vrx200-pcie: fix error return code in ltq_vrx200_pcie_phy_power_on()

Roi Dayan <[email protected]>
net/mlx5e: Fix free peer_flow when refcount is 0

Tung Nguyen <[email protected]>
tipc: fix wrong timeout input for tipc_wait_for_cond()

Tung Nguyen <[email protected]>
tipc: fix wrong socket reference counter after tipc_sk_timeout() returns

Tung Nguyen <[email protected]>
tipc: fix potential memory leak in __tipc_sendmsg()

Hoang Le <[email protected]>
tipc: update mon's self addr when node addr generated

Hoang Le <[email protected]>
tipc: reduce sensitive to retransmit failures

Ard Biesheuvel <[email protected]>
powerpc/archrandom: fix arch_get_random_seed_int()

Christophe Leroy <[email protected]>
powerpc/kasan: Fix boot failure with RELOCATABLE && FSL_BOOKE

Tyrel Datwyler <[email protected]>
powerpc/pseries: Enable support for ibm,drc-info property

Geert Uytterhoeven <[email protected]>
powerpc/security: Fix debugfs data leak on 32-bit

Chuck Lever <[email protected]>
SUNRPC: Fix backchannel latency metrics

Chuck Lever <[email protected]>
SUNRPC: Fix svcauth_gss_proxy_init()

Jarkko Nikula <[email protected]>
mfd: intel-lpss: Add default I2C device properties for Gemini Lake

Alain Volmat <[email protected]>
i2c: i2c-stm32f7: fix 10-bits check in slave free id search loop

Alain Volmat <[email protected]>
i2c: stm32f7: rework slave_id allocation

Jan Kara <[email protected]>
xfs: Sanity check flags of Q_XQUOTARM call

Markus Elfring <[email protected]>
ARM: OMAP2+: Add missing put_device() call in omapdss_init_of()

Adam Ford <[email protected]>
ARM: dts: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel

Jesper Dangaard Brouer <[email protected]>
samples/bpf: Fix broken xdp_rxq_info due to map order assumptions

Daniel T. Lee <[email protected]>
samples: bpf: update map definition to new syntax BTF-defined map

Stanislav Fomichev <[email protected]>
bpf: Force .BTF section start to zero when dumping from vmlinux

Andrii Nakryiko <[email protected]>
libbpf: Fix call relocation offset calculation bug

Andrii Nakryiko <[email protected]>
libbpf: Make btf__resolve_size logic always check size error condition

Andrii Nakryiko <[email protected]>
libbpf: Fix another potential overflow issue in bpf_prog_linfo

Andrii Nakryiko <[email protected]>
libbpf: Fix potential overflow issue

Andrii Nakryiko <[email protected]>
libbpf: Fix memory leak/double free issue

Magnus Karlsson <[email protected]>
libbpf: Fix compatibility for kernels without need_wakeup

Tvrtko Ursulin <[email protected]>
drm/i915: Fix pid leak with banned clients


-------------

Diffstat:

.../devicetree/bindings/rng/omap3_rom_rng.txt | 27 +++++
Makefile | 4 +-
.../boot/dts/logicpd-torpedo-37xx-devkit-28.dts | 20 +---
arch/arm/boot/dts/omap3-n900.dts | 6 ++
arch/arm/mach-omap2/display.c | 1 +
arch/arm/mach-omap2/pdata-quirks.c | 12 +--
arch/powerpc/include/asm/archrandom.h | 2 +-
arch/powerpc/include/asm/security_features.h | 8 +-
arch/powerpc/kernel/head_fsl_booke.S | 6 +-
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/kernel/security.c | 4 +-
block/bio-integrity.c | 2 +-
block/bio.c | 3 +
block/blk.h | 4 +
drivers/acpi/acpi_platform.c | 43 ++++++++
drivers/acpi/scan.c | 1 +
drivers/base/swnode.c | 5 +-
drivers/char/hw_random/omap3-rom-rng.c | 17 ++-
drivers/char/ipmi/ipmi_msghandler.c | 5 +-
drivers/crypto/Kconfig | 1 +
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 21 ++--
drivers/dma/ti/edma.c | 6 +-
drivers/firmware/arm_scmi/perf.c | 2 +-
drivers/firmware/imx/imx-dsp.c | 2 +-
drivers/gpio/gpiolib-of.c | 5 +-
drivers/gpio/gpiolib.c | 3 +-
drivers/gpio/sgpio-aspeed.c | 2 +-
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 -
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +-
drivers/gpu/drm/panel/panel-lvds.c | 21 +---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 +-
drivers/gpu/drm/radeon/cik.c | 4 +-
drivers/gpu/drm/radeon/r600.c | 4 +-
drivers/gpu/drm/radeon/si.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_lvds.c | 28 +++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 37 ++++++-
drivers/i2c/busses/i2c-stm32.c | 16 +--
drivers/i2c/busses/i2c-stm32f7.c | 13 ++-
drivers/leds/leds-tlc591xx.c | 7 +-
drivers/mfd/intel-lpss-pci.c | 28 +++--
drivers/mmc/core/quirks.h | 7 ++
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 47 ++++----
.../net/ethernet/freescale/dpaa2/dpaa2-ethtool.c | 2 +-
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 3 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 7 +-
drivers/net/ethernet/socionext/netsec.c | 4 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 -
drivers/net/hyperv/netvsc_drv.c | 7 +-
drivers/net/phy/broadcom.c | 11 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 5 +-
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 2 +-
drivers/net/wireless/mediatek/mt76/usb.c | 12 ++-
drivers/net/wireless/mediatek/mt7601u/phy.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 +-
drivers/net/wireless/realtek/rtw88/fw.c | 52 +++++++--
drivers/net/wireless/realtek/rtw88/main.c | 11 +-
drivers/pci/controller/pcie-mobiveil.c | 119 +++++++++++----------
drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c | 3 +-
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 4 +
drivers/phy/ti/phy-gmii-sel.c | 2 +-
drivers/platform/chrome/wilco_ec/telemetry.c | 2 +-
drivers/power/supply/bd70528-charger.c | 1 +
drivers/pwm/pwm-sun4i.c | 4 +-
drivers/regulator/bd70528-regulator.c | 1 +
drivers/rtc/rtc-bd70528.c | 2 +-
drivers/s390/crypto/pkey_api.c | 4 +-
drivers/s390/net/qeth_core.h | 3 +
drivers/s390/net/qeth_core_main.c | 71 ++++++++----
drivers/s390/net/qeth_core_mpc.h | 14 ---
drivers/s390/net/qeth_l2_main.c | 12 +--
drivers/s390/net/qeth_l3_main.c | 13 +--
drivers/scsi/ufs/ufshcd.c | 15 +--
drivers/soc/aspeed/aspeed-lpc-snoop.c | 4 +-
drivers/soc/qcom/llcc-slice.c | 3 +-
drivers/soc/renesas/renesas-soc.c | 2 +-
drivers/soc/tegra/pmc.c | 28 ++++-
drivers/tee/optee/call.c | 7 ++
drivers/tee/optee/core.c | 20 ++--
drivers/tee/optee/shm_pool.c | 25 ++++-
drivers/watchdog/sprd_wdt.c | 6 +-
fs/afs/dir_edit.c | 12 +--
fs/nfsd/Kconfig | 1 +
fs/xfs/xfs_quotaops.c | 3 +
include/linux/mmc/sdio_ids.h | 2 +
kernel/bpf/devmap.c | 74 ++++++++-----
kernel/dma/direct.c | 2 +-
kernel/rcu/tree_plugin.h | 2 +-
kernel/sched/deadline.c | 7 +-
kernel/sched/fair.c | 113 ++++++++++---------
kernel/sched/idle.c | 4 +-
kernel/sched/rt.c | 7 +-
kernel/sched/sched.h | 4 +-
kernel/sched/stop_task.c | 4 +-
kernel/workqueue.c | 3 +-
net/core/neighbour.c | 4 +-
net/core/net-sysfs.c | 7 +-
net/openvswitch/datapath.c | 2 +-
net/packet/af_packet.c | 12 ++-
net/sunrpc/auth_gss/svcauth_gss.c | 84 +++++++++++----
net/sunrpc/xdr.c | 11 +-
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
net/sunrpc/xprtsock.c | 3 +-
net/tipc/link.c | 2 +-
net/tipc/monitor.c | 15 +++
net/tipc/monitor.h | 1 +
net/tipc/net.c | 2 +
net/tipc/socket.c | 7 +-
samples/bpf/sockex1_kern.c | 12 +--
samples/bpf/sockex2_kern.c | 12 +--
samples/bpf/xdp1_kern.c | 12 +--
samples/bpf/xdp2_kern.c | 12 +--
samples/bpf/xdp_adjust_tail_kern.c | 12 +--
samples/bpf/xdp_fwd_kern.c | 13 ++-
samples/bpf/xdp_redirect_cpu_kern.c | 108 +++++++++----------
samples/bpf/xdp_redirect_kern.c | 24 ++---
samples/bpf/xdp_redirect_map_kern.c | 24 ++---
samples/bpf/xdp_router_ipv4_kern.c | 64 +++++------
samples/bpf/xdp_rxq_info_kern.c | 37 +++----
samples/bpf/xdp_rxq_info_user.c | 6 +-
samples/bpf/xdp_tx_iptunnel_kern.c | 26 ++---
scripts/link-vmlinux.sh | 5 +-
tools/lib/bpf/bpf.c | 2 +-
tools/lib/bpf/bpf_prog_linfo.c | 14 +--
tools/lib/bpf/btf.c | 3 +-
tools/lib/bpf/libbpf.c | 10 +-
tools/lib/bpf/xsk.c | 83 +++++++++++---
tools/perf/util/machine.c | 27 +----
tools/testing/selftests/bpf/progs/test_btf_haskv.c | 4 +-
tools/testing/selftests/bpf/progs/test_btf_newkv.c | 4 +-
tools/testing/selftests/bpf/progs/test_btf_nokv.c | 4 +-
tools/testing/selftests/cgroup/test_freezer.c | 1 +
tools/testing/selftests/gen_kselftest_tar.sh | 21 ++--
tools/testing/selftests/kselftest_install.sh | 24 ++---
135 files changed, 1150 insertions(+), 739 deletions(-)



2020-01-24 10:56:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 025/102] tipc: fix potential memory leak in __tipc_sendmsg()

From: Tung Nguyen <[email protected]>

commit 2fe97a578d7bad3116a89dc8a6692a51e6fc1d9c upstream.

When initiating a connection message to a server side, the connection
message is cloned and added to the socket write queue. However, if the
cloning is failed, only the socket write queue is purged. It causes
memory leak because the original connection message is not freed.

This commit fixes it by purging the list of connection message when
it cannot be cloned.

Fixes: 6787927475e5 ("tipc: buffer overflow handling in listener socket")
Reported-by: Hoang Le <[email protected]>
Signed-off-by: Tung Nguyen <[email protected]>
Acked-by: Ying Xue <[email protected]>
Acked-by: Jon Maloy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/tipc/socket.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1396,8 +1396,10 @@ static int __tipc_sendmsg(struct socket
rc = tipc_msg_build(hdr, m, 0, dlen, mtu, &pkts);
if (unlikely(rc != dlen))
return rc;
- if (unlikely(syn && !tipc_msg_skb_clone(&pkts, &sk->sk_write_queue)))
+ if (unlikely(syn && !tipc_msg_skb_clone(&pkts, &sk->sk_write_queue))) {
+ __skb_queue_purge(&pkts);
return -ENOMEM;
+ }

trace_tipc_sk_sendmsg(sk, skb_peek(&pkts), TIPC_DUMP_SK_SNDQ, " ");
rc = tipc_node_xmit(net, &pkts, dnode, tsk->portid);


2020-01-24 11:01:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 034/102] ice: fix stack leakage

From: Jesse Brandeburg <[email protected]>

commit 949375de945f7042df2b6488228a1a2b36e69f35 upstream.

In the case of an invalid virtchannel request the driver
would return uninitialized data to the VF from the PF stack
which is a bug. Fix by initializing the stack variable
earlier in the function before any return paths can be taken.

Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support")
Signed-off-by: Jesse Brandeburg <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -1873,8 +1873,8 @@ static int ice_vc_get_stats_msg(struct i
enum virtchnl_status_code v_ret = VIRTCHNL_STATUS_SUCCESS;
struct virtchnl_queue_select *vqs =
(struct virtchnl_queue_select *)msg;
+ struct ice_eth_stats stats = { 0 };
struct ice_pf *pf = vf->pf;
- struct ice_eth_stats stats;
struct ice_vsi *vsi;

if (!test_bit(ICE_VF_STATE_ACTIVE, vf->vf_states)) {
@@ -1893,7 +1893,6 @@ static int ice_vc_get_stats_msg(struct i
goto error_param;
}

- memset(&stats, 0, sizeof(struct ice_eth_stats));
ice_update_eth_stats(vsi);

stats = vsi->eth_stats;


2020-01-24 11:02:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 089/102] sched/cpufreq: Move the cfs_rq_util_change() call to cpufreq_update_util()

From: Vincent Guittot <[email protected]>

[ Upstream commit bef69dd87828ef5d8ecdab8d857cd3a33cf98675 ]

update_cfs_rq_load_avg() calls cfs_rq_util_change() every time PELT decays,
which might be inefficient when the cpufreq driver has rate limitation.

When a task is attached on a CPU, we have this call path:

update_load_avg()
update_cfs_rq_load_avg()
cfs_rq_util_change -- > trig frequency update
attach_entity_load_avg()
cfs_rq_util_change -- > trig frequency update

The 1st frequency update will not take into account the utilization of the
newly attached task and the 2nd one might be discarded because of rate
limitation of the cpufreq driver.

update_cfs_rq_load_avg() is only called by update_blocked_averages()
and update_load_avg() so we can move the call to
cfs_rq_util_change/cpufreq_update_util() into these two functions.

It's also interesting to note that update_load_avg() already calls
cfs_rq_util_change() directly for the !SMP case.

This change will also ensure that cpufreq_update_util() is called even
when there is no more CFS rq in the leaf_cfs_rq_list to update, but only
IRQ, RT or DL PELT signals.

[ mingo: Minor updates. ]

Reported-by: Doug Smythies <[email protected]>
Tested-by: Doug Smythies <[email protected]>
Signed-off-by: Vincent Guittot <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Dietmar Eggemann <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path")
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/sched/fair.c | 111 +++++++++++++++++++++++++-------------------
1 file changed, 62 insertions(+), 49 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2b7034e6fa241..c87a798d14562 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3504,9 +3504,6 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
cfs_rq->load_last_update_time_copy = sa->last_update_time;
#endif

- if (decayed)
- cfs_rq_util_change(cfs_rq, 0);
-
return decayed;
}

@@ -3616,8 +3613,12 @@ static inline void update_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *s
attach_entity_load_avg(cfs_rq, se, SCHED_CPUFREQ_MIGRATION);
update_tg_load_avg(cfs_rq, 0);

- } else if (decayed && (flags & UPDATE_TG))
- update_tg_load_avg(cfs_rq, 0);
+ } else if (decayed) {
+ cfs_rq_util_change(cfs_rq, 0);
+
+ if (flags & UPDATE_TG)
+ update_tg_load_avg(cfs_rq, 0);
+ }
}

#ifndef CONFIG_64BIT
@@ -7517,6 +7518,28 @@ static inline bool others_have_blocked(struct rq *rq) { return false; }
static inline void update_blocked_load_status(struct rq *rq, bool has_blocked) {}
#endif

+static bool __update_blocked_others(struct rq *rq, bool *done)
+{
+ const struct sched_class *curr_class;
+ u64 now = rq_clock_pelt(rq);
+ bool decayed;
+
+ /*
+ * update_load_avg() can call cpufreq_update_util(). Make sure that RT,
+ * DL and IRQ signals have been updated before updating CFS.
+ */
+ curr_class = rq->curr->sched_class;
+
+ decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
+ update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
+ update_irq_load_avg(rq, 0);
+
+ if (others_have_blocked(rq))
+ *done = false;
+
+ return decayed;
+}
+
#ifdef CONFIG_FAIR_GROUP_SCHED

static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq)
@@ -7536,29 +7559,11 @@ static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq)
return true;
}

-static void update_blocked_averages(int cpu)
+static bool __update_blocked_fair(struct rq *rq, bool *done)
{
- struct rq *rq = cpu_rq(cpu);
struct cfs_rq *cfs_rq, *pos;
- const struct sched_class *curr_class;
- struct rq_flags rf;
- bool done = true;
-
- rq_lock_irqsave(rq, &rf);
- update_rq_clock(rq);
-
- /*
- * update_cfs_rq_load_avg() can call cpufreq_update_util(). Make sure
- * that RT, DL and IRQ signals have been updated before updating CFS.
- */
- curr_class = rq->curr->sched_class;
- update_rt_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &rt_sched_class);
- update_dl_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &dl_sched_class);
- update_irq_load_avg(rq, 0);
-
- /* Don't need periodic decay once load/util_avg are null */
- if (others_have_blocked(rq))
- done = false;
+ bool decayed = false;
+ int cpu = cpu_of(rq);

/*
* Iterates the task_group tree in a bottom up fashion, see
@@ -7567,9 +7572,13 @@ static void update_blocked_averages(int cpu)
for_each_leaf_cfs_rq_safe(rq, cfs_rq, pos) {
struct sched_entity *se;

- if (update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq))
+ if (update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq)) {
update_tg_load_avg(cfs_rq, 0);

+ if (cfs_rq == &rq->cfs)
+ decayed = true;
+ }
+
/* Propagate pending load changes to the parent, if any: */
se = cfs_rq->tg->se[cpu];
if (se && !skip_blocked_update(se))
@@ -7584,11 +7593,10 @@ static void update_blocked_averages(int cpu)

/* Don't need periodic decay once load/util_avg are null */
if (cfs_rq_has_blocked(cfs_rq))
- done = false;
+ *done = false;
}

- update_blocked_load_status(rq, !done);
- rq_unlock_irqrestore(rq, &rf);
+ return decayed;
}

/*
@@ -7638,29 +7646,16 @@ static unsigned long task_h_load(struct task_struct *p)
cfs_rq_load_avg(cfs_rq) + 1);
}
#else
-static inline void update_blocked_averages(int cpu)
+static bool __update_blocked_fair(struct rq *rq, bool *done)
{
- struct rq *rq = cpu_rq(cpu);
struct cfs_rq *cfs_rq = &rq->cfs;
- const struct sched_class *curr_class;
- struct rq_flags rf;
-
- rq_lock_irqsave(rq, &rf);
- update_rq_clock(rq);
-
- /*
- * update_cfs_rq_load_avg() can call cpufreq_update_util(). Make sure
- * that RT, DL and IRQ signals have been updated before updating CFS.
- */
- curr_class = rq->curr->sched_class;
- update_rt_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &rt_sched_class);
- update_dl_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &dl_sched_class);
- update_irq_load_avg(rq, 0);
+ bool decayed;

- update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq);
+ decayed = update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq);
+ if (cfs_rq_has_blocked(cfs_rq))
+ *done = false;

- update_blocked_load_status(rq, cfs_rq_has_blocked(cfs_rq) || others_have_blocked(rq));
- rq_unlock_irqrestore(rq, &rf);
+ return decayed;
}

static unsigned long task_h_load(struct task_struct *p)
@@ -7669,6 +7664,24 @@ static unsigned long task_h_load(struct task_struct *p)
}
#endif

+static void update_blocked_averages(int cpu)
+{
+ bool decayed = false, done = true;
+ struct rq *rq = cpu_rq(cpu);
+ struct rq_flags rf;
+
+ rq_lock_irqsave(rq, &rf);
+ update_rq_clock(rq);
+
+ decayed |= __update_blocked_others(rq, &done);
+ decayed |= __update_blocked_fair(rq, &done);
+
+ update_blocked_load_status(rq, !done);
+ if (decayed)
+ cpufreq_update_util(rq, 0);
+ rq_unlock_irqrestore(rq, &rf);
+}
+
/********** Helpers for find_busiest_group ************************/

/*
--
2.20.1



2020-01-24 11:02:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 044/102] soc: aspeed: Fix snoop_file_poll()s return type

From: Luc Van Oostenryck <[email protected]>

commit a4e55ccd4392e70f296d12e81b93c6ca96ee21d5 upstream.

snoop_file_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.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev")
Signed-off-by: Luc Van Oostenryck <[email protected]>
Reviewed-by: Joel Stanley <[email protected]>
Reviewed-by: Andrew Jeffery <[email protected]>
Signed-off-by: Joel Stanley <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/soc/aspeed/aspeed-lpc-snoop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -97,13 +97,13 @@ static ssize_t snoop_file_read(struct fi
return ret ? ret : copied;
}

-static unsigned int snoop_file_poll(struct file *file,
+static __poll_t snoop_file_poll(struct file *file,
struct poll_table_struct *pt)
{
struct aspeed_lpc_snoop_channel *chan = snoop_file_to_chan(file);

poll_wait(file, &chan->wq, pt);
- return !kfifo_is_empty(&chan->fifo) ? POLLIN : 0;
+ return !kfifo_is_empty(&chan->fifo) ? EPOLLIN : 0;
}

static const struct file_operations snoop_fops = {


2020-01-24 11:02:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 091/102] dma-direct: dont check swiotlb=force in dma_direct_map_resource

From: Christoph Hellwig <[email protected]>

[ Upstream commit 4268ac6ae5870af10a7417b22990d615f72f77e2 ]

When mapping resources we can't just use swiotlb ram for bounce
buffering. Switch to a direct dma_capable check instead.

Fixes: cfced786969c ("dma-mapping: remove the default map_resource implementation")
Reported-by: Robin Murphy <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/dma/direct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8402b29c280f5..867fd72cb2605 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -375,7 +375,7 @@ dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
{
dma_addr_t dma_addr = paddr;

- if (unlikely(!dma_direct_possible(dev, dma_addr, size))) {
+ if (unlikely(!dma_capable(dev, dma_addr, size))) {
report_addr(dev, dma_addr, size);
return DMA_MAPPING_ERROR;
}
--
2.20.1



2020-01-24 11:02:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 046/102] ipmi: Fix memory leak in __ipmi_bmc_register

From: Navid Emamdoost <[email protected]>

commit 4aa7afb0ee20a97fbf0c5bab3df028d5fb85fdab upstream.

In the impelementation of __ipmi_bmc_register() the allocated memory for
bmc should be released in case ida_simple_get() fails.

Fixes: 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name")
Signed-off-by: Navid Emamdoost <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/ipmi/ipmi_msghandler.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3039,8 +3039,11 @@ static int __ipmi_bmc_register(struct ip
bmc->pdev.name = "ipmi_bmc";

rv = ida_simple_get(&ipmi_bmc_ida, 0, 0, GFP_KERNEL);
- if (rv < 0)
+ if (rv < 0) {
+ kfree(bmc);
goto out;
+ }
+
bmc->pdev.dev.driver = &ipmidriver.driver;
bmc->pdev.id = rv;
bmc->pdev.dev.release = release_bmc_device;


2020-01-24 11:02:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 094/102] drm/radeon: fix bad DMA from INTERRUPT_CNTL2

From: Sam Bobroff <[email protected]>

[ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]

The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address. This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).

Instead, use the DMA address of the dummy page because it will always
be safe.

Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)")
Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/radeon/cik.c | 4 ++--
drivers/gpu/drm/radeon/r600.c | 4 ++--
drivers/gpu/drm/radeon/si.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 62eab82a64f97..897442754fd03 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6969,8 +6969,8 @@ static int cik_irq_init(struct radeon_device *rdev)
}

/* setup interrupt control */
- /* XXX this should actually be a bus address, not an MC address. same on older asics */
- WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+ /* set dummy read address to dummy page address */
+ WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled without msi
* IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e937cc01910d9..033bc466a862a 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3696,8 +3696,8 @@ int r600_irq_init(struct radeon_device *rdev)
}

/* setup interrupt control */
- /* set dummy read address to ring address */
- WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+ /* set dummy read address to dummy page address */
+ WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled without msi
* IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 05894d198a798..1d8efb0eefdb4 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -5997,8 +5997,8 @@ static int si_irq_init(struct radeon_device *rdev)
}

/* setup interrupt control */
- /* set dummy read address to ring address */
- WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+ /* set dummy read address to dummy page address */
+ WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled without msi
* IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
--
2.20.1



2020-01-24 12:06:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 006/102] libbpf: Make btf__resolve_size logic always check size error condition

From: Andrii Nakryiko <[email protected]>

commit 994021a7e08477f7e51285920aac99fc967fae8a upstream.

Perform size check always in btf__resolve_size. Makes the logic a bit more
robust against corrupted BTF and silences LGTM/Coverity complaining about
always true (size < 0) check.

Fixes: 69eaab04c675 ("btf: extract BTF type size calculation")
Signed-off-by: Andrii Nakryiko <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/lib/bpf/btf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -269,10 +269,9 @@ __s64 btf__resolve_size(const struct btf
t = btf__type_by_id(btf, type_id);
}

+done:
if (size < 0)
return -EINVAL;
-
-done:
if (nelems && size > UINT32_MAX / nelems)
return -E2BIG;



2020-01-24 12:06:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 021/102] powerpc/kasan: Fix boot failure with RELOCATABLE && FSL_BOOKE

From: Christophe Leroy <[email protected]>

commit 71eb40fc53371bc247c8066ae76ad9e22ae1e18d upstream.

When enabling CONFIG_RELOCATABLE and CONFIG_KASAN on FSL_BOOKE,
the kernel doesn't boot.

relocate_init() requires KASAN early shadow area to be set up because
it needs access to the device tree through generic functions.

Call kasan_early_init() before calling relocate_init()

Reported-by: Lexi Shao <[email protected]>
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/b58426f1664a4b344ff696d18cacf3b3e8962111.1575036985.git.christophe.leroy@c-s.fr
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kernel/head_fsl_booke.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -238,6 +238,9 @@ set_ivor:

bl early_init

+#ifdef CONFIG_KASAN
+ bl kasan_early_init
+#endif
#ifdef CONFIG_RELOCATABLE
mr r3,r30
mr r4,r31
@@ -264,9 +267,6 @@ set_ivor:
/*
* Decide what sort of machine this is and initialize the MMU.
*/
-#ifdef CONFIG_KASAN
- bl kasan_early_init
-#endif
mr r3,r30
mr r4,r31
bl machine_init


2020-01-24 12:06:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 011/102] ARM: dts: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel

From: Adam Ford <[email protected]>

commit a177057a95f6a3f1e0e52a17eea2178c15073648 upstream.

With the removal of the panel-dpi from the omap drivers, the
LCD no longer works. This patch points the device tree to
a newly created panel named "logicpd,type28"

Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by: Adam Ford <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts | 20 +------------------
1 file changed, 2 insertions(+), 18 deletions(-)

--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit-28.dts
@@ -11,22 +11,6 @@
#include "logicpd-torpedo-37xx-devkit.dts"

&lcd0 {
-
- label = "28";
-
- panel-timing {
- clock-frequency = <9000000>;
- hactive = <480>;
- vactive = <272>;
- hfront-porch = <3>;
- hback-porch = <2>;
- hsync-len = <42>;
- vback-porch = <3>;
- vfront-porch = <2>;
- vsync-len = <11>;
- hsync-active = <1>;
- vsync-active = <1>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ /* To make it work, set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 */
+ compatible = "logicpd,type28";
};


2020-01-24 12:07:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 048/102] gpiolib: No need to call gpiochip_remove_pin_ranges() twice

From: Andy Shevchenko <[email protected]>

commit 2f4133bb5f14f49a99acf0cc55b84996dbfb4dff upstream.

of_gpiochip_add(), when fails, calls gpiochip_remove_pin_ranges().

ADD:
gpiochip_add_data_with_key() ->
of_gpiochip_add() -> (ERROR path)
gpiochip_remove_pin_ranges()

At the same time of_gpiochip_remove() calls exactly the above mentioned
function unconditionally and so does gpiochip_remove().

REMOVE:
gpiochip_remove() ->
gpiochip_remove_pin_ranges()
of_gpiochip_remove() ->
gpiochip_remove_pin_ranges()

Since gpiochip_remove() calls gpiochip_remove_pin_ranges() unconditionally,
we have duplicate call to the same function when it's not necessary.

Move gpiochip_remove_pin_ranges() from of_gpiochip_add() to gpiochip_add()
to avoid duplicate calls and be consistent with the explicit call in
gpiochip_remove().

Fixes: e93fa3f24353 ("gpiolib: remove duplicate pin range code")
Depends-on: f7299d441a4d ("gpio: of: Fix of_gpiochip_add() error path")
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpio/gpiolib-of.c | 5 +----
drivers/gpio/gpiolib.c | 3 ++-
2 files changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -909,16 +909,13 @@ int of_gpiochip_add(struct gpio_chip *ch
of_node_get(chip->of_node);

ret = of_gpiochip_scan_gpios(chip);
- if (ret) {
+ if (ret)
of_node_put(chip->of_node);
- gpiochip_remove_pin_ranges(chip);
- }

return ret;
}

void of_gpiochip_remove(struct gpio_chip *chip)
{
- gpiochip_remove_pin_ranges(chip);
of_node_put(chip->of_node);
}
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1452,6 +1452,7 @@ err_remove_of_chip:
gpiochip_free_hogs(chip);
of_gpiochip_remove(chip);
err_free_gpiochip_mask:
+ gpiochip_remove_pin_ranges(chip);
gpiochip_free_valid_mask(chip);
err_remove_from_list:
spin_lock_irqsave(&gpio_lock, flags);
@@ -1507,8 +1508,8 @@ void gpiochip_remove(struct gpio_chip *c
gdev->chip = NULL;
gpiochip_irqchip_remove(chip);
acpi_gpiochip_remove(chip);
- gpiochip_remove_pin_ranges(chip);
of_gpiochip_remove(chip);
+ gpiochip_remove_pin_ranges(chip);
gpiochip_free_valid_mask(chip);
/*
* We accept no more calls into the driver from this point, so


2020-01-24 12:07:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 039/102] perf map: No need to adjust the long name of modules

From: Arnaldo Carvalho de Melo <[email protected]>

commit f068435d9bb2d825d59e3c101bc579f09315ee01 upstream.

At some point in the past we needed to make sure we would get the long
name of modules and not just what we get from /proc/modules, but that
need, as described in the cset that introduced the adjustment function:

Fixes: c03d5184f0e9 ("perf machine: Adjust dso->long_name for offline module")

Without using the buildid-cache:

# lsmod | grep trusted
# insmod trusted.ko
# lsmod | grep trusted
trusted 24576 0
# strace -e open,openat perf probe -m ./trusted.ko key_seal |& grep trusted
openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 7
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/.debug/root/trusted.ko/dd3d355d567394d540f527e093e0f64b95879584/probes", O_RDWR|O_CREAT, 0644) = 3
openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/.debug/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, ".debug/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 4
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
probe:key_seal (on key_seal in trusted)
# perf probe -l
probe:key_seal (on key_seal in trusted)
#

No attempt at opening '[trusted]'.

Now using the build-id cache:

# rmmod trusted
# perf buildid-cache --add ./trusted.ko
# insmod trusted.ko
# strace -e open,openat perf probe -m ./trusted.ko key_seal |& grep trusted
openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 7
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/.debug/root/trusted.ko/dd3d355d567394d540f527e093e0f64b95879584/probes", O_RDWR|O_CREAT, 0644) = 3
openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/.debug/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, ".debug/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 4
openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3
#

Again, no attempt at reading '[trusted]'.

Finally, adding a probe to that function and then using:

[root@quaco ~]# perf trace -e probe_perf:*/max-stack=16/ --max-events=2
0.000 perf/13456 probe_perf:dso__adjust_kmod_long_name(__probe_ip: 5492263)
dso__adjust_kmod_long_name (/home/acme/bin/perf)
machine__process_kernel_mmap_event (/home/acme/bin/perf)
machine__process_mmap_event (/home/acme/bin/perf)
perf_event__process_mmap (/home/acme/bin/perf)
machines__deliver_event (/home/acme/bin/perf)
perf_session__deliver_event (/home/acme/bin/perf)
perf_session__process_event (/home/acme/bin/perf)
process_simple (/home/acme/bin/perf)
reader__process_events (/home/acme/bin/perf)
__perf_session__process_events (/home/acme/bin/perf)
perf_session__process_events (/home/acme/bin/perf)
process_buildids (/home/acme/bin/perf)
record__finish_output (/home/acme/bin/perf)
__cmd_record (/home/acme/bin/perf)
cmd_record (/home/acme/bin/perf)
run_builtin (/home/acme/bin/perf)
0.055 perf/13456 probe_perf:dso__adjust_kmod_long_name(__probe_ip: 5492263)
dso__adjust_kmod_long_name (/home/acme/bin/perf)
machine__process_kernel_mmap_event (/home/acme/bin/perf)
machine__process_mmap_event (/home/acme/bin/perf)
perf_event__process_mmap (/home/acme/bin/perf)
machines__deliver_event (/home/acme/bin/perf)
perf_session__deliver_event (/home/acme/bin/perf)
perf_session__process_event (/home/acme/bin/perf)
process_simple (/home/acme/bin/perf)
reader__process_events (/home/acme/bin/perf)
__perf_session__process_events (/home/acme/bin/perf)
perf_session__process_events (/home/acme/bin/perf)
process_buildids (/home/acme/bin/perf)
record__finish_output (/home/acme/bin/perf)
__cmd_record (/home/acme/bin/perf)
cmd_record (/home/acme/bin/perf)
run_builtin (/home/acme/bin/perf)
#

This was the only path I could find using the perf tools that reach at this
function, then as of november/2019, if we put a probe in the line where the
actuall setting of the dso->long_name is done:

# perf trace -e probe_perf:*
^C[root@quaco ~]
# perf stat -e probe_perf:* -I 2000
2.000404265 0 probe_perf:dso__adjust_kmod_long_name
4.001142200 0 probe_perf:dso__adjust_kmod_long_name
6.001704120 0 probe_perf:dso__adjust_kmod_long_name
8.002398316 0 probe_perf:dso__adjust_kmod_long_name
10.002984010 0 probe_perf:dso__adjust_kmod_long_name
12.003597851 0 probe_perf:dso__adjust_kmod_long_name
14.004113303 0 probe_perf:dso__adjust_kmod_long_name
16.004582773 0 probe_perf:dso__adjust_kmod_long_name
18.005176373 0 probe_perf:dso__adjust_kmod_long_name
20.005801605 0 probe_perf:dso__adjust_kmod_long_name
22.006467540 0 probe_perf:dso__adjust_kmod_long_name
^C 23.683261941 0 probe_perf:dso__adjust_kmod_long_name

#

Its not being used at all.

To further test this I used kvm.ko as the offline module, i.e. removed
if from the buildid-cache by nuking it completely (rm -rf ~/.debug) and
moved it from the normal kernel distro path, removed the modules, stoped
the kvm guest, and then installed it manually, etc.

# rmmod kvm-intel
# rmmod kvm
# lsmod | grep kvm
# modprobe kvm-intel
modprobe: ERROR: ctx=0x55d3b1722260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory
modprobe: ERROR: ctx=0x55d3b1722260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory
modprobe: ERROR: could not insert 'kvm_intel': Unknown symbol in module, or unknown parameter (see dmesg)
# insmod ./kvm.ko
# modprobe kvm-intel
modprobe: ERROR: ctx=0x562f34026260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory
modprobe: ERROR: ctx=0x562f34026260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory
# lsmod | grep kvm
kvm_intel 299008 0
kvm 765952 1 kvm_intel
irqbypass 16384 1 kvm
#
# perf probe -x ~/bin/perf machine__findnew_module_map:12 mname=m.name:string filename=filename:string 'dso_long_name=map->dso->long_name:string' 'dso_name=map->dso->name:string'
# perf probe -l
probe_perf:machine__findnew_module_map (on machine__findnew_module_map:12@util/machine.c in /home/acme/bin/perf with mname filename dso_long_name dso_name)
# perf record
^C[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 3.416 MB perf.data (33956 samples) ]
# perf trace -e probe_perf:machine*
<SNIP>
6.322 perf/23099 probe_perf:machine__findnew_module_map(__probe_ip: 5492493, mname: "[salsa20_generic]", filename: "/lib/modules/5.3.8-200.fc30.x86_64/kernel/crypto/salsa20_generic.ko.xz", dso_long_name: "/lib/modules/5.3.8-200.fc30.x86_64/kernel/crypto/salsa20_generic.ko.xz", dso_name: "[salsa20_generic]")
6.375 perf/23099 probe_perf:machine__findnew_module_map(__probe_ip: 5492493, mname: "[kvm]", filename: "[kvm]", dso_long_name: "[kvm]", dso_name: "[kvm]")
<SNIP>

The filename doesn't come with the path, no point in trying to set the dso->long_name.

[root@quaco ~]# strace -e open,openat perf probe -m ./kvm.ko kvm_apic_local_deliver |& egrep 'open.*kvm'
openat(AT_FDCWD, "/sys/module/kvm_intel/notes/.note.gnu.build-id", O_RDONLY) = 4
openat(AT_FDCWD, "/sys/module/kvm/notes/.note.gnu.build-id", O_RDONLY) = 4
openat(AT_FDCWD, "/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 7
openat(AT_FDCWD, "/sys/module/kvm_intel/notes/.note.gnu.build-id", O_RDONLY) = 8
openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/.debug/root/kvm.ko/5955f426cb93f03f30f3e876814be2db80ab0b55/probes", O_RDWR|O_CREAT, 0644) = 3
openat(AT_FDCWD, "/usr/lib/debug/root/kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/debug/root/kvm.ko", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/.debug/kvm.ko", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3
openat(AT_FDCWD, "kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, ".debug/kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3
openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 4
openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3
[root@quaco ~]#

Cc: Adrian Hunter <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Wang Nan <[email protected]>
Link: https://lkml.kernel.org/n/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/perf/util/machine.c | 27 +--------------------------
1 file changed, 1 insertion(+), 26 deletions(-)

--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -767,24 +767,6 @@ int machine__process_ksymbol(struct mach
return machine__process_ksymbol_register(machine, event, sample);
}

-static void dso__adjust_kmod_long_name(struct dso *dso, const char *filename)
-{
- const char *dup_filename;
-
- if (!filename || !dso || !dso->long_name)
- return;
- if (dso->long_name[0] != '[')
- return;
- if (!strchr(filename, '/'))
- return;
-
- dup_filename = strdup(filename);
- if (!dup_filename)
- return;
-
- dso__set_long_name(dso, dup_filename, true);
-}
-
struct map *machine__findnew_module_map(struct machine *machine, u64 start,
const char *filename)
{
@@ -796,15 +778,8 @@ struct map *machine__findnew_module_map(
return NULL;

map = map_groups__find_by_name(&machine->kmaps, m.name);
- if (map) {
- /*
- * If the map's dso is an offline module, give dso__load()
- * a chance to find the file path of that module by fixing
- * long_name.
- */
- dso__adjust_kmod_long_name(map->dso, filename);
+ if (map)
goto out;
- }

dso = machine__findnew_module_dso(machine, &m, filename);
if (dso == NULL)


2020-01-24 12:07:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 030/102] net: phy: broadcom: Fix RGMII delays configuration for BCM54210E

From: Florian Fainelli <[email protected]>

commit fea7fda7f50a6059220f83251e70709e45cc8040 upstream.

Commit 0fc9ae107669 ("net: phy: broadcom: add support for
BCM54210E") added support for BCM54210E but also unconditionally cleared
the RXC to RXD skew and the TXD to TXC skew, thus only making
PHY_INTERFACE_MODE_RGMII a possible configuration. Use
bcm54xx_config_clock_delay() which correctly sets the registers
depending on the 4 possible PHY interface values that exist for RGMII.

Fixes: 0fc9ae107669 ("net: phy: broadcom: add support for BCM54210E")
Reported-by: Manasa Mudireddy <[email protected]>
Reported-by: Ray Jui <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/phy/broadcom.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)

--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -26,18 +26,13 @@ MODULE_DESCRIPTION("Broadcom PHY driver"
MODULE_AUTHOR("Maciej W. Rozycki");
MODULE_LICENSE("GPL");

+static int bcm54xx_config_clock_delay(struct phy_device *phydev);
+
static int bcm54210e_config_init(struct phy_device *phydev)
{
int val;

- val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
- val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
- val |= MII_BCM54XX_AUXCTL_MISC_WREN;
- bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC, val);
-
- val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
- val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
- bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
+ bcm54xx_config_clock_delay(phydev);

if (phydev->dev_flags & PHY_BRCM_EN_MASTER_MODE) {
val = phy_read(phydev, MII_CTRL1000);


2020-01-24 12:08:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 059/102] drm: rcar_lvds: Fix color mismatches on R-Car H2 ES2.0 and later

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 3986457110a054466bf02f9c4a85aa2bba96177b ]

Commit 5cca30ebe089be23 ("drm/rcar-du: Add LVDS_LANES quirk") states
that LVDS lanes 1 and 3 are inverted on R-Car H2 ES1 only, and that the
problem has been fixed in newer revisions.

However, the code didn't take into account the actual hardware revision,
thus applying the quirk also on newer hardware revisions, causing green
color reversals.

Fix this by applying the quirk when running on R-Car H2 ES1.x only.

Reported-by: Yoshihiro Shimoda <[email protected]>
Fixes: 5cca30ebe089be23 ("drm/rcar-du: Add LVDS_LANES quirk")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Tested-by: Yoshihiro Shimoda <[email protected]>
Reviewed-by: Ulrich Hecht <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3fc7e6899cab5..50c11a7f0467f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -16,6 +16,7 @@
#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/sys_soc.h>

#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
@@ -842,8 +843,23 @@ static int rcar_lvds_get_clocks(struct rcar_lvds *lvds)
return 0;
}

+static const struct rcar_lvds_device_info rcar_lvds_r8a7790es1_info = {
+ .gen = 2,
+ .quirks = RCAR_LVDS_QUIRK_LANES,
+ .pll_setup = rcar_lvds_pll_setup_gen2,
+};
+
+static const struct soc_device_attribute lvds_quirk_matches[] = {
+ {
+ .soc_id = "r8a7790", .revision = "ES1.*",
+ .data = &rcar_lvds_r8a7790es1_info,
+ },
+ { /* sentinel */ }
+};
+
static int rcar_lvds_probe(struct platform_device *pdev)
{
+ const struct soc_device_attribute *attr;
struct rcar_lvds *lvds;
struct resource *mem;
int ret;
@@ -857,6 +873,10 @@ static int rcar_lvds_probe(struct platform_device *pdev)
lvds->dev = &pdev->dev;
lvds->info = of_device_get_match_data(&pdev->dev);

+ attr = soc_device_match(lvds_quirk_matches);
+ if (attr)
+ lvds->info = attr->data;
+
ret = rcar_lvds_parse_dt(lvds);
if (ret < 0)
return ret;
@@ -893,12 +913,6 @@ static const struct rcar_lvds_device_info rcar_lvds_gen2_info = {
.pll_setup = rcar_lvds_pll_setup_gen2,
};

-static const struct rcar_lvds_device_info rcar_lvds_r8a7790_info = {
- .gen = 2,
- .quirks = RCAR_LVDS_QUIRK_LANES,
- .pll_setup = rcar_lvds_pll_setup_gen2,
-};
-
static const struct rcar_lvds_device_info rcar_lvds_gen3_info = {
.gen = 3,
.quirks = RCAR_LVDS_QUIRK_PWD,
@@ -930,7 +944,7 @@ static const struct of_device_id rcar_lvds_of_table[] = {
{ .compatible = "renesas,r8a7744-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a774a1-lvds", .data = &rcar_lvds_gen3_info },
{ .compatible = "renesas,r8a774c0-lvds", .data = &rcar_lvds_r8a77990_info },
- { .compatible = "renesas,r8a7790-lvds", .data = &rcar_lvds_r8a7790_info },
+ { .compatible = "renesas,r8a7790-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a7791-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a7793-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a7795-lvds", .data = &rcar_lvds_gen3_info },
--
2.20.1



2020-01-24 12:08:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 086/102] tee: optee: fix device enumeration error handling

From: Jens Wiklander <[email protected]>

[ Upstream commit 03212e347f9443e524d6383c6806ac08295c1fb0 ]

Prior to this patch in optee_probe() when optee_enumerate_devices() was
called the struct optee was fully initialized. If
optee_enumerate_devices() returns an error optee_probe() is supposed to
clean up and free the struct optee completely, but will at this late
stage need to call optee_remove() instead. This isn't done and thus
freeing the struct optee prematurely.

With this patch the call to optee_enumerate_devices() is done after
optee_probe() has returned successfully and in case
optee_enumerate_devices() fails everything is cleaned up with a call to
optee_remove().

Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support")
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/tee/optee/core.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 1854a3db73457..b830e0a87fbac 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -643,11 +643,6 @@ static struct optee *optee_probe(struct device_node *np)
if (optee->sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM)
pr_info("dynamic shared memory is enabled\n");

- rc = optee_enumerate_devices();
- if (rc)
- goto err;
-
- pr_info("initialized driver\n");
return optee;
err:
if (optee) {
@@ -702,9 +697,10 @@ static struct optee *optee_svc;

static int __init optee_driver_init(void)
{
- struct device_node *fw_np;
- struct device_node *np;
- struct optee *optee;
+ struct device_node *fw_np = NULL;
+ struct device_node *np = NULL;
+ struct optee *optee = NULL;
+ int rc = 0;

/* Node is supposed to be below /firmware */
fw_np = of_find_node_by_name(NULL, "firmware");
@@ -723,6 +719,14 @@ static int __init optee_driver_init(void)
if (IS_ERR(optee))
return PTR_ERR(optee);

+ rc = optee_enumerate_devices();
+ if (rc) {
+ optee_remove(optee);
+ return rc;
+ }
+
+ pr_info("initialized driver\n");
+
optee_svc = optee;

return 0;
--
2.20.1



2020-01-24 12:15:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 019/102] powerpc/security: Fix debugfs data leak on 32-bit

From: Geert Uytterhoeven <[email protected]>

commit 3b05a1e517e1a8cfda4866ec31d28b2bc4fee4c4 upstream.

"powerpc_security_features" is "unsigned long", i.e. 32-bit or 64-bit,
depending on the platform (PPC_FSL_BOOK3E or PPC_BOOK3S_64). Hence
casting its address to "u64 *", and calling debugfs_create_x64() is
wrong, and leaks 32-bit of nearby data to userspace on 32-bit platforms.

While all currently defined SEC_FTR_* security feature flags fit in
32-bit, they all have "ULL" suffixes to make them 64-bit constants.
Hence fix the leak by changing the type of "powerpc_security_features"
(and the parameter types of its accessors) to "u64". This also allows
to drop the cast.

Fixes: 398af571128fe75f ("powerpc/security: Show powerpc_security_features in debugfs")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/include/asm/security_features.h | 8 ++++----
arch/powerpc/kernel/security.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)

--- a/arch/powerpc/include/asm/security_features.h
+++ b/arch/powerpc/include/asm/security_features.h
@@ -9,7 +9,7 @@
#define _ASM_POWERPC_SECURITY_FEATURES_H


-extern unsigned long powerpc_security_features;
+extern u64 powerpc_security_features;
extern bool rfi_flush;

/* These are bit flags */
@@ -24,17 +24,17 @@ void setup_stf_barrier(void);
void do_stf_barrier_fixups(enum stf_barrier_type types);
void setup_count_cache_flush(void);

-static inline void security_ftr_set(unsigned long feature)
+static inline void security_ftr_set(u64 feature)
{
powerpc_security_features |= feature;
}

-static inline void security_ftr_clear(unsigned long feature)
+static inline void security_ftr_clear(u64 feature)
{
powerpc_security_features &= ~feature;
}

-static inline bool security_ftr_enabled(unsigned long feature)
+static inline bool security_ftr_enabled(u64 feature)
{
return !!(powerpc_security_features & feature);
}
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -16,7 +16,7 @@
#include <asm/setup.h>


-unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
+u64 powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;

enum count_cache_flush_type {
COUNT_CACHE_FLUSH_NONE = 0x1,
@@ -109,7 +109,7 @@ device_initcall(barrier_nospec_debugfs_i
static __init int security_feature_debugfs_init(void)
{
debugfs_create_x64("security_features", 0400, powerpc_debugfs_root,
- (u64 *)&powerpc_security_features);
+ &powerpc_security_features);
return 0;
}
device_initcall(security_feature_debugfs_init);


2020-01-24 12:21:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 042/102] soc: qcom: llcc: Name regmaps to avoid collisions

From: Stephen Boyd <[email protected]>

commit 2bfd3e7651addcaf48f12d4f11ea9d8fca6c3aa8 upstream.

We'll end up with debugfs collisions if we don't give names to the
regmaps created by this driver. Change the name of the config before
registering it so we don't collide in debugfs.

Fixes: 7f9c136216c7 ("soc: qcom: Add broadcast base for Last Level Cache Controller (LLCC)")
Cc: Venkata Narendra Kumar Gutta <[email protected]>
Reviewed-by: Evan Green <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/soc/qcom/llcc-slice.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -48,7 +48,7 @@

static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;

-static const struct regmap_config llcc_regmap_config = {
+static struct regmap_config llcc_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
@@ -323,6 +323,7 @@ static struct regmap *qcom_llcc_init_mmi
if (IS_ERR(base))
return ERR_CAST(base);

+ llcc_regmap_config.name = name;
return devm_regmap_init_mmio(&pdev->dev, base, &llcc_regmap_config);
}



2020-01-24 12:21:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 043/102] soc: renesas: Add missing check for non-zero product register address

From: Geert Uytterhoeven <[email protected]>

commit 4194b583c104922c6141d6610bfbce26847959df upstream.

If the DTB for a device with an RZ/A2 SoC lacks a device node for the
BSID register, the ID validation code falls back to using a register at
address 0x0, which leads to undefined behavior (e.g. reading back a
random value).

This could be fixed by letting fam_rza2.reg point to the actual BSID
register. However, the hardcoded fallbacks were meant for backwards
compatibility with old DTBs only, not for new SoCs. Hence fix this by
validating renesas_family.reg before using it.

Fixes: 175f435f44b724e3 ("soc: renesas: identify RZ/A2")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/soc/renesas/renesas-soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -326,7 +326,7 @@ static int __init renesas_soc_init(void)
if (np) {
chipid = of_iomap(np, 0);
of_node_put(np);
- } else if (soc->id) {
+ } else if (soc->id && family->reg) {
chipid = ioremap(family->reg, 4);
}
if (chipid) {


2020-01-24 12:23:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 033/102] mt7601u: fix bbp version check in mt7601u_wait_bbp_ready

From: Lorenzo Bianconi <[email protected]>

commit 15e14f76f85f4f0eab3b8146e1cd3c58ce272823 upstream.

Fix bbp ready check in mt7601u_wait_bbp_ready. The issue is reported by
coverity with the following error:

Logical vs. bitwise operator
The expression's value does not depend on the operands; inadvertent use
of the wrong operator is a likely logic error.

Addresses-Coverity-ID: 1309441 ("Logical vs. bitwise operator")
Fixes: c869f77d6abb ("add mt7601u driver")
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mediatek/mt7601u/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/mediatek/mt7601u/phy.c
+++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
@@ -213,7 +213,7 @@ int mt7601u_wait_bbp_ready(struct mt7601

do {
val = mt7601u_bbp_rr(dev, MT_BBP_REG_VERSION);
- if (val && ~val)
+ if (val && val != 0xff)
break;
} while (--i);



2020-01-24 12:23:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 045/102] watchdog: sprd: Fix the incorrect pointer getting from driver data

From: Shuiqing Li <[email protected]>

commit 39e68d9e7ab276880980ee5386301fb218202192 upstream.

The device driver data saved the 'struct sprd_wdt' object, it is
incorrect to get 'struct watchdog_device' object from the driver
data, thus fix it.

Fixes: 477603467009 ("watchdog: Add Spreadtrum watchdog driver")
Reported-by: Dongwei Wang <[email protected]>
Signed-off-by: Shuiqing Li <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/76d4687189ec940baa90cb8d679a8d4c8f02ee80.1573210405.git.baolin.wang@linaro.org
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/watchdog/sprd_wdt.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/watchdog/sprd_wdt.c
+++ b/drivers/watchdog/sprd_wdt.c
@@ -327,10 +327,9 @@ static int sprd_wdt_probe(struct platfor

static int __maybe_unused sprd_wdt_pm_suspend(struct device *dev)
{
- struct watchdog_device *wdd = dev_get_drvdata(dev);
struct sprd_wdt *wdt = dev_get_drvdata(dev);

- if (watchdog_active(wdd))
+ if (watchdog_active(&wdt->wdd))
sprd_wdt_stop(&wdt->wdd);
sprd_wdt_disable(wdt);

@@ -339,7 +338,6 @@ static int __maybe_unused sprd_wdt_pm_su

static int __maybe_unused sprd_wdt_pm_resume(struct device *dev)
{
- struct watchdog_device *wdd = dev_get_drvdata(dev);
struct sprd_wdt *wdt = dev_get_drvdata(dev);
int ret;

@@ -347,7 +345,7 @@ static int __maybe_unused sprd_wdt_pm_re
if (ret)
return ret;

- if (watchdog_active(wdd)) {
+ if (watchdog_active(&wdt->wdd)) {
ret = sprd_wdt_start(&wdt->wdd);
if (ret) {
sprd_wdt_disable(wdt);


2020-01-24 12:36:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 064/102] drm/amdgpu/vi: silence an uninitialized variable warning

From: Dan Carpenter <[email protected]>

[ Upstream commit 4ff17a1df7d550257972a838220a8af4611c8f2c ]

Smatch complains that we need to initialized "*cap" otherwise it can
lead to an uninitialized variable bug in the caller. This seems like a
reasonable warning and it doesn't hurt to silence it at least.

drivers/gpu/drm/amd/amdgpu/vi.c:767 vi_asic_reset_method() error: uninitialized symbol 'baco_reset'.

Fixes: 425db2553e43 ("drm/amdgpu: expose BACO interfaces to upper level from PP")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index fa8ad7db2b3a1..d306cc7119976 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -1421,6 +1421,7 @@ static int pp_get_asic_baco_capability(void *handle, bool *cap)
{
struct pp_hwmgr *hwmgr = handle;

+ *cap = false;
if (!hwmgr)
return -EINVAL;

--
2.20.1



2020-01-24 12:40:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 068/102] rcu: Fix uninitialized variable in nocb_gp_wait()

From: Dan Carpenter <[email protected]>

[ Upstream commit b8889c9c89a2655a231dfed93cc9bdca0930ea67 ]

We never set this to false. This probably doesn't affect most people's
runtime because GCC will automatically initialize it to false at certain
common optimization levels. But that behavior is related to a bug in
GCC and obviously should not be relied on.

Fixes: 5d6742b37727 ("rcu/nocb: Use rcu_segcblist for no-CBs CPUs")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/rcu/tree_plugin.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 2defc7fe74c39..fa08d55f7040c 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1946,7 +1946,7 @@ static void nocb_gp_wait(struct rcu_data *my_rdp)
int __maybe_unused cpu = my_rdp->cpu;
unsigned long cur_gp_seq;
unsigned long flags;
- bool gotcbs;
+ bool gotcbs = false;
unsigned long j = jiffies;
bool needwait_gp = false; // This prevents actual uninitialized use.
bool needwake;
--
2.20.1



2020-01-24 12:43:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 100/102] gpio: aspeed: avoid return type warning

From: Arnd Bergmann <[email protected]>

[ Upstream commit 11e299de3aced4ea23a9fb1fef6c983c8d516302 ]

gcc has a hard time tracking whether BUG_ON(1) ends
execution or not:

drivers/gpio/gpio-aspeed-sgpio.c: In function 'bank_reg':
drivers/gpio/gpio-aspeed-sgpio.c:112:1: error: control reaches end of non-void function [-Werror=return-type]

Use the simpler BUG() that gcc knows cannot continue.

Fixes: f8b410e3695a ("gpio: aspeed-sgpio: Rename and add Kconfig/Makefile")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Andrew Jeffery <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpio/sgpio-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/sgpio-aspeed.c b/drivers/gpio/sgpio-aspeed.c
index 7e99860ca447e..8319812593e31 100644
--- a/drivers/gpio/sgpio-aspeed.c
+++ b/drivers/gpio/sgpio-aspeed.c
@@ -107,7 +107,7 @@ static void __iomem *bank_reg(struct aspeed_sgpio *gpio,
return gpio->base + bank->irq_regs + GPIO_IRQ_STATUS;
default:
/* acturally if code runs to here, it's an error case */
- BUG_ON(1);
+ BUG();
}
}

--
2.20.1



2020-01-24 12:43:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 078/102] rtc: bd70528: fix module alias to autoload module

From: Colin Ian King <[email protected]>

[ Upstream commit afe19a7ae8b6b6032d04d3895ebd5bbac7fe9f30 ]

The module alias platform tag contains a spelling mistake. Fix it.

Fixes: f33506abbcdd ("rtc: bd70528: Add MODULE ALIAS to autoload module")
Signed-off-by: Colin Ian King <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/rtc/rtc-bd70528.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
index ddfef4d43bab7..627037aa66a80 100644
--- a/drivers/rtc/rtc-bd70528.c
+++ b/drivers/rtc/rtc-bd70528.c
@@ -491,4 +491,4 @@ module_platform_driver(bd70528_rtc);
MODULE_AUTHOR("Matti Vaittinen <[email protected]>");
MODULE_DESCRIPTION("BD70528 RTC driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platofrm:bd70528-rtc");
+MODULE_ALIAS("platform:bd70528-rtc");
--
2.20.1



2020-01-24 12:43:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 099/102] net-sysfs: Call dev_hold always in netdev_queue_add_kobject

From: Jouni Hogander <[email protected]>

[ Upstream commit e0b60903b434a7ee21ba8d8659f207ed84101e89 ]

Dev_hold has to be called always in netdev_queue_add_kobject.
Otherwise usage count drops below 0 in case of failure in
kobject_init_and_add.

Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject")
Reported-by: Hulk Robot <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: David Miller <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/core/net-sysfs.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index b4db68e5caa9a..4c826b8bf9b1e 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1462,14 +1462,17 @@ static int netdev_queue_add_kobject(struct net_device *dev, int index)
struct kobject *kobj = &queue->kobj;
int error = 0;

+ /* Kobject_put later will trigger netdev_queue_release call
+ * which decreases dev refcount: Take that reference here
+ */
+ dev_hold(queue->dev);
+
kobj->kset = dev->queues_kset;
error = kobject_init_and_add(kobj, &netdev_queue_ktype, NULL,
"tx-%u", index);
if (error)
goto err;

- dev_hold(queue->dev);
-
#ifdef CONFIG_BQL
error = sysfs_create_group(kobj, &dql_group);
if (error)
--
2.20.1



2020-01-24 15:18:47

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review


On 24/01/2020 09:30, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.15 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


All tests are passing for Tegra ...

Test results for stable-v5.4:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 fail

Linux version: 5.4.15-rc1-g28d0c8c0a7ca
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-01-24 20:42:44

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On Fri, 24 Jan 2020 at 15:04, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.15 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> Andrii Nakryiko <[email protected]>
> libbpf: Fix call relocation offset calculation bug

Perf build failed on stable-rc 5.4 branch for arm, arm64, x86_64 and i386.

libbpf.c: In function 'bpf_program__collect_reloc':
libbpf.c:1795:5: error: implicit declaration of function 'pr_warn';
did you mean 'pr_warning'? [-Werror=implicit-function-declaration]
pr_warn("bad call relo offset: %lu\n", sym.st_value);
^~~~~~~
pr_warning
libbpf.c:1795:5: error: nested extern declaration of 'pr_warn'
[-Werror=nested-externs]
Makefile:653: arch/arm64/Makefile: No such file or directory
cc1: all warnings being treated as errors

--
Linaro LKFT
https://lkft.linaro.org

2020-01-24 21:48:52

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On 1/24/20 2:30 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.15 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2020-01-24 23:58:56

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On Fri, Jan 24, 2020 at 10:30:01AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.15 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> Anything received after that time might be too late.
>

For v5.4.14-102-g5b29268443c0:

Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 389 pass: 389 fail: 0

Guenter

2020-01-25 10:26:39

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On Fri, 24 Jan 2020 at 15:04, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.15 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

rc2 test results report.

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 5.4.15-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 5b29268443c010e77bd281f8439188f03c4cdf7c
git describe: v5.4.14-102-g5b29268443c0
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.14-102-g5b29268443c0

No regressions (compared to build v5.4.14)

No fixes (compared to build v5.4.14)

Ran 25632 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-containers-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-mm-tests
* spectre-meltdown-checker-test
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite

--
Linaro LKFT
https://lkft.linaro.org

2020-01-26 07:45:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On Fri, Jan 24, 2020 at 03:56:48PM -0800, Guenter Roeck wrote:
> On Fri, Jan 24, 2020 at 10:30:01AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.15 release.
> > There are 102 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> > Anything received after that time might be too late.
> >
>
> For v5.4.14-102-g5b29268443c0:
>
> Build results:
> total: 158 pass: 158 fail: 0
> Qemu test results:
> total: 389 pass: 389 fail: 0

Great, thanks for testing all of these and letting me know.

greg k-h

2020-01-26 07:45:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On Sat, Jan 25, 2020 at 03:52:52PM +0530, Naresh Kamboju wrote:
> On Fri, 24 Jan 2020 at 15:04, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.4.15 release.
> > There are 102 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> rc2 test results report.
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing all of these and letting me know.

greg k-h

2020-01-26 07:45:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.4 000/102] 5.4.15-stable review

On Fri, Jan 24, 2020 at 02:46:59PM -0700, shuah wrote:
> On 1/24/20 2:30 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.15 release.
> > There are 102 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 26 Jan 2020 09:26:29 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.15-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h