577336 Commits

Author SHA1 Message Date
Brian Norris
26b056e9fc firmware: actually return NULL on failed request_firmware_nowait()
commit 715780ae4bb76d6fd2f20eb78e2a9ba9769a6cdc 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 471b095dfe0d ("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: 471b095dfe0d ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:54 +02:00
Alexey Kardashevskiy
91e5d3fbb0 powerpc/pci/of: Parse unassigned resources
commit dead1c845dbe97e0061dae2017eaf3bd8f8f06ee 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:53 +02:00
Alexander Duyck
21fbc1a133 GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU
commit a0ca153f98db8cf25298565a09e11fe9d82846ad 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: c3483384ee511 ("gro: Allow tunnel stacking in the case of FOU/GUE")
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:53 +02:00
Nicolas Dichtel
96edfba59c ovs/gre,geneve: fix error path when creating an iface
commit 106da663ff495e0aea3ac15b8317aa410754fcac upstream.

After ipgre_newlink()/geneve_configure() call, the netdev is registered.

Fixes: 7e059158d57b ("vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices")
CC: David Wragg <david@weave.works>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:53 +02:00
Matan Barak
e01128e3ce IB/mlx4: Initialize hop_limit when creating address handle
commit 4e4081673445485aa6bc90383bdb83e7a96cc48a 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: fa417f7b520e ("IB/mlx4: Add support for IBoE")
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:53 +02:00
Ido Schimmel
4ec565c2ee mlxsw: Treat local port 64 as valid
commit 1e5ad30c649a82a062ce79a87c1296e6c6f328c2 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: 93c1edb27f9e ("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: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:53 +02:00
Franky Lin
0e15fa1883 brcmfmac: add eth_type_trans back for PCIe full dongle
commit 31143e2933d1675c4c1ba6ce125cdd95870edd85 upstream.

A regression was introduced in commit 9c349892ccc9 ("brcmfmac: revise
handling events in receive path") which moves eth_type_trans() call
to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but invokes
brcmf_netif_rx() directly. In such case the Ethernet header was not
stripped out resulting in null pointer dereference in the networking
stack.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
IP: [<ffffffff814c3ce6>] enqueue_to_backlog+0x56/0x260
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: fuse ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
[...]
rtsx_pci scsi_mod usbcore usb_common i8042 serio nvme nvme_core
CPU: 7 PID: 1340 Comm: irq/136-brcmf_p Not tainted 4.7.0-rc1-mainline #1
Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
task: ffff8804a0c5bd00 ti: ffff88049e124000 task.ti: ffff88049e124000
RIP: 0010:[<ffffffff814c3ce6>] [<ffffffff814c3ce6>]
enqueue_to_backlog+0x56/0x260
RSP: 0018:ffff88049e127ca0 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff8804bddd7c40 RCX: 000000000000002f
RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff8804bddd7d4c
RBP: ffff88049e127ce8 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8804bddd12c0 R11: 000000000000149e R12: 0000000000017c40
R13: ffff88049e127d08 R14: ffff8804a9bd6d00 R15: ffff8804bddd7d4c
FS: 0000000000000000(0000) GS:ffff8804bddc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000048 CR3: 0000000001806000 CR4: 00000000003406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
ffff8804bdddad00 ffff8804ad089e00 0000000000000000 0000000000000282
0000000000000000 ffff8804a9bd6d00 ffff8804a1b27e00 ffff8804a9bd6d00
ffff88002ee88000 ffff88049e127d28 ffffffff814c3f3b ffffffff81311fc3
Call Trace:
[<ffffffff814c3f3b>] netif_rx_internal+0x4b/0x170
[<ffffffff81311fc3>] ? swiotlb_tbl_unmap_single+0xf3/0x120
[<ffffffff814c5467>] netif_rx_ni+0x27/0xc0
[<ffffffffa08519e9>] brcmf_netif_rx+0x49/0x70 [brcmfmac]
[<ffffffffa08564d4>] brcmf_msgbuf_process_rx+0x2b4/0x570 [brcmfmac]
[<ffffffff81020017>] ? __xen_set_pgd_hyper+0x57/0xd0
[<ffffffff810d60b0>] ? irq_forced_thread_fn+0x70/0x70
[<ffffffffa0857381>] brcmf_proto_msgbuf_rx_trigger+0x31/0xe0 [brcmfmac]
[<ffffffffa0861e8f>] brcmf_pcie_isr_thread+0x7f/0x110 [brcmfmac]
[<ffffffff810d60d0>] irq_thread_fn+0x20/0x50
[<ffffffff810d63ad>] irq_thread+0x12d/0x1c0
[<ffffffff815d07d5>] ? __schedule+0x2f5/0x7a0
[<ffffffff810d61d0>] ? wake_threads_waitq+0x30/0x30
[<ffffffff810d6280>] ? irq_thread_dtor+0xb0/0xb0
[<ffffffff81098ea8>] kthread+0xd8/0xf0
[<ffffffff815d4b7f>] ret_from_fork+0x1f/0x40
[<ffffffff81098dd0>] ? kthread_worker_fn+0x170/0x170
Code: 1c f5 60 9a 8e 81 9c 58 0f 1f 44 00 00 48 89 45 d0 fa 66 0f 1f
44 00 00 4c 8d bb 0c 01 00 00 4c 89 ff e8 5e 08 11 00 49 8b 56 20 <48>
8b 52 48 83 e2 01 74 10 8b 8b 08 01 00 00 8b 15 59 c5 42 00
RIP [<ffffffff814c3ce6>] enqueue_to_backlog+0x56/0x260
RSP <ffff88049e127ca0>
CR2: 0000000000000048

Fixes: 9c349892ccc9 ("brcmfmac: revise handling events in receive path")
Reported-by: Rafal Milecki <zajec5@gmail.com>
Reported-by: Grey Christoforo <grey@christoforo.net>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Signed-off-by: Franky Lin <franky.lin@broadcom.com>
[arend@broadcom.com: rephrased the commit message]
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:52 +02:00
Alex Williamson
a13415839d vfio/pci: Allow VPD short read
commit ce7585f3c4d76bca1dff4b66ae1ea32552954f9e 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: 4e1a635552d3 ("vfio/pci: Use kernel VPD access functions")
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:52 +02:00
Bjorn Helgaas
7cf7cfdf3c alpha/PCI: Call iomem_is_exclusive() for IORESOURCE_MEM, but not IORESOURCE_IO
commit c20e128030caf0537d5e906753eac1c28fefdb75 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: 10a0ef39fbd1 ("PCI/alpha: pci sysfs resources")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:52 +02:00
Daniel Jurgens
b1611bb6a9 net/mlx4_core: Implement pci_resume callback
commit c12833acff62cff83a8b728253e7ebbc1264d75e upstream.

Move resume related activities to a new pci_resume function instead of
performing them in mlx4_pci_slot_reset.  This change is needed to avoid
a hotplug during EEH recovery due to commit f2da4ccf8bd4 ("powerpc/eeh:
More relaxed hotplug criterion").

Fixes: 2ba5fbd62b25 ('net/mlx4_core: Handle AER flow properly')
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:52 +02:00
Bjorn Helgaas
011f69c4bd PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive()
commit ca620723d4ff9ea7ed484eab46264c3af871b9ae 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: e8de1481fd71 ("resource: allow MMIO exclusivity for device drivers")
Suggested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:52 +02:00
Ido Schimmel
0a8b5f3fac mlxsw: pci: Correctly determine if descriptor queue is full
commit 5091730d7795ccb21eb880699b5194730641c70b 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: eda6500a987a ("mlxsw: Add PCI bus implementation")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:51 +02:00
Daniel Jurgens
15aeb6325d net/mlx4_core: Do not BUG_ON during reset when PCI is offline
commit 22e3817e6c8301dc0520b855c8a2d764580e719c upstream.

The PCI channel could go offline during reset due to EEH.  Don't bug on in
this case, the error is recoverable.

Fixes: f6bc11e42646 ('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: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:51 +02:00
Willem de Bruijn
792d5414d0 dccp: limit sk_filter trim to payload
commit 4f0c40d94461cfd23893a17335b2ab78ecb333c8 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: 7c657876b63c ("[DCCP]: Initial implementation")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:51 +02:00
Chin-Ran Lo
6c687c0c28 Bluetooth: btmrvl: fix hung task warning dump
commit 86f7ac77d4035e22ec7e58dcdb96327e2ecc3a9b 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: 4863e4cc31d647e1 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:51 +02:00
Emmanuel Grumbach
ea2bedc0f8 iwlwifi: set max firmware version of 7265 to 17
commit ed0450cef00d2c76bcb8778721df947ba7ff4147 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: 628a2918afe4 ("iwlwifi: separate firmware version for 7260 devices")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:51 +02:00
Amitkumar Karwar
1a22e80896 mwifiex: add missing check for PCIe8997 chipset
commit f3b35f28096895f2438c10ef719ef67d2951a8c9 upstream.

This patch ensures mwifiex_pcie_txbd_empty() does take care
of 8997 chipset.

Fixes: 6d85ef00d9dfe ("mwifiex: add support for 8997 chipset")
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>
2020-05-10 10:25:51 +02:00
chunfan chen
e5501b261c mwifiex: fix IBSS data path issue.
commit dc386ce76dedaeeaaf006fceb6ed8cf2e20ff026 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: 5c8946330abfa4c ("mwifiex: enable traffic only when port is open")
Signed-off-by: chunfan chen <jeffc@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>
2020-05-10 10:25:50 +02:00
Vegard Nossum
0cbb0084fa xfrm: fix crash in XFRM_MSG_GETSA netlink handler
commit 1ba5bf993c6a3142e18e68ea6452b347f9cb5635 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: d3623099d3 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:50 +02:00
Pablo Neira Ayuso
6eea9a7650 netfilter: nfnetlink: use original skbuff when acking batches
commit 7c7bdf35991bb8f7cfaeaf22ea3a2f2d1967c166 upstream.

Since bd678e09dc17 ("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: bd678e09dc17 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:50 +02:00
Andy Shevchenko
c99044c924 ALSA: fm801: detect FM-only card earlier
commit b56fa687e02b27f8bd9d282950a88c2ed23d766b 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: 5618955c4269 (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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:50 +02:00
Andy Shevchenko
6c318f9052 ALSA: fm801: propagate TUNER_ONLY bit when autodetected
commit dbec6719ac036f68568d8488805d41346c021eff upstream.

The commit d7ba858a7f7a (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: d7ba858a7f7a (ALSA: fm801: implement TEA575x tuner autodetection)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:50 +02:00
Andy Shevchenko
d692ef8ce6 ALSA: fm801: explicitly free IRQ line
commit e97e98c63b43040732ad5d1f0b38ad4a8371c73a 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: 5618955c4269 (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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:49 +02:00
Dan Carpenter
82ff45e06d x86/apic/uv: Silence a shift wrapping warning
commit c4597fd756836a5fb7900f2091797ab564390ad0 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: b15cc4a12bed ("x86, uv, uv3: Update x2apic Support for SGI UV3")
Link: http://lkml.kernel.org/r/20161123221908.GA23997@mwanda
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:49 +02:00
Jan Beulich
d41bffbc70 x86/LDT: Print the real LDT base address
commit 0d430e3fb3f7cdc13c0d22078b820f682821b45a upstream.

This was meant to print base address and entry count; make it do so
again.

Fixes: 37868fe113ff "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.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:49 +02:00
Stephane Eranian
0554b4d5dd perf/x86: Fix filter_events() bug with event mappings
commit 61b87cae6361ea6af161c1ffa549898892707b19 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: 8300daa26755 ("perf/x86: Filter out undefined events from sysfs events attribute")
Link: http://lkml.kernel.org/r/1449516805-6637-1-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:49 +02:00
Suman Anna
f7766d1fdf ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence
commit c20c8f750d9f8f8617f07ee2352d3ff560e66bc2 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: 747834ab8347 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:49 +02:00
Heinrich Schuchardt
31906bd42e ARM: dts: kirkwood: add kirkwood-ds112.dtb to Makefile
commit fc5c796e12511a7c027b5a4438719dde2f796208 upstream.

Commit 2d0a7addbd10 ("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: 2d0a7addbd10 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:48 +02:00
Heinrich Schuchardt
972093389a ARM: dts: kirkwood: use unique machine name for ds112
commit 9d021c9d1b4b774a35d8a03d58dbf029544debda 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 2d0a7addbd10 ("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: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:48 +02:00
Roger Shimizu
6e4a4856ba ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
commit 44361a2cc13493fc41216d33bb9a562ec3a9cc4e 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: dc57844a736f ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:48 +02:00
Roger Shimizu
71c26bb299 ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl
commit ff61ee84e7aa5842d9e33c0b442f0b43a6a44eaf 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: dc57844a736f ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:48 +02:00
Roger Shimizu
7931b0b0bf ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wvl/vl
commit 0418138e2ffd90f4a00b263593f2e199db87321d 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: c43379e150aa ("ARM: dts: add buffalo linkstation ls-wvl/vl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:48 +02:00
Roger Shimizu
3d90a4c2c8 ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wxl/wsxl
commit e98bd707e39d52d8bef8622e6e7b0ab4bd0ed8d0 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: e54e4b1b622e ("ARM: dts: add buffalo linkstation ls-wxl/wsxl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:47 +02:00
Roger Shimizu
0e16d8be37 ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wvl/vl
commit 6f86e9adc53b4c0a2a4283692216d119019f0b8d 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: c43379e150aa ("ARM: dts: add buffalo linkstation ls-wvl/vl")
Reported-by: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:47 +02:00
Roger Shimizu
de8966f681 ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wxl/wsxl
commit 144e08abe80080c9c2cf0a06e40f1bc8150674eb 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: e54e4b1b622e ("ARM: dts: add buffalo linkstation ls-wxl/wsxl")
Reported-by: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:47 +02:00
Arnd Bergmann
30b4465af2 ARM: imx: select SRC for i.MX7
commit f1858b0e801a45d801dc23bc1ff5be14805022c8 upstream.

The i.MX7 Kconfig option had a couple of missing select lines that
I fixed already, but I missed HAVE_IMX_SRC:

arch/arm/mach-imx/built-in.o: In function `imx7d_init_irq':
platform-spi_imx.c:(.init.text+0x25a8): undefined reference to `imx_src_init'

This adds that one as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 0be5da9dc249 ("ARM: imx: imx7d requires anatop")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:47 +02:00
Geert Uytterhoeven
e44ef9c4fa ARM: dts: armadillo800eva Correct extal1 frequency to 24 MHz
commit c61f30a255550bbfc6b83c1ca720661489cac4c0 upstream.

On r8a7740/armadillo, actual clock rates are ca. 4% lower than reported
by /sys/kernel/debug/clk/clk_summary. Correct the extal1 frequency from
25 MHz to 24 MHz to fix this.

This matches the Armadillo-800 EVA Product Manual, which claims the main
crystal runs at 24 MHz, and the old legacy/reference board code.

Fixes: 25aa7ba3fdfb ("ARM: shmobile: armadillo800eva: Sync DTS")
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>
2020-05-10 10:25:46 +02:00
Hidehiro Kawai
95f179ffff mips/panic: replace smp_send_stop() with kdump friendly version in panic path
commit 54c721b857fd45f3ad3bda695ee4f472518db02a upstream.

Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).

In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online.  As the result, kdump
routines fail to save other CPUs' registers.  Additionally for MIPS
OCTEON, it misses to stop the watchdog timer.

To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
weak function, and it just call smp_send_stop().  Architecture
codes should override it so that kdump can work appropriately.
This patch provides MIPS version.

Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Link: http://lkml.kernel.org/r/20160810080950.11028.28000.stgit@sysi4-13.yrl.intra.hitachi.co.jp
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Reported-by: Daniel Walker <dwalker@fifo99.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Xunlei Pang <xpang@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Daney <david.daney@cavium.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: "Steven J. Hill" <steven.hill@cavium.com>
Cc: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:46 +02:00
James Hogan
4aa560bc83 MIPS: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
commit 233b2ca181f20674ecad11be90b00814911ce345 upstream.

AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
for MIPS at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for
the VDSO address.

This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
AT_BASE_PLATFORM which MIPS doesn't use, but lets define it now and add
the comment above ARCH_DLINFO as found in several other architectures to
remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
date.

Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-arch@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13823/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:46 +02:00
Dan Carpenter
0fb34ac0f0 MIPS: RM7000: Double locking bug in rm7k_tc_disable()
commit 58a7e1c140f3ad61646bc0cd9a1f6a9cafc0b225 upstream.

We obviously intended to enable IRQs again at the end.

Fixes: 745aef5df1e2 ('MIPS: RM7000: Add support for tertiary cache')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13815/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:46 +02:00
Daniel Borkmann
506a1e3bef bpf, mips: fix off-by-one in ctx offset allocation
commit b4e76f7e6d3200462c6354a6ad4ae167459e61f8 upstream.

Dan Carpenter reported [1] a static checker warning that ctx->offsets[]
may be accessed off by one from build_body(), since it's allocated with
fp->len * sizeof(*ctx.offsets) as length. The cBPF arm and ppc code
doesn't have this issue as claimed, so only mips seems to be affected and
should like most other JITs allocate with fp->len + 1. A few number of
JITs (x86, sparc, arm64) handle this differently, where they only require
fp->len array elements.

  [1] http://www.spinics.net/lists/mips/msg64193.html

Fixes: c6610de353da ("MIPS: net: Add BPF JIT")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: ast@kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13814/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:45 +02:00
Dan Carpenter
cdd952995b MIPS: Octeon: Off by one in octeon_irq_gpio_map()
commit 008d0cf1ec69ec6d2c08f2d23aff2b67cbe5d2af upstream.

It should be >= ARRAY_SIZE() instead of > ARRAY_SIZE().

Fixes: 64b139f97c01 ('MIPS: OCTEON: irq: add CIB and other fixes')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: David Daney <david.daney@cavium.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-mips@linux-mips.org
Cc: kernel-janitors@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13813/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:45 +02:00
James Hogan
6da475d078 MIPS: c-r4k: Fix protected_writeback_scache_line for EVA
commit 0758b116b4080d9a2a2a715bec6eee2cbd828215 upstream.

The protected_writeback_scache_line() function is used by
local_r4k_flush_cache_sigtramp() to flush an FPU delay slot emulation
trampoline on the userland stack from the caches so it is visible to
subsequent instruction fetches.

Commit de8974e3f76c ("MIPS: asm: r4kcache: Add EVA cache flushing
functions") updated some protected_ cache flush functions to use EVA
CACHEE instructions via protected_cachee_op(), and commit 83fd43449baa
("MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line") did
the same thing for protected_writeback_dcache_line(), but
protected_writeback_scache_line() never got updated. Lets fix that now
to flush the right user address from the secondary cache rather than
some arbitrary kernel unmapped address.

This issue was spotted through code inspection, and it seems unlikely to
be possible to hit this in practice. It theoretically affect EVA kernels
on EVA capable cores with an L2 cache, where the icache fetches straight
from RAM (cpu_icache_snoops_remote_store == 0), running a hard float
userland with FPU disabled (nofpu). That both Malta and Boston platforms
override cpu_icache_snoops_remote_store to 1 suggests that all MIPS
cores fetch instructions into icache straight from L2 rather than RAM.

Fixes: de8974e3f76c ("MIPS: asm: r4kcache: Add EVA cache flushing functions")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13800/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:45 +02:00
James Hogan
4cf3afdf97 MIPS: SMP: Update cpu_foreign_map on CPU disable
commit 826e99be6ab5189dbfb096389016ffb8d20a683e upstream.

When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated.
This could result in cache management SMP calls being sent to offline
CPUs instead of online siblings in the same core.

Add a call to calculate_cpu_foreign_map() in the various MIPS cpu
disable callbacks after set_cpu_online(). All cases are updated for
consistency and to keep cpu_foreign_map strictly up to date, not just
those which may support hardware multithreading.

Fixes: cccf34e9411c ("MIPS: c-r4k: Fix cache flushing for MT cores")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: David Daney <david.daney@cavium.com>
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Hongliang Tao <taohl@lemote.com>
Cc: Hua Yan <yanh@lemote.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13799/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:45 +02:00
James Hogan
439b0831e5 MIPS: KVM: Fix translation of MFC0 ErrCtl
commit 66ffc50c480e7ab6ad5642f47276435a8873c31a upstream.

The MIPS KVM dynamic translation is meant to translate "MFC0 rt, ErrCtl"
instructions into "ADD rt, zero, zero" to zero the destination register,
however the rt register number was copied into rt of the ADD instruction
encoding, which is the 2nd source operand. This results in "ADD zero,
zero, rt" which is a no-op, so only the first execution of each such
MFC0 from ErrCtl will actually read 0.

Fix the shift to put the rt from the MFC0 encoding into the rd field of
the ADD.

Fixes: 50c8308538dc ("KVM/MIPS32: Binary patching of select privileged instructions.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:44 +02:00
James Hogan
dce6c5bb91 MIPS: perf: Fix I6400 event numbers
commit fd716fca10fc3dc0f18b8c16d4ecfa6d93f010d2 upstream.

Fix perf hardware performance counter event numbers for I6400. This core
does not follow the performance event numbering scheme of previous MIPS
cores. All performance counters (both odd and even) are capable of
counting any of the available events.

Fixes: 4e88a8621301 ("MIPS: Add cases for CPU_I6400")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13259/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:43 +02:00
Paul Burton
524fafef88 MIPS: Fix BC1{EQ,NE}Z return offset calculation
commit ac1496980f1d2752f26769f5db63afbc9ac2b603 upstream.

The conditions for branching when emulating the BC1EQZ & BC1NEZ
instructions were backwards, leading to each of those instructions being
treated as the other. Fix this by reversing the conditions, and clear up
the code a little for readability & checkpatch.

Fixes: c8a34581ec09 ("MIPS: Emulate the BC1{EQ,NE}Z FPU instructions")
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13151/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:43 +02:00
Paul Burton
26bf2650cd MIPS: math-emu: Fix BC1{EQ,NE}Z emulation
commit 93583e178ebfdd2fadf950eef1547f305cac12ca upstream.

The conditions for branching when emulating the BC1EQZ & BC1NEZ
instructions were backwards, leading to each of those instructions being
treated as the other. Fix this by reversing the conditions, and clear up
the code a little for readability & checkpatch.

Fixes: c909ca718e8f ("MIPS: math-emu: Emulate missing BC1{EQ,NE}Z instructions")
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: Maciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13150/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:43 +02:00
Florian Fainelli
8a70d2a0c1 MIPS: BMIPS: Adjust mips-hpt-frequency for BCM7435
commit 80fa40acaa1dad5a0a9c15ed2e5d2e72461843f5 upstream.

The CPU actually runs at 1405Mhz which gives us a 175625000 Hz MIPS timer
frequency (CPU frequency / 8).

Fixes: e4c7d009654a ("MIPS: BMIPS: Add BCM7435 dtsi")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: john@phrozen.org
Cc: cernekee@gmail.com
Cc: jaedon.shin@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/13132/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:42 +02:00
James Hogan
b3582e67d5 MIPS: Fix HTW config on XPA kernel without LPA enabled
commit 14bc241443e126c62fcbf571b7d4c79740debc58 upstream.

The hardware page table walker (HTW) configuration is broken on XPA
kernels where XPA couldn't be enabled (either nohtw or the hardware
doesn't support it). This is because the PWSize.PTEW field (PTE width)
was only set to 8 bytes (an extra shift of 1) in config_htw_params() if
PageGrain.ELPA (enable large physical addressing) is set. On an XPA
kernel though the size of PTEs is fixed at 8 bytes regardless of whether
XPA could actually be enabled.

Fix the initialisation of this field based on sizeof(pte_t) instead.

Fixes: c5b367835cfc ("MIPS: Add support for XPA.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Steven J. Hill <sjhill@realitydiluted.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13113/
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-10 10:25:42 +02:00