- 13 Nov, 2018 40 commits
-
-
Douglas Anderson authored
[ Upstream commit b432414b ] If you look at "pinconf-groups" in debugfs for ssbi-gpio you'll notice it looks like nonsense. The problem is fairly well described in commit 1cf86bc2 ("pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and commit 05e0c828 ("pinctrl: msm: Fix msm_config_group_get() to be compliant"), but it was pointed out that ssbi-gpio has the same problem. Let's fix it there too. Fixes: b4c45fe9 ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Douglas Anderson authored
[ Upstream commit 0d5b476f ] If you look at "pinconf-groups" in debugfs for ssbi-mpp you'll notice it looks like nonsense. The problem is fairly well described in commit 1cf86bc2 ("pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and commit 05e0c828 ("pinctrl: msm: Fix msm_config_group_get() to be compliant"), but it was pointed out that ssbi-mpp has the same problem. Let's fix it there too. NOTE: in case it's helpful to someone reading this, the way to tell whether to do the -EINVAL or not is to look at the PCONFDUMP for a given attribute. If the last element (has_arg) is false then you need to do the -EINVAL trick. ALSO NOTE: it seems unlikely that the values returned when we try to get PIN_CONFIG_BIAS_PULL_UP will actually be printed since "has_arg" is false for that one, but I guess it's still fine to return different values so I kept doing that. It seems like another driver (ssbi-gpio) uses a custom attribute (PM8XXX_QCOM_PULL_UP_STRENGTH) for something similar so maybe a future change should do that here too. Fixes: cfb24f6e ("pinctrl: Qualcomm SPMI PMIC MPP pin controller driver") Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 16329364 ] When we don't have the iputils-debuginfo package installed, i.e. when we don't have the DWARF information needed to resolve ping's samples, we end up failing this 'perf test' entry: # perf test ping 62: probe libc's inet_pton & backtrace it with ping : Ok # rpm -e iputils-debuginfo # perf test ping 62: probe libc's inet_pton & backtrace it with ping : FAILED! # Fix it to accept "[unknown]" where the symbol + offset, when resolved, is expected. I think this will fail in the other arches as well, but since I can't test now, I'm leaving s390x and ppc cases as-is. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kim Phillips <kim.phillips@arm.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Cc: Sandipan Das <sandipan@linux.vnet.ibm.com> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Cc: Thomas Richter <tmricht@linux.vnet.ibm.com> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 7903a708 ("perf script: Show symbol offsets by default") Link: https://lkml.kernel.org/n/tip-hnizqwqrs03vcq1b74yao0f6@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 9e7e6cab ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/net_failover.c: In function 'net_failover_slave_unregister': drivers/net/net_failover.c:598:35: warning: variable 'primary_dev' set but not used [-Wunused-but-set-variable] There should check the validity of 'slave_dev'. Fixes: cfc80d9a ("net: Introduce net_failover driver") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alexei Starovoitov authored
[ Upstream commit a9c676bc ] Edward Cree says: In check_mem_access(), for the PTR_TO_CTX case, after check_ctx_access() has supplied a reg_type, the other members of the register state are set appropriately. Previously reg.range was set to 0, but as it is in a union with reg.map_ptr, which is larger, upper bytes of the latter were left in place. This then caused the memcmp() in regsafe() to fail, preventing some branches from being pruned (and occasionally causing the same program to take a varying number of processed insns on repeated verifier runs). Fix the instability by clearing bpf_reg_state in __mark_reg_[un]known() Fixes: f1174f77 ("bpf/verifier: rework value tracking") Debugged-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit 89c68b10 ] It looks like we parse the drive strength setting here, but never actually write it into the hardware to update it. Parse the setting and then write it at the end of the pinconf setting function so that it actually sticks in the hardware. Fixes: 0e948042 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode") Cc: Doug Anderson <dianders@chromium.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Hans de Goede authored
[ Upstream commit 24071406 ] Bay and Cherry Trail DSTDs represent a different set of devices depending on which OS the device think it is booting. One set of decices for Windows and another set of devices for Android which targets the Android-x86 Linux kernel fork (which e.g. used to have its own display driver instead of using the i915 driver). Which set of devices we are actually going to get is out of our control, this is controlled by the ACPI OSID variable, which gets either set through an EFI setup option, or sometimes is autodetected. So we need to support both. This commit adds support for the 80862286 and 808622C0 ACPI HIDs which we get for the first resp. second DMA controller on Cherry Trail devices when OSID is set to Android. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit abf5feef ] There is a logical problem in spi-gpio with host just assigning a MOSI line and no MISO: this is interpreted as the host cannot do RX and the host is flagged with SPI_MASTER_NO_RX. This is wrong: since GPIO lines can switch direction, in 3WIRE operation the host will simply reverse the direction of the GPIO line and start reading from it, there is even code for doing this in the driver, but it went unnoticed because it was tested by using a master with 4 wires but a device using just 3 wires. Remove the offending flag. Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 819319fc ] Make reuse_unused_kprobe() to return error code if it fails to reuse unused kprobe for optprobe instead of calling BUG_ON(). Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: David S . Miller <davem@davemloft.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/153666124040.21306.14150398706331307654.stgit@devboxSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 0bf0f444 ] Rather than panic() when taking an undefined instruction exception from EL1, allow a hook to be registered in case we want to emulate the instruction, like we will for the SSBS PSTATE manipulation instructions. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Paolo Valente authored
[ Upstream commit cbeb869a ] BFQ schedules entities (which represent either per-process queues or groups of queues) as a function of their timestamps. In particular, as a function of their (virtual) finish times. The finish time of an entity is computed as a function of the budget assigned to the entity, assuming, tentatively, that the entity, once in service, will receive an amount of service equal to its budget. Then, when the entity is expired because it finishes to be served, this finish time is updated as a function of the actual service received by the entity. This allows the entity to be correctly charged with only the service received, and then to be correctly re-scheduled. Yet an entity may receive service also while not being the entity in service (in the scheduling environment of its parent entity), for several reasons. If the entity remains with no backlog while receiving this 'unofficial' service, then it is expired. Also on such an expiration, the finish time of the entity should be updated to account for only the service actually received by the entity. Unfortunately, such an update is not performed for an entity expiring without being the entity in service. In a similar vein, the service counter of the entity in service is reset when the entity is expired, to be ready to be used for next service cycle. This reset too should be performed also in case an entity is expired because it remains empty after receiving service while not being the entity in service. But in this case the reset is not performed. This commit performs the above update of the finish time and reset of the service received, also for an entity expiring while not being the entity in service. Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Antoine Tenart authored
[ Upstream commit aeeb2e8f ] Phylink made an assumption about the carrier state being down when calling phylink_start(). If this assumption isn't satisfied, the internal phylink state could misbehave and a net device could end up not being functional. This patch fixes this by explicitly calling netif_carrier_off() in phylink_start(). Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Fuyun Liang authored
[ Upstream commit 2f7e4896 ] We clear STATE_DOWN bit of hdev state when starting net, but do not set it again when stopping net. It causes that the net is down, but hdev state is still up. STATE_DOWN bit of hdev state should be set when stopping net. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by:
Fuyun Liang <liangfuyun1@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
Peng Li authored
[ Upstream commit 582d37bb ] By default, HW link status is up. If hclge_update_link_status is called before net up, driver will print "link up". It is not suitable. hdev state check is needed when getting link status. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by:
-
Arend van Spriel authored
[ Upstream commit 330994e8 ] Decoding of firmware channel information was not complete for 160MHz support. This resulted in the following warning: WARNING: CPU: 2 PID: 2222 at .../broadcom/brcm80211/brcmutil/d11.c:196 brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil] Modules linked in: brcmfmac(O) brcmutil(O) sha256_generic cfg80211 ... CPU: 2 PID: 2222 Comm: kworker/2:0 Tainted: G O 4.17.0-wt-testing-x64-00002-gf1bed50 #1 Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011 Workqueue: events request_firmware_work_func RIP: 0010:brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil] RSP: 0018:ffffc90000047bd0 EFLAGS: 00010206 RAX: 000000000000e832 RBX: ffff8801146fe910 RCX: ffff8801146fd3c0 RDX: 0000000000002800 RSI: 0000000000000070 RDI: ffffc90000047c30 RBP: ffffc90000047bd0 R08: 0000000000000000 R09: ffffffffa0798c80 R10: ffff88012bca55e0 R11: ffff880110a4ea00 R12: ffff8801146f8000 R13: ffffc90000047c30 R14: ffff8801146fe930 R15: ffff8801138e02e0 FS: 0000000000000000(0000) GS:ffff88012bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f18ce8b8070 CR3: 000000000200a003 CR4: 00000000000206e0 Call Trace: brcmf_setup_wiphybands+0x212/0x780 [brcmfmac] brcmf_cfg80211_attach+0xae2/0x11a0 [brcmfmac] brcmf_attach+0x1fc/0x4b0 [brcmfmac] ? __kmalloc+0x13c/0x1c0 brcmf_pcie_setup+0x99b/0xe00 [brcmfmac] brcmf_fw_request_done+0x16a/0x1f0 [brcmfmac] request_firmware_work_func+0x36/0x60 process_one_work+0x146/0x350 worker_thread+0x4a/0x3b0 kthread+0x102/0x140 ? process_one_work+0x350/0x350 ? kthread_bind+0x20/0x20 ret_from_fork+0x35/0x40 Code: 66 90 0f b7 07 55 48 89 e5 89 c2 88 47 02 88 47 03 66 81 e2 00 38 66 81 fa 00 18 74 6e 66 81 fa 00 20 74 39 66 81 fa 00 10 74 14 <0f> 0b 66 25 00 c0 74 20 66 3d 00 c0 75 20 c6 47 04 01 5d c3 66 ---[ end trace 550c46682415b26d ]--- brcmfmac: brcmf_construct_chaninfo: Ignoring unexpected firmware channel 50 This patch adds the missing stuff to properly handle this. Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 69f8455f ] 'ret' should be returned while pmic_mpp_write_mode_ctl fails. Fixes: 0e948042 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode") Signed-off-by:
-
YueHaibing authored
[ Upstream commit a4925311 ] fixes following Smatch static check warning: ./drivers/pinctrl/sunxi/pinctrl-sunxi.c:1112 sunxi_pinctrl_build_state() warn: passing devm_ allocated variable to kfree. 'pctrl->functions' As we will be calling krealloc() on pointer 'pctrl->functions', which means kfree() will be called in there, devm_kzalloc() shouldn't be used with the allocation in the first place. Fix the warning by calling kcalloc() and managing the free procedure in error path on our own. Fixes: 0e37f88d ("ARM: sunxi: Add pinctrl driver for Allwinner SoCs") Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Jian Shen authored
[ Upstream commit adefc0a2 ] There is a defect in hclge_ets_validate(). If each member of tc_tsa is not IEEE_8021QAZ_TSA_ETS, the variable total_ets_bw won't be updated. In this case, the check for value of total_ets_bw will fail. This patch fixes it by checking total_ets_bw only after it has been updated. Fixes: cacde272 ("net: hns3: Add hclge_dcb module for the support of DCB feature") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jian Shen authored
[ Upstream commit 7a810110 ] When nic down, it firstly calls netif_tx_stop_all_queues(), then calls napi_disable(). But napi_disable() will wait current napi_poll finish, it may call netif_tx_wake_queue(). This patch fixes it by add nic state checking. Fixes: 424eb834 ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by:
-
Ben Hutchings authored
[ Upstream commit 9c1442a9 ] We currently align the end of the compressed image to a multiple of 16. However, the PE-COFF header included in the EFI stub says that the file alignment is 32 bytes, and when adding an EFI signature to the file it must first be padded to this alignment. sbsigntool commands warn about this: warning: file-aligned section .text extends beyond end of file warning: checksum areas are greater than image size. Invalid section table? Worse, pesign -at least when creating a detached signature- uses the hash of the unpadded file, resulting in an invalid signature if padding is required. Avoid both these problems by increasing alignment to 32 bytes when CONFIG_EFI_STUB is enabled. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit c33ce984 ] Before this commit we were only calling efi_parse_options() from make_boot_params(), but make_boot_params() only gets called if the kernel gets booted directly as an EFI executable. So when booted through e.g. grub we ended up not parsing the commandline in the boot code. This makes the drivers/firmware/efi/libstub code ignore the "quiet" commandline argument resulting in the following message being printed: "EFI stub: UEFI Secure Boot is enabled." Despite the quiet request. This commits adds an extra call to efi_parse_options() to efi_main() to make sure that the options are always processed. This fixes quiet not working. This also fixes the libstub code ignoring nokaslr and efi=nochunk. Reported-by:
Peter Robinson <pbrobinson@redhat.com> Signed-off-by:
-
Balakrishna Godavarthi authored
[ Upstream commit c2d78273 ] When flag KASAN is set, we are seeing an following crash while removing hci_uart module. [ 50.589909] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b73 [ 50.597902] Mem abort info: [ 50.600846] Exception class = DABT (current EL), IL = 32 bits [ 50.606959] SET = 0, FnV = 0 [ 50.610142] EA = 0, S1PTW = 0 [ 50.613396] Data abort info: [ 50.616401] ISV = 0, ISS = 0x00000004 [ 50.620373] CM = 0, WnR = 0 [ 50.623466] [006b6b6b6b6b6b73] address between user and kernel address ranges [ 50.630818] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 50.671670] PC is at qca_power_shutdown+0x28/0x100 [hci_uart] [ 50.677593] LR is at qca_close+0x74/0xb0 [hci_uart] [ 50.775689] Process rmmod (pid: 2144, stack limit = 0xffffff801ba90000) [ 50.782493] Call trace: [ 50.872150] [<ffffff8000c3c81c>] qca_power_shutdown+0x28/0x100 [hci_uart] [ 50.879138] [<ffffff8000c3c968>] qca_close+0x74/0xb0 [hci_uart] [ 50.885238] [<ffffff8000c3a71c>] hci_uart_unregister_device+0x44/0x50 [hci_uart] [ 50.892846] [<ffffff8000c3c9f4>] qca_serdev_remove+0x50/0x5c [hci_uart] [ 50.899654] [<ffffff800844f630>] serdev_drv_remove+0x28/0x38 [ 50.905489] [<ffffff800850fc44>] device_release_driver_internal+0x140/0x1e4 [ 50.912653] [<ffffff800850fd94>] driver_detach+0x78/0x84 [ 50.918121] [<ffffff800850edac>] bus_remove_driver+0x80/0xa8 [ 50.923942] [<ffffff80085107dc>] driver_unregister+0x4c/0x58 [ 50.929768] [<ffffff8000c3ca8c>] qca_deinit+0x24/0x598 [hci_uart] [ 50.936045] [<ffffff8000c3ca10>] hci_uart_exit+0x10/0x48 [hci_uart] [ 50.942495] [<ffffff8008136630>] SyS_delete_module+0x17c/0x224 This crash is due to dereference of hdev, after freeing it. Signed-off-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Christian Hewitt authored
[ Upstream commit a357ea09 ] This patch adds the device ID for the AMPAK AP6335 combo module used in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI chip identifies itself as BCM4339, while Bluetooth identifies itself as BCM4335 (rev C0): ``` [ 4.864248] Bluetooth: hci0: BCM: chip id 86 [ 4.866388] Bluetooth: hci0: BCM: features 0x2f [ 4.889317] Bluetooth: hci0: BCM4335C0 [ 4.889332] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0000 [ 9.778383] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0268 ``` Output from hciconfig: ``` hci0: Type: Primary Bus: UART BD Address: 43:39:00:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:7567 acl:234 sco:0 events:386 errors:0 TX bytes:53844 acl:77 sco:0 commands:304 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'HUB' Class: 0x0c0000 Service Classes: Rendering, Capturing Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x10c LMP Version: 4.0 (0x6) Subversion: 0x6109 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Signed-off-by:
-
Yunsheng Lin authored
[ Upstream commit 996ff918 ] The hardware expects a unit of 128 bytes when setting packet buffer. When calculating the packet buffer size, hclge_rx_buffer_calc does not round up the size as a unit of 128 byte, which may casue packet lost problem when stress testing. This patch fixes it by rounding up packet size when calculating. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
-
Jacob Keller authored
[ Upstream commit 396fbf9c ] We have MAX_FW_API_VER_BRANCH, MAX_FW_API_VER_MAJOR, and MAX_FW_API_VER_MINOR that we use in ice_controlq.h to test when a firmware version is newer than expected. This is currently tested by comparing each field separately. Thus, we compare the branch field against the MAX_FW_API_VER_BRANCH, and so forth. This means that currently, if we suppose that the max firmware version is defined as 0.2.1, i.e. Then firmware 0.1.3 will fail to load. This is because the minor version 3 is greater than the max minor version 1. This is not intuitive, because of the notion that increasing the major firmware version to 2 should mean any firmware version with a major version is less than 2 should be considered older than 2... In order to allow both 0.2.1 and 0.1.3 to load, you would have to define the "max" firmware version as 0.2.3.. It is possible that such a firmware version doesn't even exist yet! Fix this by replacing the current logic with an updated check that behaves as follows: First, we check the major version. If it is greater than the expected version, then we prevent driver load. Additionally, a warning message is logged to indicate to the system administrator that they need to update their driver. This is now the only case where the driver will refuse to load. Second, if the major version is less than the expected version, we log an information message indicating the NVM should be updated. Third, if the major version is exact, we'll then check the minor version. If the minor version is more than two versions less than expected, we log an information message indicating the NVM should be updated. If it is more than two versions greater than the expected version, we log an information message that the driver should be updated. To support this, the ice_aq_ver_check function needs its signature updated to pass the HW structure. Since we now pass this structure, there is no need to pass the firmware API versions separately. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Bruce Allan authored
[ Upstream commit f934bb9b ] rx_mini_pending was set to an incorrect value. This was causing EINVAL to always be returned to 'ethtool -G'. The driver does not support mini or jumbo rings so the respective settings should be zero. Also, change the valid range of the number of descriptors in the rings to make the code simpler and easier for users to understand (this removes the valid settings of 8 and 16). Add a system log message indicating when the number is rounded-up from what the user specifies with the 'ethtool -G' command (i.e. when it is not a multiple of 32), and update the log message when a user-provided value is out of range to also indicate the stride. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 22839869 ] The sigaltstack(2) system call fails with -ENOMEM if the new alternative signal stack is found to be smaller than SIGMINSTKSZ. On architectures such as arm64, where the native value for SIGMINSTKSZ is larger than the compat value, this can result in an unexpected error being reported to a compat task. See, for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904385 This patch fixes the problem by extending do_sigaltstack to take the minimum signal stack size as an additional parameter, allowing the native and compat system call entry code to pass in their respective values. COMPAT_SIGMINSTKSZ is just defined as SIGMINSTKSZ if it has not been defined by the architecture. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Reported-by:
Steve McIntyre <steve.mcintyre@arm.com> Tested-by:
Steve McIntyre <93sam@debian.org> Signed-off-by:
-
Rakesh Pillai authored
[ Upstream commit 058a7eab ] The tx_status for management frames is being filled incorrectly in the flags of skb_cb. This incorrect flag setting causes the upper layers to consider that the particular frame was not transmitted properly, leading to improper behavior. Set the IEEE80211_TX_STAT_ACK flag in the info flags of skb_cb, to indicate the successful transmission of the management frame. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: dc405152Signed-off-by:
Rakesh Pillai <pillair@codeaurora.org> Signed-off-by:
-
James Smart authored
[ Upstream commit 783f4a44 ] When an io is rejected by nvmf_check_ready() due to validation of the controller state, the nvmf_fail_nonready_command() will normally return BLK_STS_RESOURCE to requeue and retry. However, if the controller is dying or the I/O is marked for NVMe multipath, the I/O is failed so that the controller can terminate or so that the io can be issued on a different path. Unfortunately, as this reject point is before the transport has accepted the command, blk-mq ends up completing the I/O and never calls nvme_complete_rq(), which is where multipath may preserve or re-route the I/O. The end result is, the device user ends up seeing an EIO error. Example: single path connectivity, controller is under load, and a reset is induced. An I/O is received: a) while the reset state has been set but the queues have yet to be stopped; or b) after queues are started (at end of reset) but before the reconnect has completed. The I/O finishes with an EIO status. This patch makes the following changes: - Adds the HOST_PATH_ERROR pathing status from TP4028 - Modifies the reject point such that it appears to queue successfully, but actually completes the io with the new pathing status and calls nvme_complete_rq(). - nvme_complete_rq() recognizes the new status, avoids resetting the controller (likely was already done in order to get this new status), and calls the multipather to clear the current path that errored. This allows the next command (retry or new command) to select a new path if there is one. Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit fbed2028 ] There is a potential execution path in which function of_find_compatible_node() returns NULL. In such a case, we end up having a NULL pointer dereference when accessing pointer *nfc_np* in function of_clk_get(). So, we better don't take any chances and fix this by null checking pointer *nfc_np* before calling of_clk_get(). Addresses-Coverity-ID: 1473052 ("Dereference null return value") Fixes: f88fc122 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Boris Brezillon <boris.brezillon@bootlin.com> Acked-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Xiaochen Shen authored
[ Upstream commit 2cc81c69 ] In resctrl filesystem, mount options exist to enable L3/L2 CDP and MBA Software Controller features if the platform supports them: mount -t resctrl resctrl [-o cdp[,cdpl2][,mba_MBps]] /sys/fs/resctrl But currently only "cdp" option is displayed in /proc/mounts. "cdpl2" and "mba_MBps" options are not shown even when they are active. Before: # mount -t resctrl resctrl -o cdp,mba_MBps /sys/fs/resctrl # grep resctrl /proc/mounts /sys/fs/resctrl /sys/fs/resctrl resctrl rw,relatime,cdp 0 0 After: # mount -t resctrl resctrl -o cdp,mba_MBps /sys/fs/resctrl # grep resctrl /proc/mounts /sys/fs/resctrl /sys/fs/resctrl resctrl rw,relatime,cdp,mba_MBps 0 0 Signed-off-by:
Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by:
Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: "H Peter Anvin" <hpa@zytor.com> Cc: "Tony Luck" <tony.luck@intel.com> Link: https://lkml.kernel.org/r/1536796118-60135-1-git-send-email-fenghua.yu@intel.comSigned-off-by:
-
Viresh Kumar authored
[ Upstream commit 51c99dd2 ] We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore since the latest OPP core updates as that uses reference counting to free resources. There are cases where no static OPPs are added (using DT) for a platform and trying to remove the OPP table may end up decrementing refcount which is already zero and hence generating warnings. Lets track if we were able to add static OPPs or not and then only remove the table based on that. Some reshuffling of code is also done to do that. Reported-by:
Niklas Cassel <niklas.cassel@linaro.org> Tested-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Dou Liyang authored
[ Upstream commit d0381bf4 ] ACPI driver should make sure all the processor IDs in their ACPI Namespace are unique. the driver performs a depth-first walk of the namespace tree and calls the acpi_processor_ids_walk() to check the duplicate IDs. But, the acpi_processor_ids_walk() mistakes the return value. If a processor is checked, it returns true which causes the walk break immediately, and other processors will never be checked. Repace the value with AE_OK which is the standard acpi_status value. And don't abort the namespace walk even on error. Fixes: 8c8cb30f (acpi/processor: Implement DEVICE operator for processor enumeration) Signed-off-by:
Dou Liyang <douly.fnst@cn.fujitsu.com> Signed-off-by:
-
Rajneesh Bhardwaj authored
[ Upstream commit 1cdda948 ] ACPI Low Power S0 Idle capabilities are announced via FADT table and can be used to inform the kernel about the presence of one or more Low Power Idle (LPI) entries as descried in LPIT table. LPIT table can exist independently even if the FADT S0 Idle flag is not set and thus it could confuse user since the following cpuidle attributes are created. /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us Presence or absence of above attributes could mean that the given platform supports S0ix state or not. This change allows to create the above cpuidle attributes only if FADT table supports Low Power S0 Idle. Signed-off-by:
Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by:
-
Jeffrey Hugo authored
[ Upstream commit 59bbff37 ] The type of a cache might not be specified by architectural mechanisms (ie system registers), but its type might be specified in the PPTT. In this case, we should populate the type of the cache, rather than leave it undefined. This fixes the issue where the cacheinfo driver will not populate sysfs for such caches, resulting in the information missing from utilities like lstopo and lscpu, thus degrading the user experience. Fixes: 2bd00bcd (ACPI/PPTT: Add Processor Properties Topology Table parsing) Reported-by:
Vijaya Kumar K <vkilari@codeaurora.org> Signed-off-by:
Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 4e651bad ] We do not currently clear wl->elp_compl on ELP timeout and we have bogus lingering pointer that wlcore_irq then will try to access after recovery is done: BUG: spinlock bad magic on CPU#1, irq/255-wl12xx/580 ... (spin_dump) from [<c01b9344>] (do_raw_spin_lock+0xc8/0x124) (do_raw_spin_lock) from [<c09b3970>] (_raw_spin_lock_irqsave+0x68/0x74) (_raw_spin_lock_irqsave) from [<c01a02f0>] (complete+0x24/0x58) (complete) from [<bf572610>] (wlcore_irq+0x48/0x17c [wlcore]) (wlcore_irq [wlcore]) from [<c01c5efc>] (irq_thread_fn+0x2c/0x64) (irq_thread_fn) from [<c01c623c>] (irq_thread+0x148/0x290) (irq_thread) from [<c016b4b0>] (kthread+0x160/0x17c) (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20) ... After that the system will hang. Let's fix this by adding a flag for recovery and moving the recovery work call to to the error handling section. And we want to set WL1271_FLAG_INTENDED_FW_RECOVERY and actually clear it too in wl1271_recovery_work() and just downgrade the error to a warning to prevent overly verbose output. Cc: Eyal Reizer <eyalr@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit d92116b8 ] On OLPC XO-1, the RTC is discovered via device tree from the arch initcall. Don't let the PC platform register another one from its device initcall, it's not going to work: sysfs: cannot create duplicate filename '/devices/platform/rtc_cmos' CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #12 Hardware name: OLPC XO/XO, BIOS OLPC Ver 1.00.01 06/11/2014 Call Trace: dump_stack+0x16/0x18 sysfs_warn_dup+0x46/0x58 sysfs_create_dir_ns+0x76/0x9b kobject_add_internal+0xed/0x209 ? __schedule+0x3fa/0x447 kobject_add+0x5b/0x66 device_add+0x298/0x535 ? insert_resource_conflict+0x2a/0x3e platform_device_add+0x14d/0x192 ? io_delay_init+0x19/0x19 platform_device_register+0x1c/0x1f add_rtc_cmos+0x16/0x31 do_one_initcall+0x78/0x14a ? do_early_param+0x75/0x75 kernel_init_freeable+0x152/0x1e0 ? rest_init+0xa2/0xa2 kernel_init+0x8/0xd5 ret_from_fork+0x2e/0x38 kobject_add_internal failed for rtc_cmos with -EEXIST, don't try to register things with the same name in the same directory. platform rtc_cmos: registered platform RTC device (no PNP device found) Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
-
Luca Coelho authored
[ Upstream commit 2e1976bb ] When reading the profiles from the EWRD table in ACPI, we loop over the data and set it into our internal table. We use the number of profiles specified in ACPI without checking its validity, so if the ACPI table is corrupted and the number is larger than our array size, we will try to make an out-of-bounds access. Fix this by making sure the value specified in the ACPI table is valid. Fixes: 69964905 ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit 155f7e04 ] Fix a bug that happens in the following scenario: 1) suspend without WoWLAN 2) mac80211 calls drv_stop because of the suspend 3) __iwl_mvm_mac_stop deallocates the aux station 4) during drv_stop the firmware crashes 5) iwlmvm: * sets IWL_MVM_STATUS_HW_RESTART_REQUESTED * asks mac80211 to kick the restart flow 6) mac80211 puts the restart worker into a freezable queue which means that the worker will not run for now since the workqueue is already frozen 7) ... 8) resume 9) mac80211 runs ieee80211_reconfig as part of the resume 10) mac80211 detects that a restart flow has been requested and that we are now resuming from suspend and cancels the restart worker 11) mac80211 calls drv_start() 12) __iwl_mvm_mac_start checks that IWL_MVM_STATUS_HW_RESTART_REQUESTED clears it, sets IWL_MVM_STATUS_IN_HW_RESTART and calls iwl_mvm_restart_cleanup() 13) iwl_fw_error_dump gets called and accesses the device to get debug data 14) iwl_mvm_up adds the aux station 15) iwl_mvm_add_aux_sta() allocates an internal station for the aux station 16) iwl_mvm_allocate_int_sta() tests IWL_MVM_STATUS_IN_HW_RESTART and doesn't really allocate a station ID for the aux station 17) a new queue is added for the aux station Note that steps from 5 to 9 aren't really part of the problem but were described for the sake of completeness. Once the iwl_mvm_mac_stop() is called, the device is not accessible, meaning that step 12) can't succeed and we'll see the following: drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2122 iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi]() Timeout waiting for hardware access (CSR_GP_CNTRL 0x080403d8) Call Trace: [<ffffffffc03e6ad3>] iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi] [<ffffffffc03e6a13>] iwl_trans_pcie_dump_regs+0x3fd/0x3fd [iwlwifi] [<ffffffffc03dad42>] iwl_fw_error_dump+0x4f5/0xe8b [iwlwifi] [<ffffffffc04bd43e>] __iwl_mvm_mac_start+0x5a/0x21a [iwlmvm] [<ffffffffc04bd6d2>] iwl_mvm_mac_start+0xd4/0x103 [iwlmvm] [<ffffffffc042d378>] drv_start+0xa1/0xc5 [iwl7000_mac80211] [<ffffffffc045a339>] ieee80211_reconfig+0x145/0xf50 [mac80211] [<ffffffffc044788b>] ieee80211_resume+0x62/0x66 [mac80211] [<ffffffffc0366c5b>] wiphy_resume+0xa9/0xc6 [cfg80211] The station id of the aux station is set to 0xff in step 3 and because we don't really allocate a new station id for the auxliary station (as explained in 16), we end up sending a command to the firmware asking to connect the queue to station id 0xff. This makes the firmware crash with the following information: 0x00002093 | ADVANCED_SYSASSERT 0x000002F0 | trm_hw_status0 0x00000000 | trm_hw_status1 0x00000B38 | branchlink2 0x0001978C | interruptlink1 0x00000000 | interruptlink2 0xFF080501 | data1 0xDEADBEEF | data2 0xDEADBEEF | data3 Firmware error during reconfiguration - reprobe! FW error in SYNC CMD SCD_QUEUE_CFG Fix this by clearing IWL_MVM_STATUS_HW_RESTART_REQUESTED in iwl_mvm_mac_stop(). We won't be able to collect debug data anyway and when we will brought up again, we will have a clean state from the firmware perspective. Since we won't have IWL_MVM_STATUS_IN_HW_RESTART set in step 12) we won't get to the 2093 ASSERT either. Fixes: bf8b286f ("iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Shaul Triebitz authored
[ Upstream commit 868a1e86 ] If all free RB queues are empty, the driver will never restock the free RB queue. That's because the restocking happens in the Rx flow, and if the free queue is empty there will be no Rx. Although there's a background worker (a.k.a. allocator) allocating memory for RBs so that the Rx handler can restock them, the worker may run only after the free queue has become empty (and then it is too late for restocking as explained above). There is a solution for that called 'emergency': If the number of used RB's reaches half the amount of all RB's, the Rx handler will not wait for the allocator but immediately allocate memory for the used RB's and restock the free queue. But, since the used RB's is per queue, it may happen that the used RB's are spread between the queues such that the emergency check will fail for each of the queues (and still run out of RBs, causing the above symptom). To fix it, move to emergency mode if the sum of *all* used RBs (for all Rx queues) reaches half the amount of all RB's Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
-
