summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* clk: qcom: gcc: Add clock driver for SM8350Vivek Aknurwar2021-02-083-0/+3799
| | | | | | | | | | | | This adds Global Clock controller (GCC) driver for SM8350 SoC Signed-off-by: Vivek Aknurwar <viveka@codeaurora.org> Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org> [vkoul: rebase and tidy up for upstream] Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210127070811.152690-6-vkoul@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLLVivek Aknurwar2021-02-082-0/+177
| | | | | | | | | | | | | | Lucid 5LPE is a slightly different Lucid PLL with different offsets and porgramming sequence so add support for these Signed-off-by: Vivek Aknurwar <viveka@codeaurora.org> Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org> [vkoul: rebase and tidy up for upstream] Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210127070811.152690-4-vkoul@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: clk-alpha-pll: modularize alpha_pll_trion_set_rate()Vinod Koul2021-02-081-7/+11
| | | | | | | | | | | | Trion 5LPE set rate uses code similar to alpha_pll_trion_set_rate() but with different registers. Modularize these by moving out latch and latch ack bits so that we can reuse the function. Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210127070811.152690-3-vkoul@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: clk-alpha-pll: replace regval with valVinod Koul2021-02-081-10/+10
| | | | | | | | | | | Driver uses regval variable for holding register values, replace with a shorter one val Suggested-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210127070811.152690-2-vkoul@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: gcc: Add global clock controller driver for SC8180xBjorn Andersson2021-02-083-0/+4639
| | | | | | | | | | Add clocks, resets and some of the GDSC provided by the global clock controller found in the Qualcomm SC8180x platform. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210126043155.1847823-2-bjorn.andersson@linaro.org [sboyd@kernel.org: Drop F macro as it's already defined] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: gcc-sc7180: Mark the MM XO clocks to be always ONTaniya Das2021-02-081-43/+4
| | | | | | | | | | | There are intermittent GDSC power-up failures observed for titan top gdsc, which requires the XO clock. Thus mark all the MM XO clocks always enabled from probe. Fixes: 8d4025943e13 ("clk: qcom: camcc-sc7180: Use runtime PM ops instead of clk ones") Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/1611128871-5898-1-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: rpmhcc: Add sc8180x rpmh clocksBjorn Andersson2021-02-081-0/+25
| | | | | | | | Add clocks provides by RPMH in the Qualcomm SC8180x platform. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210120223741.1610344-2-bjorn.andersson@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: gfm-mux: fix clk maskSrinivas Kandagatla2021-02-081-4/+4
| | | | | | | | | | For some reason global GFM_MASK ended up with bit 1 instead of bit 0. Remove the global GFM_MASK and reuse mux_mask field. Fixes: a2d8f507803e ("clk: qcom: Add support to LPASS AUDIO_CC Glitch Free Mux clocks") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210119113851.18946-1-srinivas.kandagatla@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: Add SDX55 APCS clock controller supportManivannan Sadhasivam2021-02-083-0/+159
| | | | | | | | | | | | | | | | | | | Add a driver for the SDX55 APCS clock controller. It is part of the APCS hardware block, which among other things implements also a combined mux and half integer divider functionality. The APCS clock controller has 3 parent clocks: 1. Board XO 2. Fixed rate GPLL0 3. A7 PLL This is required for enabling CPU frequency scaling on SDX55-based platforms. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210118041156.50016-6-manivannan.sadhasivam@linaro.org [sboyd@kernel.org: Fix unused ret in probe by hardcoding it] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* clk: qcom: Add A7 PLL supportManivannan Sadhasivam2021-02-083-0/+109
| | | | | | | | | | | | | | | Add support for PLL found in Qualcomm SDX55 platforms which is used to provide clock to the Cortex A7 CPU via a mux. This PLL can provide high frequency clock to the CPU above 1GHz as compared to the other sources like GPLL0. In this driver, the power domain is attached to the cpudev. This is required for CPUFreq functionality and there seems to be no better place to do other than this driver (no dedicated CPUFreq driver). Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210118041156.50016-5-manivannan.sadhasivam@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* Merge tag 'ntb-5.11' of git://github.com/jonmason/ntbLinus Torvalds2020-12-274-3/+44
|\ | | | | | | | | | | | | | | | | Pull NTB fixes from Jon Mason: "Bug fix for IDT NTB and Intel NTB LTR management support" * tag 'ntb-5.11' of git://github.com/jonmason/ntb: ntb: intel: add Intel NTB LTR vendor support for gen4 NTB ntb: idt: fix error check in ntb_hw_idt.c
| * ntb: intel: add Intel NTB LTR vendor support for gen4 NTBDave Jiang2020-12-073-1/+42
| | | | | | | | | | | | | | | | | | Intel NTB device has custom LTR management that is not compliant with the PCIe standard. Add support to set LTR status triggered by link status change. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
| * ntb: idt: fix error check in ntb_hw_idt.cWang Qing2020-12-071-2/+2
| | | | | | | | | | | | | | | | idt_create_dev never return NULL and fix smatch warning. Signed-off-by: Wang Qing <wangqing@vivo.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
* | Merge branch 'linus' of ↵Linus Torvalds2020-12-272-2/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "Fix a number of autobuild failures due to missing Kconfig dependencies" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: qat - add CRYPTO_AES to Kconfig dependencies crypto: keembay - Add dependency on HAS_IOMEM crypto: keembay - CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAY
| * | crypto: qat - add CRYPTO_AES to Kconfig dependenciesMarco Chiappero2020-12-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch includes a missing dependency (CRYPTO_AES) which may lead to an "undefined reference to `aes_expandkey'" linking error. Fixes: 5106dfeaeabe ("crypto: qat - add AES-XTS support for QAT GEN4 devices") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: keembay - Add dependency on HAS_IOMEMDaniele Alessandrelli2020-12-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add dependency for CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 on HAS_IOMEM to prevent build failures. Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: keembay - CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAYGeert Uytterhoeven2020-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Intel Keem Bay Offload and Crypto Subsystem (OCS) is only present on Intel Keem Bay SoCs. Hence add a dependency on ARCH_KEEMBAY, to prevent asking the user about this driver when configuring a kernel without Intel Keem Bay platform support. While at it, fix a misspelling of "cipher". Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | | mfd: ab8500-debugfs: Remove extraneous seq_putcLinus Torvalds2020-12-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c9a3c4e637ac ("mfd: ab8500-debugfs: Remove extraneous curly brace") removed a left-over curly brace that caused build failures, but Joe Perches points out that the subsequent 'seq_putc()' should also be removed, because the commit that caused all these problems already added the final '\n' to the seq_printf() above it. Reported-by: Joe Perches <joe@perches.com> Fixes: 886c8121659d ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc") Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Merge tag 'pci-v5.11-fixes-1' of ↵Linus Torvalds2020-12-262-32/+31
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: - Fix a tegra enumeration regression (Rob Herring) - Fix a designware-host check that warned on *success*, not failure (Alexander Lobakin) * tag 'pci-v5.11-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: dwc: Fix inverted condition of DMA mask setup warning PCI: tegra: Fix host link initialization
| * | | PCI: dwc: Fix inverted condition of DMA mask setup warningAlexander Lobakin2020-12-261-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 660c486590aa ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation") added dma_mask_set() call to explicitly set 32-bit DMA mask for MSI message mapping, but for now it throws a warning on ret == 0, while dma_set_mask() returns 0 in case of success. Fix this by inverting the condition. [bhelgaas: join string to make it greppable] Fixes: 660c486590aa ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation") Link: https://lore.kernel.org/r/20201222150708.67983-1-alobakin@pm.me Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | | PCI: tegra: Fix host link initializationRob Herring2020-12-261-26/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit b9ac0f9dc8ea ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code") broke enumeration of downstream devices on Tegra: In non-working case (next-20201211): 0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1) 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13) 0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1) In working case (v5.10-rc7): 0001:00:00.0 PCI bridge: Molex Incorporated Device 1ad2 (rev a1) 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13) 0005:00:00.0 PCI bridge: Molex Incorporated Device 1ad0 (rev a1) 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab) 0005:02:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab) 0005:03:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab) The problem seems to be dw_pcie_setup_rc() is now called twice before and after the link up handling. The fix is to move Tegra's link up handling to .start_link() function like other DWC drivers. Tegra is a bit more complicated than others as it re-inits the whole DWC controller to retry the link. With this, the initialization ordering is restored to match the prior sequence. Fixes: b9ac0f9dc8ea ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code") Link: https://lore.kernel.org/r/20201218143905.1614098-1-robh@kernel.org Reported-by: Mian Yousaf Kaukab <ykaukab@suse.de> Tested-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Vidya Sagar <vidyas@nvidia.com>
* | | | mfd: ab8500-debugfs: Remove extraneous curly braceNathan Chancellor2020-12-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang errors: drivers/mfd/ab8500-debugfs.c:1526:2: error: non-void function does not return a value [-Werror,-Wreturn-type] } ^ drivers/mfd/ab8500-debugfs.c:1528:2: error: expected identifier or '(' return 0; ^ drivers/mfd/ab8500-debugfs.c:1529:1: error: extraneous closing brace ('}') } ^ 3 errors generated. The cleanup in ab8500_interrupts_show left a curly brace around, remove it to fix the error. Fixes: 886c8121659d ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | drm/amd/display: avoid uninitialized variable warningLinus Torvalds2020-12-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang (quite rightly) complains fairly loudly about the newly added mpc1_get_mpc_out_mux() function returning an uninitialized value if the 'opp_id' checks don't pass. This may not happen in practice, but the code really shouldn't return garbage if the sanity checks don't pass. So just initialize 'val' to zero to avoid the issue. Fixes: 110b055b2827 ("drm/amd/display: add getter routine to retrieve mpcc mux") Cc: Josip Pavic <Josip.Pavic@amd.com> Cc: Bindu Ramamurthy <bindu.r@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | Merge tag 'irq-core-2020-12-23' of ↵Linus Torvalds2020-12-2419-174/+183
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq updates from Thomas Gleixner: "This is the second attempt after the first one failed miserably and got zapped to unblock the rest of the interrupt related patches. A treewide cleanup of interrupt descriptor (ab)use with all sorts of racy accesses, inefficient and disfunctional code. The goal is to remove the export of irq_to_desc() to prevent these things from creeping up again" * tag 'irq-core-2020-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (30 commits) genirq: Restrict export of irq_to_desc() xen/events: Implement irq distribution xen/events: Reduce irq_info:: Spurious_cnt storage size xen/events: Only force affinity mask for percpu interrupts xen/events: Use immediate affinity setting xen/events: Remove disfunct affinity spreading xen/events: Remove unused bind_evtchn_to_irq_lateeoi() net/mlx5: Use effective interrupt affinity net/mlx5: Replace irq_to_desc() abuse net/mlx4: Use effective interrupt affinity net/mlx4: Replace irq_to_desc() abuse PCI: mobiveil: Use irq_data_get_irq_chip_data() PCI: xilinx-nwl: Use irq_data_get_irq_chip_data() NTB/msi: Use irq_has_action() mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc pinctrl: nomadik: Use irq_has_action() drm/i915/pmu: Replace open coded kstat_irqs() copy drm/i915/lpe_audio: Remove pointless irq_to_desc() usage s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt() parisc/irq: Use irq_desc_kstat_cpu() in show_interrupts() ...
| * | | | xen/events: Implement irq distributionThomas Gleixner2020-12-151-8/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keep track of the assignments of event channels to CPUs and select the online CPU with the least assigned channels in the affinity mask which is handed to irq_chip::irq_set_affinity() from the core code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.457218278@linutronix.de
| * | | | xen/events: Reduce irq_info:: Spurious_cnt storage sizeThomas Gleixner2020-12-151-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To prepare for interrupt spreading reduce the storage size of irq_info::spurious_cnt to u8 so the required flag for the spreading logic will not increase the storage size. Protect the usage site against overruns. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.360198201@linutronix.de
| * | | | xen/events: Only force affinity mask for percpu interruptsThomas Gleixner2020-12-151-14/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN implementation of irqchip::irq_set_affinity() already picks a single target CPU out of the affinity mask and the actual target is stored in the effective CPU mask, so destroying the user chosen affinity mask which might contain more than one CPU is wrong. Change the implementation so that the channel is bound to CPU0 at the XEN level and leave the affinity mask alone. At startup of the interrupt affinity will be assigned out of the affinity mask and the XEN binding will be updated. Only keep the enforcement for real percpu interrupts. On resume the overwrite is not required either because info->cpu and the affinity mask are still the same as at the time of suspend. Same for rebind_evtchn_irq(). This also prepares for proper interrupt spreading. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.250321315@linutronix.de
| * | | | xen/events: Use immediate affinity settingThomas Gleixner2020-12-151-26/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is absolutely no reason to mimic the x86 deferred affinity setting. This mechanism is required to handle the hardware induced issues of IO/APIC and MSI and is not in use when the interrupts are remapped. XEN does not need this and can simply change the affinity from the calling context. The core code invokes this with the interrupt descriptor lock held so it is fully serialized against any other operation. Mark the interrupts with IRQ_MOVE_PCNTXT to disable the deferred affinity setting. The conditional mask/unmask operation is already handled in xen_rebind_evtchn_to_cpu(). This makes XEN on x86 use the same mechanics as on e.g. ARM64 where deferred affinity setting is not required and not implemented and the code path in the ack functions is compiled out. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.157601122@linutronix.de
| * | | | xen/events: Remove disfunct affinity spreadingThomas Gleixner2020-12-152-42/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function can only ever work when the event channels: - are already established - interrupts assigned to them - the affinity has been set by user space already because any newly set up event channel is forced to be bound to CPU0 and the affinity mask of the interrupt is forced to contain cpumask_of(0). As the CPU0 enforcement was in place _before_ this was implemented it's entirely unclear how that can ever have worked at all. Remove it as preparation for doing it proper. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.065115500@linutronix.de
| * | | | xen/events: Remove unused bind_evtchn_to_irq_lateeoi()Thomas Gleixner2020-12-151-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194044.972064156@linutronix.de
| * | | | net/mlx5: Use effective interrupt affinityThomas Gleixner2020-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the interrupt affinity mask for checking locality is not really working well on architectures which support effective affinity masks. The affinity mask is either the system wide default or set by user space, but the architecture can or even must reduce the mask to the effective set, which means that checking the affinity mask itself does not really tell about the actual target CPUs. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.876342330@linutronix.de
| * | | | net/mlx5: Replace irq_to_desc() abuseThomas Gleixner2020-12-153-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No driver has any business with the internals of an interrupt descriptor. Storing a pointer to it just to use yet another helper at the actual usage site to retrieve the affinity mask is creative at best. Just because C does not allow encapsulation does not mean that the kernel has no limits. Retrieve a pointer to the affinity mask itself and use that. It's still using an interface which is usually not for random drivers, but definitely less hideous than the previous hack. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.769458162@linutronix.de
| * | | | net/mlx4: Use effective interrupt affinityThomas Gleixner2020-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the interrupt affinity mask for checking locality is not really working well on architectures which support effective affinity masks. The affinity mask is either the system wide default or set by user space, but the architecture can or even must reduce the mask to the effective set, which means that checking the affinity mask itself does not really tell about the actual target CPUs. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.672935978@linutronix.de
| * | | | net/mlx4: Replace irq_to_desc() abuseThomas Gleixner2020-12-153-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No driver has any business with the internals of an interrupt descriptor. Storing a pointer to it just to use yet another helper at the actual usage site to retrieve the affinity mask is creative at best. Just because C does not allow encapsulation does not mean that the kernel has no limits. Retrieve a pointer to the affinity mask itself and use that. It's still using an interface which is usually not for random drivers, but definitely less hideous than the previous hack. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.580936243@linutronix.de
| * | | | PCI: mobiveil: Use irq_data_get_irq_chip_data()Thomas Gleixner2020-12-151-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Going through a full irq descriptor lookup instead of just using the proper helper function which provides direct access is suboptimal. In fact it _is_ wrong because the chip callback needs to get the chip data which is relevant for the chip while using the irq descriptor variant returns the irq chip data of the top level chip of a hierarchy. It does not matter in this case because the chip is the top level chip, but that doesn't make it more correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201210194044.473308721@linutronix.de
| * | | | PCI: xilinx-nwl: Use irq_data_get_irq_chip_data()Thomas Gleixner2020-12-151-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Going through a full irq descriptor lookup instead of just using the proper helper function which provides direct access is suboptimal. In fact it _is_ wrong because the chip callback needs to get the chip data which is relevant for the chip while using the irq descriptor variant returns the irq chip data of the top level chip of a hierarchy. It does not matter in this case because the chip is the top level chip, but that doesn't make it more correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201210194044.364211860@linutronix.de
| * | | | NTB/msi: Use irq_has_action()Thomas Gleixner2020-12-151-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the proper core function. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Link: https://lore.kernel.org/r/20201210194044.255887860@linutronix.de
| * | | | mfd: ab8500-debugfs: Remove the racy fiddling with irq_descThomas Gleixner2020-12-151-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First of all drivers have absolutely no business to dig into the internals of an irq descriptor. That's core code and subject to change. All of this information is readily available to /proc/interrupts in a safe and race free way. Remove the inspection code which is a blatant violation of subsystem boundaries and racy against concurrent modifications of the interrupt descriptor. Print the irq line instead so the information can be looked up in a sane way in /proc/interrupts. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201210194044.157283633@linutronix.de
| * | | | pinctrl: nomadik: Use irq_has_action()Thomas Gleixner2020-12-151-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let the core code do the fiddling with irq_desc. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201210194044.065003856@linutronix.de
| * | | | drm/i915/pmu: Replace open coded kstat_irqs() copyThomas Gleixner2020-12-153-18/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver code has no business with the internals of the irq descriptor. Aside of that the count is per interrupt line and therefore takes interrupts from other devices into account which share the interrupt line and are not handled by the graphics driver. Replace it with a pmu private count which only counts interrupts which originate from the graphics card. To avoid atomics or heuristics of some sort make the counter field 'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and postprocessing can easily deal with the occasional wraparound. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://lore.kernel.org/r/20201210194043.957046529@linutronix.de
| * | | | drm/i915/lpe_audio: Remove pointless irq_to_desc() usageThomas Gleixner2020-12-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nothing uses the result and nothing should ever use it in driver code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20201210194043.862572239@linutronix.de
* | | | | Merge tag 'efi_updates_for_v5.11' of ↵Linus Torvalds2020-12-2410-39/+61
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI updates from Borislav Petkov: "These got delayed due to a last minute ia64 build issue which got fixed in the meantime. EFI updates collected by Ard Biesheuvel: - Don't move BSS section around pointlessly in the x86 decompressor - Refactor helper for discovering the EFI secure boot mode - Wire up EFI secure boot to IMA for arm64 - Some fixes for the capsule loader - Expose the RT_PROP table via the EFI test module - Relax DT and kernel placement restrictions on ARM with a few followup fixes: - fix the build breakage on IA64 caused by recent capsule loader changes - suppress a type mismatch build warning in the expansion of EFI_PHYS_ALIGN on ARM" * tag 'efi_updates_for_v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: arm: force use of unsigned type for EFI_PHYS_ALIGN efi: ia64: disable the capsule loader efi: stub: get rid of efi_get_max_fdt_addr() efi/efi_test: read RuntimeServicesSupported efi: arm: reduce minimum alignment of uncompressed kernel efi: capsule: clean scatter-gather entries from the D-cache efi: capsule: use atomic kmap for transient sglist mappings efi: x86/xen: switch to efi_get_secureboot_mode helper arm64/ima: add ima_arch support ima: generalize x86/EFI arch glue for other EFI architectures efi: generalize efi_get_secureboot efi/libstub: EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER should not default to yes efi/x86: Only copy the compressed kernel image in efi_relocate_kernel() efi/libstub/x86: simplify efi_is_native()
| * | | | | efi: ia64: disable the capsule loaderArd Biesheuvel2020-12-142-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EFI capsule loading is a feature that was introduced into EFI long after its initial introduction on Itanium, and it is highly unlikely that IA64 systems are receiving firmware updates in the first place, let alone using EFI capsules. So let's disable capsule support altogether on IA64. This fixes a build error on IA64 due to a recent change that added an unconditional include of asm/efi.h, which IA64 does not provide. While at it, tweak the make rules a bit so that the EFI capsule component that is always builtin (even if the EFI capsule loader itself is built as a module) is omitted for all architectures if the module is not enabled in the build. Cc: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/linux-efi/20201214152200.38353-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
| * | | | | efi: stub: get rid of efi_get_max_fdt_addr()Ard Biesheuvel2020-12-093-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that ARM started following the example of arm64 and RISC-V, and no longer imposes any restrictions on the placement of the FDT in memory at boot, we no longer need per-arch implementations of efi_get_max_fdt_addr() to factor out the differences. So get rid of it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Atish Patra <atish.patra@wdc.com> Link: https://lore.kernel.org/r/20201029134901.9773-1-ardb@kernel.org
| * | | | | efi/efi_test: read RuntimeServicesSupportedHeinrich Schuchardt2020-12-092-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the UEFI 2.8A specification the UEFI enabled firmware provides a configuration table EFI_RT_PROPERTIES_TABLE which indicates which runtime services are enabled. The EFI stub reads this table and saves the value of the field RuntimeServicesSupported internally. The Firmware Test Suite requires the value to determine if UEFI runtime services are correctly implemented. With this patch an IOCTL call is provided to read the value of the field RuntimeServicesSupported, e.g. #define EFI_RUNTIME_GET_SUPPORTED_MASK \ _IOR('p', 0x0C, unsigned int) unsigned int mask; fd = open("/dev/efi_test", O_RDWR); ret = ioctl(fd, EFI_RUNTIME_GET_SUPPORTED_MASK, &mask); Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Link: https://lore.kernel.org/r/20201127192051.1430-1-xypron.glpk@gmx.de Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ivan Hu <ivan.hu@canonical.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
| * | | | | efi: capsule: clean scatter-gather entries from the D-cacheArd Biesheuvel2020-12-091-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scatter-gather lists passed to UpdateCapsule() should be cleaned from the D-cache to ensure that they are visible to the CPU after a warm reboot before the MMU is enabled. On ARM and arm64 systems, this implies a D-cache clean by virtual address to the point of coherency. However, due to the fact that the firmware itself is not able to map physical addresses back to virtual addresses when running under the OS, this must be done by the caller. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
| * | | | | efi: capsule: use atomic kmap for transient sglist mappingsArd Biesheuvel2020-12-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the heavy-weight kmap() API to create short-lived mappings of the scatter-gather list entries that are released as soon as the entries are written. Instead, use kmap_atomic(), which is more suited to this purpose. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
| * | | | | efi: x86/xen: switch to efi_get_secureboot_mode helperArd Biesheuvel2020-11-171-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have a static inline helper to discover the platform's secure boot mode that can be shared between the EFI stub and the kernel proper, switch to it, and drop some comments about keeping them in sync manually. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
| * | | | | efi: generalize efi_get_securebootChester Lin2020-11-042-26/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generalize the efi_get_secureboot() function so not only efistub but also other subsystems can use it. Note that the MokSbState handling is not factored out: the variable is boot time only, and so it cannot be parameterized as easily. Also, the IMA code will switch to this version in a future patch, and it does not incorporate the MokSbState exception in the first place. Note that the new efi_get_secureboot_mode() helper treats any failures to read SetupMode as setup mode being disabled. Co-developed-by: Chester Lin <clin@suse.com> Signed-off-by: Chester Lin <clin@suse.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
| * | | | | efi/libstub: EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER should not default to yesGeert Uytterhoeven2020-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is deprecated, so it should not be enabled by default. In light of commit 4da0b2b7e67524cc ("efi/libstub: Re-enable command line initrd loading for x86"), keep the default for X86. Fixes: cf6b83664895a5c7 ("efi/libstub: Make initrd file loader configurable") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201028153402.1736103-1-geert+renesas@glider.be Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-25 01:47:33 +0100