summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-09-25dma-mapping: add a new dma_alloc_pages APIChristoph Hellwig10-5/+24
This API is the equivalent of alloc_pages, except that the returned memory is guaranteed to be DMA addressable by the passed in device. The implementation will also be used to provide a more sensible replacement for DMA_ATTR_NON_CONSISTENT flag. Additionally dma_alloc_noncoherent is switched over to use dma_alloc_pages as its backend. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> (MIPS part)
2020-09-25dma-mapping: remove dma_cache_syncChristoph Hellwig5-15/+0
All users are gone now, remove the API. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> (MIPS part)
2020-09-25Merge branch 'master' of ↵Christoph Hellwig120-387/+719
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into dma-mapping-for-next Pull in the latest 5.9 tree for the commit to revert the V4L2_FLAG_MEMORY_NON_CONSISTENT uapi addition.
2020-09-25ARM/omap1: switch to use dma_direct_set_offset for lbus DMA offsetsChristoph Hellwig3-49/+22
Switch the omap1510 platform ohci device to use dma_direct_set_offset to set the DMA offset instead of using direct hooks into the DMA mapping code and remove the now unused hooks. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Tony Lindgren <tony@atomide.com>
2020-09-24KVM: x86: fix MSR_IA32_TSC read for nested migrationMaxim Levitsky1-2/+15
MSR reads/writes should always access the L1 state, since the (nested) hypervisor should intercept all the msrs it wants to adjust, and these that it doesn't should be read by the guest as if the host had read it. However IA32_TSC is an exception. Even when not intercepted, guest still reads the value + TSC offset. The write however does not take any TSC offset into account. This is documented in Intel's SDM and seems also to happen on AMD as well. This creates a problem when userspace wants to read the IA32_TSC value and then write it. (e.g for migration) In this case it reads L2 value but write is interpreted as an L1 value. To fix this make the userspace initiated reads of IA32_TSC return L1 value as well. Huge thanks to Dave Gilbert for helping me understand this very confusing semantic of MSR writes. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20200921103805.9102-2-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-24kbuild: remove cc-option test of -Werror=date-timeMasahiro Yamada1-1/+1
The minimal compiler versions, GCC 4.9 and Clang 10 support this flag. Here is the godbolt: https://godbolt.org/z/xvjcMa Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Will Deacon <will@kernel.org>
2020-09-24kbuild: remove cc-option test of -fno-strict-overflowMasahiro Yamada1-1/+1
The minimal compiler versions, GCC 4.9 and Clang 10 support this flag. Here is the godbolt: https://godbolt.org/z/odq8h9 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Will Deacon <will@kernel.org>
2020-09-24kbuild: preprocess module linker scriptMasahiro Yamada13-15/+7
There was a request to preprocess the module linker script like we do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512) The difference between vmlinux.lds and module.lds is that the latter is needed for external module builds, thus must be cleaned up by 'make mrproper' instead of 'make clean'. Also, it must be created by 'make modules_prepare'. You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by 'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to arch/$(SRCARCH)/include/asm/module.lds.h, which is included from scripts/module.lds.S. scripts/module.lds is fine because 'make clean' keeps all the build artifacts under scripts/. You can add arch-specific sections in <asm/module.lds.h>. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Jessica Yu <jeyu@kernel.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Jessica Yu <jeyu@kernel.org>
2020-09-24perf/x86/intel/uncore: Support PCIe3 unit on Snow RidgeKan Liang1-0/+53
The Snow Ridge integrated PCIe3 uncore unit can be used to collect performance data, e.g. utilization, between PCIe devices, plugged into the PCIe port, and the components (in M2IOSF) responsible for translating and managing requests to/from the device. The performance data is very useful for analyzing the performance of PCIe devices. The device with the PCIe3 uncore PMON units is owned by the portdrv_pci driver. Create a PCI sub driver for the PCIe3 uncore PMON units. Here are some difference between PCIe3 uncore unit and other uncore pci units. - There may be several Root Ports on a system. But the uncore counters only exist in the Root Port A. A user can configure the channel mask to collect the data from other Root Ports. - The event format of the PCIe3 uncore unit is the same as IIO unit of SKX. - The Control Register of PCIe3 uncore unit is 64 bits. - The offset of each counters is 8, which is the same as M2M unit of SNR. - New MSR addresses for unit control, counter and counter config. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1600094060-82746-7-git-send-email-kan.liang@linux.intel.com
2020-09-24perf/x86/intel/uncore: Generic support for the PCI sub driverKan Liang2-0/+82
Some uncore counters may be located in the configuration space of a PCI device, which already has a bonded driver. Currently, the uncore driver cannot register a PCI uncore PMU for these counters, because, to register a PCI uncore PMU, the uncore driver must be bond to the device. However, one device can only have one bonded driver. Add an uncore PCI sub driver to support such kind of devices. The sub driver doesn't own the device. In initialization, the sub driver searches the device via pci_get_device(), and register the corresponding PMU for the device. In the meantime, the sub driver registers a PCI bus notifier, which is used to notify the sub driver once the device is removed. The sub driver can unregister the PMU accordingly. The sub driver only searches the devices defined in its id table. The id table varies on different platforms, which will be implemented in the following platform-specific patch. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1600094060-82746-6-git-send-email-kan.liang@linux.intel.com
2020-09-24perf/x86/intel/uncore: Factor out uncore_pci_pmu_unregister()Kan Liang1-10/+25
The PMU unregistration in the uncore PCI sub driver is similar as the normal PMU unregistration for a PCI device. The codes to unregister a PCI PMU can be shared. Factor out uncore_pci_pmu_unregister(), which will be used later. Use uncore_pci_get_dev_die_info() to replace the codes which retrieve the socket and die informaion. The pci_set_drvdata() is not included in uncore_pci_pmu_unregister() as well, because the uncore PCI sub driver will not touch the private driver data pointer of the device. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1600094060-82746-5-git-send-email-kan.liang@linux.intel.com
2020-09-24perf/x86/intel/uncore: Factor out uncore_pci_pmu_register()Kan Liang1-31/+51
The PMU registration in the uncore PCI sub driver is similar as the normal PMU registration for a PCI device. The codes to register a PCI PMU can be shared. Factor out uncore_pci_pmu_register(), which will be used later. The pci_set_drvdata() is not included in uncore_pci_pmu_register(). The uncore PCI sub driver doesn't own the PCI device. It will not touch the private driver data pointer for the device. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1600094060-82746-4-git-send-email-kan.liang@linux.intel.com
2020-09-24perf/x86/intel/uncore: Factor out uncore_pci_find_dev_pmu()Kan Liang1-15/+33
When an uncore PCI sub driver gets a remove notification, the corresponding PMU has to be retrieved and unregistered. The codes, which find the corresponding PMU by comparing the pci_device_id table, can be shared. Factor out uncore_pci_find_dev_pmu(), which will be used later. There is no functional change. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1600094060-82746-3-git-send-email-kan.liang@linux.intel.com
2020-09-24perf/x86/intel/uncore: Factor out uncore_pci_get_dev_die_info()Kan Liang1-8/+23
The socket and die information is required to register/unregister a PMU in the uncore PCI sub driver. The codes, which get the socket and die information from a BUS number, can be shared. Factor out uncore_pci_get_dev_die_info(), which will be used later. There is no functional change. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1600094060-82746-2-git-send-email-kan.liang@linux.intel.com
2020-09-24perf/amd/uncore: Inform the user how many counters each uncore PMU hasKim Phillips1-6/+7
Previously, the uncore driver would say "NB counters detected" on F17h machines, which don't have NorthBridge (NB) counters. They have Data Fabric (DF) counters. Just use the pmu.name to inform users which pmu to use and its associated counter count. F17h dmesg BEFORE: amd_uncore: AMD NB counters detected amd_uncore: AMD LLC counters detected F17h dmesg AFTER: amd_uncore: 4 amd_df counters detected amd_uncore: 6 amd_l3 counters detected Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200921144330.6331-5-kim.phillips@amd.com
2020-09-24perf/amd/uncore: Allow F19h user coreid, threadmask, and sliceid specificationKim Phillips1-5/+32
On Family 19h, the driver checks for a populated 2-bit threadmask in order to establish that the user wants to measure individual slices, individual cores (only one can be measured at a time), and lets the user also directly specify enallcores and/or enallslices if desired. Example F19h invocation to measure L3 accesses (event 4, umask 0xff) by the first thread (id 0 -> mask 0x1) of the first core (id 0) on the first slice (id 0): perf stat -a -e instructions,amd_l3/umask=0xff,event=0x4,coreid=0,threadmask=1,sliceid=0,enallcores=0,enallslices=0/ <workload> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200921144330.6331-4-kim.phillips@amd.com
2020-09-24perf/amd/uncore: Allow F17h user threadmask and slicemask specificationKim Phillips1-7/+16
Continue to fully populate either one of threadmask or slicemask if the user doesn't. Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200921144330.6331-3-kim.phillips@amd.com
2020-09-24perf/amd/uncore: Prepare to scale for more attributes that vary per familyKim Phillips1-50/+61
Replace AMD_FORMAT_ATTR with the more apropos DEFINE_UNCORE_FORMAT_ATTR stolen from arch/x86/events/intel/uncore.h. This way we can clearly see the bit-variants of each of the attributes that want to have the same name across families. Also unroll AMD_ATTRIBUTE because we are going to separately add new attributes that differ between DF and L3. Also clean up the if-Family 17h-else logic in amd_uncore_init. This is basically a rewrite of commit da6adaea2b7e ("perf/x86/amd/uncore: Update sysfs attributes for Family17h processors"). No functional changes. Tested F17h+ /sys/bus/event_source/devices/amd_{l3,df}/format/* content remains unchanged: /sys/bus/event_source/devices/amd_l3/format/event:config:0-7 /sys/bus/event_source/devices/amd_l3/format/umask:config:8-15 /sys/bus/event_source/devices/amd_df/format/event:config:0-7,32-35,59-60 /sys/bus/event_source/devices/amd_df/format/umask:config:8-15 Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200921144330.6331-2-kim.phillips@amd.com
2020-09-24arm64: dts: ti: k3-j7200-common-proc-board: Add support for eMMC and SD cardFaiz Abbas1-0/+28
Add support for the eMMC and SD card connected on the common processor board sdhci0 is connected to an eMMC while sdhci1 is connected to the micro SD slot. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Link: https://lore.kernel.org/r/20200924112644.11076-3-faiz_abbas@ti.com
2020-09-24arm64: dts: ti: k3-j7200-main: Add support for MMC/SD controller nodesFaiz Abbas1-0/+37
Add support for MMC/SD controller nodes present on TI's j7200 SoCs. There are two nodes: 1. sdhci0 (8 bit bus width, 200 MHz, HS200, 200 MBps) 2. sdhci1 (4 bit bus width, 50 MHz, HS, 25 MBps) Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Link: https://lore.kernel.org/r/20200924112644.11076-2-faiz_abbas@ti.com
2020-09-24ARM: omap3: enable off mode automaticallyAndreas Kemnade4-7/+27
Enabling off mode was only reachable deeply hidden in the debugfs. As powersaving is an important feature, move the option out of its shady place. The debugfs file can still be used to override the default. Use the presence of a device compatible to ti,twl4030-idle or ti,twl4030-idle-osc-off as an indicator that the board is wired correctly for off mode. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> [tony@atomide.com: updated to fix a checkpatch warning] Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-09-24arm64: dts: ti: k3-j7200-som-p0: Add HyperFlash nodeVignesh Raghavendra1-0/+36
J7200 SoM has a HyperFlash connected to HyperBus memory controller. But HyperBus is muxed with OSPI, therefore keep HyperBus node disabled. Bootloader will detect the mux and enable the node as required. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Link: https://lore.kernel.org/r/20200923163150.16973-3-vigneshr@ti.com
2020-09-24arm64: dts: ti: k3-j7200-mcu-wakeup: Add HyperBus nodeVignesh Raghavendra1-0/+27
J7200 has a Flash SubSystem that has one OSPI and one HyperBus.. Add DT nodes for HyperBus controller for now. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Link: https://lore.kernel.org/r/20200923163150.16973-2-vigneshr@ti.com
2020-09-24arm64: dts: ti: k3-j7200-common-proc-board: Add I2C IO expandersVignesh Raghavendra1-0/+49
Add DT nodes for I2C GPIO expanders on main_i2c0 and main_i2c1 and also add the pinmux corresponding to these I2C instances. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Reviewed-by: Faiz Abbas <faiz_abbas@ti.com> Link: https://lore.kernel.org/r/20200923155400.13757-3-vigneshr@ti.com
2020-09-24arm64: dts: ti: k3-j7200: Add I2C nodesVignesh Raghavendra2-0/+110
J7200 has 7 I2Cs in main domain, 2 I2Cs in MCU and 1 in wakeup domain. Add DT nodes for the same. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Reviewed-by: Faiz Abbas <faiz_abbas@ti.com> Link: https://lore.kernel.org/r/20200923155400.13757-2-vigneshr@ti.com
2020-09-24arm64: dts: ti: k3-j7200-common-proc-board: add mcu cpsw nuss pinmux and phy ↵Grygorii Strashko1-0/+45
defs The TI J7200 EVM base board has TI DP83867 PHY connected to external CPSW NUSS Port 1 in rgmii-rxid mode. Hence, add pinmux and Ethernet PHY configuration for TI J7200 SoC MCU Gigabit Ethernet two ports Switch subsystem (CPSW NUSS). Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20200923220938.30788-5-grygorii.strashko@ti.com
2020-09-24arm64: dts: ti: k3-j7200-mcu: add mcu cpsw nuss nodeGrygorii Strashko1-0/+74
Add DT node for The TI J7200 MCU SoC Gigabit Ethernet two ports Switch subsystem (MCU CPSW NUSS). Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20200923220938.30788-4-grygorii.strashko@ti.com
2020-09-24arm64: dts: ti: k3-j7200-main: add main navss cpts nodeGrygorii Strashko1-0/+12
Add DT node for Main NAVSS CPTS module. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20200923220938.30788-3-grygorii.strashko@ti.com
2020-09-24arm64: dts: ti: k3-j7200: add DMA supportPeter Ujfalusi2-0/+80
Add the ringacc and udmap nodes for Main and MCU NAVSS. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20200923220938.30788-2-grygorii.strashko@ti.com
2020-09-24ARM: dts: at91: sam9x60ek: enable usb deviceCristian Birsan2-0/+27
Enable usb device for sam9x60ek board. Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-09-24s390/pkey: support CCA and EP11 secure ECC private keysHarald Freudenberger1-15/+62
This patch extends the pkey kernel module to support CCA and EP11 secure ECC (private) keys as source for deriving ECC protected (private) keys. There is yet another new ioctl to support this: PKEY_KBLOB2PROTK3 can handle all the old keys plus CCA and EP11 secure ECC keys. For details see ioctl description in pkey.h. The CPACF unit currently only supports a subset of 5 different ECC curves (P-256, P-384, P-521, ED25519, ED448) and so only keys of this curve type can be transformed into protected keys. However, the pkey and the cca/ep11 low level functions do not check this but simple pass-through the key blob to the firmware onto the crypto cards. So most likely the failure will be a response carrying an error code resulting in user space errno value EIO instead of EINVAL. Deriving a protected key from an EP11 ECC secure key requires a CEX7 in EP11 mode. Deriving a protected key from an CCA ECC secure key requires a CEX7 in CCA mode. Together with this new ioctl the ioctls for querying lists of apqns (PKEY_APQNS4K and PKEY_APQNS4KT) have been extended to support EP11 and CCA ECC secure key type and key blobs. Together with this ioctl there comes a new struct ep11kblob_header which is to be prepended onto the EP11 key blob. See details in pkey.h for the fields in there. The older EP11 AES key blob with some info stored in the (unused) session field is also supported with this new ioctl. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-09-24arm64: dts: qcom: sm8250: Add thermal zones and throttling supportAmit Kucheria1-0/+766
sm8250 has 24 thermal sensors split across two tsens controllers. Add the thermal zones to expose them and wireup the cpus to throttle on crossing passive temperature thresholds. Signed-off-by: Amit Kucheria <amitk@kernel.org> Link: https://lore.kernel.org/r/89b83b3caa4e32db08fe402cfa510feb25232aa0.1599732068.git.amitk@kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-24arm64: defconfig: enable Qualcomm ASoC modulesDmitry Baryshkov1-0/+3
Enable CONFIG_SND_SOC_QCOM and several platform drivers to be built as modules. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20200917203913.3250205-3-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-24arm64: defconfig: qcom: enable GPU clock controller for SM8[12]50Dmitry Baryshkov1-0/+2
Enable GPU Clock Controller for SM8150 and SM8250 to allow using Adreon GPU on these SoCs. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20200917203913.3250205-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-24arm64: defconfig: enable INTERCONNECT for Qualcomm chipsetsDmitry Baryshkov1-0/+6
Enable CONFIG_INTERCONNECT and interconnect drivers for several Qualcomm chipsets to enable bus bandwidth control on these SoCs. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20200917203913.3250205-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-09-23x86/ioapic: Unbreak check_timer()Thomas Gleixner1-0/+1
Several people reported in the kernel bugzilla that between v4.12 and v4.13 the magic which works around broken hardware and BIOSes to find the proper timer interrupt delivery mode stopped working for some older affected platforms which need to fall back to ExtINT delivery mode. The reason is that the core code changed to keep track of the masked and disabled state of an interrupt line more accurately to avoid the expensive hardware operations. That broke an assumption in i8259_make_irq() which invokes disable_irq_nosync(); irq_set_chip_and_handler(); enable_irq(); Up to v4.12 this worked because enable_irq() unconditionally unmasked the interrupt line, but after the state tracking improvements this is not longer the case because the IO/APIC uses lazy disabling. So the line state is unmasked which means that enable_irq() does not call into the new irq chip to unmask it. In principle this is a shortcoming of the core code, but it's more than unclear whether the core code should try to reset state. At least this cannot be done unconditionally as that would break other existing use cases where the chip type is changed, e.g. when changing the trigger type, but the callers expect the state to be preserved. As the way how check_timer() is switching the delivery modes is truly unique, the obvious fix is to simply unmask the i8259 manually after changing the mode to ExtINT delivery and switching the irq chip to the legacy PIC. Note, that the fixes tag is not really precise, but identifies the commit which broke the assumptions in the IO/APIC and i8259 code and that's the kernel version to which this needs to be backported. Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls") Reported-by: p_c_chan@hotmail.com Reported-by: ecm4@mail.com Reported-by: perdigao1@yahoo.com Reported-by: matzes@users.sourceforge.net Reported-by: rvelascog@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: p_c_chan@hotmail.com Tested-by: matzes@users.sourceforge.net Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=197769
2020-09-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller3-103/+239
Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-09-23 The following pull-request contains BPF updates for your *net-next* tree. We've added 95 non-merge commits during the last 22 day(s) which contain a total of 124 files changed, 4211 insertions(+), 2040 deletions(-). The main changes are: 1) Full multi function support in libbpf, from Andrii. 2) Refactoring of function argument checks, from Lorenz. 3) Make bpf_tail_call compatible with functions (subprograms), from Maciej. 4) Program metadata support, from YiFei. 5) bpf iterator optimizations, from Yonghong. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-23ARM: dts: stm32: add arm-pmu node on stm32mp15Alexandre Torgue2-0/+13
Add arm-pmu node on stm32mp15. Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Marek Vasut <marex@denx.de> # update to linux-next Tested-by: Marek Vasut <marex@denx.de> # on DH PDK2 and Avenger96 Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: add FMC2 EBI support for stm32mp157cChristophe Kerello2-21/+38
This patch adds FMC2 External Bus Interface support on stm32mp157c. Signed-off-by: Christophe Kerello <christophe.kerello@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: lxa-mc1: enable DDR50 mode on eMMCAhmad Fatoum1-0/+1
The "eMMC high-speed DDR mode (3.3V I/O)" at 50MHz is supported on the eMMC-interface of the lxa-mc1. Set it in the device tree to benefit from the speed improvement. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Holger Assmann <h.assmann@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: Fix DH PDK2 display PWM channelMarek Vasut1-1/+1
The display PWM channel is number 3 (PWM2 CH4), make it so. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: Enable RTS/CTS for DH AV96 UART7Marek Vasut1-0/+1
The DH AV96 has RTS/CTS lines available on UART7, describe them in DT. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: Swap PHY reset GPIO and TSC2004 IRQ on DHCOM SOMMarek Vasut1-2/+2
On the production revision of the SoM, 587-200, the PHY reset GPIO and touchscreen IRQs are swapped to prevent collision between EXTi IRQs, reflect that in DT. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: use stm32h7 usart compatible string for stm32h743Tobias Schramm1-2/+2
Previously the FIFO on the stm32h743 usart was not utilized, because the stm32f7 compatible configures it without FIFO support. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: add resets property to spi device nodes on stm32h743Tobias Schramm1-0/+6
The stm32 spi driver tries to determine the fifo size of spi devices dynamically. However, if the spi was already configured by the bootloader the fifo size check can become an endless loop, because the driver expects the spi to be in its initial "after device reset" state. The driver does already support resetting the spi device at probe, thus this patch adds only the required device tree properties Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: add display controller node to stm32h743Tobias Schramm1-0/+10
Declare LTDC (display controller) on stm32h743. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: Enable RTS/CTS for DH PDK2 UART8Marek Vasut1-1/+2
The DH PDK2 has RTS/CTS lines available on UART8, describe them in DT. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: Drop QSPI CS2 pinmux on DHCOMMarek Vasut1-2/+2
The QSPI CS2 is not used on DHCOM, remove the pinmux settings. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: Add STM32MP1 UART8 RTS/CTS pinmuxMarek Vasut1-0/+8
Add extra RTS/CTS line pinmux for STM32MP1 UART8. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-09-23ARM: dts: stm32: add initial support for stm32mp157-odyssey boardMarcin Sloniewski4-1/+376
Add support for Seeed Studio's stm32mp157c odyssey board. Board consists of SoM with stm32mp157c with 4GB eMMC and 512 MB DDR3 RAM and carrier board with USB and ETH interfaces, SD card connector, wifi and BT chip AP6236. In this patch only basic kernel boot is supported and interfacing SD card and on-board eMMC. Signed-off-by: Marcin Sloniewski <marcin.sloniewski@gmail.com> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>