- 14 May, 2017 40 commits
-
-
Emmanuel Grumbach authored
commit 04fa3e68 upstream. David reported that the code I added uses the decrement and increment operator on a boolean variable. Fix that. Fixes: 0cd58eaa ("iwlwifi: pcie: allow the op_mode to block the tx queues") Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johannes Berg authored
commit bd05a5bd upstream. We don't really need clear the skb's status area nor store the dev_cmd into it until we really commit to the frame by handing it to the transport - defer those operations until just before we do that. This doesn't entirely fix the bug with frames not getting sent out after having been deferred due to DQA, because it doesn't restore the info->driver_data[0] place that was already set to zero (or another value) by the A-MSDU logic. Fixes: 24afba76 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luca Coelho authored
commit bac453ab upstream. For unified images, we shouldn't restart the HW if suspend fails. The only reason for restarting the HW with non-unified images is to go back to the D0 image. Fixes: 23ae6128 ("iwlwifi: mvm: Do not switch to D3 image on suspend") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jürg Billeter authored
commit d8320d75 upstream. IWL6000G2B_UCODE_API_MAX is not defined. ucode_api_max of IWL_DEVICE_6030 uses IWL6000G2_UCODE_API_MAX. Use this also for MODULE_FIRMWARE. Fixes: 9d9b21d1 ("iwlwifi: remove IWL_*_UCODE_API_OK") Signed-off-by: Jürg Billeter <j@bitron.ch> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johannes Berg authored
commit c2e27e16 upstream. When copying from vmalloc'ed memory to the SG list, don't crash if the transport didn't provide any data. Fixes: 7e62a699 ("iwlwifi: mvm: use dev_coredumpsg()") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Brian Norris authored
commit ba1c7e45 upstream. The mwifiex_dbg() log handler utilizes the struct device in adapter->dev. Without it, it decides not to print anything. As of commit 2e02b581 ("mwifiex: Allow mwifiex early access to device structure"), we started assigning that pointer only after we finished mwifiex_register() -- this effectively neuters any mwifiex_dbg() logging done before this point. Let's move the device assignment into mwifiex_register(). Fixes: 2e02b581 ("mwifiex: Allow mwifiex early access to device structure") Cc: Rajat Jain <rajatja@google.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Brian Norris authored
commit 2447e2ca upstream. If we don't have an out-of-band wakeup IRQ configured through DT (as most platforms don't), then we fall out of this function with 'irq_wakeup == 0'. Other code (e.g., mwifiex_disable_wake() and mwifiex_enable_wake()) treats 'irq_wakeup >= 0' as a valid IRQ, and so we end up calling {enable,disable}_irq() on IRQ 0. That seems bad, so let's not do that. Same problem as fixed in this patch: https://patchwork.kernel.org/patch/9531693/ [PATCH v2 2/3] btmrvl: set irq_bt to -1 when failed to parse it with the difference that: (a) this one is actually a regression and (b) this affects both device tree and non-device-tree systems While fixing the regression, also drop the verbosity on the parse failure, so we don't see this when a DT node is present but doesn't have an interrupt property (this is perfectly legal): [ 21.999000] mwifiex_pcie 0000:01:00.0: fail to parse irq_wakeup from device tree Fixes: 853402a0 ("mwifiex: Enable WoWLAN for both sdio and pcie") Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Rajat Jain <rajatja@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ganapathi Bhat authored
commit a5b60de6 upstream. This patch fixes the issue specific to AP. AP is started with WEP security and external station is connected to it. Data path works in this case. Now if AP is restarted with WPA/WPA2 security, station is able to connect but ping fails. Driver skips the deletion of WEP keys if interface type is AP. Removing that redundant check resolves the issue. Fixes: e57f1734 ("mwifiex: add key material v2 support") Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Xinming Hu authored
commit 5f0a221f upstream. We already ensure 64 bytes alignment and add padding if required during skb_aggr allocation. Alignment and padding in mwifiex_11n_form_amsdu_txpd() is redundant. We may end up accessing more data than allocated size with this. This patch fixes following issue by removing redundant padding. [ 370.241338] skbuff: skb_over_panic: text:ffffffffc046946a len:3550 put:72 head:ffff880000110000 data:ffff8800001100e4 tail:0xec2 end:0xec0 dev:<NULL> [ 370.241374] ------------[ cut here ]------------ [ 370.241382] kernel BUG at net/core/skbuff.c:104! 370.244032] Call Trace: [ 370.244041] [<ffffffff8c3df5ec>] skb_put+0x44/0x45 [ 370.244055] [<ffffffffc046946a>] mwifiex_11n_aggregate_pkt+0x1e9/0xa50 [mwifiex] [ 370.244067] [<ffffffffc0467c16>] mwifiex_wmm_process_tx+0x44a/0x6b7 [mwifiex] [ 370.244074] [<ffffffffc0411eb8>] ? 0xffffffffc0411eb8 [ 370.244084] [<ffffffffc046116b>] mwifiex_main_process+0x476/0x5a5 [mwifiex] [ 370.244098] [<ffffffffc0461298>] mwifiex_main_process+0x5a3/0x5a5 [mwifiex] [ 370.244113] [<ffffffff8be7e9ff>] process_one_work+0x1a4/0x309 [ 370.244123] [<ffffffff8be7f4ca>] worker_thread+0x20c/0x2ee [ 370.244130] [<ffffffff8be7f2be>] ? rescuer_thread+0x383/0x383 [ 370.244136] [<ffffffff8be7f2be>] ? rescuer_thread+0x383/0x383 [ 370.244143] [<ffffffff8be83742>] kthread+0x11c/0x124 [ 370.244150] [<ffffffff8be83626>] ? kthread_parkme+0x24/0x24 [ 370.244157] [<ffffffff8c4da1ef>] ret_from_fork+0x3f/0x70 [ 370.244168] [<ffffffff8be83626>] ? kthread_parkme+0x24/0x24 Fixes: 84b313b3 ("mwifiex: make tx packet 64 byte DMA aligned") Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Brian Norris authored
commit 6183468a upstream. Similar to commit fcd2042e ("mwifiex: printk() overflow with 32-byte SSIDs"), we failed to account for the existence of 32-char SSIDs in our debugfs code. Unlike in that case though, we zeroed out the containing struct first, and I'm pretty sure we're guaranteed to have some padding after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes long). So, this is the difference between: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef " ... and the correct output: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef" ... Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Florian Fainelli authored
commit 0cdefd5b upstream. The CPU port of the BCM53125 is configured with RGMII (no delays) but this should actually be RGMII with transmit delay (rgmii-txid) because STMMAC takes care of inserting the transmitter delay. This fixes occasional packet loss encountered. Fixes: d7b9eaff ("ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board") Reported-by: Hartmut Knaack <knaack.h@gmx.de> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sekhar Nori authored
commit f5432f01 upstream. commit 50e95b6b ("ARM: dts: am57xx-idk: Add Industrial output support") added the TPIC2810 device-tree node under SPI bus instead of I2C1. Fix it. Tested on AM572x IDK by driving on-board LEDs connected to TPIC2810 Fixes: 50e95b6b ("ARM: dts: am57xx-idk: Add Industrial output support") Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tony Lindgren authored
commit 17912508 upstream. Commit d9d9cec0 ("ARM: OMAP2+: Remove legacy data from hwmod for omap3") dropped platform data that should no longer be used as we're booting with device tree. It turns out that smartreflex is still using platform data and produces the following errors during probe: smartreflex smartreflex.0: invalid resource smartreflex smartreflex.0: omap_sr_probe: ioremap fail smartreflex: probe of smartreflex.0 failed with error -22 smartreflex smartreflex.1: invalid resource smartreflex smartreflex.1: omap_sr_probe: ioremap fail smartreflex: probe of smartreflex.1 failed with error -22 Let's fix the regression by adding back the smartreflex hwmod data. The long term is to update the smartreflex driver to use device tree based probing. Fixes: d9d9cec0 ("ARM: OMAP2+: Remove legacy data from hwmod for omap3") Reported-by: Adam Ford <aford173@gmail.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs van Duin authored
commit 448c077e upstream. 'adr' yields a data-pointer, not a function-pointer. Fixes: 999f934d ("ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode") Signed-off-by: Matthijs van Duin <matthijsvanduin@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fabio Estevam authored
commit 12aff997 upstream. After issuing a 'reboot' command the imx6sx-udoo-neo board does not reboot as expected and it just hangs instead. In mainline kernel only LDO enabled mode is supported. Do not provide arm-supply/soc-supply nodes in the device tree, so that the board operates in LDO enabled mode and can then successfully reboot via watchdog. Fixes: 76e691fc ("ARM: dts: imx6sx: Add UDOO Neo support") Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Breno Lima <breno.lima@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jon Mason authored
commit acfa28b3 upstream. The libgpio code pre-sets the GPIO values for the gpio-reset in the device tree. This results in the device being reset during bringup. To prevent this pre-setting, use the "open-source" flag in the device tree. Signed-off-by: Jon Mason <jon.mason@broadcom.com> Fixes: b1aaf88b ("ARM: dts: NSP: Add GPIO reboot method to bcm958625hr DTS file") Fixes: 10baed1c ("ARM: dts: NSP: Add GPIO reboot method to bcm958625xmc DTS file") Fixes: 088e3148 ("ARM: dts: NSP: Add new DT file for bcm958522er") Fixes: e3227c12 ("ARM: dts: NSP: Add new DT file for bcm958525er") Fixes: 2f8bc002 ("ARM: dts: NSP: Add new DT file for bcm958622hr") Fixes: d454c376 ("ARM: dts: NSP: Add new DT file for bcm958623hr") Fixes: f27eacf2 ("ARM: dts: NSP: Add new DT file for bcm988312hr") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
commit 67af5ebd upstream. The camera_supply_dummy_device definition is shared between a780 and a910, but only provided when the first is enabled and fails to build for a configuration with only a910: arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function) This moves the definition into its own section. Fixes: 6c1b417a ("ARM: pxa: ezx: use the new pxa_camera platform_data") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
commit cbe99c53 upstream. gcc gets confused about the control flow in ktd2692_parse_dt(), causing it to warn about what seems like a potential bug: drivers/leds/leds-ktd2692.c: In function 'ktd2692_probe': drivers/leds/leds-ktd2692.c:244:15: error: '*((void *)&led_cfg+8)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/leds/leds-ktd2692.c:225:7: error: 'led_cfg.flash_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/leds/leds-ktd2692.c:232:3: error: 'led_cfg.movie_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code is fine, and slightly reworking it in an equivalent way lets gcc figure that out too, which gets rid of the warning. Fixes: 77e7915b ("leds: ktd2692: Add missing of_node_put") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei Yongjun authored
commit e92f0051 upstream. The call to spi_master_put() in a3700_spi_remove() is redundant since the master is registered using devm_spi_register_master() and no reference hold by using spi_master_get() in a3700_spi_remove(). This is detected by Coccinelle semantic patch. Fixes: 5762ab71 ("spi: Add support for Armada 3700 SPI Controller") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Catalin Marinas authored
commit ec663d96 upstream. Commit cab15ce6 ("arm64: Introduce execute-only page access permissions") allowed a valid user PTE to have the PTE_USER bit clear. As a consequence, the pte_valid_not_user() macro in set_pte() was replaced with pte_valid_global() under the assumption that only user pages have the nG bit set. EFI mappings, however, also have the nG bit set and set_pte() wrongly ignores issuing the DSB+ISB. This patch reinstates the pte_valid_not_user() macro and adds the PTE_UXN bit check since all kernel mappings have this bit set. For clarity, pte_exec() is renamed to pte_user_exec() as it only checks for the absence of PTE_UXN. Consequently, the user executable check in set_pte_at() drops the pte_ng() test since pte_user_exec() is sufficient. Fixes: cab15ce6 ("arm64: Introduce execute-only page access permissions") Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juri Lelli authored
commit fe0a7ef7 upstream. The sysfs cpu_capacity entry for each CPU has nothing to do with PROC_FS, nor it's in /proc/sys path. Remove such ifdef. Cc: Will Deacon <will.deacon@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Reported-and-suggested-by: Sudeep Holla <sudeep.holla@arm.com> Fixes: be8f185d ('arm64: add sysfs cpu_capacity attribute') Signed-off-by: Juri Lelli <juri.lelli@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit 06dbf468 upstream. The ipq board has these rates as 25MHz, and not 19.2 and 27. I copy/pasted from other boards that have those rates but forgot to fix the rates here. Fixes: 30fc4212 ("arm: dts: qcom: Add more board clocks") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
commit 0d1390ff upstream. Device nodes representing I/O devices should be marked disabled in the SoC-specific DTS, and overridden by board-specific DTSes where needed. Fixes: a92843c8 ("arm64: dts: r8a7795: add EthernetAVB device node") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liam Breck authored
commit ba52e757 upstream. Reading both fault and status registers and logging any fault should take priority over handling status register update. Fix by moving the status handling to later in interrupt routine. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liam Breck authored
commit 68abfb80 upstream. Caching the fault register after a single I2C read may not keep an accurate value. Fix by doing two reads in irq_handle_thread() and using the cached value elsewhere. If a safety timer fault later clears itself, we apparently don't get an interrupt (INT), however other interrupts would refresh the register cache. From the data sheet: "When a fault occurs, the charger device sends out INT and keeps the fault state in REG09 until the host reads the fault register. Before the host reads REG09 and all the faults are cleared, the charger device would not send any INT upon new faults. In order to read the current fault status, the host has to read REG09 two times consecutively. The 1st reads fault register status from the last read [1] and the 2nd reads the current fault register status." [1] presumably a typo; should be "last fault" Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liam Breck authored
commit 2d9fee6a upstream. We wrongly get uevents for bq24190-charger and bq24190-battery on every register change. Fix by checking the association with charger and battery before emitting uevent(s). Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liam Breck authored
commit d62acc5e upstream. The device specific data is not fully initialized on request_threaded_irq(). This may cause a crash when the IRQ handler tries to reference them. Fix the issue by installing IRQ handler at the end of the probe. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liam Breck authored
commit e05ad7e0 upstream. pm_resume() does a register_reset() which clears charger host mode. Fix by calling set_mode_host() after the reset. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Liam Breck authored
commit 767eee36 upstream. The interrupt signal is TRIGGER_FALLING. This is is specified in the data sheet PIN FUNCTIONS: "The INT pin sends active low, 256us pulse to host to report charger device status and fault." Also the direction can be seen in the data sheet Figure 37 "BQ24190 with D+/D- Detection and USB On-The-Go (OTG)" which shows a 10k pull-up resistor installed for the sample configurations. Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger") Signed-off-by: Liam Breck <kernel@networkimprov.net> Acked-by: Mark Greer <mgreer@animalcreek.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alexander Shishkin authored
commit 5443624b upstream. Commit: 8ee83b2a ("perf/x86/intel/pt: Add support for PTWRITE and power event tracing") forgot to add format strings to the PT driver. So one could enable these features by setting corresponding bits in the event config, but not by their mnemonic names. This patch adds the format strings. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Borislav Petkov <bp@suse.de> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: vince@deater.net Fixes: 8ee83b2a ("perf/x86/intel/pt: Add support for PTWRITE...") Link: http://lkml.kernel.org/r/20170127151644.8585-2-alexander.shishkin@linux.intel.comSigned-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrew Donnellan authored
commit eac6f8b0 upstream. Commit 38addce8 ("gcc-plugins: Add latent_entropy plugin") excludes certain powerpc early boot code from the latent entropy plugin by adding appropriate CFLAGS. It looks like this was supposed to cover prom_init.o, but ended up saying init.o (which doesn't exist) instead. Fix the typo. Fixes: 38addce8 ("gcc-plugins: Add latent_entropy plugin") Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Anton Blanchard authored
commit 496e9cb5 upstream. The final paragraph of the help text is reversed. We want to enable this option by default, and disable it if the toolchain has a working -mprofile-kernel. Fixes: 8c50b72a ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel") Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Ellerman authored
commit a05ef161 upstream. Currently the build breaks if CMA=n and SPAPR_TCE_IOMMU=y: arch/powerpc/mm/mmu_context_iommu.c: In function ‘mm_iommu_get’: arch/powerpc/mm/mmu_context_iommu.c:193:42: error: ‘MIGRATE_CMA’ undeclared (first use in this function) if (get_pageblock_migratetype(page) == MIGRATE_CMA) { ^~~~~~~~~~~ Fix it by using the existing is_migrate_cma_page(), which evaulates to false when CMA=n. Fixes: 2e5bbb54 ("KVM: PPC: Book3S HV: Migrate pinned pages out of CMA") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Ellerman authored
commit a7e0fb6c upstream. Currently the opal_exit tracepoint usually shows the opcode as 0: <idle>-0 [047] d.h. 635.654292: opal_entry: opcode=63 <idle>-0 [047] d.h. 635.654296: opal_exit: opcode=0 retval=0 kopald-1209 [019] d... 636.420943: opal_entry: opcode=10 kopald-1209 [019] d... 636.420959: opal_exit: opcode=0 retval=0 This is because we incorrectly load the opcode into r0 before calling __trace_opal_exit(), whereas it expects the opcode in r3 (first function parameter). In fact we are leaving the retval in r3, so opcode and retval will always show the same value. Instead load the opcode into r3, resulting in: <idle>-0 [040] d.h. 636.618625: opal_entry: opcode=63 <idle>-0 [040] d.h. 636.618627: opal_exit: opcode=63 retval=0 Fixes: c49f6353 ("powernv: Add OPAL tracepoints") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aneesh Kumar K.V authored
commit 4ab2537c upstream. In commit a4b34954 ("powerpc/mm: Cleanup LPCR defines") we updated LPCR_VRMASD wrongly as below. -#define LPCR_VRMASD (0x1ful << (63-16)) +#define LPCR_VRMASD_SH 47 +#define LPCR_VRMASD (ASM_CONST(1) << LPCR_VRMASD_SH) We initialize the VRMA bits in LPCR to 0x00 in kvm. Hence using a different mask value as above while updating lpcr should not have any impact. This patch updates it to the correct value. Fixes: a4b34954 ("powerpc/mm: Cleanup LPCR defines") Reported-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Jia He <hejianet@gmail.com> Acked-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Madhavan Srinivasan authored
commit 78a16d9f upstream. Since power9 does not support FAB_*_MATCH bits in MMCR1, avoid these checks for power9. For this, patch factor out code in isa207_get_constraint() to retain these checks only for power8. Patch also updates the comment in power9-pmu raw event encode layout to remove FAB_*_MATCH. Finally for power9, patch adds additional check for threshold events when adding the thresh mask and value in isa207_get_constraint(). fixes: 7ffd948f ('powerpc/perf: factor out power8 pmu functions') fixes: 18201b20 ('powerpc/perf: power9 raw event format encoding') Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Madhavan Srinivasan authored
commit 78b4416a upstream. MMCRA[SDAR_MODE] specifices how the SDAR should be updated in continous sampling mode. On P9 it must be set to 0b00 when MMCRA[63] is set. Fixes: c7c3f568 ('powerpc/perf: macros for power9 format encoding') Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Madhavan Srinivasan authored
commit f04d1080 upstream. Power9 DD1 do not support PMU_HAS_SIER flag and sdsync in perf_get_data_addr() defaults to MMCRA_SDSYNC which is wrong. Since power9 MMCRA does not support SDSYNC bit, patch includes PPMU_NO_SIAR flag to the check and set the sdsync with MMCRA_SAMPLE_ENABLE; Fixes: 27593d72 ("powerpc/perf: Use MSR to report privilege level on P9 DD1") Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Hutchings authored
commit 4cca0457 upstream. The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both flags set and an assumed base clock of 100 MHz for turbo values. Reported-by: GSR <gsr.bugs@infernal-iceberg.com> Tested-by: GSR <gsr.bugs@infernal-iceberg.com> References: https://bugs.debian.org/859978 Fixes: 8fb2e440 (cpupower: Show Intel turbo ratio support via ...) Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Giedrius Statkevičius authored
commit bdd9968d upstream. val might become 7 in which case stime[7] (array of length 7) would be accessed during the scnprintf call later and that will cause issues. Obviously, string concatenation is not intended here so just a comma needs to be added to fix the issue. Fixes: 98a27664 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-