- 14 May, 2020 40 commits
-
-
Majd Dibbiny authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9cd3411c upstream. Mask the reserved bits when reading the number of newly created XRCD. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Majd Dibbiny authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 418f8399 upstream. Add 16 reserved bytes at the end of mlx5_modify_qp_mbox_in to match the hardware spec definition. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Rana Shahout authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6e4c2189 upstream. Bit 25 of eth_proto_capability in PTYS register is 1000Base-TT and not 100Base-T. Fixes: f62b8bb8 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by:
Rana Shahout <ranas@mellanox.com> Signed-off-by:
-
Eran Ben Elisha authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c0fcebf5 upstream. Add a 4-digit padding to show FW version in proper format. Fixes: 9603b61d ('mlx5: Move pci device handling from...') Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Or Gerlitz authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b6c07bd upstream. The command timeout is terribly long, whole two hours. Make it 60s so if things do go wrong, the user gets feedback in relatively short time, so they can take corrective actions and/or investigate using tools and such. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Leon Romanovsky authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 75c1657e upstream. Fix the RC QPs send queue overhead computation to take into account two additional segments in the WQE which are needed for registration operations. The ATOMIC and UMR segments can't coexist together, so chose maximum out of them. The commit 9e65dc37 ("IB/mlx5: Fix RC transport send queue overhead computation") was intended to update RC transport as commit messages states, but added the code to UC transport. Fixes: 9e65dc37 ("IB/mlx5: Fix RC transport send queue overhead computation") Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
-
Noa Osherovich authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b276190 upstream. Currently the firmware can't work with a page with dma address 0. Passing such an address to the firmware will cause the give_pages command to fail. To avoid this, in case we get a 0 dma address of a page from the dma engine, we avoid passing it to FW by remapping to get an address other than 0. Fixes: bf0bf77f ('mlx5: Support communicating arbitrary host...') Signed-off-by:
-
Peter Griffin authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c23ac90f upstream. c8sectpfe driver relied on CONFIG_FW_LOADER_USER_HELPER_FALLBACK option for loading its xp70 firmware. A previous commit removed this Kconfig option, as it is apparently harmful, but did not update the driver code which relied on it. This patch reworks the firmware loading into the start_feed callback. At this point we can be sure the rootfs is present, thereby removing the depedency on CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Fixes: 79f5b6ae ('[media] c8sectpfe: Remove select on CONFIG_FW_LOADER_USER_HELPER_FALLBACK') Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Brian Norris authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 715780ae upstream. The kerneldoc for request_firmware_nowait() says that it may call the provided cont() callback with @fw == NULL, if the firmware request fails. However, this is not the case when called with an empty string (""). This case is short-circuited by the 'name[0] == '\0'' check introduced in commit 471b095d ("firmware_class: make sure fw requests contain a name"), so _request_firmware() never gets to set the fw to NULL. Noticed while using the new 'trigger_async_request' testing hook: # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [10553.726178] test_firmware: loading '' [10553.729859] test_firmware: loaded: 995209091 # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [10733.676184] test_firmware: loading '' [10733.679855] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [10733.687951] pgd = ec188000 [10733.690655] [00000004] *pgd=00000000 [10733.694240] Internal error: Oops: 5 [#1] SMP ARM [10733.698847] Modules linked in: btmrvl_sdio btmrvl bluetooth sbs_battery nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables asix usbnet mwifiex_sdio mwifiex cfg80211 jitterentropy_rng drbg joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun [10733.725670] CPU: 0 PID: 6600 Comm: bash Not tainted 4.4.0-rc4-00351-g63d0877 #178 [10733.733137] Hardware name: Rockchip (Device Tree) [10733.737831] task: ed24f6c0 ti: ee322000 task.ti: ee322000 [10733.743222] PC is at do_raw_spin_lock+0x18/0x1a0 [10733.747831] LR is at _raw_spin_lock+0x18/0x1c [10733.752180] pc : [<c00653a0>] lr : [<c054c204>] psr: a00d0013 [10733.752180] sp : ee323df8 ip : ee323e20 fp : ee323e1c [10733.763634] r10: 00000051 r9 : b6f18000 r8 : ee323f80 [10733.768847] r7 : c089cebc r6 : 00000001 r5 : 00000000 r4 : ec0e6000 [10733.775360] r3 : dead4ead r2 : c06bd140 r1 : eef913b4 r0 : 00000000 [10733.781874] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [10733.788995] Control: 10c5387d Table: 2c18806a DAC: 00000051 [10733.794728] Process bash (pid: 6600, stack limit = 0xee322218) [10733.800549] Stack: (0xee323df8 to 0xee324000) [10733.804896] 3de0: ec0e6000 00000000 [10733.813059] 3e00: 00000001 c089cebc ee323f80 b6f18000 ee323e2c ee323e20 c054c204 c0065394 [10733.821221] 3e20: ee323e44 ee323e30 c02fec60 c054c1f8 ec0e7ec0 ec3fcfc0 ee323e5c ee323e48 [10733.829384] 3e40: c02fed08 c02fec48 c07dbf74 eeb05a00 ee323e8c ee323e60 c0253828 c02fecac [10733.837547] 3e60: 00000001 c0116950 ee323eac ee323e78 00000001 ec3fce00 ed2d9700 ed2d970c [10733.845710] 3e80: ee323e9c ee323e90 c02e873c c02537d4 ee323eac ee323ea0 c017bd40 c02e8720 [10733.853873] 3ea0: ee323ee4 ee323eb0 c017b250 c017bd00 00000000 00000000 f3e47a54 ec128b00 [10733.862035] 3ec0: c017b10c ee323f80 00000001 c000f504 ee322000 00000000 ee323f4c ee323ee8 [10733.870197] 3ee0: c011b71c c017b118 ee323fb0 c011bc90 becfa8d9 00000001 ec128b00 00000001 [10733.878359] 3f00: b6f18000 ee323f80 ee323f4c ee323f18 c011bc90 c0063950 ee323f3c ee323f28 [10733.886522] 3f20: c0063950 c0549138 00000001 ec128b00 00000001 ec128b00 b6f18000 ee323f80 [10733.894684] 3f40: ee323f7c ee323f50 c011bed8 c011b6ec c0135fb8 c0135f24 ec128b00 ec128b00 [10733.902847] 3f60: 00000001 b6f18000 c000f504 ee322000 ee323fa4 ee323f80 c011c664 c011be24 [10733.911009] 3f80: 00000000 00000000 00000001 b6f18000 b6e79be0 00000004 00000000 ee323fa8 [10733.919172] 3fa0: c000f340 c011c618 00000001 b6f18000 00000001 b6f18000 00000001 00000000 [10733.927334] 3fc0: 00000001 b6f18000 b6e79be0 00000004 00000001 00000001 8068a3f1 b6e79c84 [10733.935496] 3fe0: 00000000 becfa7dc b6de194d b6e20246 400d0030 00000001 7a4536e8 49bda390 [10733.943664] [<c00653a0>] (do_raw_spin_lock) from [<c054c204>] (_raw_spin_lock+0x18/0x1c) [10733.951743] [<c054c204>] (_raw_spin_lock) from [<c02fec60>] (fw_free_buf+0x24/0x64) [10733.959388] [<c02fec60>] (fw_free_buf) from [<c02fed08>] (release_firmware+0x68/0x74) [10733.967207] [<c02fed08>] (release_firmware) from [<c0253828>] (trigger_async_request_store+0x60/0x124) [10733.976501] [<c0253828>] (trigger_async_request_store) from [<c02e873c>] (dev_attr_store+0x28/0x34) [10733.985533] [<c02e873c>] (dev_attr_store) from [<c017bd40>] (sysfs_kf_write+0x4c/0x58) [10733.993437] [<c017bd40>] (sysfs_kf_write) from [<c017b250>] (kernfs_fop_write+0x144/0x1a8) [10734.001689] [<c017b250>] (kernfs_fop_write) from [<c011b71c>] (__vfs_write+0x3c/0xe4) After this patch: # printf '\x00' > /sys/devices/virtual/misc/test_firmware/trigger_async_request [ 32.126322] test_firmware: loading '' [ 32.129995] test_firmware: failed to async load firmware -bash: printf: write error: No such device Fixes: 471b095d ("firmware_class: make sure fw requests contain a name") Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Acked-by:
Ming Lei <ming.lei@canonical.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Alexey Kardashevskiy authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit dead1c84 upstream. The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing which reads "assigned-addresses" of every PCI device and initializes the device resources. However if the property is missing or zero sized, then there is no fallback of any kind and the PCI resources remain undiscovered, i.e. pdev->resource[] array remains empty. This adds a fallback which parses the "reg" property in pretty much same way except it marks resources as "unset" which later make Linux assign those resources proper addresses. This has an effect when: 1. a hypervisor failed to assign any resource for a device; 2. /chosen/linux,pci-probe-only=0 is in the DT so the system may try assigning a resource. Neither is likely to happen under PowerVM. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Alexander Duyck authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a0ca153f upstream. This patch fixes an issue I found in which we were dropping frames if we had enabled checksums on GRE headers that were encapsulated by either FOU or GUE. Without this patch I was barely able to get 1 Gb/s of throughput. With this patch applied I am now at least getting around 6 Gb/s. The issue is due to the fact that with FOU or GUE applied we do not provide a transport offset pointing to the GRE header, nor do we offload it in software as the GRE header is completely skipped by GSO and treated like a VXLAN or GENEVE type header. As such we need to prevent the stack from generating it and also prevent GRE from generating it via any interface we create. Fixes: c3483384 ("gro: Allow tunnel stacking in the case of FOU/GUE") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Matan Barak authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4e408167 upstream. Hop limit value wasn't copied from attributes when ah was created. This may influence packets for unconnected services to get dropped in routers when endpoints are not in the same subnet. Fixes: fa417f7b ("IB/mlx4: Add support for IBoE") Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1e5ad30c upstream. MLXSW_PORT_MAX_PORTS represents the maximum number of local ports, which is 65 for both ASICs (SwitchX-2 and Spectrum) supported by this driver. Fixes: 93c1edb2 ("mlxsw: Introduce Mellanox switch driver core") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Alex Williamson authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ce7585f3 upstream. The size of the VPD area is not necessarily 4-byte aligned, so a pci_vpd_read() might return less than 4 bytes. Zero our buffer and accept anything other than an error. Intel X710 NICs exercise this. Fixes: 4e1a6355 ("vfio/pci: Use kernel VPD access functions") Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c20e1280 upstream. The alpha pci_mmap_resource() is used for both IORESOURCE_MEM and IORESOURCE_IO resources, but iomem_is_exclusive() is only applicable for IORESOURCE_MEM. Call iomem_is_exclusive() only for IORESOURCE_MEM resources, and do it earlier to match the generic version of pci_mmap_resource(). Fixes: 10a0ef39 ("PCI/alpha: pci sysfs resources") Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ca620723 upstream. iomem_is_exclusive() requires a CPU physical address, but on some arches we supplied a PCI bus address instead. On most arches, pci_resource_to_user(res) returns "res->start", which is a CPU physical address. But on microblaze, mips, powerpc, and sparc, it returns the PCI bus address corresponding to "res->start". The result is that pci_mmap_resource() may fail when it shouldn't (if the bus address happens to match an existing resource), or it may succeed when it should fail (if the resource is exclusive but the bus address doesn't match it). Call iomem_is_exclusive() with "res->start", which is always a CPU physical address, not the result of pci_resource_to_user(). Fixes: e8de1481 ("resource: allow MMIO exclusivity for device drivers") Suggested-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 5091730d upstream. The descriptor queues for sending (SDQs) and receiving (RDQs) packets are managed by two counters - producer and consumer - which are both 16-bit in size. A queue is considered full when the difference between the two equals the queue's maximum number of descriptors. However, if the producer counter overflows, then it's possible for the full queue check to fail, as it doesn't take the overflow into account. In such a case, descriptors already passed to the device - but for which a completion has yet to be posted - will be overwritten, thereby causing undefined behavior. The above can be achieved under heavy load (~30 netperf instances). Fix that by casting the subtraction result to u16, preventing it from being treated as a signed integer. Fixes: eda6500a ("mlxsw: Add PCI bus implementation") Signed-off-by:
-
Daniel Jurgens authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 22e3817e upstream. The PCI channel could go offline during reset due to EEH. Don't bug on in this case, the error is recoverable. Fixes: f6bc11e4 ('net/mlx4_core: Enhance the catas flow to support device reset') Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
-
Willem de Bruijn authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4f0c40d9 upstream. Dccp verifies packet integrity, including length, at initial rcv in dccp_invalid_packet, later pulls headers in dccp_enqueue_skb. A call to sk_filter in-between can cause __skb_pull to wrap skb->len. skb_copy_datagram_msg interprets this as a negative value, so (correctly) fails with EFAULT. The negative length is reported in ioctl SIOCINQ or possibly in a DCCP_WARN in dccp_close. Introduce an sk_receive_skb variant that caps how small a filter program can trim packets, and call this in dccp with the header length. Excessively trimmed packets are now processed normally and queued for reception as 0B payloads. Fixes: 7c657876 ("[DCCP]: Initial implementation") Signed-off-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Chin-Ran Lo authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 86f7ac77 upstream. It's been observed that when bluetooth driver fails to activate the firmware, below hung task warning dump is displayed after 120 seconds. [ 36.461022] Bluetooth: vendor=0x2df, device=0x912e, class=255, fn=2 [ 56.512128] Bluetooth: FW failed to be active in time! [ 56.517264] Bluetooth: Downloading firmware failed! [ 240.252176] INFO: task kworker/3:2:129 blocked for more than 120 seconds. [ 240.258931] Not tainted 3.18.0 #254 [ 240.262972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.270751] kworker/3:2 D ffffffc000205760 0 129 2 0x00000000 [ 240.277825] Workqueue: events request_firmware_work_func [ 240.283134] Call trace: [ 240.285581] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.290693] [<ffffffc00088dae0>] __schedule+0x540/0x7b8 [ 240.295921] [<ffffffc00088ddd0>] schedule+0x78/0x84 [ 240.300764] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8 [ 240.306395] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84 [ 240.311840] [<ffffffbffc163d08>] 0xffffffbffc163d08 [ 240.316685] [<ffffffbffc165104>] 0xffffffbffc165104 [ 240.321524] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex] [ 240.327918] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex] [ 240.334741] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80 [ 240.341127] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c [ 240.346831] [<ffffffc00023c6a0>] worker_thread+0x350/0x470 [ 240.352272] [<ffffffc0002419bc>] kthread+0xf0/0xfc [ 240.357019] 2 locks held by kworker/3:2/129: [ 240.361248] #0: ("events"){.+.+.+}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c [ 240.369562] #1: ((&fw_work->work)){+.+.+.}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c [ 240.378589] task PC stack pid father [ 240.384501] kworker/1:1 D ffffffc000205760 0 40 2 0x00000000 [ 240.391524] Workqueue: events mtk_atomic_work [ 240.395884] Call trace: [ 240.398317] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.403448] [<ffffffc00027279c>] lock_acquire+0x128/0x164 [ 240.408821] kworker/3:2 D ffffffc000205760 0 129 2 0x00000000 [ 240.415867] Workqueue: events request_firmware_work_func [ 240.421138] Call trace: [ 240.423589] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.428688] [<ffffffc00088dae0>] __schedule+0x540/0x7b8 [ 240.433886] [<ffffffc00088ddd0>] schedule+0x78/0x84 [ 240.438732] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8 [ 240.444361] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84 [ 240.449801] [<ffffffbffc163d08>] 0xffffffbffc163d08 [ 240.454649] [<ffffffbffc165104>] 0xffffffbffc165104 [ 240.459486] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex] [ 240.465882] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex] [ 240.472705] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80 [ 240.479090] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c [ 240.484794] [<ffffffc00023c6a0>] worker_thread+0x350/0x470 [ 240.490231] [<ffffffc0002419bc>] kthread+0xf0/0xfc This patch adds missing sdio_release_host() call so that wlan driver thread can claim sdio host. Fixes: 4863e4cc ("Bluetooth: btmrvl: release sdio bus after firmware is up") Signed-off-by:
Chin-Ran Lo <crlo@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ed0450ce upstream. Just like 7260, 7265 will not have firmware releases newer than iwlwifi-7265-17.ucode. 7265D is still supported in latest firmware releases. Fixes: 628a2918 ("iwlwifi: separate firmware version for 7260 devices") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f3b35f28 upstream. This patch ensures mwifiex_pcie_txbd_empty() does take care of 8997 chipset. Fixes: 6d85ef00 ("mwifiex: add support for 8997 chipset") Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
chunfan chen authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit dc386ce7 upstream. The port_open flag is not applicable for IBSS mode. IBSS data path was broken when port_open flag was introduced. This patch fixes the problem by correcting the checks. Fixes: 5c894633 ("mwifiex: enable traffic only when port is open") Signed-off-by:
chunfan chen <jeffc@marvell.com> Signed-off-by:
-
Vegard Nossum authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 1ba5bf99 upstream. If we hit any of the error conditions inside xfrm_dump_sa(), then xfrm_state_walk_init() never gets called. However, we still call xfrm_state_walk_done() from xfrm_dump_sa_done(), which will crash because the state walk was never initialized properly. We can fix this by setting cb->args[0] only after we've processed the first element and checking this before calling xfrm_state_walk_done(). Fixes: d3623099 ("ipsec: add support of limited SA dump") Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Acked-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Pablo Neira Ayuso authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 7c7bdf35 upstream. Since bd678e09 ("netfilter: nfnetlink: fix splat due to incorrect socket memory accounting in skbuff clones"), we don't manually attach the sk to the skbuff clone anymore, so we have to use the original skbuff from netlink_ack() which needs to access the sk pointer. Fixes: bd678e09 ("netfilter: nfnetlink: fix splat due to incorrect socket memory accounting in skbuff clones") Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b56fa687 upstream. If user does not supply tea575x_tuner parameter the driver tries to detect the tuner type. The failed codec initialization is considered as FM-only card present, however the driver still registers an IRQ handler for it. Move codec detection earlier to set tea575x_tuner parameter before check. Here the following functions are introduced reset_coded() resets AC97 codec snd_fm801_chip_multichannel_init() initializes cards with multichannel support Fixes: 5618955c (ALSA: fm801: move to pcim_* and devm_* functions) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit dbec6719 upstream. The commit d7ba858a (ALSA: fm801: implement TEA575x tuner autodetection) brings autodetection to the driver. However the autodetection algorithm misses the TUNER_ONLY bit if it is supplied by the user. Thus, user gets weird messages and no card registered. snd_fm801 0000:0d:01.0: detected TEA575x radio type SF64-PCR snd_fm801 0000:0d:01.0: AC'97 interface is busy (1) snd_fm801 0000:0d:01.0: AC'97 interface is busy (1) ... snd_fm801 0000:0d:01.0: AC'97 0 does not respond - RESET snd_fm801 0000:0d:01.0: AC'97 interface is busy (1) snd_fm801 0000:0d:01.0: AC'97 interface is busy (1) snd_fm801 0000:0d:01.0: AC'97 0 access is not valid [0x0], removing mixer. snd_fm801: probe of 0000:0d:01.0 failed with error -5 Do a copy of TUNER_ONLY bit to be applied after autodetection is done. Fixes: d7ba858a (ALSA: fm801: implement TEA575x tuner autodetection) Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e97e98c6 upstream. Otherwise we will have a warning on ->remove() since device is a PCI one. WARNING: CPU: 4 PID: 1411 at /home/andy/prj/linux/fs/proc/generic.c:575 remove_proc_entry+0x137/0x160() remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'snd_fm801' Fixes: 5618955c (ALSA: fm801: move to pcim_* and devm_* functions) Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c4597fd7 upstream. 'm_io' is stored in 6 bits so it's a number in the 0-63 range. Static analysis tools complain that 1 << 63 will wrap so I have changed it to 1ULL << m_io. This code is over three years old so presumably the bug doesn't happen very frequently in real life or someone would have complained by now. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Alex Thorlton <athorlton@sgi.com> Cc: Dimitri Sivanich <sivanich@sgi.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Travis <travis@sgi.com> Cc: Nathan Zimmer <nzimmer@sgi.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kernel-janitors@vger.kernel.org Fixes: b15cc4a1 ("x86, uv, uv3: Update x2apic Support for SGI UV3") Link: http://lkml.kernel.org/r/20161123221908.GA23997@mwandaSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jan Beulich authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0d430e3f upstream. This was meant to print base address and entry count; make it do so again. Fixes: 37868fe1 "x86/ldt: Make modify_ldt synchronous" Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
Andy Lutomirski <luto@kernel.org> Link: http://lkml.kernel.org/r/56797D8402000078000C24F0@prv-mh.provo.novell.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Stephane Eranian authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 61b87cae upstream. This patch fixes a bug in the filter_events() function. The patch fixes the bug whereby if some mappings did not exist, e.g., STALLED_CYCLES_FRONTEND, then any event after it in the attrs array would disappear from the published list of events in /sys/devices/cpu/events. This could be verified easily on any system post SNB (which do not publish STALLED_CYCLES_FRONTEND): $ ./perf stat -e cycles,ref-cycles true Performance counter stats for 'true': 1,217,348 cycles <not supported> ref-cycles The problem is that in filter_events() there is an assumption that the argument (attrs) is organized in increasing continuous event indexes related to the event_map(). But if we remove the non-supported events by shifing the position in the array, then the lookup x86_pmu.event_map() needs to compensate for it, otherwise we are looking up the wrong index. This patch corrects this problem by compensating for the deleted events and with that ref-cycles reappears (here shown on Haswell): $ perf stat -e ref-cycles,cycles true Performance counter stats for 'true': 4,525,910 ref-cycles 1,064,920 cycles 0.002943888 seconds time elapsed Signed-off-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: jolsa@kernel.org Cc: kan.liang@intel.com Fixes: 8300daa2 ("perf/x86: Filter out undefined events from sysfs events attribute") Link: http://lkml.kernel.org/r/1449516805-6637-1-git-send-email-eranian@google.comSigned-off-by:
-
Suman Anna authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c20c8f75 upstream. The omap_hwmod _enable() function can return success without setting the hwmod state to _HWMOD_STATE_ENABLED for IPs with reset lines when all of the reset lines are asserted. The omap_hwmod _idle() function also performs a similar check, but after checking for the hwmod state first. This triggers the WARN when pm_runtime_get and pm_runtime_put are invoked on IPs with all reset lines asserted. Reverse the checks for hwmod state and reset lines status to fix this. Issue found during a unbind operation on a device with reset lines still asserted, example backtrace below ------------[ cut here ]------------ WARNING: CPU: 1 PID: 879 at arch/arm/mach-omap2/omap_hwmod.c:2207 _idle+0x1e4/0x240() omap_hwmod: mmu_dsp: idle state can only be entered from enabled state Modules linked in: CPU: 1 PID: 879 Comm: sh Not tainted 4.4.0-00008-ga989d951331a #3 Hardware name: Generic OMAP5 (Flattened Device Tree) [<c0018e60>] (unwind_backtrace) from [<c0014dc4>] (show_stack+0x10/0x14) [<c0014dc4>] (show_stack) from [<c037ac28>] (dump_stack+0x90/0xc0) [<c037ac28>] (dump_stack) from [<c003f420>] (warn_slowpath_common+0x78/0xb4) [<c003f420>] (warn_slowpath_common) from [<c003f48c>] (warn_slowpath_fmt+0x30/0x40) [<c003f48c>] (warn_slowpath_fmt) from [<c0028c20>] (_idle+0x1e4/0x240) [<c0028c20>] (_idle) from [<c0029080>] (omap_hwmod_idle+0x28/0x48) [<c0029080>] (omap_hwmod_idle) from [<c002a5a4>] (omap_device_idle+0x3c/0x90) [<c002a5a4>] (omap_device_idle) from [<c0427a90>] (__rpm_callback+0x2c/0x60) [<c0427a90>] (__rpm_callback) from [<c0427ae4>] (rpm_callback+0x20/0x80) [<c0427ae4>] (rpm_callback) from [<c0427f84>] (rpm_suspend+0x138/0x74c) [<c0427f84>] (rpm_suspend) from [<c0428b78>] (__pm_runtime_idle+0x78/0xa8) [<c0428b78>] (__pm_runtime_idle) from [<c041f514>] (__device_release_driver+0x64/0x100) [<c041f514>] (__device_release_driver) from [<c041f5d0>] (device_release_driver+0x20/0x2c) [<c041f5d0>] (device_release_driver) from [<c041d85c>] (unbind_store+0x78/0xf8) [<c041d85c>] (unbind_store) from [<c0206df8>] (kernfs_fop_write+0xc0/0x1c4) [<c0206df8>] (kernfs_fop_write) from [<c018a120>] (__vfs_write+0x20/0xdc) [<c018a120>] (__vfs_write) from [<c018a9cc>] (vfs_write+0x90/0x164) [<c018a9cc>] (vfs_write) from [<c018b1f0>] (SyS_write+0x44/0x9c) [<c018b1f0>] (SyS_write) from [<c0010420>] (ret_fast_syscall+0x0/0x1c) ---[ end trace a4182013c75a9f50 ]--- While at this, fix the sequence in _shutdown() as well, though there is no easy reproducible scenario. Fixes: 747834ab ("ARM: OMAP2+: hwmod: revise hardreset behavior") Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Heinrich Schuchardt authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit fc5c796e upstream. Commit 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") created the new file kirkwood-ds112.dts but did not add it to the Makefile. Fixes: 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Heinrich Schuchardt authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9d021c9d upstream. Downstream packages like Debian flash-kernel use /proc/device-tree/model to determine which dtb file to install. Hence each dts in the Linux kernel should provide a unique model identifier. Commit 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") created the new files kirkwood-ds111.dts and kirkwood-ds112.dts using the same model identifier. This patch provides a unique model identifier for the Synology DiskStation DS112. Fixes: 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 44361a2c upstream. MTD flash stores u-boot and u-boot environment on linkstation lswtgl. The latter one can be easily read/write by u-boot-tools package in Debian. Fixes: dc57844a ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl") Signed-off-by:
Roger Shimizu <rogershimizu@gmail.com> Reviewed-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ff61ee84 upstream. Here're a few gpio pin related fixes: - remove pinctrl-0 definition from pinctrl, since those pins are used in other places such as gpio-fan and regulators. - keep initial state of power led - fix for alarm pin of gpio-fan. Fixes: dc57844a ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl") Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0418138e upstream. The GPIOs controlling the LEDs, listed below, are active high, not low: - gpio-leds: "lswvl:red:alarm" pin - gpio-leds: "lswvl:red:func" pin - gpio-leds: "lswvl:amber:info" pin - gpio-leds: "lswvl:blue:func" pin - gpio-leds: "lswvl:red:hdderr{0,1}" pin Fixes: c43379e1 ("ARM: dts: add buffalo linkstation ls-wvl/vl") Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e98bd707 upstream. The GPIOs controlling the LEDs, listed below, are active high, not low: - gpio-leds: "lswxl:blue:power" pin - gpio-leds: "lswxl:red:func" pin - gpio-leds: "lswxl:red:hdderr{0,1}" pin Fixes: e54e4b1b ("ARM: dts: add buffalo linkstation ls-wxl/wsxl") Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6f86e9ad upstream. For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be converted to "gpio1 <pin minus 32>" in dts file. e.g. gpio 40 should be "gpio1 8" The pin/bank issue was found when discussing Debian Bug #810894 [https://bugs.debian.org/810894#47] Fixes: c43379e1 ("ARM: dts: add buffalo linkstation ls-wvl/vl") Reported-by:
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> Signed-off-by:
-
Roger Shimizu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 144e08ab upstream. For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be converted to "gpio1 <pin minus 32>" in dts file. e.g. gpio 40 should be "gpio1 8" Besides, a few other pin fixes for ls-wxl/wsxl, to match with mpp pin definition: - gpio-leds: "lswxl:blue:power" pin - gpio-leds: "lswxl:red:func" pin - gpio-leds: "lswxl:red:hdderr0" pin - gpio-leds: "lswxl:red:hdderr1" pin - gpio-fan: low/high/alarm pin The pin/bank issue was found when discussing Debian Bug #810894 [https://bugs.debian.org/810894#47] Fixes: e54e4b1b ("ARM: dts: add buffalo linkstation ls-wxl/wsxl") Reported-by:
-
