summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-11-17arm64: dts: apalis/colibri-imx8qxp: use pmic sensor nameOleksandr Suvorov
Use the predefined resource name of the PMIC thermal sensor. Related-to: ELB-3037 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-17Merge branch 'toradex_5.4-2.1.x-imx' into HEADIgor Opaniuk
2020-11-13net: wireless: cfg80211: delete sched_scan error messagePhilippe Schenker
Do not print an error. This is no error in our use-case so just delete this error message that confuses users. As we now move back to full loglevel this is the only way to get rid of that message. fixes: d182137f18f24de3bc4b45c5a3d52e2f8f96a093 net: wireless: cfg80211: decrease importance of sched_scan message Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-11-13Revert "ARM/ARM64: apalis/colibri defconfigs: decrease default console loglevel"Philippe Schenker
This reverts commit 2c7781c5d5d0b0c8b4c67f945fdf7e8992fb36b5. We decided to go back to full loglevel so customers can see all messages on boot. Related-to: ELB-3183 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-11-13Merge commit '70d1232fdbe28e4c765c4cfc3cc5c7580959d5e0' into ↵Igor Opaniuk
toradex_5.4-2.1.x-imx Update 5.4-2.1.x-imx to v5.4.74 from [1]. [1] https://github.com/Freescale/linux-fslc
2020-11-11MLK-24521: drm: bridge: hdmi: Prevent the driver from rejecting VIC 0 modesOliver F. Brown
iMX8QM can support the non CEA modes, iMX8M cannot support non CEA modes. So driver should allow non CEA modes for iMX8QM. Signed-off-by: Oliver F. Brown <oliver.brown@nxp.com> Reviewed-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 863af2196cb53200f50b1d04c6eb90d04262b0e4) Related-to: ELB-3237 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-11-10arm64: dts: apalis-imx8: enable vpu mailboxesMax Krummenacher
The VPU subsystem uses hardware Messaging Units (MU) for inter processor communication with the controlling OS. The driver for the MU is implemented as a Linux mailbox. Enable the VPU MU in the device-tree. Related-to: ELB-3196 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-11-10ARM: dts: apalis-imx6: move atmel mxt ts to overlayOleksandr Suvorov
The touchscreen Atmel MXT TS is integrated to display panels. Remove its definition from the main device trees. Also release pingroups used in atmel mxt ts overlay from iomuxc driver. Related-to: ELB-2943 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-09arm64: dts: apalis-imx8p: initial device treeOleksandr Suvorov
Fork and tune the device trees to support iMXQP SoC on modules Apalis-iMX8QP. Related-to: ELB-3036 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-09arm64: dts: apalis-imx8: remove duplicate compatible entriesOleksandr Suvorov
Removed the duplicate "toradex,apalis-imx8" entries in "compatible" strings set. Related-to: ELB-3036 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-09arm64: dts: apalis-imx8: fix model stringOleksandr Suvorov
Remove iMX8QP variant from the model string as it takes its own device tree files. Related-to: ELB-3036 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-09arm64: dts: apalis-imx8: separate common module partOleksandr Suvorov
Apalis iMX8QM and iMX8QP are almost the same. Separate the common part of device tree to use it for both these modules. Related-to: ELB-3036 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-09arm64: dts: apalis-imx8: rename ixora board device treeOleksandr Suvorov
The device tree of Apalis Ixora v1.1 board is common for both Apalis iMX8QM and Apalis iMX8QP modules. Rename the device tree to further use it for both modules. Related-to: ELB-3036 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-09arm64: dts: apalis-imx8: rename Eval board device treeOleksandr Suvorov
The device tree of Apalis Evaluation board is common for both Apalis iMX8QM and Apalis iMX8QP modules. Rename the device tree to further use it for both modules. Related-to: ELB-3036 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-06rtc: ds1307: enable rx8130's backup battery, make it chargeable optionallyBastian Krause
The ds1307 charger infrastructure now allows to add a rx8130 charger setup that.. - does not depend on trickle-resistor-ohms - does not use DS13XX_TRICKLE_CHARGER_MAGIC trickle-charge select (TCS) bits - keeps previous no-charge behavior for device trees without aux-voltage-chargeable Make that happen. Signed-off-by: Bastian Krause <bst@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200917183246.19446-9-bst@pengutronix.de (cherry picked from commit 0026f1604c9ba1ae8108d4977da0366c283552bc) Related-to: ELB-3226 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-11-06rtc: ds1307: consider aux-voltage-chargeableBastian Krause
Prefer aux-voltage-chargeable over trickle-diode-disable and set diode accordingly. This is then passed to the chip's appropriate charge setup function. Signed-off-by: Bastian Krause <bst@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200917183246.19446-8-bst@pengutronix.de (cherry picked from commit 0874734e09af5cc05439dbe2c8ff704f14d679f5)
2020-11-06rtc: ds1307: store previous charge default per chipBastian Krause
Some RTC's batteries and supercaps were charged by default until now. In contrast other RTCs allow charging but the driver did not configure them to do so until now. These must not be charged by default to stay backwards compatible. In order to do that, store the charge default per chip. Signed-off-by: Bastian Krause <bst@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200917183246.19446-7-bst@pengutronix.de (cherry picked from commit 95a74cbb21a2431dd2fd8918fa26113629b6e13e)
2020-11-06rtc: ds1307: introduce requires_trickle_resistor per chipBastian Krause
Make trickle-resistor-ohms optional for charging setups that do not require specifying ROUT bits (specifying the resistor value between Vcc and Vbackup). In order to allow specifying that, introduce requires_trickle_resistor per chip. Signed-off-by: Bastian Krause <bst@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200917183246.19446-6-bst@pengutronix.de (cherry picked from commit 1b5b6af788ae59ee73e3f3230dbfa4f0e31d8d18)
2020-11-06rtc: ds1307: apply DS13XX_TRICKLE_CHARGER_MAGIC only conditionallyBastian Krause
DS13XX_TRICKLE_CHARGER_MAGIC sets the trickle-charge select (TCS) bits (7..4). The datasheet of Maxim Integrated's DS1339 [1] for instance reads: "To prevent accidental enabling, only a pattern on 1010 enables the trickle charger. All other patterns disable the trickle charger." Since not all RTCs connected to a backup battery or supercap use these bits DS13XX_TRICKLE_CHARGER_MAGIC should not get applied for all charger setups unconditionally. Epson's RX8130 is such an example: Instead of TCS bits "SMPTSEL1", "SMPTSEL0", "CHGEN" and "INIEN" are expected as bit 7..4. DS1339 and DS1340 are currently the only RTCs in the ds1307 driver that apply DS13XX_TRICKLE_CHARGER_MAGIC to their setup register value. So apply DS13XX_TRICKLE_CHARGER_MAGIC in do_trickle_setup_ds1339() which is used by both RTCs. [1] https://datasheets.maximintegrated.com/en/ds/DS1339-DS1339U.pdf [2] https://support.epson.biz/td/api/doc_check.php?dl=app_RX8130CE Signed-off-by: Bastian Krause <bst@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200917183246.19446-5-bst@pengutronix.de (cherry picked from commit 462eb736db3db76899022e4e4db788a7b6efbe09)
2020-11-06ARM64: dts: apalis-imx8x: add workaround for pcie problemPhilippe Schenker
Currently the PCIe switch on the eval-board is not working. As the carrier-board reset is controlled by the PCIe driver this reset never gets deasserted. This is a workaround until PCIe works properly. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-11-06arm64: dts: apalis-imx8: fec: add fsl,mii-exclusiveMax Krummenacher
When fsl,mii-exclusive is not specified the driver only uses the MII bus of the fec device with dev_id=0 for both fec1 and fec2. On the Apalis iMX8 hardware design a potential second PHY is connected to the second MAC's MII bus. This property is needed to select the MDIO bus coupled with fec2, if fec2 is used. We put it in fec1 for customers so they automatically inherit this property if they placed a PHY on their carrier-board and copied the fec1 node. Compare with commit 9801f2e913a2 ("net: fec: reinit MAC0 MII bus to be used by MAC1 after resume back") Related-to: ELB-3177 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-11-04ARM64: dts: apalis-imx8: disable dma for lpuart2Philippe Schenker
lpuart2 is the only UART where DMA request works and linux tries to use a DMA. However this DMA does not work and output hangs, disbling the DMA works for now. Related-to: ELB-3178 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-11-03drivers: spi-fsl-lpspi: Update driver from L5.4.47-2.2.0Philippe Schenker
This patch just copies the driver from the new NXP release. It solves multiple problems that existed with that driver Related-to: ELB-3181 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-11-01Merge pull request #163 from zandrey/5.4-2.1.x-imxOtavio Salvador
Update 5.4-2.1.x-imx to v5.4.74 from stable
2020-11-01Merge tag 'v5.4.74' into 5.4-2.1.x-imxAndrey Zhizhikin
This is the 5.4.74 stable release Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2020-11-01Linux 5.4.74Greg Kroah-Hartman
Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/CA+G9fYtw23F_PuCjiyVXz4464PsjcTSsL1jgvPP6D9xoZWZU7A@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01phy: marvell: comphy: Convert internal SMCC firmware return codes to errnoPali Rohár
commit ea17a0f153af2cd890e4ce517130dcccaa428c13 upstream. Driver ->power_on and ->power_off callbacks leaks internal SMCC firmware return codes to phy caller. This patch converts SMCC error codes to standard linux errno codes. Include file linux/arm-smccc.h already provides defines for SMCC error codes, so use them instead of custom driver defines. Note that return value is signed 32bit, but stored in unsigned long type with zero padding. Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Link: https://lore.kernel.org/r/20200902144344.16684-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01misc: rtsx: do not setting OC_POWER_DOWN reg in rtsx_pci_init_ocp()Ricky Wu
commit 551b6729578a8981c46af964c10bf7d5d9ddca83 upstream. this power saving action in rtsx_pci_init_ocp() cause INTEL-NUC6 platform missing card reader Signed-off-by: Ricky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/20200824030006.30033-1-ricky_wu@realtek.com Cc: Chris Clayton <chris2553@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01openrisc: Fix issue with get_user for 64-bit valuesStafford Horne
commit d877322bc1adcab9850732275670409e8bcca4c4 upstream. A build failure was raised by kbuild with the following error. drivers/android/binder.c: Assembler messages: drivers/android/binder.c:3861: Error: unrecognized keyword/register name `l.lwz ?ap,4(r24)' drivers/android/binder.c:3866: Error: unrecognized keyword/register name `l.addi ?ap,r0,0' The issue is with 64-bit get_user() calls on openrisc. I traced this to a problem where in the internally in the get_user macros there is a cast to long __gu_val this causes GCC to think the get_user call is 32-bit. This binder code is really long and GCC allocates register r30, which triggers the issue. The 64-bit get_user asm tries to get the 64-bit pair register, which for r30 overflows the general register names and returns the dummy register ?ap. The fix here is to move the temporary variables into the asm macros. We use a 32-bit __gu_tmp for 32-bit and smaller macro and a 64-bit tmp in the 64-bit macro. The cast in the 64-bit macro has a trick of casting through __typeof__((x)-(x)) which avoids the below warning. This was barrowed from riscv. arch/openrisc/include/asm/uaccess.h:240:8: warning: cast to pointer from integer of different size I tested this in a small unit test to check reading between 64-bit and 32-bit pointers to 64-bit and 32-bit values in all combinations. Also I ran make C=1 to confirm no new sparse warnings came up. It all looks clean to me. Link: https://lore.kernel.org/lkml/202008200453.ohnhqkjQ%25lkp@intel.com/ Signed-off-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01crypto: x86/crc32c - fix building with clang iasArnd Bergmann
commit 44623b2818f4a442726639572f44fd9b6d0ef68c upstream. The clang integrated assembler complains about movzxw: arch/x86/crypto/crc32c-pcl-intel-asm_64.S:173:2: error: invalid instruction mnemonic 'movzxw' It seems that movzwq is the mnemonic that it expects instead, and this is what objdump prints when disassembling the file. Fixes: 6a8ce1ef3940 ("crypto: crc32c - Optimize CRC32C calculation with PCLMULQDQ instruction") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> [jc: Fixed conflicts due to lack of 34fdce6981b9 ("x86: Change {JMP,CALL}_NOSPEC argument")] Signed-off-by: Jian Cai <jiancai@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01xen/gntdev.c: Mark pages as dirtySouptick Joarder
commit 779055842da5b2e508f3ccf9a8153cb1f704f566 upstream. There seems to be a bug in the original code when gntdev_get_page() is called with writeable=true then the page needs to be marked dirty before being put. To address this, a bool writeable is added in gnt_dev_copy_batch, set it in gntdev_grant_copy_seg() (and drop `writeable` argument to gntdev_get_page()) and then, based on batch->writeable, use set_page_dirty_lock(). Fixes: a4cdb556cae0 (xen/gntdev: add ioctl for grant copy) Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1599375114-32360-1-git-send-email-jrdr.linux@gmail.com Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01ata: sata_rcar: Fix DMA boundary maskGeert Uytterhoeven
commit df9c590986fdb6db9d5636d6cd93bc919c01b451 upstream. Before commit 9495b7e92f716ab2 ("driver core: platform: Initialize dma_parms for platform devices"), the R-Car SATA device didn't have DMA parameters. Hence the DMA boundary mask supplied by its driver was silently ignored, as __scsi_init_queue() doesn't check the return value of dma_set_seg_boundary(), and the default value of 0xffffffff was used. Now the device has gained DMA parameters, the driver-supplied value is used, and the following warning is printed on Salvator-XS: DMA-API: sata_rcar ee300000.sata: mapping sg segment across boundary [start=0x00000000ffffe000] [end=0x00000000ffffefff] [boundary=0x000000001ffffffe] WARNING: CPU: 5 PID: 38 at kernel/dma/debug.c:1233 debug_dma_map_sg+0x298/0x300 (the range of start/end values depend on whether IOMMU support is enabled or not) The issue here is that SATA_RCAR_DMA_BOUNDARY doesn't have bit 0 set, so any typical end value, which is odd, will trigger the check. Fix this by increasing the DMA boundary value by 1. This also fixes the following WRITE DMA EXT timeout issue: # dd if=/dev/urandom of=/mnt/de1/file1-1024M bs=1M count=1024 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen ata1.00: failed command: WRITE DMA EXT ata1.00: cmd 35/00:00:00:e6:0c/00:0a:00:00:00/e0 tag 0 dma 1310720 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1.00: status: { DRDY } as seen by Shimoda-san since commit 429120f3df2dba2b ("block: fix splitting segments on boundary masks"). Fixes: 8bfbeed58665dbbf ("sata_rcar: correct 'sata_rcar_sht'") Fixes: 9495b7e92f716ab2 ("driver core: platform: Initialize dma_parms for platform devices") Fixes: 429120f3df2dba2b ("block: fix splitting segments on boundary masks") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01PM: runtime: Fix timer_expires data type on 32-bit archesGrygorii Strashko
commit 6b61d49a55796dbbc479eeb4465e59fd656c719c upstream. Commit 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") switched PM runtime autosuspend to use hrtimers and all related time accounting in ns, but missed to update the timer_expires data type in struct dev_pm_info to u64. This causes the timer_expires value to be truncated on 32-bit architectures when assignment is done from u64 values: rpm_suspend() |- dev->power.timer_expires = expires; Fix it by changing the timer_expires type to u64. Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Vincent Guittot <vincent.guittot@linaro.org> Cc: 5.0+ <stable@vger.kernel.org> # 5.0+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01serial: pl011: Fix lockdep splat when handling magic-sysrq interruptPeter Zijlstra
commit 534cf755d9df99e214ddbe26b91cd4d81d2603e2 upstream. Issuing a magic-sysrq via the PL011 causes the following lockdep splat, which is easily reproducible under QEMU: | sysrq: Changing Loglevel | sysrq: Loglevel set to 9 | | ====================================================== | WARNING: possible circular locking dependency detected | 5.9.0-rc7 #1 Not tainted | ------------------------------------------------------ | systemd-journal/138 is trying to acquire lock: | ffffab133ad950c0 (console_owner){-.-.}-{0:0}, at: console_lock_spinning_enable+0x34/0x70 | | but task is already holding lock: | ffff0001fd47b098 (&port_lock_key){-.-.}-{2:2}, at: pl011_int+0x40/0x488 | | which lock already depends on the new lock. [...] | Possible unsafe locking scenario: | | CPU0 CPU1 | ---- ---- | lock(&port_lock_key); | lock(console_owner); | lock(&port_lock_key); | lock(console_owner); | | *** DEADLOCK *** The issue being that CPU0 takes 'port_lock' on the irq path in pl011_int() before taking 'console_owner' on the printk() path, whereas CPU1 takes the two locks in the opposite order on the printk() path due to setting the "console_owner" prior to calling into into the actual console driver. Fix this in the same way as the msm-serial driver by dropping 'port_lock' before handling the sysrq. Cc: <stable@vger.kernel.org> # 4.19+ Cc: Russell King <linux@armlinux.org.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20200811101313.GA6970@willie-the-truck Signed-off-by: Peter Zijlstra <peterz@infradead.org> Tested-by: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200930120432.16551-1-will@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01serial: qcom_geni_serial: To correct QUP Version detection logicParas Sharma
commit c9ca43d42ed8d5fd635d327a664ed1d8579eb2af upstream. For QUP IP versions 2.5 and above the oversampling rate is halved from 32 to 16. Commit ce734600545f ("tty: serial: qcom_geni_serial: Update the oversampling rate") is pushed to handle this scenario. But the existing logic is failing to classify QUP Version 3.0 into the correct group ( 2.5 and above). As result Serial Engine clocks are not configured properly for baud rate and garbage data is sampled to FIFOs from the line. So, fix the logic to detect QUP with versions 2.5 and above. Fixes: ce734600545f ("tty: serial: qcom_geni_serial: Update the oversampling rate") Cc: stable <stable@vger.kernel.org> Signed-off-by: Paras Sharma <parashar@codeaurora.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Link: https://lore.kernel.org/r/1601445926-23673-1-git-send-email-parashar@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01mtd: lpddr: Fix bad logic in print_drs_errorGustavo A. R. Silva
commit 1c9c02bb22684f6949d2e7ddc0a3ff364fd5a6fc upstream. Update logic for broken test. Use a more common logging style. It appears the logic in this function is broken for the consecutive tests of if (prog_status & 0x3) ... else if (prog_status & 0x2) ... else (prog_status & 0x1) ... Likely the first test should be if ((prog_status & 0x3) == 0x3) Found by inspection of include files using printk. Fixes: eb3db27507f7 ("[MTD] LPDDR PFOW definition") Cc: stable@vger.kernel.org Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/3fb0e29f5b601db8be2938a01d974b00c8788501.1588016644.git.gustavo@embeddedor.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01RDMA/addr: Fix race with netevent_callback()/rdma_addr_cancel()Jason Gunthorpe
commit 2ee9bf346fbfd1dad0933b9eb3a4c2c0979b633e upstream. This three thread race can result in the work being run once the callback becomes NULL: CPU1 CPU2 CPU3 netevent_callback() process_one_req() rdma_addr_cancel() [..] spin_lock_bh() set_timeout() spin_unlock_bh() spin_lock_bh() list_del_init(&req->list); spin_unlock_bh() req->callback = NULL spin_lock_bh() if (!list_empty(&req->list)) // Skipped! // cancel_delayed_work(&req->work); spin_unlock_bh() process_one_req() // again req->callback() // BOOM cancel_delayed_work_sync() The solution is to always cancel the work once it is completed so any in between set_timeout() does not result in it running again. Cc: stable@vger.kernel.org Fixes: 44e75052bc2a ("RDMA/rdma_cm: Make rdma_addr_cancel into a fence") Link: https://lore.kernel.org/r/20200930072007.1009692-1-leon@kernel.org Reported-by: Dan Aloni <dan@kernelim.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01cxl: Rework error message for incompatible slotsFrederic Barrat
commit 40ac790d99c6dd16b367d5c2339e446a5f1b0593 upstream. Improve the error message shown if a capi adapter is plugged on a capi-incompatible slot directly under the PHB (no intermediate switch). Fixes: 5632874311db ("cxl: Add support for POWER9 DD2") Cc: stable@vger.kernel.org # 4.14+ Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200407115601.25453-1-fbarrat@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01p54: avoid accessing the data mapped to streaming DMAJia-Ju Bai
commit 478762855b5ae9f68fa6ead1edf7abada70fcd5f upstream. In p54p_tx(), skb->data is mapped to streaming DMA on line 337: mapping = pci_map_single(..., skb->data, ...); Then skb->data is accessed on line 349: desc->device_addr = ((struct p54_hdr *)skb->data)->req_id; This access may cause data inconsistency between CPU cache and hardware. To fix this problem, ((struct p54_hdr *)skb->data)->req_id is stored in a local variable before DMA mapping, and then the driver accesses this local variable instead of skb->data. Cc: <stable@vger.kernel.org> Signed-off-by: Jia-Ju Bai <baijiaju@tsinghua.edu.cn> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802132949.26788-1-baijiaju@tsinghua.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01evm: Check size of security.evm before using itRoberto Sassu
commit 455b6c9112eff8d249e32ba165742085678a80a4 upstream. This patch checks the size for the EVM_IMA_XATTR_DIGSIG and EVM_XATTR_PORTABLE_DIGSIG types to ensure that the algorithm is read from the buffer returned by vfs_getxattr_alloc(). Cc: stable@vger.kernel.org # 4.19.x Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01bpf: Fix comment for helper bpf_current_task_under_cgroup()Song Liu
commit 1aef5b4391f0c75c0a1523706a7b0311846ee12f upstream. This should be "current" not "skb". Fixes: c6b5fb8690fa ("bpf: add documentation for eBPF helpers (42-50)") Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/bpf/20200910203314.70018-1-songliubraving@fb.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01fuse: fix page dereference after freeMiklos Szeredi
commit d78092e4937de9ce55edcb4ee4c5e3c707be0190 upstream. After unlock_request() pages from the ap->pages[] array may be put (e.g. by aborting the connection) and the pages can be freed. Prevent use after free by grabbing a reference to the page before calling unlock_request(). The original patch was created by Pradeep P V K. Reported-by: Pradeep P V K <ppvk@codeaurora.org> Cc: <stable@vger.kernel.org> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01ata: ahci: mvebu: Make SATA PHY optional for Armada 3720Pali Rohár
commit 45aefe3d2251e4e229d7662052739f96ad1d08d9 upstream. Older ATF does not provide SMC call for SATA phy power on functionality and therefore initialization of ahci_mvebu is failing when older version of ATF is using. In this case phy_power_on() function returns -EOPNOTSUPP. This patch adds a new hflag AHCI_HFLAG_IGN_NOTSUPP_POWER_ON which cause that ahci_platform_enable_phys() would ignore -EOPNOTSUPP errors from phy_power_on() call. It fixes initialization of ahci_mvebu on Espressobin boards where is older Marvell's Arm Trusted Firmware without SMC call for SATA phy power. This is regression introduced in commit 8e18c8e58da64 ("arm64: dts: marvell: armada-3720-espressobin: declare SATA PHY property") where SATA phy was defined and therefore ahci_platform_enable_phys() on Espressobin started failing. Fixes: 8e18c8e58da64 ("arm64: dts: marvell: armada-3720-espressobin: declare SATA PHY property") Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Cc: <stable@vger.kernel.org> # 5.1+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01x86/xen: disable Firmware First mode for correctable memory errorsJuergen Gross
commit d759af38572f97321112a0852353613d18126038 upstream. When running as Xen dom0 the kernel isn't responsible for selecting the error handling mode, this should be handled by the hypervisor. So disable setting FF mode when running as Xen pv guest. Not doing so might result in boot splats like: [ 7.509696] HEST: Enabling Firmware First mode for corrected errors. [ 7.510382] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 2. [ 7.510383] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 3. [ 7.510384] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 4. [ 7.510384] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 5. [ 7.510385] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 6. [ 7.510386] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 7. [ 7.510386] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 8. Reason is that the HEST ACPI table contains the real number of MCA banks, while the hypervisor is emulating only 2 banks for guests. Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20200925140751.31381-1-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01arch/x86/amd/ibs: Fix re-arming IBS FetchKim Phillips
commit 221bfce5ebbdf72ff08b3bf2510ae81058ee568b upstream. Stephane Eranian found a bug in that IBS' current Fetch counter was not being reset when the driver would write the new value to clear it along with the enable bit set, and found that adding an MSR write that would first disable IBS Fetch would make IBS Fetch reset its current count. Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12, 2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when IbsFetchEn is changed from 0 to 1." Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch, so the driver properly resets the internal counter to 0 and IBS Fetch starts counting again. A family 15h machine tested does not have this problem, and the extra wrmsr is also not needed on Family 19h, so only do the extra wrmsr on families 16h through 18h. Reported-by: Stephane Eranian <stephane.eranian@google.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> [peterz: optimized] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01erofs: avoid duplicated permission check for "trusted." xattrsGao Xiang
commit d578b46db69d125a654f509bdc9091d84e924dc8 upstream. Don't recheck it since xattr_permission() already checks CAP_SYS_ADMIN capability. Just follow 5d3ce4f70172 ("f2fs: avoid duplicated permission check for "trusted." xattrs") Reported-by: Hongyu Jin <hongyu.jin@unisoc.com> [ Gao Xiang: since it could cause some complex Android overlay permission issue as well on android-5.4+, it'd be better to backport to 5.4+ rather than pure cleanup on mainline. ] Cc: <stable@vger.kernel.org> # 5.4+ Link: https://lore.kernel.org/r/20200811070020.6339-1-hsiangkao@redhat.com Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01bnxt_en: Invoke cancel_delayed_work_sync() for PFs also.Vasundhara Volam
[ Upstream commit 631ce27a3006fc0b732bfd589c6df505f62eadd9 ] As part of the commit b148bb238c02 ("bnxt_en: Fix possible crash in bnxt_fw_reset_task()."), cancel_delayed_work_sync() is called only for VFs to fix a possible crash by cancelling any pending delayed work items. It was assumed by mistake that the flush_workqueue() call on the PF would flush delayed work items as well. As flush_workqueue() does not cancel the delayed workqueue, extend the fix for PFs. This fix will avoid the system crash, if there are any pending delayed work items in fw_reset_task() during driver's .remove() call. Unify the workqueue cleanup logic for both PF and VF by calling cancel_work_sync() and cancel_delayed_work_sync() directly in bnxt_remove_one(). Fixes: b148bb238c02 ("bnxt_en: Fix possible crash in bnxt_fw_reset_task().") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01bnxt_en: Fix regression in workqueue cleanup logic in bnxt_remove_one().Vasundhara Volam
[ Upstream commit 21d6a11e2cadfb8446265a3efff0e2aad206e15e ] A recent patch has moved the workqueue cleanup logic before calling unregister_netdev() in bnxt_remove_one(). This caused a regression because the workqueue can be restarted if the device is still open. Workqueue cleanup must be done after unregister_netdev(). The workqueue will not restart itself after the device is closed. Call bnxt_cancel_sp_work() after unregister_netdev() and call bnxt_dl_fw_reporters_destroy() after that. This fixes the regession and the original NULL ptr dereference issue. Fixes: b16939b59cc0 ("bnxt_en: Fix NULL ptr dereference crash in bnxt_fw_reset_task()") Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01bnxt_en: Re-write PCI BARs after PCI fatal error.Vasundhara Volam
[ Upstream commit f75d9a0aa96721d20011cd5f8c7a24eb32728589 ] When a PCIe fatal error occurs, the internal latched BAR addresses in the chip get reset even though the BAR register values in config space are retained. pci_restore_state() will not rewrite the BAR addresses if the BAR address values are valid, causing the chip's internal BAR addresses to stay invalid. So we need to zero the BAR registers during PCIe fatal error to force pci_restore_state() to restore the BAR addresses. These write cycles to the BAR registers will cause the proper BAR addresses to latch internally. Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.") Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-01net: hns3: Clear the CMDQ registers before unmapping BAR regionZenghui Yu
[ Upstream commit e3364c5ff3ff975b943a7bf47e21a2a4bf20f3fe ] When unbinding the hns3 driver with the HNS3 VF, I got the following kernel panic: [ 265.709989] Unable to handle kernel paging request at virtual address ffff800054627000 [ 265.717928] Mem abort info: [ 265.720740] ESR = 0x96000047 [ 265.723810] EC = 0x25: DABT (current EL), IL = 32 bits [ 265.729126] SET = 0, FnV = 0 [ 265.732195] EA = 0, S1PTW = 0 [ 265.735351] Data abort info: [ 265.738227] ISV = 0, ISS = 0x00000047 [ 265.742071] CM = 0, WnR = 1 [ 265.745055] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000009b54000 [ 265.751753] [ffff800054627000] pgd=0000202ffffff003, p4d=0000202ffffff003, pud=00002020020eb003, pmd=00000020a0dfc003, pte=0000000000000000 [ 265.764314] Internal error: Oops: 96000047 [#1] SMP [ 265.830357] CPU: 61 PID: 20319 Comm: bash Not tainted 5.9.0+ #206 [ 265.836423] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019 [ 265.843873] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 265.843890] pc : hclgevf_cmd_uninit+0xbc/0x300 [ 265.861988] lr : hclgevf_cmd_uninit+0xb0/0x300 [ 265.861992] sp : ffff80004c983b50 [ 265.881411] pmr_save: 000000e0 [ 265.884453] x29: ffff80004c983b50 x28: ffff20280bbce500 [ 265.889744] x27: 0000000000000000 x26: 0000000000000000 [ 265.895034] x25: ffff800011a1f000 x24: ffff800011a1fe90 [ 265.900325] x23: ffff0020ce9b00d8 x22: ffff0020ce9b0150 [ 265.905616] x21: ffff800010d70e90 x20: ffff800010d70e90 [ 265.910906] x19: ffff0020ce9b0080 x18: 0000000000000004 [ 265.916198] x17: 0000000000000000 x16: ffff800011ae32e8 [ 265.916201] x15: 0000000000000028 x14: 0000000000000002 [ 265.916204] x13: ffff800011ae32e8 x12: 0000000000012ad8 [ 265.946619] x11: ffff80004c983b50 x10: 0000000000000000 [ 265.951911] x9 : ffff8000115d0888 x8 : 0000000000000000 [ 265.951914] x7 : ffff800011890b20 x6 : c0000000ffff7fff [ 265.951917] x5 : ffff80004c983930 x4 : 0000000000000001 [ 265.951919] x3 : ffffa027eec1b000 x2 : 2b78ccbbff369100 [ 265.964487] x1 : 0000000000000000 x0 : ffff800054627000 [ 265.964491] Call trace: [ 265.964494] hclgevf_cmd_uninit+0xbc/0x300 [ 265.964496] hclgevf_uninit_ae_dev+0x9c/0xe8 [ 265.964501] hnae3_unregister_ae_dev+0xb0/0x130 [ 265.964516] hns3_remove+0x34/0x88 [hns3] [ 266.009683] pci_device_remove+0x48/0xf0 [ 266.009692] device_release_driver_internal+0x114/0x1e8 [ 266.030058] device_driver_detach+0x28/0x38 [ 266.034224] unbind_store+0xd4/0x108 [ 266.037784] drv_attr_store+0x40/0x58 [ 266.041435] sysfs_kf_write+0x54/0x80 [ 266.045081] kernfs_fop_write+0x12c/0x250 [ 266.049076] vfs_write+0xc4/0x248 [ 266.052378] ksys_write+0x74/0xf8 [ 266.055677] __arm64_sys_write+0x24/0x30 [ 266.059584] el0_svc_common.constprop.3+0x84/0x270 [ 266.064354] do_el0_svc+0x34/0xa0 [ 266.067658] el0_svc+0x38/0x40 [ 266.070700] el0_sync_handler+0x8c/0xb0 [ 266.074519] el0_sync+0x140/0x180 It looks like the BAR memory region had already been unmapped before we start clearing CMDQ registers in it, which is pretty bad and the kernel happily kills itself because of a Current EL Data Abort (on arm64). Moving the CMDQ uninitialization a bit early fixes the issue for me. Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF doing FLR") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20201023051550.793-1-yuzenghui@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-03 04:43:06 +0000