summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-20mmc: sdhci-brcmstb: Add shutdown callbackAl Cooper
Shutdown controller and disable it's clocks to insure max power savings in S5 on systems that leave power on. Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20200113210706.11972-5-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-brcmstb: Fix driver to defer on clk_get deferAl Cooper
The new SCMI clock protocol driver does not get probed that early in boot. Brcmstb drivers typically have the following code when getting a clock: priv->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(priv->clk)) { dev_err(&pdev->dev, "Clock not found in Device Tree\n"); priv->clk = NULL; } This commit changes the driver to do what is below. priv->clk = devm_clk_get(&pdev->dev, NULL); if (IS_ERR(priv->clk)) { if (PTR_ERR(priv->clk) == -EPROBE_DEFER) return -EPROBE_DEFER; dev_err(&pdev->dev, "Clock not found in Device Tree\n"); priv->clk = NULL; } Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20200113210706.11972-4-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-brcmstb: Add ability to use HS400ES transfer modeAl Cooper
The latest eMMC JEDEC specification version 5.1 added a new transfer mode, HS400 with enhanced strobe (HS400ES). This mode will be selected if both the host controller and eMMC device support it. The latest Arasan 5.1 controller in the 7216a0 supports this mode. The "Host Controller Specification" has not been updated so the controller register bit used to enable this mode is not specified and varies the with controller vendor. The Linux SDHCI driver supplies a callback for enabling HS400ES mode and that callback will be used to supply a routine that will set the proper bit in the Arasan Vendor register. Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20200113210706.11972-3-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20dt-bindings: mmc: brcm,sdhci-brcmstb: Add support for 7216b0Al Cooper
Add 7216b0 with supports CQE, HS400, HS400-ES and SDR104. Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20200113210706.11972-2-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: core: limit probe clock frequency to configured f_maxMichał Mirosław
Currently MMC core disregards host->f_max during card initialization phase. Obey upper boundary for the clock frequency and skip faster speeds when they are above the limit. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/f471bceaf237d582d746bd289c4c4f3639cb7b45.1577962382.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-milbeaut: Remove redundant platform_get_irq error messageYueHaibing
platform_get_irq() will call dev_err() itself on failure, so there is no need for the driver to also do this. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116144322.57308-1-yuehaibing@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: fix an issue of mixing different typesChunyan Zhang
Fix an issue reported by sparse, since mixed types of parameters are used on calling dmaengine_prep_slave_sg(). Fixes: 36e1da441fec (mmc: sdhci: add support for using external DMA devices) Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200120033223.897-1-zhang.chunyan@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20Merge branch 'for-linus' into for-nextTakashi Iwai
Resolved the merge conflict in HD-audio Tegra driver. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-20ALSA: hda: Apply aligned MMIO access only conditionallyTakashi Iwai
It turned out that the recent simplification of HD-audio bus access helpers caused a regression on the virtual HD-audio device on QEMU with ARM platforms. The driver got a CORB/RIRB timeout and couldn't probe any codecs. The essential difference that caused a problem was the enforced aligned MMIO accesses by simplification. Since snd-hda-tegra driver is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes the all HD-audio drivers using the aligned MMIO accesses. While this is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM gets broken by this access pattern. For addressing the regression, this patch introduces a new flag, aligned_mmio, to hdac_bus object, and applies the aligned MMIO only when this flag is set. This change affects only platforms with CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms. Unfortunately the patch became a big bigger than it should be, just because the former calls didn't take hdac_bus object in the argument, hence we had to extend the call patterns. Fixes: 19abfefd4c76 ("ALSA: hda: Direct MMIO accesses") BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-20x86/sysfb: Fix check for bad VRAM sizeArvind Sankar
When checking whether the reported lfb_size makes sense, the height * stride result is page-aligned before seeing whether it exceeds the reported size. This doesn't work if height * stride is not an exact number of pages. For example, as reported in the kernel bugzilla below, an 800x600x32 EFI framebuffer gets skipped because of this. Move the PAGE_ALIGN to after the check vs size. Reported-by: Christopher Head <chead@chead.ca> Tested-by: Christopher Head <chead@chead.ca> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206051 Link: https://lkml.kernel.org/r/20200107230410.2291947-1-nivedita@alum.mit.edu
2020-01-20Merge branch 'net-phy-add-generic-ndo_do_ioctl-handler-phy_do_ioctl'David S. Miller
Heiner Kallweit says: ==================== net: phy: add generic ndo_do_ioctl handler phy_do_ioctl A number of network drivers has the same glue code to use phy_mii_ioctl as ndo_do_ioctl handler. So let's add such a generic ndo_do_ioctl handler to phylib. As first user convert r8169. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20r8169: use generic ndo_do_ioctl handler phy_do_ioctlHeiner Kallweit
Replace rtl8169_ioctl with new generic function phy_do_ioctl. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: phy: add generic ndo_do_ioctl handler phy_do_ioctlHeiner Kallweit
A number of network drivers has the same glue code to use phy_mii_ioctl as ndo_do_ioctl handler. So let's add such a generic ndo_do_ioctl handler to phylib. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20Merge branch 'fixes' into nextUlf Hansson
2020-01-20platform/x86: asus-nb-wmi: Support left round button on N56VBPaul Cercueil
The N56VB laptop has a round button located on the left side above the keyboard. Map it to F13 since it does not have any predeterminated purpose. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-20tools/power/x86/intel-speed-select: Update versionSrinivas Pandruvada
As we added new set of mailbox commands, increment version. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-20tools/power/x86/intel-speed-select: Change the order for clos disableSrinivas Pandruvada
In turbo-freq or base-freq auto mode, for disable, first disable the feature and then disable clos. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-20tools/power/x86/intel-speed-select: Fix result display for turbo-freq auto modeSrinivas Pandruvada
The turbo-freq enable with auto mode, prints result for the last possible CPU, which is not correct when either CPU is not present or user wants command to be limited to a single die/package. For example, in the below command user wants to limit to die/package 0, but the "turbo-freq --auto" result is displayed using the other package. $ sudo intel-speed-select -c 0 turbo-freq enable -a Intel(R) Speed Select Technology package-0 die-0 cpu-0 turbo-freq enable:success package--1 die-0 cpu-31 turbo-freq --auto enable:success Since we do have to traverse all CPUs, don't display CPU info for "turbo-freq --auto", as we already displayed the result for turbo-freq enable with the CPU information. With the fix, the same command results in: $ sudo intel-speed-select -c 0 turbo-freq enable -a Intel(R) Speed Select Technology package-0 die-0 cpu-0 turbo-freq enable:success turbo-freq --auto enable:success Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-20tools/power/x86/intel-speed-select: Add support for core-power discoverySrinivas Pandruvada
It is possible that BIOS may not enable core-power feature. In this case this additional interface will allow to enable from this utility. Also the information dump, includes the current status of core-power. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-20platform/x86: ISST: Allow additional core-power mailbox commandsSrinivas Pandruvada
To discover core-power capability, some new mailbox commands are added. Allow those commands to execute. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-01-20mmc: sdhci: fix minimum clock rate for v3 controllerMichał Mirosław
For SDHCIv3+ with programmable clock mode, minimal clock frequency is still base clock / max(divider). Minimal programmable clock frequency is always greater than minimal divided clock frequency. Without this patch, SDHCI uses out-of-spec initial frequency when multiplier is big enough: mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz [for 480 MHz source clock divided by 1024] The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode. Fixes: c3ed3877625f ("mmc: sdhci: add support for programmable clock mode") Cc: <stable@vger.kernel.org> # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present Cc: <stable@vger.kernel.org> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-omap: Add special reset capabilityFaiz Abbas
Some omap controllers need software to monitor a 0->1->0 for software reset. Add a SDHCI_OMAP_SPECIAL_RESET flag to indicate this. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-11-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-omap: Add am335x and am437x specific compatiblesFaiz Abbas
Add support for new compatible for TI's am335x and am437x devices. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-10-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20dt-bindings: sdhci-omap: Add am335x and am437x specific bindingsFaiz Abbas
Add binding for the TI's sdhci-omap controller present in am335x and am437x devices. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200116105154.7685-9-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-omap: Disable data timeout interrupt during eraseFaiz Abbas
Disable data timeout interrupt during an erase operation. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-8-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: Refactor sdhci_set_timeout()Faiz Abbas
Refactor sdhci_set_timeout() such that platform drivers can do some functionality in a set_timeout() callback and then call __sdhci_set_timeout() to complete the operation. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-7-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: Convert sdhci_set_timeout_irq() to non-staticFaiz Abbas
Export sdhci_set_timeout_irq() so that it is accessible from platform drivers. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-6-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-omap: Add using external dmaChunyan Zhang
sdhci-omap can support both external dma controller via dmaengine framework as well as ADMA which standard SD host controller provides. Fixes by Faiz Abbas <fazi_abbas@ti.com>: 1. Switch to DMA slave mode when using external DMA 2. Add offset to mapbase Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-5-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: add support for using external DMA devicesChunyan Zhang
Some standard SD host controllers can support both external dma controllers as well as ADMA/SDMA in which the SD host controller acts as DMA master. TI's omap controller is the case as an example. Currently the generic SDHCI code supports ADMA/SDMA integrated in the host controller but does not have any support for external DMA controllers implemented using dmaengine, meaning that custom code is needed for any systems that use an external DMA controller with SDHCI. Fixes by Faiz Abbas <faiz_abbas@ti.com>: 1. Map scatterlists before dmaengine_prep_slave_sg() 2. Use dma_async() functions inside of the send_command() path and call terminate_sync() in non-atomic context in case of an error. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-4-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci: Factor out some operations set to their own functionsFaiz Abbas
In preparation for adding external dma support, factor out data initialization, block info and mrq_done to their own functions. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Tested-by: Baolin Wang <baolin.wang7@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200116105154.7685-3-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20dt-bindings: sdhci-omap: Add properties for using external dmaChunyan Zhang
sdhci-omap can support both external dma controller via dmaengine framework as well as ADMA which standard SD host controller provides. Add binding documentation for these external dma properties. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200116105154.7685-2-faiz_abbas@ti.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20dt-bindings: mmc: fsl-imx-esdhc: add i.MX8MP compatible stringAnson Huang
Add compatible string for imx8mp Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1578893602-14395-2-git-send-email-Anson.Huang@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20net: dsa: mv88e6xxx: Add SERDES stats counters to all 6390 family membersAndrew Lunn
The SERDES statistics are valid for all members of the 6390 family, not just the 6390 itself. Add the needed callbacks to all members of the family. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: phylink: allow in-band AN for USXGMIIAlex Marginean
USXGMII supports passing link information in-band between PHY and MAC PCS, add it to the list of protocols that support in-band AN mode. Being a MAC-PHY protocol that can auto-negotiate link speeds up to 10 Gbps, we populate the initial supported mask with the entire spectrum of link modes up to 10G that PHYLINK supports, and we let the driver reduce that mask in its .phylink_validate method. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20gpio/sifive: Add DT documentation for SiFive GPIOYash Shah
DT json-schema for GPIO controller added. Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> [Atish: Compatible string update] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-5-git-send-email-yash.shah@sifive.com
2020-01-20irqchip/sifive-plic: Support irq domain hierarchyYash Shah
Add support for hierarchical irq domains. This is needed as pre-requisite for gpio-sifive driver. Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-4-git-send-email-yash.shah@sifive.com
2020-01-20irqchip/nvic: Use irq_domain_translate_onecell instead of custom funcYash Shah
Make use of newly introduced irq_domain_translate_onecell() instead of custom made function. Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-3-git-send-email-yash.shah@sifive.com
2020-01-20genirq: Introduce irq_domain_translate_onecellYash Shah
Add a new function irq_domain_translate_onecell() that is to be used as the translate function in struct irq_domain_ops. Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1575976274-13487-2-git-send-email-yash.shah@sifive.com
2020-01-20net: phy: don't crash in phy_read/_write_mmd without a PHY driverAlex Marginean
The APIs can be used by Ethernet drivers without actually loading a PHY driver. This may become more widespread in the future with 802.3z compatible MAC PCS devices being locally driven by the MAC driver when configuring for a PHY mode with in-band negotiation. Check that drv is not NULL before reading from it. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: phylink: Allow 2.5BASE-T, 5GBASE-T and 10GBASE-T for the 10G link modesVladimir Oltean
For some reason, PHYLINK does not put the copper modes for 802.3bz (NBASE-T) and 802.3an-2006 (10GBASE-T) in the PHY's supported mask, when the PHY-MAC connection is a 10G-capable one (10GBase-KR, 10GBase-R, USXGMII). One possible way through which the cable side can work at the lower speed is by having the PHY emit PAUSE frames towards the MAC. So fix that omission. Also include the 2500Base-X fiber mode in this list while we're at it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: ip6_gre: fix moving ip6gre between namespacesNiko Kortstrom
Support for moving IPv4 GRE tunnels between namespaces was added in commit b57708add314 ("gre: add x-netns support"). The respective change for IPv6 tunnels, commit 22f08069e8b4 ("ip6gre: add x-netns support") did not drop NETIF_F_NETNS_LOCAL flag so moving them from one netns to another is still denied in IPv6 case. Drop NETIF_F_NETNS_LOCAL flag from ip6gre tunnels to allow moving ip6gre tunnel endpoints between network namespaces. Signed-off-by: Niko Kortstrom <niko.kortstrom@nokia.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20net: stmmac: modified pcs mode support for RGMIIDejin Zheng
snps databook noted that physical coding sublayer (PCS) interface that can be used when the MAC is configured for the TBI, RTBI, or SGMII PHY interface. we have RGMII and SGMII in a SoC and it also has the PCS block. it needs stmmac_init_phy and stmmac_mdio_register function for initializing phy when it used RGMII interface. Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20cpufreq: brcmstb-avs: fix imbalance of cpufreq policy refcountchenqiwu
brcm_avs_cpufreq_get() calls cpufreq_cpu_get() to get the cpufreq policy, meanwhile, it also increments the kobject reference count to mark it busy. However, a corresponding call of cpufreq_cpu_put() is ignored to decrement the kobject reference count back, which may lead to a potential stuck risk that the cpuhp thread deadly waits for dropping of kobject refcount when cpufreq policy free. With this patch, the cpuhp thread can be easily exercised by attempting to force an unbind of the CPUfreq driver. Signed-off-by: chenqiwu <chenqiwu@xiaomi.com> [ Viresh: Dropped !policy check ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-01-20Merge tag 'perf-core-for-mingo-5.6-20200116' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: perf report: Andi Kleen: - Clarify in help that --children is default. Jin Yao: - Fix no libunwind compiled warning breaking s390. perf annotate/report/top: Andi Kleen: - Support --prefix/--prefix-strip, use it with objdump when doing disassembly. perf c2c: Andres Freund: - Fix return type for histogram sorting comparision functions. perf header: Michael Petlan: - Use last modification time for timestamp, i.e. st.st_mtime instead of the st_ctime. perf beauty: Cengiz Can: - Fix sockaddr printf format for long integers. libperf: Jiri Olsa: - Setup initial evlist::all_cpus value perf parser: Jiri Olsa: - Use %define api.pure full instead of %pure-parser, nuking warning from bison about using deprecated stuff. perf ui gtk: - Add missing zalloc object, fixing gtk browser build. perf clang: Maciej S. Szmigiero: - Fix build issues with Clang 9 and 8+. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20Merge tag 'v5.5-rc7' into perf/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20x86/boot/compressed: Relax sed symbol type regex for LLVM ld.lldArd Biesheuvel
The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h The symbol type is indicated by a single letter, which we match strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored. Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases. However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be undefined in a subtraction expression init_size: .long (0x00000000008fd000 - ZO_startup_32 + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
2020-01-20efi/x86: avoid KASAN false positives when accessing the 1: 1 mappingArd Biesheuvel
When installing the EFI virtual address map during early boot, we access the EFI system table to retrieve the 1:1 mapped address of the SetVirtualAddressMap() EFI runtime service. This memory is not known to KASAN, so on KASAN enabled builds, this may result in a splat like ================================================================== BUG: KASAN: user-memory-access in efi_set_virtual_address_map+0x141/0x354 Read of size 4 at addr 000000003fbeef38 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc5+ #758 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0x8b/0xbb ? efi_set_virtual_address_map+0x141/0x354 ? efi_set_virtual_address_map+0x141/0x354 __kasan_report+0x176/0x192 ? efi_set_virtual_address_map+0x141/0x354 kasan_report+0xe/0x20 efi_set_virtual_address_map+0x141/0x354 ? efi_thunk_runtime_setup+0x148/0x148 ? __inc_numa_state+0x19/0x90 ? memcpy+0x34/0x50 efi_enter_virtual_mode+0x5fd/0x67d start_kernel+0x5cd/0x682 ? mem_encrypt_init+0x6/0x6 ? x86_family+0x5/0x20 ? load_ucode_bsp+0x46/0x154 secondary_startup_64+0xa4/0xb0 ================================================================== Since this code runs only a single time during early boot, let's annotate it as __no_sanitize_address so KASAN disregards it entirely. Fixes: 698294704573 ("efi/x86: Split SetVirtualAddresMap() wrappers into ...") Reported-by: Qian Cai <cai@lca.pw> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-01-20efi: Fix handling of multiple efi_fake_mem= entriesDan Williams
Dave noticed that when specifying multiple efi_fake_mem= entries only the last entry was successfully being reflected in the efi memory map. This is due to the fact that the efi_memmap_insert() is being called multiple times, but on successive invocations the insertion should be applied to the last new memmap rather than the original map at efi_fake_memmap() entry. Rework efi_fake_memmap() to install the new memory map after each efi_fake_mem= entry is parsed. This also fixes an issue in efi_fake_memmap() that caused it to litter emtpy entries into the end of the efi memory map. An empty entry causes efi_memmap_insert() to attempt more memmap splits / copies than efi_memmap_split_count() accounted for when sizing the new map. When that happens efi_memmap_insert() may overrun its allocation, and if you are lucky will spill over to an unmapped page leading to crash signature like the following rather than silent corruption: BUG: unable to handle page fault for address: ffffffffff281000 [..] RIP: 0010:efi_memmap_insert+0x11d/0x191 [..] Call Trace: ? bgrt_init+0xbe/0xbe ? efi_arch_mem_reserve+0x1cb/0x228 ? acpi_parse_bgrt+0xa/0xd ? acpi_table_parse+0x86/0xb8 ? acpi_boot_init+0x494/0x4e3 ? acpi_parse_x2apic+0x87/0x87 ? setup_acpi_sci+0xa2/0xa2 ? setup_arch+0x8db/0x9e1 ? start_kernel+0x6a/0x547 ? secondary_startup_64+0xb6/0xc0 Commit af1648984828 "x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage" introduced more occurrences where efi_memmap_insert() is invoked after an efi_fake_mem= configuration has been parsed. Previously the side effects of vestigial empty entries were benign, but with commit af1648984828 that follow-on efi_memmap_insert() invocation triggers efi_memmap_insert() overruns. Reported-by: Dave Young <dyoung@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20191231014630.GA24942@dhcp-128-65.nay.redhat.com Link: https://lore.kernel.org/r/20200113172245.27925-14-ardb@kernel.org
2020-01-20efi: Fix efi_memmap_alloc() leaksDan Williams
With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be updated and replaced multiple times. When that happens a previous dynamically allocated efi memory map can be garbage collected. Use the new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically allocated memory map is being replaced. Debug statements in efi_memmap_free() reveal: efi: __efi_memmap_free:37: phys: 0x23ffdd580 size: 2688 flags: 0x2 efi: __efi_memmap_free:37: phys: 0x9db00 size: 2640 flags: 0x2 efi: __efi_memmap_free:37: phys: 0x9e580 size: 2640 flags: 0x2 ...a savings of 7968 bytes on a qemu boot with 2 entries specified to efi_fake_mem=. [ ardb: added a comment to clarify that efi_memmap_free() does nothing when called from efi_clean_memmap(), i.e., with data->flags == 0x0 ] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-13-ardb@kernel.org
2020-01-20efi: Add tracking for dynamically allocated memmapsDan Williams
In preparation for fixing efi_memmap_alloc() leaks, add support for recording whether the memmap was dynamically allocated from slab, memblock, or is the original physical memmap provided by the platform. Given this tracking is established in efi_memmap_alloc() and needs to be carried to efi_memmap_install(), use 'struct efi_memory_map_data' to convey the flags. Some small cleanups result from this reorganization, specifically the removal of local variables for 'phys' and 'size' that are already tracked in @data. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200113172245.27925-12-ardb@kernel.org
generated by cgit (git 2.34.1) at 2025-09-17 11:49:26 +0000