4.14 2.3.x imx: net: sch_generic compilation fix, rel_imx_4.14.98_2.3.1_patch and v4.14.170 stable #61

ziswiler · 2020-03-08T00:04:25Z

First, this fixes the net: sch_generic compilation introduced by commit fb1d29a ("net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware").

Then, I merged NXP's latest rel_imx_4.14.98_2.3.1_patch.

And, last but not least, I merged the v4.14.170 stable release which already has a matching PREEMPT_RT kernel patch 4.14.170-rt75.

Thanks!

…ing irq [ Upstream commit 3572e8a ] Besides the alarm, the PCF8563 also has a timer triggered interrupt. In cases where the previous system left the timer and interrupts on, or somehow the bits got enabled, the interrupt would keep triggering as the kernel doesn't know about it. Clear both the alarm and timer event flags, and disable the interrupts, before requesting the interrupt line. Fixes: ede3e9d ("drivers/rtc/rtc-pcf8563.c: add alarm support") Fixes: a45d528 ("rtc: pcf8563: clear expired alarm at boot time") Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit f47bee2 ] These regs are write-only, and the hw throws a hissy-fit (ie. reboots) when we try to read them for GPU state snapshot, in response to a GPU hang. It is rather impolite when GPU recovery triggers an insta- reboot, so lets remove the TPL1 registers from the snapshot. Fixes: 7198e6b drm/msm: add a3xx gpu support Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Jordan Crouse <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 913a90b ] perf_event_open() limits the sample_period to 63 bits. See: 0819b2e ("perf: Limit perf_event_attr::sample_period to 63 bits") Make ioctl() consistent with it. Also on PowerPC, negative sample_period could cause a recursive PMIs leading to a hang (reported when running perf-fuzzer). Signed-off-by: Ravi Bangoria <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Fixes: 0819b2e ("perf: Limit perf_event_attr::sample_period to 63 bits") Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit c24a5c7 ] The commit 080edf7 ("dmaengine: hsu: set HSU_CH_MTSR to memory width") has been mistakenly submitted. The further investigations show that the original code does better job since the memory side transfer size has never been configured by DMA users. As per latest revision of documentation: "Channel minimum transfer size (CHnMTSR)... For IOSF UART, maximum value that can be programmed is 64 and minimum value that can be programmed is 1." This reverts commit 080edf7. Fixes: 080edf7 ("dmaengine: hsu: set HSU_CH_MTSR to memory width") Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit da64242 ] Clang produces the following warning drivers/clk/qcom/gcc-msm8996.c:133:32: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div_map' [-Wunused-const-variable] static const struct parent_map gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div_map[] = { ^drivers/clk/qcom/gcc-msm8996.c:141:27: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div' [-Wunused-const-variable] static const char * const gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div[] = { ^ drivers/clk/qcom/gcc-msm8996.c:187:32: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div_map' [-Wunused-const-variable] static const struct parent_map gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div_map[] = { ^ drivers/clk/qcom/gcc-msm8996.c:197:27: warning: unused variable 'gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div' [-Wunused-const-variable] static const char * const gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div[] = { It looks like these were never used. Fixes: b1e010c ("clk: qcom: Add MSM8996 Global Clock Control (GCC) driver") Cc: [email protected] Link: ClangBuiltLinux#518 Suggested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nathan Huckleberry <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 0493c47 ] The i.MX6 and i.MX8 both have a bit-field spanning bits 27:22 called the WAIT field. The WAIT field according to the documentation for both parts "specifies time interval between auto read and write access in one time program. It is given in number of ipg_clk periods." This patch ensures that the relevant field is read and written back to the timing register. Fixes: 0642bac ("nvmem: imx-ocotp: add write support") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Leonard Crestez <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit d27e2ca ] After ethtool loopback packet tests, we re-open the nic for the next IRQ test. If the open fails, we must not proceed with the IRQ test or we will crash with NULL pointer dereference. Fix it by checking the bnxt_open_nic() return code before proceeding. Reported-by: Somasundaram Krishnasamy <[email protected]> Fixes: 67fea46 ("bnxt_en: Add interrupt test to ethtool -t selftest.") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 3ddbe91 ] Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in iommu_feature_disable. Fixes: 2c0ae17 ('iommu/amd: Convert iommu initialization to state machine') Signed-off-by: Kevin Mitchell <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 02f3691 ] ida instances allocate some internal memory for ->free_bitmap in addition to the base 'struct ida'. Use ida_destroy() to release that memory at module_exit(). Fixes: 4b45efe ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 3427beb ] With gcc 4.1: net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’: net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function Indeed, if the first jump to the send_fragmentable label is made, and the address family is not handled in the switch() statement, ret will be used uninitialized. Fix this by BUG()'ing as is done in other places in rxrpc where internal support for future address families will need adding. It should not be possible to reach this normally as the address families are checked up-front. Fixes: 5a924b8 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs") Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 9dea44c ] devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway: drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~ Change the prototype to allow it, as there is no real reason not to. Fixes: 9bb2e04 ("gpio: amd: Make resource struct const") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Greg Kroah-Hartman <[email protected]> Reviwed-By: Enrico Weigelt <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit ec5bc2c ] When smmu is enable, if execute the perftest command and then use 'kill -9' to exit, follow this operation repeatedly, the kernel will have a high probability to print the following smmu event: arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.1.auto: 0x00007d0000000010 arm-smmu-v3 arm-smmu-v3.1.auto: 0x0000020900000080 arm-smmu-v3 arm-smmu-v3.1.auto: 0x00000000f47cf000 arm-smmu-v3 arm-smmu-v3.1.auto: 0x00000000f47cf000 This is because the hw will periodically refresh the qpc cache until the next reset. This patch fixed it by removing the action that release qpc memory in the 'hns_roce_qp_free' function. Fixes: 9a44353 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Xi Wang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit faf5577 ] The phy_dn variable is still being used in of_phy_connect() after the of_node_put() call, which may result in use-after-free. Fixes: 1dd2d06 ("net: Rework pasemi_mac driver to use of_mdio infrastructure") Signed-off-by: Wen Yang <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 41a6bf6 ] Currently if lport is null then the null lport pointer is dereference when printing out debug via the FC_LPORT_DB macro. Fix this by using the more generic FC_LIBFC_DBG debug macro instead that does not use lport. Addresses-Coverity: ("Dereference after null check") Fixes: 7414705 ("libfc: Add runtime debugging with debug_logging module parameter") Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit c5ed947 ] The user manual of V3/V3s/S3 declares a PLL_DDR1, however it's forgot when developing the V3s CCU driver. Add back the missing PLL_DDR1. Fixes: d0f11d1 ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Icenowy Zheng <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 2933954 ] It is not actually guaranteed that pm_abort_suspend will be nonzero when pm_system_cancel_wakeup() is called which may lead to subtle issues, so make it use atomic_dec_if_positive() instead of atomic_dec() for the safety sake. Fixes: 33e4f80 ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 2ec4ad4 ] It seems we should use 'range' instead of 'priv->range' in lbtf_geo_init(), because 'range' is the corret one related to current regioncode. Reported-by: Hulk Robot <[email protected]> Fixes: 691cdb4 ("libertas_tf: command helper functions for libertas_tf") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 7c116e0 ] clang warns about an overly large stack frame in one function when it decides to inline all __qed_get_vport_*() functions into __qed_get_vport_stats(): drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=] Use a noinline_for_stack annotation to prevent clang from inlining these, which keeps the maximum stack usage at around half of that in the worst case, similar to what we get with gcc. Fixes: 86622ee ("qed: Move statistics to L2 code") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 6269e4c ] Don't do extra cpu_to_le32 conversion for put_unaligned_le32 because it is already implemented in this function. Fixes sparse error: xhci-hub.c:1152:44: warning: incorrect type in argument 1 (different base types) xhci-hub.c:1152:44: expected unsigned int [usertype] val xhci-hub.c:1152:44: got restricted __le32 [usertype] Fixes: 395f540 "xhci: support new USB 3.1 hub request to get extended port status" Cc: Mathias Nyman <[email protected]> Signed-off-by: Ruslan Bilovol <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit bc83f79 ] Generally, declaring a platform device as a static variable is a bad idea and can cause all kinds of problems, in particular with the DMA configuration and lifetime rules. A specific problem we hit here is from a bug in clang that warns about certain (otherwise valid) macros when used in static variables: drivers/misc/mic/card/mic_x100.c:285:27: warning: shift count >= width of type [-Wshift-count-overflow] static u64 mic_dma_mask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ A slightly better way here is to create the platform device dynamically and set the dma mask in the probe function. This avoids the warning and some other problems, but is still not ideal because the device creation should really be separated from the driver, and the fact that the device has no parent means we have to force the dma mask rather than having it set up from the bus that the device is actually on. Fixes: dd8d8d4 ("misc: mic: MIC card driver specific changes to enable SCIF") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 2591bc4 ] apic->send_IPI_allbutself() takes a vector number as argument. APIC_DM_NMI is clearly not a vector number. It's defined to 0x400 which is outside the vector space. Use NMI_VECTOR instead as that's what it is intended to be. Fixes: 82da3ff ("x86: kgdb support") Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 72c8117 ] Each of the operations in ccp_run_cmd() needs several hundred bytes of kernel stack. Depending on the inlining, these may need separate stack slots that add up to more than the warning limit, as shown in this clang based build: drivers/crypto/ccp/ccp-ops.c:871:12: error: stack frame size of 1164 bytes in function 'ccp_run_aes_cmd' [-Werror,-Wframe-larger-than=] static int ccp_run_aes_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd) The problem may also happen when there is no warning, e.g. in the ccp_run_cmd()->ccp_run_aes_cmd()->ccp_run_aes_gcm_cmd() call chain with over 2000 bytes. Mark each individual function as 'noinline_for_stack' to prevent this from happening, and move the calls to the two special cases for aes into the top-level function. This will keep the actual combined stack usage to the mimimum: 828 bytes for ccp_run_aes_gcm_cmd() and at most 524 bytes for each of the other cases. Fixes: 63b9450 ("crypto: ccp - CCP device driver and interface support") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit f474808 ] A lot of places in the driver use onyx_read_register() without checking the return value, and it's been working OK for ~10 years or so, so probably never fails ... Rather than trying to check the return value everywhere, which would be relatively intrusive, at least make sure we don't use an uninitialized value. Fixes: f3d9478 ("[ALSA] snd-aoa: add snd-aoa") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 7c5b420 ] In commit 365ad35 ("tipc: reduce risk of user starvation during link congestion") we allowed senders to add exactly one list of extra buffers to the link backlog queues during link congestion (aka "oversubscription"). However, the criteria for when to stop adding wakeup messages to the input queue when the overload abates is inaccurate, and may cause starvation problems during very high load. Currently, we stop adding wakeup messages after 10 total failed attempts where we find that there is no space left in the backlog queue for a certain importance level. The counter for this is accumulated across all levels, which may lead the algorithm to leave the loop prematurely, although there may still be plenty of space available at some levels. The result is sometimes that messages near the wakeup queue tail are not added to the input queue as they should be. We now introduce a more exact algorithm, where we keep adding wakeup messages to a level as long as the backlog queue has free slots for the corresponding level, and stop at the moment there are no more such slots or when there are no more wakeup messages to dequeue. Fixes: 365ad35 ("tipc: reduce risk of user starvation during link congestion") Reported-by: Tung Nguyen <[email protected]> Acked-by: Ying Xue <[email protected]> Signed-off-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 493e84c ] Add missing vdda-supply required by STM32 ADC. Fixes: 090992a ("ARM: dts: stm32: enable ADC on stm32h743i-eval board") Signed-off-by: Fabrice Gasnier <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit ea77388 ] Remove the "reserved_at_40" field to match the device specification. Fixes: 84df61e ("net/mlx5: Add HW interfaces used by LAG") Signed-off-by: Mark Zhang <[email protected]> Reviewed-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 247bc94 ] Fixes: 72abe3b ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig") The global change from force_sig caused module unloading of cifs.ko to fail (since the cifsd process could not be killed, "rmmod cifs" now would always fail) Signed-off-by: Steve French <[email protected]> Reviewed-by: Ronnie Sahlberg <[email protected]> CC: Eric W. Biederman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit c59a1d4 ] Check the return value of the hardware registration for caam_rng and free resources in case of failure. Fixes: e24f7c9 ("crypto: caam - hwrng support") Signed-off-by: Iuliana Prodan <[email protected]> Reviewed-by: Horia Geanta <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 7a14826 ] Currently when the call to ext4_htree_store_dirent fails the error return variable 'ret' is is not being set to the error code and variable count is instead, hence the error code is not being returned. Fix this by assigning ret to the error return code. Addresses-Coverity: ("Unused value") Fixes: 8af0f08 ("ext4: fix readdir error in the case of inline_data+dir_index") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 630742c ] It seems 'es8328_rline_enum' should be used in es8328_right_line_controls Fixes: 567e4f9 ("ASoC: add es8328 codec driver") Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 1d3ca68 ] When fsl,erratum-a011043 is set, adjust for erratum A011043: MDIO reads to internal PCS registers may result in having the MDIO_CFG[MDIO_RD_ER] bit set, even when there is no error and read data (MDIO_DATA[MDIO_DATA]) is correct. Software may get false read error when reading internal PCS registers through MDIO. As a workaround, all internal MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit. Signed-off-by: Madalin Bucur <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 457bfc0 ] As the only 10G PHY interface type defined at the moment the code was developed was XGMII, although the PHY interface mode used was not XGMII, XGMII was used in the code to denote 10G. This patch renames the 10G interface mode to remove the ambiguity. Signed-off-by: Madalin Bucur <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 865ad2f ] The netif_stop_queue() call in sonic_send_packet() races with the netif_wake_queue() call in sonic_interrupt(). This causes issues like "NETDEV WATCHDOG: eth0 (macsonic): transmit queue 0 timed out". Fix this by disabling interrupts when accessing tx_skb[] and next_tx. Update a comment to clarify the synchronization properties. Fixes: efcce83 ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit e3885f5 ] The driver accesses descriptor memory which is simultaneously accessed by the chip, so the compiler must not be allowed to re-order CPU accesses. sonic_buf_get() used 'volatile' to prevent that. sonic_buf_put() should have done so too but was overlooked. Fixes: efcce83 ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 9e31182 ] The SONIC can sometimes advance its rx buffer pointer (RRP register) without advancing its rx descriptor pointer (CRDA register). As a result the index of the current rx descriptor may not equal that of the current rx buffer. The driver mistakenly assumes that they are always equal. This assumption leads to incorrect packet lengths and possible packet duplication. Avoid this by calling a new function to locate the buffer corresponding to a given descriptor. Fixes: efcce83 ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 3f4b7e6 ] Make sure the SONIC's DMA engine is idle before altering the transmit and receive descriptors. Add a helper for this as it will be needed again. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 70a8728 ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 66018a1 ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 189c9b1 ] skb->csum is updated incorrectly, when manipulation for NF_NAT_MANIP_SRC\DST is done on IPV6 packet. Fix: There is no need to update skb->csum in inet_proto_csum_replace16(), because update in two fields a.) IPv6 src/dst address and b.) L4 header checksum cancels each other for skb->csum calculation. Whereas inet_proto_csum_replace4 function needs to update skb->csum, because update in 3 fields a.) IPv4 src/dst address, b.) IPv4 Header checksum and c.) L4 header checksum results in same diff as L4 Header checksum for skb->csum calculation. [ [email protected]: a few comestic documentation edits ] Signed-off-by: Praveen Chaudhary <[email protected]> Signed-off-by: Zhenggen Xu <[email protected]> Signed-off-by: Andy Stracner <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

commit d55966c upstream. There was some logic added a while ago to clear out f_bavail in statfs() if we did not have enough free metadata space to satisfy our global reserve. This was incorrect at the time, however didn't really pose a problem for normal file systems because we would often allocate chunks if we got this low on free metadata space, and thus wouldn't really hit this case unless we were actually full. Fast forward to today and now we are much better about not allocating metadata chunks all of the time. Couple this with d792b0f ("btrfs: always reserve our entire size for the global reserve") which now means we'll easily have a larger global reserve than our free space, we are now more likely to trip over this while still having plenty of space. Fix this by skipping this logic if the global rsv's space_info is not full. space_info->full is 0 unless we've attempted to allocate a chunk for that space_info and that has failed. If this happens then the space for the global reserve is definitely sacred and we need to report b_avail == 0, but before then we can just use our calculated b_avail. Reported-by: Martin Steigerwald <[email protected]> Fixes: ca8a51b ("btrfs: statfs: report zero available if metadata are exhausted") CC: [email protected] # 4.5+ Reviewed-by: Qu Wenruo <[email protected]> Tested-By: Martin Steigerwald <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit c3314a7 ] Commit 800d3f5 ("perf report: Add warning when libunwind not compiled in") breaks the s390 platform. S390 uses libdw-dwarf-unwind for call chain unwinding and had no support for libunwind. So the warning "Please install libunwind development packages during the perf build." caused the confusion even if the call-graph is displayed correctly. This patch adds checking for HAVE_DWARF_SUPPORT, which is set when libdw-dwarf-unwind is compiled in. Fixes: 800d3f5 ("perf report: Add warning when libunwind not compiled in") Signed-off-by: Jin Yao <[email protected]> Reviewed-by: Thomas Richter <[email protected]> Tested-by: Thomas Richter <[email protected]> Acked-by: Jiri Olsa <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Jin Yao <[email protected]> Cc: Kan Liang <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

Add ov5640 dts support for i.MX8DX MEK board Signed-off-by: Guoniu.zhou <[email protected]>

…port Add tja1100 card support for enet2 port. Reviewed-by: Ye Li <[email protected]> Signed-off-by: Fugang Duan <[email protected]>

Create the fsl-imx8dx-mek-dsi-rm67191.dts in order to add support for the MIPI-DSI panel usecase with the Raydium RM67191 DSI panel. Signed-off-by: Robert Chiras <[email protected]> Reviewed-by: Fugang Duan <[email protected]>

…nnel support This patch adds IT6263 LVDS to HDMI transmitter dual channel support. The transmitter works with LDB split mode. fsl-imx8dx-mek-it6263-lvds0-dual-channel.dts uses LDB1 channel0 as the channel to transmit odd pixels and LDB2 channel0 as the channel to transmit even pixels. fsl-imx8dx-mek-it6263-lvds1-dual-channel.dts swaps the channels to transmit odd/even pixels. Signed-off-by: Liu Ying <[email protected]> (cherry picked from commit 7cd2417af24b8f54d0b91f9b655211db79f63abb)

This patch adds JDI WUXGA LVDS panel support on the i.MX8DX MEK platform. The JDI WUXGA LVDS panel works in LDB split mode. fsl-imx8dx-mek-jdi-wuxga-lvds0-panel.dts uses LDB1 channel0 as the channel to transmit odd pixels and LDB2 channel0 as the channel to transmit even pixels. fsl-imx8dx-mek-jdi-wuxga-lvds1-panel.dts swaps the channels to transmit odd/even pixels. Signed-off-by: Liu Ying <[email protected]> (cherry picked from commit 31c6c62eff01b3288828f2e1b9ecf6ad9204b3c6)

This fixes the following error upon compiling: /fslc/4.14-2.3.x-imx/net/sched/sch_generic.c: In function ‘attach_one_default_qdisc’: /fslc/4.14-2.3.x-imx/net/sched/sch_generic.c:771:23: error: ‘ARPHRD_CAN’ undeclared (first use in this function); did you mean ‘ETH_P_CAN’? else if(dev->type == ARPHRD_CAN) ^~~~~~~~~~ ETH_P_CAN /fslc/4.14-2.3.x-imx/net/sched/sch_generic.c:771:23: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [/fslc/4.14-2.3.x-imx/scripts/Makefile.build:326: net/sched/sch_generic.o] Error 1 make[2]: *** [/fslc/4.14-2.3.x-imx/scripts/Makefile.build:585: net/sched] Error 2 make[2]: *** Waiting for unfinished jobs.... Fixes: fb1d29a ("net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware") Signed-off-by: Marcel Ziswiler <[email protected]>

This is the 4.14.170 stable release Conflicts: drivers/net/phy/phy_device.c drivers/tty/serial/imx.c include/linux/platform_data/dma-imx-sdma.h net/wireless/util.c

commit 7733306 upstream. The "inline" keyword is a hint for the compiler to inline a function. The functions system_uses_irq_prio_masking() and gic_write_pmr() are used by the code running at EL2 on a non-VHE system, so mark them as __always_inline to make sure they'll always be part of the .hyp.text section. This fixes the following splat when trying to run a VM: [ 47.625273] Kernel panic - not syncing: HYP panic: [ 47.625273] PS:a00003c9 PC:0000ca0b42049fc4 ESR:86000006 [ 47.625273] FAR:0000ca0b42049fc4 HPFAR:0000000010001000 PAR:0000000000000000 [ 47.625273] VCPU:0000000000000000 [ 47.647261] CPU: 1 PID: 217 Comm: kvm-vcpu-0 Not tainted 5.8.0-rc1-ARCH+ Freescale#61 [ 47.654508] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 47.661139] Call trace: [ 47.663659] dump_backtrace+0x0/0x1cc [ 47.667413] show_stack+0x18/0x24 [ 47.670822] dump_stack+0xb8/0x108 [ 47.674312] panic+0x124/0x2f4 [ 47.677446] panic+0x0/0x2f4 [ 47.680407] SMP: stopping secondary CPUs [ 47.684439] Kernel Offset: disabled [ 47.688018] CPU features: 0x240402,20002008 [ 47.692318] Memory Limit: none [ 47.695465] ---[ end Kernel panic - not syncing: HYP panic: [ 47.695465] PS:a00003c9 PC:0000ca0b42049fc4 ESR:86000006 [ 47.695465] FAR:0000ca0b42049fc4 HPFAR:0000000010001000 PAR:0000000000000000 [ 47.695465] VCPU:0000000000000000 ]--- The instruction abort was caused by the code running at EL2 trying to fetch an instruction which wasn't mapped in the EL2 translation tables. Using objdump showed the two functions as separate symbols in the .text section. Fixes: 85738e0 ("arm64: kvm: Unmask PMR before entering guest") Cc: [email protected] Signed-off-by: Alexandru Elisei <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Acked-by: James Morse <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 704adfb upstream. The histogram logic was allowing events with char * pointers to be used as normal strings. But it was easy to crash the kernel with: # echo 'hist:keys=filename' > events/syscalls/sys_enter_openat/trigger And open some files, and boom! BUG: unable to handle page fault for address: 00007f2ced0c3280 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1173fa067 P4D 1173fa067 PUD 1171b6067 PMD 1171dd067 PTE 0 Oops: 0000 [Freescale#1] PREEMPT SMP CPU: 6 PID: 1810 Comm: cat Not tainted 5.13.0-rc5-test+ Freescale#61 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2a 0b a9 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2a 0b a9 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 RSP: 0018:ffffbdbf81567b50 EFLAGS: 00010246 RAX: 0000000000000003 RBX: ffff93815cdb3800 RCX: ffff9382401a22d0 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 00007f2ced0c3280 RBP: 0000000000000100 R08: ffff9382409ff074 R09: ffffbdbf81567c98 R10: ffff9382409ff074 R11: 0000000000000000 R12: ffff9382409ff074 R13: 0000000000000001 R14: ffff93815a744f00 R15: 00007f2ced0c3280 FS: 00007f2ced0f8580(0000) GS:ffff93825a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2ced0c3280 CR3: 0000000107069005 CR4: 00000000001706e0 Call Trace: event_hist_trigger+0x463/0x5f0 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? kernel_init_free_pages+0x6d/0x90 ? preempt_count_sub+0x9b/0xd0 ? kernel_init_free_pages+0x6d/0x90 ? get_page_from_freelist+0x12c4/0x1680 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 ftrace_syscall_enter+0x264/0x2c0 syscall_trace_enter.constprop.0+0x1ee/0x210 do_syscall_64+0x1c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Where it triggered a fault on strlen(key) where key was the filename. The reason is that filename is a char * to user space, and the histogram code just blindly dereferenced it, with obvious bad results. I originally tried to use strncpy_from_user/kernel_nofault() but found that there's other places that its dereferenced and not worth the effort. Just do not allow "char *" to act like strings. Link: https://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Cc: [email protected] Acked-by: Namhyung Kim <[email protected]> Acked-by: Tom Zanussi <[email protected]> Fixes: 79e577c ("tracing: Support string type key properly") Fixes: 5967bd5 ("tracing: Let filter_assign_type() detect FILTER_PTR_STRING") Signed-off-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…s test Kernel will dump randomly afer run about 650 times AP1302 resolution switching test. The reason is that ISI HW is filling buffer and user space call streamoff to stop streaming. After that, driver will do cleanup in stop_streaming. During this time, ISI interrupt triggered and change the buffer v4l2 state, then back to stop_streaming and continue to do cleanup, v4l2-core will do buffer state checking every time when driver try to release buffer to v4l2 core, so it leads to kernel dump as bellow. The solution is to add spin lock to make sure atomic cleanup operation without ISI interrupt. Got EOS from element "pipeline0"[ 8640.544083] ------------[ cut here ]------------ . Execution end[ 8640.549919] WARNING: CPU: 1 PID: 21556 at drivers/media/common/videobuf2/videobuf2-core.c:1960 __vb2_queue_cancel+0x1b0/0x21c ed after 0:00:02[ 8640.562588] Modules linked in: imx8_media_dev(C) .716028126 Setti[ 8640.568587] CPU: 1 PID: 21556 Comm: gst-launch-1.0 Tainted: G WC 5.15.52-03897-g7b0c32a97056-dirty #61 ng pipeline to NU[ 8640.580554] Hardware name: NXP i.MX93 11X11 EVK board (DT) LL ... [ 8640.587497] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8640.595131] pc : __vb2_queue_cancel+0x1b0/0x21c [ 8640.599646] lr : __vb2_queue_cancel+0x34/0x21c [ 8640.604075] sp : ffff80000b9c3b30 [ 8640.607377] x29: ffff80000b9c3b30 x28: ffff0000091b8700 x27: 0000000000000000 [ 8640.614501] x26: 0000000000000000 x25: ffff80000b9c3d28 x24: ffff00000494f828 [ 8640.621625] x23: ffff000008fda000 x22: 0000000000000009 x21: ffff00000494e7c0 [ 8640.628749] x20: 0000000000000009 x19: ffff00000494e7c0 x18: 0000000000000000 [ 8640.635873] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaafbda3510 [ 8640.642997] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 8640.650121] x11: 0000000000000000 x10: ffff80000b9c3970 x9 : ffff00006fbbf140 [ 8640.657245] x8 : fffffc0001c6e508 x7 : 0000000000000016 x6 : 0000000000000056 [ 8640.664369] x5 : ffff00000409e370 x4 : ffffffffffffffff x3 : ffffffffffffffff [ 8640.671493] x2 : 0000000000000000 x1 : ffff000008bdaa00 x0 : 00000000ffffffff [ 8640.678618] Call trace: [ 8640.681053] __vb2_queue_cancel+0x1b0/0x21c [ 8640.685229] vb2_core_streamoff+0x28/0xc0 [ 8640.689234] vb2_ioctl_streamoff+0x60/0xb0 [ 8640.693316] mxc_isi_cap_streamoff+0x4c/0x11c [ 8640.697666] v4l_streamoff+0x28/0x3c [ 8640.701237] __video_do_ioctl+0x178/0x3dc [ 8640.705232] video_usercopy+0x368/0x6ec [ 8640.709054] video_ioctl2+0x1c/0x30 [ 8640.712529] v4l2_ioctl+0x44/0x64 [ 8640.715832] __arm64_sys_ioctl+0xac/0xf0 [ 8640.719749] invoke_syscall+0x48/0x114 [ 8640.723493] el0_svc_common.constprop.0+0xd4/0xfc [ 8640.728181] do_el0_svc+0x2c/0x94 [ 8640.731484] el0_svc+0x28/0x80 [ 8640.734534] el0t_64_sync_handler+0xa8/0x130 [ 8640.738790] el0t_64_sync+0x1a0/0x1a4 [ 8640.742439] ---[ end trace d116e7f9ad624e8c ]--- [ 8640.748360] ------------[ cut here ]------------ Signed-off-by: Guoniu.zhou <[email protected]> Reviewed-by: Robby Cai <[email protected]>

commit 76d588d upstream. Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event. Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sys Below is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 Freescale#1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 Freescale#2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 Freescale#3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 Freescale#61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 Freescale#61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1 The above warning triggered because the current imc-pmu code uses mutex lock in interrupt disabled sections. The function mutex_lock() internally calls __might_resched(), which will check if IRQs are disabled and in case IRQs are disabled, it will trigger the warning. Fix the issue by changing the mutex lock to spinlock. Fixes: 8f95faa ("powerpc/powernv: Detect and create IMC device") Reported-by: Michael Petlan <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Kajol Jain <[email protected]> [mpe: Fix comments, trim oops in change log, add reported-by tags] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

wens and others added 30 commits January 27, 2020 14:46

madalinbucur and others added 20 commits February 5, 2020 14:18

Linux 4.14.170

e0f8b8a

MLK-23286: arm64: dts: add ov5640 dts support for i.MX8DX MEK

07ff321

Add ov5640 dts support for i.MX8DX MEK board Signed-off-by: Guoniu.zhou <[email protected]>

MLK-23288 dts: arm64: imx8dx-mek: add tja1100 card support for enet2 …

b41e649

…port Add tja1100 card support for enet2 port. Reviewed-by: Ye Li <[email protected]> Signed-off-by: Fugang Duan <[email protected]>

arch: arm64: dts: 8dx: Add dts file for dsi panel use-case

8d1f5c6

Create the fsl-imx8dx-mek-dsi-rm67191.dts in order to add support for the MIPI-DSI panel usecase with the Raydium RM67191 DSI panel. Signed-off-by: Robert Chiras <[email protected]> Reviewed-by: Fugang Duan <[email protected]>

Merge tag 'rel_imx_4.14.98_2.3.1_patch' into 4.14-2.3.x-imx

b16d3d6

Merge tag 'v4.14.170' into 4.14-2.3.x-imx

f2c1392

This is the 4.14.170 stable release Conflicts: drivers/net/phy/phy_device.c drivers/tty/serial/imx.c include/linux/platform_data/dma-imx-sdma.h net/wireless/util.c

otavio merged commit cd7c926 into Freescale:4.14-2.3.x-imx Mar 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

4.14 2.3.x imx: net: sch_generic compilation fix, rel_imx_4.14.98_2.3.1_patch and v4.14.170 stable #61

4.14 2.3.x imx: net: sch_generic compilation fix, rel_imx_4.14.98_2.3.1_patch and v4.14.170 stable #61

Uh oh!

ziswiler commented Mar 8, 2020

Uh oh!

Uh oh!

4.14 2.3.x imx: net: sch_generic compilation fix, rel_imx_4.14.98_2.3.1_patch and v4.14.170 stable #61

4.14 2.3.x imx: net: sch_generic compilation fix, rel_imx_4.14.98_2.3.1_patch and v4.14.170 stable #61

Uh oh!

Conversation

ziswiler commented Mar 8, 2020

Uh oh!

Uh oh!