- Linux-stable-mirror - lists.linaro.org

Patch "media: videobuf2-core: don't go out of the buffer range" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: videobuf2-core: don't go out of the buffer range to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-videobuf2-core-don-t-go-out-of-the-buffer-range.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Date: Thu, 28 Dec 2017 09:16:47 -0500 Subject: media: videobuf2-core: don't go out of the buffer range From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> [ Upstream commit df93dc61b0d8b19a5c9db545cf3fcc24f88dfde4 ] Currently, there's no check if an invalid buffer range is passed. However, while testing DVB memory mapped apps, I got this: videobuf2_core: VB: num_buffers -2143943680, buffer 33, index -2143943647 unable to handle kernel paging request at ffff888b773c0890 IP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] PGD 4142c7067 P4D 4142c7067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill ecdh_generic binfmt_misc rc_dvbsky sp2 ts2020 intel_rapl x86_pkg_temp_thermal dvb_usb_dvbsky intel_powerclamp dvb_usb_v2 coretemp m88ds3103 kvm_intel i2c_mux dvb_core snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul videobuf2_vmalloc videobuf2_memops snd_hda_intel ghash_clmulni_intel videobuf2_core snd_hda_codec rc_core mei_me intel_cstate snd_hwdep snd_hda_core videodev intel_uncore snd_pcm mei media tpm_tis tpm_tis_core intel_rapl_perf tpm snd_timer lpc_ich snd soundcore kvm irqbypass libcrc32c i915 i2c_algo_bit drm_kms_helper e1000e ptp drm crc32c_intel video pps_core CPU: 3 PID: 1776 Comm: dvbv5-zap Not tainted 4.14.0+ #78 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017 task: ffff88877c73bc80 task.stack: ffffb7c402418000 RIP: 0010:__vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: 0018:ffffb7c40241bc60 EFLAGS: 00010246 RAX: 0000000080360421 RBX: 0000000000000021 RCX: 000000000000000a RDX: ffffb7c40241bcf4 RSI: ffff888780362c60 RDI: ffff888796d8e130 RBP: ffffb7c40241bcc8 R08: 0000000000000316 R09: 0000000000000004 R10: ffff888780362c00 R11: 0000000000000001 R12: 000000000002f000 R13: ffff8887758be700 R14: 0000000000021000 R15: 0000000000000001 FS: 00007f2849024740(0000) GS:ffff888796d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff888b773c0890 CR3: 000000043beb2005 CR4: 00000000003606e0 Call Trace: vb2_core_reqbufs+0x226/0x420 [videobuf2_core] dvb_vb2_reqbufs+0x2d/0xc0 [dvb_core] dvb_dvr_do_ioctl+0x98/0x1d0 [dvb_core] dvb_usercopy+0x53/0x1b0 [dvb_core] ? dvb_demux_ioctl+0x20/0x20 [dvb_core] ? tty_ldisc_deref+0x16/0x20 ? tty_write+0x1f9/0x310 ? process_echoes+0x70/0x70 dvb_dvr_ioctl+0x15/0x20 [dvb_core] do_vfs_ioctl+0xa5/0x600 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x1a/0xa5 RIP: 0033:0x7f28486f7ea7 RSP: 002b:00007ffc13b2db18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055b10fc06130 RCX: 00007f28486f7ea7 RDX: 00007ffc13b2db48 RSI: 00000000c0086f3c RDI: 0000000000000007 RBP: 0000000000000203 R08: 000055b10df1e02c R09: 000000000000002e R10: 0036b42415108357 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f2849062f60 R14: 00000000000001f1 R15: 00007ffc13b2da54 Code: 74 0a 60 8b 0a 48 83 c0 30 48 83 c2 04 89 48 d0 89 48 d4 48 39 f0 75 eb 41 8b 42 08 83 7d d4 01 41 c7 82 ec 01 00 00 ff ff ff ff <4d> 89 94 c5 88 00 00 00 74 14 83 c3 01 41 39 dc 0f 85 f1 fe ff RIP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: ffffb7c40241bc60 CR2: ffff888b773c0890 So, add a sanity check in order to prevent going past array. Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/videobuf2-core.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -332,6 +332,10 @@ static int __vb2_queue_alloc(struct vb2_ struct vb2_buffer *vb; int ret; + /* Ensure that q->num_buffers+num_buffers is below VB2_MAX_FRAME */ + num_buffers = min_t(unsigned int, num_buffers, + VB2_MAX_FRAME - q->num_buffers); + for (buffer = 0; buffer < num_buffers; ++buffer) { /* Allocate videobuf buffer structures */ vb = kzalloc(q->buf_struct_size, GFP_KERNEL); Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are queue-4.14/media-videobuf2-core-don-t-go-out-of-the-buffer-range.patch

7 years, 5 months

1
0
0 0

Patch "l2tp: fix missing print session offset info" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled l2tp: fix missing print session offset info to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: l2tp-fix-missing-print-session-offset-info.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hangbin Liu <liuhangbin(a)gmail.com> Date: Fri, 22 Dec 2017 15:10:17 +0100 Subject: l2tp: fix missing print session offset info From: Hangbin Liu <liuhangbin(a)gmail.com> [ Upstream commit 820da5357572715c6235ba3b3daa2d5b43a1198f ] Report offset parameter in L2TP_CMD_SESSION_GET command if it has been configured by userspace Fixes: 309795f4bec ("l2tp: Add netlink control API for L2TP") Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/l2tp/l2tp_netlink.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/l2tp/l2tp_netlink.c +++ b/net/l2tp/l2tp_netlink.c @@ -765,6 +765,8 @@ static int l2tp_nl_session_send(struct s if ((session->ifname[0] && nla_put_string(skb, L2TP_ATTR_IFNAME, session->ifname)) || + (session->offset && + nla_put_u16(skb, L2TP_ATTR_OFFSET, session->offset)) || (session->cookie_len && nla_put(skb, L2TP_ATTR_COOKIE, session->cookie_len, &session->cookie[0])) || Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are queue-4.14/l2tp-fix-missing-print-session-offset-info.patch

7 years, 5 months

1
0
0 0

Patch "mac80211: Fix setting TX power on monitor interfaces" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Fix setting TX power on monitor interfaces to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-setting-tx-power-on-monitor-interfaces.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Peter Große" <pegro(a)friiks.de> Date: Wed, 13 Dec 2017 18:29:46 +0100 Subject: mac80211: Fix setting TX power on monitor interfaces From: "Peter Große" <pegro(a)friiks.de> [ Upstream commit 3a3713ec360138f806c6fc368d1de570f692b347 ] Instead of calling ieee80211_recalc_txpower on monitor interfaces directly, call it using the virtual monitor interface, if one exists. In case of a single monitor interface given, reject setting TX power, if no virtual monitor interface exists. That being checked, don't warn in ieee80211_bss_info_change_notify, after setting TX power on a monitor interface. Fixes warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167 ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O) vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0 PID: 2193 Comm: iw Tainted: G O 4.12.12-gentoo #2 task: ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP: 0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10 EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX: 0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI: ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09: 0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12: 0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15: ffffc90001b57b48 FS: 00007f92644b4580(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0 Call Trace: ieee80211_recalc_txpower+0x33/0x40 ieee80211_set_tx_power+0x40/0x180 nl80211_set_wiphy+0x32e/0x950 Reported-by: Peter GroÃe <pegro(a)friiks.de> Signed-off-by: Peter GroÃe <pegro(a)friiks.de> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/cfg.c | 28 +++++++++++++++++++++++++++- net/mac80211/driver-ops.h | 3 ++- 2 files changed, 29 insertions(+), 2 deletions(-) --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2373,10 +2373,17 @@ static int ieee80211_set_tx_power(struct struct ieee80211_sub_if_data *sdata; enum nl80211_tx_power_setting txp_type = type; bool update_txp_type = false; + bool has_monitor = false; if (wdev) { sdata = IEEE80211_WDEV_TO_SUB_IF(wdev); + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) { + sdata = rtnl_dereference(local->monitor_sdata); + if (!sdata) + return -EOPNOTSUPP; + } + switch (type) { case NL80211_TX_POWER_AUTOMATIC: sdata->user_power_level = IEEE80211_UNSET_POWER_LEVEL; @@ -2415,15 +2422,34 @@ static int ieee80211_set_tx_power(struct mutex_lock(&local->iflist_mtx); list_for_each_entry(sdata, &local->interfaces, list) { + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) { + has_monitor = true; + continue; + } sdata->user_power_level = local->user_power_level; if (txp_type != sdata->vif.bss_conf.txpower_type) update_txp_type = true; sdata->vif.bss_conf.txpower_type = txp_type; } - list_for_each_entry(sdata, &local->interfaces, list) + list_for_each_entry(sdata, &local->interfaces, list) { + if (sdata->vif.type == NL80211_IFTYPE_MONITOR) + continue; ieee80211_recalc_txpower(sdata, update_txp_type); + } mutex_unlock(&local->iflist_mtx); + if (has_monitor) { + sdata = rtnl_dereference(local->monitor_sdata); + if (sdata) { + sdata->user_power_level = local->user_power_level; + if (txp_type != sdata->vif.bss_conf.txpower_type) + update_txp_type = true; + sdata->vif.bss_conf.txpower_type = txp_type; + + ieee80211_recalc_txpower(sdata, update_txp_type); + } + } + return 0; } --- a/net/mac80211/driver-ops.h +++ b/net/mac80211/driver-ops.h @@ -165,7 +165,8 @@ static inline void drv_bss_info_changed( if (WARN_ON_ONCE(sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE || sdata->vif.type == NL80211_IFTYPE_NAN || (sdata->vif.type == NL80211_IFTYPE_MONITOR && - !sdata->vif.mu_mimo_owner))) + !sdata->vif.mu_mimo_owner && + !(changed & BSS_CHANGED_TXPOWER)))) return; if (!check_sdata_in_driver(sdata)) Patches currently in stable-queue which might be from pegro(a)friiks.de are queue-4.14/mac80211-fix-setting-tx-power-on-monitor-interfaces.patch

7 years, 5 months

1
0
0 0

[GIT PULL] commits for Linux 4.14

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 4.14 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 9b1fb9cc922dbf27959287ad75009bb388d115fe: Linux 4.14.27 (2018-03-15 10:54:38 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-04052018 for you to fetch changes up to 9c55e4701c7ae30bd21e7bbbcebd08f81005690b: thermal: int3400_thermal: fix error handling in int3400_thermal_probe() (2018-04-05 00:52:17 -0400) - ---------------------------------------------------------------- for-greg-4.14-04052018 - ---------------------------------------------------------------- Alexey Khoroshilov (1): thermal: int3400_thermal: fix error handling in int3400_thermal_probe() Andy Shevchenko (1): sdhci: Advertise 2.0v supply on SDIO host controller Arjun Vynipadath (1): cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages Arnd Bergmann (1): crypto: aes-generic - build with -Os on gcc-7+ Chaitra P B (1): scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. Christophe JAILLET (2): ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' EDAC, mv64x60: Fix an error handling path Colin Ian King (1): wl1251: check return from call to wl1251_acx_arp_ip_filter Daniel Jurgens (1): net/mlx5: Fix race for multiple RoCE enable Eric W. Biederman (3): signal/metag: Document a conflict with SI_USER with SIGFPE signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP signal/arm: Document conflicts with SI_USER and SIGFPE Florian Westphal (1): netfilter: core: only allow one nat hook per hook point Fuyun Liang (2): net: hns3: fix for getting auto-negotiation state in hclge_get_autoneg net: hns3: fix for changing MTU Gautham R. Shenoy (1): powernv-cpufreq: Add helper to extract pstate from PMSR Geert Uytterhoeven (2): spi: sh-msiof: Fix timeout failures for TX-only DMA transfers ACPI: EC: Fix debugfs_create_*() usage Gustavo A. R. Silva (1): PM / devfreq: Fix potential NULL pointer dereference in governor_store Hangbin Liu (1): l2tp: fix missing print session offset info Hans de Goede (5): ACPI / video: Default lcd_only to true on Win8-ready and newer machines ASoC: Intel: cht_bsw_rt5645: Analog Mic support pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts power: supply: axp288_charger: Properly stop work on probe-error / remove Input: goodix - disable IRQs while suspended Icenowy Zheng (1): clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU Ioan Moldovan (1): Bluetooth: Add a new 04ca:3015 QCA_ROME device Jacob Keller (1): i40evf: don't rely on netif_running() outside rtnl_lock() James Smart (2): nvme_fcloop: disassocate local port structs nvme_fcloop: fix abort race condition Jason Yan (2): scsi: libsas: fix memory leak in sas_smp_get_phy_events() scsi: libsas: fix error when getting phy events Javier Martinez Canillas (1): tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented Jernej Å krabec (1): clk: sunxi-ng: a83t: Add M divider to TCON1 clock Jerome Brunet (1): clk: divider: fix incorrect usage of container_of Jian Shen (3): net: hns3: Fix an error of total drop packet statistics net: hns3: Fix a loop index error of tqp statistics query net: hns3: Fix an error macro definition of HNS3_TQP_STAT Jin Yao (1): perf report: Fix a no annotate browser displayed issue Jiri Bohac (1): x86/gart: Exclude GART aperture from vmcore Jiri Olsa (1): perf tools: Fix copyfile_offset update of output offset Leon Romanovsky (1): RDMA/cma: Mark end of CMA ID messages Linus Walleij (1): gpio: label descriptors using the device name Lorenzo Bianconi (1): iio: imu: st_lsm6dsx: fix endianness in st_lsm6dsx_read_oneshot() Maciej Purski (1): hwmon: (ina2xx) Make calibration register value fixed Martin Blumenstingl (1): clk: meson: mpll: use 64-bit maths in params_from_rate Masami Hiramatsu (2): perf probe: Find versioned symbols from map perf probe: Add warning message if there is unexpected event name Mauro Carvalho Chehab (1): media: videobuf2-core: don't go out of the buffer range Mengting Zhang (1): perf evsel: Enable ignore_missing_thread for pid option Mike Christie (1): tcmu: release blocks for partially setup cmds Mike Marciniszyn (1): IB/rdmavt: Allocate CQ memory on the correct node Ming Lei (3): blk-mq: avoid to map CPU into stale hw queue blk-mq: fix race between updating nr_hw_queues and switching io sched blk-mq: fix kernel oops in blk_mq_tag_idle() Miquel Raynal (1): mtd: mtd_oobtest: Handle bitflips during reads Moni Shoua (1): net/mlx4_en: Change default QoS settings Nathan Fontenot (1): ibmvnic: Don't handle RX interrupts when not up. NeilBrown (2): VFS: close race between getcwd() and d_move() staging: lustre: disable preempt while sampling processor id. Oleksij Rempel (1): watchdog: dw_wdt: add stop watchdog operation Paolo Valente (1): block, bfq: put async queues for root bfq groups too Parav Pandit (1): RDMA/cma: Fix rdma_cm path querying for RoCE Pardha Saradhi K (1): ASoC: Intel: Skylake: Disable clock gating during firmware and library download Peng Li (1): net: hns3: free the ring_data structrue when change tqps Peter GroÃŸe (1): mac80211: Fix setting TX power on monitor interfaces Pieter \"PoroCYon\" Sluys (1): vfb: fix video mode and line_length being set when loaded Quinn Tran (1): scsi: qla2xxx: Fix NULL pointer access for fcport structure Rafael David Tinoco (1): scsi: libiscsi: Allow sd_shutdown on bad transport Rasmus Villemoes (1): ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node Robert Jarzmik (1): backlight: tdo24m: Fix the SPI CS between transfers Rui Hua (1): bcache: ret IOERR when read meets metadata error Shanker Donthineni (1): irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry Shiraz Saleem (2): i40iw: Fix sequence number for the first partial FPDU i40iw: Correct Q1/XF object count equation Shivasharan S (2): scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called Sowmini Varadhan (2): rds; Reset rs->rs_bound_addr in rds_add_bound() failure path selftests/net: fix bugs in address and port initialization Stanislaw Gruszka (1): rt2x00: do not pause queue unconditionally on error path Stephen Hemminger (1): uio_hv_generic: check that host supports monitor page Tang Junhui (2): bcache: stop writeback thread after detaching bcache: segregate flash only volume write streams Tatyana Nikolova (1): i40iw: Validate correct IRD/ORD connection parameters Tobias Brunner (1): ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT Tony Lindgren (1): tty: n_gsm: Allow ADM response in addition to UA for control dlci Wei Yongjun (1): gpio: thunderx: fix error return code in thunderx_gpio_probe() Yi Zeng (1): thermal: power_allocator: fix one race condition issue for thermal_instances list chenxiang (1): scsi: libsas: initialize sas_phy status according to response of DISCOVER arch/arm/boot/dts/ls1021a.dtsi | 2 +- arch/arm/include/uapi/asm/siginfo.h | 13 ++++ arch/arm/vfp/vfpmodule.c | 2 +- arch/metag/include/uapi/asm/siginfo.h | 7 ++ arch/metag/kernel/traps.c | 2 +- arch/powerpc/include/uapi/asm/siginfo.h | 15 ++++ arch/powerpc/kernel/traps.c | 10 +-- arch/x86/kernel/aperture_64.c | 46 +++++++++++- arch/x86/xen/mmu_hvm.c | 2 +- block/bfq-cgroup.c | 7 +- block/blk-mq.c | 29 +++++++- crypto/Makefile | 1 + drivers/acpi/acpi_video.c | 14 +++- drivers/acpi/ec.c | 2 +- drivers/acpi/ec_sys.c | 2 +- drivers/acpi/internal.h | 2 +- drivers/bluetooth/btusb.c | 1 + drivers/char/tpm/tpm-interface.c | 28 +++++-- drivers/char/tpm/tpm.h | 5 ++ drivers/clk/clk-divider.c | 7 +- drivers/clk/hisilicon/clkdivider-hi6220.c | 2 +- drivers/clk/meson/clk-mpll.c | 2 +- drivers/clk/nxp/clk-lpc32xx.c | 2 +- drivers/clk/qcom/clk-regmap-divider.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 +- drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 6 +- drivers/clk/sunxi-ng/ccu_div.c | 2 +- drivers/cpufreq/powernv-cpufreq.c | 37 +++++---- drivers/devfreq/devfreq.c | 3 +- drivers/edac/mv64x60_edac.c | 2 +- drivers/gpio/gpio-thunderx.c | 4 +- drivers/gpio/gpiolib.c | 3 +- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 +- drivers/hwmon/ina2xx.c | 87 +++++++++++++--------- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 2 +- drivers/infiniband/core/cma.c | 1 + drivers/infiniband/core/ucma.c | 7 +- drivers/infiniband/hw/i40iw/i40iw_cm.c | 5 +- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 +- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- drivers/infiniband/sw/rdmavt/cq.c | 10 ++- drivers/input/touchscreen/goodix.c | 8 +- drivers/irqchip/irq-gic-v3.c | 11 +++ drivers/md/bcache/alloc.c | 19 +++-- drivers/md/bcache/request.c | 22 ++++++ drivers/md/bcache/super.c | 6 ++ drivers/media/v4l2-core/videobuf2-core.c | 4 + drivers/mmc/host/sdhci-pci-core.c | 2 + drivers/mmc/host/sdhci.c | 7 ++ drivers/mtd/tests/oobtest.c | 21 ++++++ drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 23 ++++-- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 + .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 17 ++++- .../ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 13 ++-- drivers/net/ethernet/ibm/ibmvnic.c | 6 ++ drivers/net/ethernet/intel/i40evf/i40evf_main.c | 20 ++++- drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 5 ++ drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 ++ drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 + drivers/net/ethernet/mellanox/mlx5/core/vport.c | 33 ++++++-- drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 22 ++++-- drivers/net/wireless/ti/wl1251/main.c | 3 +- drivers/nvme/target/fcloop.c | 47 ++++++++---- drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++ drivers/power/supply/axp288_charger.c | 13 ++++ drivers/rtc/rtc-ac100.c | 6 +- drivers/scsi/libiscsi.c | 24 +++++- drivers/scsi/libsas/sas_expander.c | 4 +- drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- drivers/scsi/megaraid/megaraid_sas_fp.c | 16 +++- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 28 +++---- drivers/scsi/qla2xxx/qla_init.c | 13 +++- drivers/spi/spi-sh-msiof.c | 12 ++- .../staging/lustre/lnet/libcfs/linux/linux-cpu.c | 13 ++-- drivers/target/target_core_user.c | 7 ++ drivers/thermal/int340x_thermal/int3400_thermal.c | 10 ++- drivers/thermal/power_allocator.c | 2 + drivers/tty/n_gsm.c | 17 ++++- drivers/uio/uio_hv_generic.c | 7 ++ drivers/video/backlight/corgi_lcd.c | 2 +- drivers/video/backlight/tdo24m.c | 2 +- drivers/video/backlight/tosa_lcd.c | 2 +- drivers/video/fbdev/vfb.c | 17 +++++ drivers/watchdog/dw_wdt.c | 18 ++++- fs/dcache.c | 23 ++++-- include/linux/clk-provider.h | 2 +- include/linux/mlx5/driver.h | 2 +- include/linux/netfilter.h | 1 + net/ipv4/netfilter/iptable_nat.c | 4 + net/ipv6/ip6_output.c | 8 ++ net/ipv6/netfilter/ip6table_nat.c | 4 + net/l2tp/l2tp_netlink.c | 2 + net/mac80211/cfg.c | 28 ++++++- net/mac80211/driver-ops.h | 3 +- net/netfilter/core.c | 6 ++ net/netfilter/nf_tables_api.c | 2 + net/rds/bind.c | 1 + sound/soc/intel/atom/sst/sst_stream.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5645.c | 7 ++ sound/soc/intel/skylake/skl-messages.c | 4 + sound/soc/intel/skylake/skl-pcm.c | 4 + tools/perf/arch/powerpc/util/sym-handling.c | 8 ++ tools/perf/builtin-record.c | 4 +- tools/perf/builtin-report.c | 18 ++++- tools/perf/util/evsel.c | 47 +++++++++++- tools/perf/util/probe-event.c | 28 ++++++- tools/perf/util/symbol.c | 5 ++ tools/perf/util/symbol.h | 1 + tools/perf/util/util.c | 2 +- tools/testing/selftests/net/msg_zerocopy.c | 21 ++++-- 111 files changed, 913 insertions(+), 235 deletions(-) create mode 100644 arch/arm/include/uapi/asm/siginfo.h -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlrFwP4ACgkQ3qZv95d3 LNy4PA/+MH4fZECGWKXQd+KzRkbeAdSAcASVZnjmNFleQKEfY8e45EgOSYgGOXdi qZ2y6PJHSTiv/dPy3+h9tPppb/8AkOw51zwWQVK1WRm+jEzn7Lajcho84LwfWxV7 umO82Xam2SFa7SjaLDxFrh2gAunkh8jdpEdqvqCd9n2FOFuBVLODkqvDfHoUcWrU dl5XZXZ13/H0Lvw9dnlEZyarwiquZY5ayWiMKZsRVea7WJTmuQ22nyjpH+b7KxFQ rmxJcAjNpsWeieMaB80wWhJFvH72rJJ6edcR/+vTIbTqgvJNi4UiSWK5hxO0VrMQ JGHm5c4IFGZcI+05QEzFBWurLVV1b6Oc6zKZuNcqM4XMI3ll4ykYhcM7/1xi3UK6 8QdRPMBGlAu1GzgqaI1qcd4wEqBgGRL7smbuO4htFlgyOdVFB7ivnU0FW5ioDob4 WhMY7fnuJbV1rT32yEpAJnIElqx8cIXOMKB2E8e3RBxylucF3p6kvNhE3irm9B1B HJPPm01osZDM7DwvpYRjiTqnEWld/3MDByaYsx65oEjLYQ87MGINrvH7B7WKO7Se Rkww8M46ZJvBHGL/Dr0FpAo5RtyOKBzZAFf6bEpRxa9yidoCyJbU1QZ8n5fDraXh BJBU7MCN/XIjVVtMP8m6VhbcB1fYpcpLhGAys3Alj2xOZEv0ewc= =tzYe -----END PGP SIGNATURE-----

7 years, 5 months

2
1
0 0

Patch "irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shanker Donthineni <shankerd(a)codeaurora.org> Date: Tue, 5 Dec 2017 13:16:21 -0600 Subject: irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry From: Shanker Donthineni <shankerd(a)codeaurora.org> [ Upstream commit ebe2f8718007d5a1238bb3cb8141b5bb2b4d5773 ] The ACPI specification says OS shouldn't attempt to use GICC configuration parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code skips the disabled GICC entries but not causing any issue. However the current GICv3 driver probe bails out causing kernel panic() instead of skipping the disabled GICC interfaces. This issue happens on systems where redistributor regions are not in the always-on power domain and one of GICC interface marked with ACPI_MADT_ENABLED=0. This patch does the two things to fix the panic. - Don't return an error in gic_acpi_match_gicc() for disabled GICC entry. - No need to keep GICR region information for disabled GICC entry. Observed kernel crash on QDF2400 platform GICC entry is disabled. Kernel crash traces: Kernel panic - not syncing: No interrupt controller found. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26 [<ffff000008087770>] dump_backtrace+0x0/0x218 [<ffff0000080879dc>] show_stack+0x14/0x20 [<ffff00000883b078>] dump_stack+0x98/0xb8 [<ffff0000080c5c14>] panic+0x118/0x26c [<ffff000008b62348>] init_IRQ+0x24/0x2c [<ffff000008b609fc>] start_kernel+0x230/0x394 [<ffff000008b601e4>] __primary_switched+0x64/0x6c ---[ end Kernel panic - not syncing: No interrupt controller found. Disabled GICC subtable example: Subtable Type : 0B [Generic Interrupt Controller] Length : 50 Reserved : 0000 CPU Interface Number : 0000003D Processor UID : 0000003D Flags (decoded below) : 00000000 Processor Enabled : 0 Performance Interrupt Trig Mode : 0 Virtual GIC Interrupt Trig Mode : 0 Parking Protocol Version : 00000000 Performance Interrupt : 00000017 Parked Address : 0000000000000000 Base Address : 0000000000000000 Virtual GIC Base Address : 0000000000000000 Hypervisor GIC Base Address : 0000000000000000 Virtual GIC Interrupt : 00000019 Redistributor Base Address : 0000FFFF88F40000 ARM MPIDR : 000000000000000D Efficiency Class : 00 Reserved : 000000 Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -1297,6 +1297,10 @@ gic_acpi_parse_madt_gicc(struct acpi_sub u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2; void __iomem *redist_base; + /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */ + if (!(gicc->flags & ACPI_MADT_ENABLED)) + return 0; + redist_base = ioremap(gicc->gicr_base_address, size); if (!redist_base) return -ENOMEM; @@ -1346,6 +1350,13 @@ static int __init gic_acpi_match_gicc(st if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address) return 0; + /* + * It's perfectly valid firmware can pass disabled GICC entry, driver + * should not treat as errors, skip the entry instead of probe fail. + */ + if (!(gicc->flags & ACPI_MADT_ENABLED)) + return 0; + return -ENODEV; } Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are queue-4.14/irqchip-gic-v3-fix-the-driver-probe-fail-due-to-disabled-gicc-entry.patch

7 years, 5 months

1
0
0 0

Patch "Input: goodix - disable IRQs while suspended" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: goodix - disable IRQs while suspended to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-goodix-disable-irqs-while-suspended.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Fri, 12 Jan 2018 00:36:48 -0800 Subject: Input: goodix - disable IRQs while suspended From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit faec44b6838312484d63e82286087cf2d5ebb891 ] We should not try to do any i2c transfers before the controller is resumed (which happens before our resume method gets called). So we need to disable our IRQ while suspended to enforce this. The code paths for devices with GPIOs for the int and reset pins already disable the IRQ the through goodix_free_irq(). This commit also disables the IRQ while suspended for devices without GPIOs for the int and reset pins. This fixes the i2c bus sometimes getting stuck after a suspend/resume causing the touchscreen to sometimes not work after a suspend/resume. This has been tested on a GPD pocked device. BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://www.reddit.com/r/GPDPocket/comments/7niut2/fix_for_broken_touch_aft… Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Bastien Nocera <hadess(a)hadess.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/touchscreen/goodix.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -808,8 +808,10 @@ static int __maybe_unused goodix_suspend int error; /* We need gpio pins to suspend/resume */ - if (!ts->gpiod_int || !ts->gpiod_rst) + if (!ts->gpiod_int || !ts->gpiod_rst) { + disable_irq(client->irq); return 0; + } wait_for_completion(&ts->firmware_loading_complete); @@ -849,8 +851,10 @@ static int __maybe_unused goodix_resume( struct goodix_ts_data *ts = i2c_get_clientdata(client); int error; - if (!ts->gpiod_int || !ts->gpiod_rst) + if (!ts->gpiod_int || !ts->gpiod_rst) { + enable_irq(client->irq); return 0; + } /* * Exit sleep mode by outputting HIGH level to INT pin Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.14/input-goodix-disable-irqs-while-suspended.patch queue-4.14/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.14/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 5 months

1
0
0 0

Patch "ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipv6-reinject-ipv6-packets-if-ipsec-policy-matches-after-snat.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tobias Brunner <tobias(a)strongswan.org> Date: Thu, 21 Dec 2017 17:32:24 +0100 Subject: ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT From: Tobias Brunner <tobias(a)strongswan.org> [ Upstream commit 09ee9dba9611cd382fd360a99ad1c2fa23bfdca8 ] If SNAT modifies the source address the resulting packet might match an IPsec policy, reinject the packet if that's the case. The exact same thing is already done for IPv4. Signed-off-by: Tobias Brunner <tobias(a)strongswan.org> Acked-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_output.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -138,6 +138,14 @@ static int ip6_finish_output(struct net return ret; } +#if defined(CONFIG_NETFILTER) && defined(CONFIG_XFRM) + /* Policy lookup after SNAT yielded a new policy */ + if (skb_dst(skb)->xfrm) { + IPCB(skb)->flags |= IPSKB_REROUTED; + return dst_output(net, sk, skb); + } +#endif + if ((skb->len > ip6_skb_dst_mtu(skb) && !skb_is_gso(skb)) || dst_allfrag(skb_dst(skb)) || (IP6CB(skb)->frag_max_size && skb->len > IP6CB(skb)->frag_max_size)) Patches currently in stable-queue which might be from tobias(a)strongswan.org are queue-4.14/ipv6-reinject-ipv6-packets-if-ipsec-policy-matches-after-snat.patch

7 years, 5 months

1
0
0 0

Patch "IB/rdmavt: Allocate CQ memory on the correct node" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/rdmavt: Allocate CQ memory on the correct node to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-rdmavt-allocate-cq-memory-on-the-correct-node.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Mon, 18 Dec 2017 19:57:06 -0800 Subject: IB/rdmavt: Allocate CQ memory on the correct node From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> [ Upstream commit db9a2c6f9b6196b889b98e961cb9a37617b11ccf ] CQ allocation does not ensure that completion queue entries and the completion queue structure are allocated on the correct numa node. Fix by allocating the rvt_cq and kernel CQ entries on the device node, leaving the user CQ entries on the default local node. Also ensure CQ resizes use the correct allocator when extending a CQ. Reviewed-by: Sebastian Sanchez <sebastian.sanchez(a)intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rdmavt/cq.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/infiniband/sw/rdmavt/cq.c +++ b/drivers/infiniband/sw/rdmavt/cq.c @@ -198,7 +198,7 @@ struct ib_cq *rvt_create_cq(struct ib_de return ERR_PTR(-EINVAL); /* Allocate the completion queue structure. */ - cq = kzalloc(sizeof(*cq), GFP_KERNEL); + cq = kzalloc_node(sizeof(*cq), GFP_KERNEL, rdi->dparms.node); if (!cq) return ERR_PTR(-ENOMEM); @@ -214,7 +214,9 @@ struct ib_cq *rvt_create_cq(struct ib_de sz += sizeof(struct ib_uverbs_wc) * (entries + 1); else sz += sizeof(struct ib_wc) * (entries + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) { ret = ERR_PTR(-ENOMEM); goto bail_cq; @@ -369,7 +371,9 @@ int rvt_resize_cq(struct ib_cq *ibcq, in sz += sizeof(struct ib_uverbs_wc) * (cqe + 1); else sz += sizeof(struct ib_wc) * (cqe + 1); - wc = vmalloc_user(sz); + wc = udata ? + vmalloc_user(sz) : + vzalloc_node(sz, rdi->dparms.node); if (!wc) return -ENOMEM; Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.14/ib-rdmavt-allocate-cq-memory-on-the-correct-node.patch

7 years, 5 months

1
0
0 0

Patch "ibmvnic: Don't handle RX interrupts when not up." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ibmvnic: Don't handle RX interrupts when not up. to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ibmvnic-don-t-handle-rx-interrupts-when-not-up.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Wed, 10 Jan 2018 10:40:09 -0600 Subject: ibmvnic: Don't handle RX interrupts when not up. From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> [ Upstream commit 09fb35ead58cd557aa9b20576d15816bc91a4deb ] Initiating a kdump via the command line can cause a pending interrupt to be handled by the ibmvnic driver when initializing the sub-CRQ irqs during driver initialization. NIP [d000000000ca34f0] ibmvnic_interrupt_rx+0x40/0xd0 [ibmvnic] LR [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0 Call Trace: [c000000047fcfde0] [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0 [c000000047fcfea0] [c00000000813317c] handle_irq_event_percpu+0x3c/0x90 [c000000047fcfee0] [c00000000813323c] handle_irq_event+0x6c/0xd0 [c000000047fcff10] [c0000000081385e0] handle_fasteoi_irq+0xf0/0x250 [c000000047fcff40] [c0000000081320a0] generic_handle_irq+0x50/0x80 [c000000047fcff60] [c000000008014984] __do_irq+0x84/0x1d0 [c000000047fcff90] [c000000008027564] call_do_irq+0x14/0x24 [c00000003c92af00] [c000000008014b70] do_IRQ+0xa0/0x120 [c00000003c92af50] [c000000008002594] hardware_interrupt_common+0x114/0x180 Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/ibm/ibmvnic.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -2209,6 +2209,12 @@ static irqreturn_t ibmvnic_interrupt_rx( struct ibmvnic_sub_crq_queue *scrq = instance; struct ibmvnic_adapter *adapter = scrq->adapter; + /* When booting a kdump kernel we can hit pending interrupts + * prior to completing driver initialization. + */ + if (unlikely(adapter->state != VNIC_OPEN)) + return IRQ_NONE; + adapter->rx_stats_buffers[scrq->scrq_num].interrupts++; if (napi_schedule_prep(&adapter->napi[scrq->scrq_num])) { Patches currently in stable-queue which might be from nfont(a)linux.vnet.ibm.com are queue-4.14/ibmvnic-don-t-handle-rx-interrupts-when-not-up.patch

7 years, 5 months

1
0
0 0

Patch "i40iw: Fix sequence number for the first partial FPDU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Fix sequence number for the first partial FPDU to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:59 -0600 Subject: i40iw: Fix sequence number for the first partial FPDU From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit df8b13a1b23356d01dfc4647a5629cdb0f4ce566 ] Partial FPDU processing is broken as the sequence number for the first partial FPDU is wrong due to incorrect Q2 buffer offset. The offset should be 64 rather than 16. Fixes: 786c6adb3a94 ("i40iw: add puda code") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- a/drivers/infiniband/hw/i40iw/i40iw_d.h +++ b/drivers/infiniband/hw/i40iw/i40iw_d.h @@ -93,6 +93,7 @@ #define RDMA_OPCODE_MASK 0x0f #define RDMA_READ_REQ_OPCODE 1 #define Q2_BAD_FRAME_OFFSET 72 +#define Q2_FPSN_OFFSET 64 #define CQE_MAJOR_DRV 0x8000 #define I40IW_TERM_SENT 0x01 --- a/drivers/infiniband/hw/i40iw/i40iw_puda.c +++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c @@ -1376,7 +1376,7 @@ static void i40iw_ieq_handle_exception(s u32 *hw_host_ctx = (u32 *)qp->hw_host_ctx; u32 rcv_wnd = hw_host_ctx[23]; /* first partial seq # in q2 */ - u32 fps = qp->q2_buf[16]; + u32 fps = *(u32 *)(qp->q2_buf + Q2_FPSN_OFFSET); struct list_head *rxlist = &pfpdu->rxlist; struct list_head *plist; Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.14/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.14/i40iw-correct-q1-xf-object-count-equation.patch queue-4.14/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 5 months

1
0
0 0

Patch "i40iw: Validate correct IRD/ORD connection parameters" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Validate correct IRD/ORD connection parameters to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: i40iw-validate-correct-ird-ord-connection-parameters.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Date: Fri, 22 Dec 2017 09:47:01 -0600 Subject: i40iw: Validate correct IRD/ORD connection parameters From: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> [ Upstream commit ce9ce74145aa6814a370a9ff4f5a1d719baaced1 ] Casting to u16 before validating IRD/ORD connection parameters could cause recording wrong IRD/ORD values in the cm_node. Validate the IRD/ORD parameters as they are passed by the application before recording them. Fixes: f27b4746f378 ("i40iw: add connection management code") Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_cm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_cm.c +++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c @@ -125,7 +125,8 @@ static u8 i40iw_derive_hw_ird_setting(u1 * @conn_ird: connection IRD * @conn_ord: connection ORD */ -static void i40iw_record_ird_ord(struct i40iw_cm_node *cm_node, u16 conn_ird, u16 conn_ord) +static void i40iw_record_ird_ord(struct i40iw_cm_node *cm_node, u32 conn_ird, + u32 conn_ord) { if (conn_ird > I40IW_MAX_IRD_SIZE) conn_ird = I40IW_MAX_IRD_SIZE; @@ -3841,7 +3842,7 @@ int i40iw_connect(struct iw_cm_id *cm_id } cm_node->apbvt_set = true; - i40iw_record_ird_ord(cm_node, (u16)conn_param->ird, (u16)conn_param->ord); + i40iw_record_ird_ord(cm_node, conn_param->ird, conn_param->ord); if (cm_node->send_rdma0_op == SEND_RDMA_READ_ZERO && !cm_node->ord_size) cm_node->ord_size = 1; Patches currently in stable-queue which might be from tatyana.e.nikolova(a)intel.com are queue-4.14/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 5 months

1
0
0 0

Patch "i40evf: don't rely on netif_running() outside rtnl_lock()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40evf: don't rely on netif_running() outside rtnl_lock() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: i40evf-don-t-rely-on-netif_running-outside-rtnl_lock.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jacob Keller <jacob.e.keller(a)intel.com> Date: Fri, 27 Oct 2017 11:06:49 -0400 Subject: i40evf: don't rely on netif_running() outside rtnl_lock() From: Jacob Keller <jacob.e.keller(a)intel.com> [ Upstream commit 44b034b406211fc103159f82b9e601e05675c739 ] In i40evf_reset_task we use netif_running() to determine whether or not the device is currently up. This allows us to properly free queue memory and shut down things before we request the hardware reset. It turns out that we cannot be guaranteed of netif_running() returning false until the device is fully up, as the kernel core code sets __LINK_STATE_START prior to calling .ndo_open. Since we're not holding the rtnl_lock(), it's possible that the driver's i40evf_open handler function is currently being called while we're resetting. We can't simply hold the rtnl_lock() while checking netif_running() as this could cause a deadlock with the i40evf_open() function. Additionally, we can't avoid the deadlock by holding the rtnl_lock() over the whole reset path, as this essentially serializes all resets, and can cause massive delays if we have multiple VFs on a system. Instead, lets just check our own internal state __I40EVF_RUNNING state field. This allows us to ensure that the state is correct and is only set after we've finished bringing the device up. Without this change we might free data structures about device queues and other memory before they've been fully allocated. Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c @@ -1775,7 +1775,11 @@ static void i40evf_disable_vf(struct i40 adapter->flags |= I40EVF_FLAG_PF_COMMS_FAILED; - if (netif_running(adapter->netdev)) { + /* We don't use netif_running() because it may be true prior to + * ndo_open() returning, so we can't assume it means all our open + * tasks have finished, since we're not holding the rtnl_lock here. + */ + if (adapter->state == __I40EVF_RUNNING) { set_bit(__I40E_VSI_DOWN, adapter->vsi.state); netif_carrier_off(adapter->netdev); netif_tx_disable(adapter->netdev); @@ -1833,6 +1837,7 @@ static void i40evf_reset_task(struct wor struct i40evf_mac_filter *f; u32 reg_val; int i = 0, err; + bool running; while (test_and_set_bit(__I40EVF_IN_CLIENT_TASK, &adapter->crit_section)) @@ -1892,7 +1897,13 @@ static void i40evf_reset_task(struct wor } continue_reset: - if (netif_running(netdev)) { + /* We don't use netif_running() because it may be true prior to + * ndo_open() returning, so we can't assume it means all our open + * tasks have finished, since we're not holding the rtnl_lock here. + */ + running = (adapter->state == __I40EVF_RUNNING); + + if (running) { netif_carrier_off(netdev); netif_tx_stop_all_queues(netdev); adapter->link_up = false; @@ -1936,7 +1947,10 @@ continue_reset: mod_timer(&adapter->watchdog_timer, jiffies + 2); - if (netif_running(adapter->netdev)) { + /* We were running when the reset started, so we need to restore some + * state here. + */ + if (running) { /* allocate transmit descriptors */ err = i40evf_setup_all_tx_resources(adapter); if (err) Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are queue-4.14/i40evf-don-t-rely-on-netif_running-outside-rtnl_lock.patch

7 years, 5 months

1
0
0 0

Patch "i40iw: Correct Q1/XF object count equation" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40iw: Correct Q1/XF object count equation to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: i40iw-correct-q1-xf-object-count-equation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Shiraz Saleem <shiraz.saleem(a)intel.com> Date: Fri, 22 Dec 2017 09:46:56 -0600 Subject: i40iw: Correct Q1/XF object count equation From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit fe99afd1febd74e0ef1fed7e3283f09effe1f4f0 ] Lower Inbound RDMA Read Queue (Q1) object count by a factor of 2 as it is incorrectly doubled. Also, round up Q1 and Transmit FIFO (XF) object count to power of 2 to satisfy hardware requirement. Fixes: 86dbcd0f12e9 ("i40iw: add file to handle cqp calls") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c +++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c @@ -3875,8 +3875,10 @@ enum i40iw_status_code i40iw_config_fpm_ hmc_info->hmc_obj[I40IW_HMC_IW_APBVT_ENTRY].cnt = 1; hmc_info->hmc_obj[I40IW_HMC_IW_MR].cnt = mrwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = I40IW_MAX_WQ_ENTRIES * qpwanted; - hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = 4 * I40IW_MAX_IRD_SIZE * qpwanted; + hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = + roundup_pow_of_two(I40IW_MAX_WQ_ENTRIES * qpwanted); + hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = + roundup_pow_of_two(2 * I40IW_MAX_IRD_SIZE * qpwanted); hmc_info->hmc_obj[I40IW_HMC_IW_XFFL].cnt = hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt / hmc_fpm_misc->xf_block_size; hmc_info->hmc_obj[I40IW_HMC_IW_Q1FL].cnt = Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are queue-4.14/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch queue-4.14/i40iw-correct-q1-xf-object-count-equation.patch queue-4.14/i40iw-validate-correct-ird-ord-connection-parameters.patch

7 years, 5 months

1
0
0 0

Patch "hwmon: (ina2xx) Make calibration register value fixed" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (ina2xx) Make calibration register value fixed to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-ina2xx-make-calibration-register-value-fixed.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Maciej Purski <m.purski(a)samsung.com> Date: Wed, 22 Nov 2017 16:32:15 +0100 Subject: hwmon: (ina2xx) Make calibration register value fixed From: Maciej Purski <m.purski(a)samsung.com> [ Upstream commit 5d389b125186cf254ad5b8015763ac07c151aea4 ] Calibration register is used for calculating current register in hardware according to datasheet: current = shunt_volt * calib_register / 2048 (ina 226) current = shunt_volt * calib_register / 4096 (ina 219) Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in order to avoid truncation error and provide best precision allowed by shunt_voltage measurement. Make current scale value follow changes of shunt_resistor from sysfs as calib_register value is now fixed. Power_lsb value should also follow shunt_resistor changes as stated in datasheet: power_lsb = 25 * current_lsb (ina 226) power_lsb = 20 * current_lsb (ina 219) Signed-off-by: Maciej Purski <m.purski(a)samsung.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/ina2xx.c | 87 ++++++++++++++++++++++++++++--------------------- 1 file changed, 50 insertions(+), 37 deletions(-) --- a/drivers/hwmon/ina2xx.c +++ b/drivers/hwmon/ina2xx.c @@ -95,18 +95,20 @@ enum ina2xx_ids { ina219, ina226 }; struct ina2xx_config { u16 config_default; - int calibration_factor; + int calibration_value; int registers; int shunt_div; int bus_voltage_shift; int bus_voltage_lsb; /* uV */ - int power_lsb; /* uW */ + int power_lsb_factor; }; struct ina2xx_data { const struct ina2xx_config *config; long rshunt; + long current_lsb_uA; + long power_lsb_uW; struct mutex config_lock; struct regmap *regmap; @@ -116,21 +118,21 @@ struct ina2xx_data { static const struct ina2xx_config ina2xx_config[] = { [ina219] = { .config_default = INA219_CONFIG_DEFAULT, - .calibration_factor = 40960000, + .calibration_value = 4096, .registers = INA219_REGISTERS, .shunt_div = 100, .bus_voltage_shift = 3, .bus_voltage_lsb = 4000, - .power_lsb = 20000, + .power_lsb_factor = 20, }, [ina226] = { .config_default = INA226_CONFIG_DEFAULT, - .calibration_factor = 5120000, + .calibration_value = 2048, .registers = INA226_REGISTERS, .shunt_div = 400, .bus_voltage_shift = 0, .bus_voltage_lsb = 1250, - .power_lsb = 25000, + .power_lsb_factor = 25, }, }; @@ -169,12 +171,16 @@ static u16 ina226_interval_to_reg(int in return INA226_SHIFT_AVG(avg_bits); } +/* + * Calibration register is set to the best value, which eliminates + * truncation errors on calculating current register in hardware. + * According to datasheet (eq. 3) the best values are 2048 for + * ina226 and 4096 for ina219. They are hardcoded as calibration_value. + */ static int ina2xx_calibrate(struct ina2xx_data *data) { - u16 val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - data->rshunt); - - return regmap_write(data->regmap, INA2XX_CALIBRATION, val); + return regmap_write(data->regmap, INA2XX_CALIBRATION, + data->config->calibration_value); } /* @@ -187,10 +193,6 @@ static int ina2xx_init(struct ina2xx_dat if (ret < 0) return ret; - /* - * Set current LSB to 1mA, shunt is in uOhms - * (equation 13 in datasheet). - */ return ina2xx_calibrate(data); } @@ -268,15 +270,15 @@ static int ina2xx_get_value(struct ina2x val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_POWER: - val = regval * data->config->power_lsb; + val = regval * data->power_lsb_uW; break; case INA2XX_CURRENT: - /* signed register, LSB=1mA (selected), in mA */ - val = (s16)regval; + /* signed register, result in mA */ + val = regval * data->current_lsb_uA; + val = DIV_ROUND_CLOSEST(val, 1000); break; case INA2XX_CALIBRATION: - val = DIV_ROUND_CLOSEST(data->config->calibration_factor, - regval); + val = regval; break; default: /* programmer goofed */ @@ -304,9 +306,32 @@ static ssize_t ina2xx_show_value(struct ina2xx_get_value(data, attr->index, regval)); } -static ssize_t ina2xx_set_shunt(struct device *dev, - struct device_attribute *da, - const char *buf, size_t count) +/* + * In order to keep calibration register value fixed, the product + * of current_lsb and shunt_resistor should also be fixed and equal + * to shunt_voltage_lsb = 1 / shunt_div multiplied by 10^9 in order + * to keep the scale. + */ +static int ina2xx_set_shunt(struct ina2xx_data *data, long val) +{ + unsigned int dividend = DIV_ROUND_CLOSEST(1000000000, + data->config->shunt_div); + if (val <= 0 || val > dividend) + return -EINVAL; + + mutex_lock(&data->config_lock); + data->rshunt = val; + data->current_lsb_uA = DIV_ROUND_CLOSEST(dividend, val); + data->power_lsb_uW = data->config->power_lsb_factor * + data->current_lsb_uA; + mutex_unlock(&data->config_lock); + + return 0; +} + +static ssize_t ina2xx_store_shunt(struct device *dev, + struct device_attribute *da, + const char *buf, size_t count) { unsigned long val; int status; @@ -316,18 +341,9 @@ static ssize_t ina2xx_set_shunt(struct d if (status < 0) return status; - if (val == 0 || - /* Values greater than the calibration factor make no sense. */ - val > data->config->calibration_factor) - return -EINVAL; - - mutex_lock(&data->config_lock); - data->rshunt = val; - status = ina2xx_calibrate(data); - mutex_unlock(&data->config_lock); + status = ina2xx_set_shunt(data, val); if (status < 0) return status; - return count; } @@ -387,7 +403,7 @@ static SENSOR_DEVICE_ATTR(power1_input, /* shunt resistance */ static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR, - ina2xx_show_value, ina2xx_set_shunt, + ina2xx_show_value, ina2xx_store_shunt, INA2XX_CALIBRATION); /* update interval (ina226 only) */ @@ -448,10 +464,7 @@ static int ina2xx_probe(struct i2c_clien val = INA2XX_RSHUNT_DEFAULT; } - if (val <= 0 || val > data->config->calibration_factor) - return -ENODEV; - - data->rshunt = val; + ina2xx_set_shunt(data, val); ina2xx_regmap_config.max_register = data->config->registers; Patches currently in stable-queue which might be from m.purski(a)samsung.com are queue-4.14/hwmon-ina2xx-make-calibration-register-value-fixed.patch

7 years, 5 months

1
0
0 0

Patch "gpio: thunderx: fix error return code in thunderx_gpio_probe()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled gpio: thunderx: fix error return code in thunderx_gpio_probe() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Wed, 10 Jan 2018 14:37:13 +0000 Subject: gpio: thunderx: fix error return code in thunderx_gpio_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> [ Upstream commit 76e28f5ffed82b1e81a86c4eb8d0420515765620 ] Fix to return error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5a2a30024d8c ("gpio: Add gpio driver support for ThunderX and OCTEON-TX") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: David Daney <david.daney(a)cavium.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpio-thunderx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpio-thunderx.c +++ b/drivers/gpio/gpio-thunderx.c @@ -566,8 +566,10 @@ static int thunderx_gpio_probe(struct pc txgpio->irqd = irq_domain_create_hierarchy(irq_get_irq_data(txgpio->msix_entries[0].vector)->domain, 0, 0, of_node_to_fwnode(dev->of_node), &thunderx_gpio_irqd_ops, txgpio); - if (!txgpio->irqd) + if (!txgpio->irqd) { + err = -ENOMEM; goto out; + } /* Push on irq_data and the domain for each line. */ for (i = 0; i < ngpio; i++) { Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.14/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch

7 years, 5 months

1
0
0 0

Patch "gpio: label descriptors using the device name" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled gpio: label descriptors using the device name to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: gpio-label-descriptors-using-the-device-name.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Thu, 4 Jan 2018 22:31:11 +0100 Subject: gpio: label descriptors using the device name From: Linus Walleij <linus.walleij(a)linaro.org> [ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ] Some GPIO lines appear named "?" in the lsgpio dump due to their requesting drivers not passing a reasonable label. Most typically this happens if a device tree node just defines gpios = <...> and not foo-gpios = <...>, the former gets named "foo" and the latter gets named "?". However the struct device passed in is always valid so let's just label the GPIO with dev_name() on the device if no proper label was passed. Cc: Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpiolib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -3340,7 +3340,8 @@ struct gpio_desc *__must_check gpiod_get return desc; } - status = gpiod_request(desc, con_id); + /* If a connection label was passed use that, else use the device name as label */ + status = gpiod_request(desc, con_id ? con_id : dev_name(dev)); if (status < 0) return ERR_PTR(status); Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.14/gpio-label-descriptors-using-the-device-name.patch queue-4.14/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch queue-4.14/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 5 months

1
0
0 0

Patch "EDAC, mv64x60: Fix an error handling path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled EDAC, mv64x60: Fix an error handling path to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: edac-mv64x60-fix-an-error-handling-path.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 7 Jan 2018 21:54:00 +0100 Subject: EDAC, mv64x60: Fix an error handling path From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 68fa24f9121c04ef146b5158f538c8b32f285be5 ] We should not call edac_mc_del_mc() if a corresponding call to edac_mc_add_mc() has not been performed yet. So here, we should go to err instead of err2 to branch at the right place of the error handling path. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: linux-edac <linux-edac(a)vger.kernel.org> Link: http://lkml.kernel.org/r/20180107205400.14068-1-christophe.jaillet@wanadoo.… Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/edac/mv64x60_edac.c +++ b/drivers/edac/mv64x60_edac.c @@ -758,7 +758,7 @@ static int mv64x60_mc_err_probe(struct p /* Non-ECC RAM? */ printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__); res = -ENODEV; - goto err2; + goto err; } edac_dbg(3, "init mci\n"); Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.14/edac-mv64x60-fix-an-error-handling-path.patch queue-4.14/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch

7 years, 5 months

1
0
0 0

Patch "cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Arjun Vynipadath <arjun(a)chelsio.com> Date: Wed, 10 Jan 2018 12:02:13 +0530 Subject: cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages From: Arjun Vynipadath <arjun(a)chelsio.com> [ Upstream commit ea0a42109aee7b92e631c4eb3f2219fadf58acdd ] We'd come in with SGE_FL_BUFFER_SIZE[0] and [1] both equal to 64KB and the extant logic would flag that as an error. This was already fixed in cxgb4 driver with "92ddcc7 cxgb4: Fix some small bugs in t4_sge_init_soft() when our Page Size is 64KB". Original Work by: Casey Leedom <leedom(a)chelsio.com> Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2619,8 +2619,8 @@ void t4vf_sge_stop(struct adapter *adapt int t4vf_sge_init(struct adapter *adapter) { struct sge_params *sge_params = &adapter->params.sge; - u32 fl0 = sge_params->sge_fl_buffer_size[0]; - u32 fl1 = sge_params->sge_fl_buffer_size[1]; + u32 fl_small_pg = sge_params->sge_fl_buffer_size[0]; + u32 fl_large_pg = sge_params->sge_fl_buffer_size[1]; struct sge *s = &adapter->sge; /* @@ -2628,9 +2628,20 @@ int t4vf_sge_init(struct adapter *adapte * the Physical Function Driver. Ideally we should be able to deal * with _any_ configuration. Practice is different ... */ - if (fl0 != PAGE_SIZE || (fl1 != 0 && fl1 <= fl0)) { + + /* We only bother using the Large Page logic if the Large Page Buffer + * is larger than our Page Size Buffer. + */ + if (fl_large_pg <= fl_small_pg) + fl_large_pg = 0; + + /* The Page Size Buffer must be exactly equal to our Page Size and the + * Large Page Size Buffer should be 0 (per above) or a power of 2. + */ + if (fl_small_pg != PAGE_SIZE || + (fl_large_pg & (fl_large_pg - 1)) != 0) { dev_err(adapter->pdev_dev, "bad SGE FL buffer sizes [%d, %d]\n", - fl0, fl1); + fl_small_pg, fl_large_pg); return -EINVAL; } if ((sge_params->sge_control & RXPKTCPLMODE_F) != @@ -2642,8 +2653,8 @@ int t4vf_sge_init(struct adapter *adapte /* * Now translate the adapter parameters into our internal forms. */ - if (fl1) - s->fl_pg_order = ilog2(fl1) - PAGE_SHIFT; + if (fl_large_pg) + s->fl_pg_order = ilog2(fl_large_pg) - PAGE_SHIFT; s->stat_len = ((sge_params->sge_control & EGRSTATUSPAGESIZE_F) ? 128 : 64); s->pktshift = PKTSHIFT_G(sge_params->sge_control); Patches currently in stable-queue which might be from arjun(a)chelsio.com are queue-4.14/cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.patch

7 years, 5 months

1
0
0 0

Patch "crypto: aes-generic - build with -Os on gcc-7+" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: aes-generic - build with -Os on gcc-7+ to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-aes-generic-build-with-os-on-gcc-7.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 3 Jan 2018 23:39:27 +0100 Subject: crypto: aes-generic - build with -Os on gcc-7+ From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 148b974deea927f5dbb6c468af2707b488bfa2de ] While testing other changes, I discovered that gcc-7.2.1 produces badly optimized code for aes_encrypt/aes_decrypt. This is especially true when CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely large stack usage that in turn might cause kernel stack overflows: crypto/aes_generic.c: In function 'aes_encrypt': crypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=] crypto/aes_generic.c: In function 'aes_decrypt': crypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=] I verified that this problem exists on all architectures that are supported by gcc-7.2, though arm64 in particular is less affected than the others. I also found that gcc-7.1 and gcc-8 do not show the extreme stack usage but still produce worse code than earlier versions for this file, apparently because of optimization passes that generally provide a substantial improvement in object code quality but understandably fail to find any shortcuts in the AES algorithm. Possible workarounds include a) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier patch I tried, which reliably fixed the stack usage, but caused a serious performance regression in some versions, as later testing found. b) disabling UBSAN on this file or all ciphers, as suggested by Ard Biesheuvel. This would lead to massively better crypto performance in UBSAN-enabled kernels and avoid the stack usage, but there is a concern over whether we should exclude arbitrary files from UBSAN at all. c) Forcing the optimization level in a different way. Similar to a), but rather than deselecting specific optimization stages, this now uses "gcc -Os" for this file, regardless of the CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable workaround for the stack consumption on all architecture, and I've retested the performance results now on x86, cycles/byte (lower is better) for cbc(aes-generic) with 256 bit keys: -O2 -Os gcc-6.3.1 14.9 15.1 gcc-7.0.1 14.7 15.3 gcc-7.1.1 15.3 14.7 gcc-7.2.1 16.8 15.9 gcc-8.0.0 15.5 15.6 This implements the option c) by enabling forcing -Os on all compiler versions starting with gcc-7.1. As a workaround for PR83356, it would only be needed for gcc-7.2+ with UBSAN enabled, but since it also shows better performance on gcc-7.1 without UBSAN, it seems appropriate to use the faster version here as well. Side note: during testing, I also played with the AES code in libressl, which had a similar performance regression from gcc-6 to gcc-7.2, but was three times slower overall. It might be interesting to investigate that further and possibly port the Linux implementation into that. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 Cc: Richard Biener <rguenther(a)suse.de> Cc: Jakub Jelinek <jakub(a)gcc.gnu.org> Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/Makefile | 1 + 1 file changed, 1 insertion(+) --- a/crypto/Makefile +++ b/crypto/Makefile @@ -98,6 +98,7 @@ obj-$(CONFIG_CRYPTO_TWOFISH_COMMON) += t obj-$(CONFIG_CRYPTO_SERPENT) += serpent_generic.o CFLAGS_serpent_generic.o := $(call cc-option,-fsched-pressure) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 obj-$(CONFIG_CRYPTO_AES) += aes_generic.o +CFLAGS_aes_generic.o := $(call cc-ifversion, -ge, 0701, -Os) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 obj-$(CONFIG_CRYPTO_AES_TI) += aes_ti.o obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/crypto-aes-generic-build-with-os-on-gcc-7.patch

7 years, 5 months

1
0
0 0

Patch "clk: sunxi-ng: a83t: Add M divider to TCON1 clock" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: sunxi-ng: a83t: Add M divider to TCON1 clock to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-sunxi-ng-a83t-add-m-divider-to-tcon1-clock.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: "Jernej Škrabec" <jernej.skrabec(a)siol.net> Date: Sat, 30 Dec 2017 22:01:54 +0100 Subject: clk: sunxi-ng: a83t: Add M divider to TCON1 clock From: "Jernej Škrabec" <jernej.skrabec(a)siol.net> [ Upstream commit 7dbc7f5f4904cfddc199af171ea095490a434f15 ] TCON1 also has M divider, contrary to TCON0. And the mux is only 2 bits wide, instead of 3. Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> [wens(a)csie.org: Add description about mux width difference] Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c @@ -493,8 +493,8 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon0_clk 0x118, 24, 3, BIT(31), CLK_SET_RATE_PARENT); static const char * const tcon1_parents[] = { "pll-video1" }; -static SUNXI_CCU_MUX_WITH_GATE(tcon1_clk, "tcon1", tcon1_parents, - 0x11c, 24, 3, BIT(31), CLK_SET_RATE_PARENT); +static SUNXI_CCU_M_WITH_MUX_GATE(tcon1_clk, "tcon1", tcon1_parents, + 0x11c, 0, 4, 24, 2, BIT(31), CLK_SET_RATE_PARENT); static SUNXI_CCU_GATE(csi_misc_clk, "csi-misc", "osc24M", 0x130, BIT(16), 0); Patches currently in stable-queue which might be from jernej.skrabec(a)siol.net are queue-4.14/clk-sunxi-ng-a83t-add-m-divider-to-tcon1-clock.patch

7 years, 5 months

1
0
0 0

Patch "clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-sunxi-ng-fix-the-a64-h5-clock-description-of-de2-ccu.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Icenowy Zheng <icenowy(a)aosc.io> Date: Fri, 22 Dec 2017 20:22:35 +0800 Subject: clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU From: Icenowy Zheng <icenowy(a)aosc.io> [ Upstream commit cf4881c1293516c1975606e8f2af7948789168b8 ] The clocks of A64/H5 SoCs in the DE2 CCU is the same as the clocks in H3 DE2 CCU rather than the A83T DE2 CCU (the parent of them is the DE module clock). Fix this by change the clock descriptions to use the clocks of H3. Fixes: 763c5bd045b1 ("clk: sunxi-ng: add support for DE2 CCU") Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c @@ -129,10 +129,10 @@ static const struct sunxi_ccu_desc sun8i }; static const struct sunxi_ccu_desc sun50i_a64_de2_clk_desc = { - .ccu_clks = sun8i_a83t_de2_clks, - .num_ccu_clks = ARRAY_SIZE(sun8i_a83t_de2_clks), + .ccu_clks = sun8i_h3_de2_clks, + .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks), - .hw_clks = &sun8i_a83t_de2_hw_clks, + .hw_clks = &sun8i_h3_de2_hw_clks, .resets = sun50i_a64_de2_resets, .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets), Patches currently in stable-queue which might be from icenowy(a)aosc.io are queue-4.14/clk-sunxi-ng-fix-the-a64-h5-clock-description-of-de2-ccu.patch

7 years, 5 months

1
0
0 0

Patch "clk: meson: mpll: use 64-bit maths in params_from_rate" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: meson: mpll: use 64-bit maths in params_from_rate to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Date: Sat, 23 Dec 2017 22:38:32 +0100 Subject: clk: meson: mpll: use 64-bit maths in params_from_rate From: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> [ Upstream commit 86aacdca66774051cbc0958110a48074b57a060b ] "rem * SDM_DEN" can easily overflow on the 32-bit Meson8 and Meson8b SoCs if the "remainder" (after the division operation) is greater than 262143Hz. This is likely to happen since the input clock for the MPLLs on Meson8 and Meson8b is "fixed_pll", which is running at a rate of 2550MHz. One example where this was observed to be problematic was the Ethernet clock calculation (which takes MPLL2 as input). When requesting a rate of 125MHz there is a remainder of 2500000Hz. The resulting MPLL2 rate before this patch was 127488329Hz. The resulting MPLL2 rate after this patch is 124999103Hz. Commit b609338b26f5 ("clk: meson: mpll: use 64bit math in rate_from_params") already fixed a similar issue in rate_from_params. Fixes: 007e6e5c5f01d3 ("clk: meson: mpll: add rw operation") Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/meson/clk-mpll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/meson/clk-mpll.c +++ b/drivers/clk/meson/clk-mpll.c @@ -98,7 +98,7 @@ static void params_from_rate(unsigned lo *sdm = SDM_DEN - 1; } else { *n2 = div; - *sdm = DIV_ROUND_UP(rem * SDM_DEN, requested_rate); + *sdm = DIV_ROUND_UP_ULL((u64)rem * SDM_DEN, requested_rate); } } Patches currently in stable-queue which might be from martin.blumenstingl(a)googlemail.com are queue-4.14/clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch

7 years, 5 months

1
0
0 0

Patch "Bluetooth: Add a new 04ca:3015 QCA_ROME device" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: Add a new 04ca:3015 QCA_ROME device to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-add-a-new-04ca-3015-qca_rome-device.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> Date: Mon, 28 Aug 2017 18:09:39 +0300 Subject: Bluetooth: Add a new 04ca:3015 QCA_ROME device From: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> [ Upstream commit 0a03f98b98c201191e3ba15a0e33f46d8660e1fd ] This patch adds the 04ca:3015 (from a QCA9377 board) Bluetooth device to the btusb blacklist and makes the kernel use the btqca module instead of btusb. The patch is necessary because, without it the 04ca:3015 device defaults to using the btusb driver, which makes the WIFI side of the QCA9377 board unusable (obtains 0 MBps in speedtest, when the 04ca:3015 bluetooth is used with an audio headset). /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3015 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Ioan Moldovan <ioan.moldovan1999(a)gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -277,6 +277,7 @@ static const struct usb_device_id blackl { USB_DEVICE(0x0489, 0xe09f), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0489, 0xe0a2), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x04ca, 0x3011), .driver_info = BTUSB_QCA_ROME }, + { USB_DEVICE(0x04ca, 0x3015), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x04ca, 0x3016), .driver_info = BTUSB_QCA_ROME }, /* Broadcom BCM2035 */ Patches currently in stable-queue which might be from ioan.moldovan1999(a)gmail.com are queue-4.14/bluetooth-add-a-new-04ca-3015-qca_rome-device.patch

7 years, 5 months

1
0
0 0

Patch "clk: divider: fix incorrect usage of container_of" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: divider: fix incorrect usage of container_of to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-divider-fix-incorrect-usage-of-container_of.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Jerome Brunet <jbrunet(a)baylibre.com> Date: Thu, 21 Dec 2017 17:30:54 +0100 Subject: clk: divider: fix incorrect usage of container_of From: Jerome Brunet <jbrunet(a)baylibre.com> [ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ] divider_recalc_rate() is an helper function used by clock divider of different types, so the structure containing the 'hw' pointer is not always a 'struct clk_divider' At the following line: > div = _get_div(table, val, flags, divider->width); in several cases, the value of 'divider->width' is garbage as the actual structure behind this memory is not a 'struct clk_divider' Fortunately, this width value is used by _get_val() only when CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so far when the structure is not a 'struct clk_divider'. This is probably why we did not notice this bug before Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero") Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Acked-by: Sylvain Lemieux <slemieux.tyco(a)gmail.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/clk-divider.c | 7 +++---- drivers/clk/hisilicon/clkdivider-hi6220.c | 2 +- drivers/clk/nxp/clk-lpc32xx.c | 2 +- drivers/clk/qcom/clk-regmap-divider.c | 2 +- drivers/clk/sunxi-ng/ccu_div.c | 2 +- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 +- drivers/rtc/rtc-ac100.c | 6 ++++-- include/linux/clk-provider.h | 2 +- 8 files changed, 13 insertions(+), 12 deletions(-) --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -118,12 +118,11 @@ static unsigned int _get_val(const struc unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate, unsigned int val, const struct clk_div_table *table, - unsigned long flags) + unsigned long flags, unsigned long width) { - struct clk_divider *divider = to_clk_divider(hw); unsigned int div; - div = _get_div(table, val, flags, divider->width); + div = _get_div(table, val, flags, width); if (!div) { WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO), "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n", @@ -145,7 +144,7 @@ static unsigned long clk_divider_recalc_ val &= div_mask(divider->width); return divider_recalc_rate(hw, parent_rate, val, divider->table, - divider->flags); + divider->flags, divider->width); } static bool _is_valid_table_div(const struct clk_div_table *table, --- a/drivers/clk/hisilicon/clkdivider-hi6220.c +++ b/drivers/clk/hisilicon/clkdivider-hi6220.c @@ -56,7 +56,7 @@ static unsigned long hi6220_clkdiv_recal val &= div_mask(dclk->width); return divider_recalc_rate(hw, parent_rate, val, dclk->table, - CLK_DIVIDER_ROUND_CLOSEST); + CLK_DIVIDER_ROUND_CLOSEST, dclk->width); } static long hi6220_clkdiv_round_rate(struct clk_hw *hw, unsigned long rate, --- a/drivers/clk/nxp/clk-lpc32xx.c +++ b/drivers/clk/nxp/clk-lpc32xx.c @@ -956,7 +956,7 @@ static unsigned long clk_divider_recalc_ val &= div_mask(divider->width); return divider_recalc_rate(hw, parent_rate, val, divider->table, - divider->flags); + divider->flags, divider->width); } static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, --- a/drivers/clk/qcom/clk-regmap-divider.c +++ b/drivers/clk/qcom/clk-regmap-divider.c @@ -59,7 +59,7 @@ static unsigned long div_recalc_rate(str div &= BIT(divider->width) - 1; return divider_recalc_rate(hw, parent_rate, div, NULL, - CLK_DIVIDER_ROUND_CLOSEST); + CLK_DIVIDER_ROUND_CLOSEST, divider->width); } const struct clk_ops clk_regmap_div_ops = { --- a/drivers/clk/sunxi-ng/ccu_div.c +++ b/drivers/clk/sunxi-ng/ccu_div.c @@ -71,7 +71,7 @@ static unsigned long ccu_div_recalc_rate parent_rate); val = divider_recalc_rate(hw, parent_rate, val, cd->div.table, - cd->div.flags); + cd->div.flags, cd->div.width); if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV) val /= cd->fixed_post_div; --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c @@ -698,7 +698,7 @@ static unsigned long dsi_pll_14nm_postdi val &= div_mask(width); return divider_recalc_rate(hw, parent_rate, val, NULL, - postdiv->flags); + postdiv->flags, width); } static long dsi_pll_14nm_postdiv_round_rate(struct clk_hw *hw, --- a/drivers/rtc/rtc-ac100.c +++ b/drivers/rtc/rtc-ac100.c @@ -137,13 +137,15 @@ static unsigned long ac100_clkout_recalc div = (reg >> AC100_CLKOUT_PRE_DIV_SHIFT) & ((1 << AC100_CLKOUT_PRE_DIV_WIDTH) - 1); prate = divider_recalc_rate(hw, prate, div, - ac100_clkout_prediv, 0); + ac100_clkout_prediv, 0, + AC100_CLKOUT_PRE_DIV_WIDTH); } div = (reg >> AC100_CLKOUT_DIV_SHIFT) & (BIT(AC100_CLKOUT_DIV_WIDTH) - 1); return divider_recalc_rate(hw, prate, div, NULL, - CLK_DIVIDER_POWER_OF_TWO); + CLK_DIVIDER_POWER_OF_TWO, + AC100_CLKOUT_DIV_WIDTH); } static long ac100_clkout_round_rate(struct clk_hw *hw, unsigned long rate, --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -412,7 +412,7 @@ extern const struct clk_ops clk_divider_ unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate, unsigned int val, const struct clk_div_table *table, - unsigned long flags); + unsigned long flags, unsigned long width); long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent, unsigned long rate, unsigned long *prate, const struct clk_div_table *table, Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are queue-4.14/clk-divider-fix-incorrect-usage-of-container_of.patch queue-4.14/clk-meson-mpll-use-64-bit-maths-in-params_from_rate.patch

7 years, 5 months

1
0
0 0

Patch "block, bfq: put async queues for root bfq groups too" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled block, bfq: put async queues for root bfq groups too to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: block-bfq-put-async-queues-for-root-bfq-groups-too.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 13:58:16 CEST 2018 From: Paolo Valente <paolo.valente(a)linaro.org> Date: Tue, 9 Jan 2018 10:27:58 +0100 Subject: block, bfq: put async queues for root bfq groups too From: Paolo Valente <paolo.valente(a)linaro.org> [ Upstream commit 52257ffbfcaf58d247b13fb148e27ed17c33e526 ] For each pair [device for which bfq is selected as I/O scheduler, group in blkio/io], bfq maintains a corresponding bfq group. Each such bfq group contains a set of async queues, with each async queue created on demand, i.e., when some I/O request arrives for it. On creation, an async queue gets an extra reference, to make sure that the queue is not freed as long as its bfq group exists. Accordingly, to allow the queue to be freed after the group exited, this extra reference must released on group exit. The above holds also for a bfq root group, i.e., for the bfq group corresponding to the root blkio/io root for a given device. Yet, by mistake, the references to the existing async queues of a root group are not released when the latter exits. This causes a memory leak when the instance of bfq for a given device exits. In a similar vein, bfqg_stats_xfer_dead is not executed for a root group. This commit fixes bfq_pd_offline so that the latter executes the above missing operations for a root group too. Reported-by: Holger Hoffstätte <holger(a)applied-asynchrony.com> Reported-by: Guoqing Jiang <gqjiang(a)suse.com> Tested-by: Holger Hoffstätte <holger(a)applied-asynchrony.com> Signed-off-by: Davide Ferrari <davideferrari8(a)gmail.com> Signed-off-by: Paolo Valente <paolo.valente(a)linaro.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/bfq-cgroup.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/block/bfq-cgroup.c +++ b/block/bfq-cgroup.c @@ -749,10 +749,11 @@ static void bfq_pd_offline(struct blkg_p unsigned long flags; int i; + spin_lock_irqsave(&bfqd->lock, flags); + if (!entity) /* root group */ - return; + goto put_async_queues; - spin_lock_irqsave(&bfqd->lock, flags); /* * Empty all service_trees belonging to this group before * deactivating the group itself. @@ -783,6 +784,8 @@ static void bfq_pd_offline(struct blkg_p } __bfq_deactivate_entity(entity, false); + +put_async_queues: bfq_put_async_queues(bfqd, bfqg); spin_unlock_irqrestore(&bfqd->lock, flags); Patches currently in stable-queue which might be from paolo.valente(a)linaro.org are queue-4.14/block-bfq-put-async-queues-for-root-bfq-groups-too.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror