As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge, all such checking should be done by it. If
ACPI data gets uploaded despite some missing capability, the hypervisor
is free to ignore part or all of that data.

Ditch the entire check_prereq() function, and do the only valid check
(xen_initial_domain()) in the caller in its place.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

No need to retain a local copy of the full request message, only the
type is really needed.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

xenbus_dev_request_and_reply() needs to track whether a transaction is
open.  For XS_TRANSACTION_START messages it calls transaction_start()
and for XS_TRANSACTION_END messages it calls transaction_end().

If sending an XS_TRANSACTION_START message fails or responds with an
an error, the transaction is not open and transaction_end() must be
called.

If sending an XS_TRANSACTION_END message fails, the transaction is
still open, but if an error response is returned the transaction is
closed.

Commit 027bd7e8 ("xen/xenbus: Avoid synchronous wait on XenBus
stalling shutdown/restart") introduced a regression where failed
XS_TRANSACTION_START messages were leaving the transaction open.  This
can cause problems with suspend (and migration) as all transactions
must be closed before suspending.

It appears that the problematic change was added accidentally, so just
remove it.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

As get the right evv voltage, update them to latest coefficients to
align with BB.

agd: squash in Slava's 32 bit build fix
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

value is 32 bits for polaris, not 16.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NKen Wang <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

'0' means true.
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There is a race condition in the AMD IOMMU init code that
causes requested unity mappings to be blocked by the IOMMU
for a short period of time. This results on boot failures
and IO_PAGE_FAULTs on some machines.

Fix this by making sure the unity mappings are installed
before all other DMA is blocked.

Fixes: aafd8ba0 ('iommu/amd: Implement add_device and remove_device')
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

The FIFO unlocking mechanism in acpi_dbg has been broken by the
following commit:

  Commit: 287980e4
  Subject: remove lots of IS_ERR_VALUE abuses

It converted !IS_ERR_VALUE(ret) into !ret which was not entirely
correct. Fix the regression by taking ret > 0 into account too as
appropriate.

Fixes: 287980e4 (remove lots of IS_ERR_VALUE abuses)
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
[ rjw: Simplifications, changelog & subject massage ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We verify "u_cmd.outsize" and "u_cmd.insize" but we need to make sure
that those values have not changed between the two copy_from_user()
calls.  Otherwise it could lead to a buffer overflow.

Additionally, cros_ec_cmd_xfer() can set s_cmd->insize to a lower value.
We should use the new smaller value so we don't copy too much data to
the user.
Reported-by: NPengfei Wang <wpengfeinudt@gmail.com>
Fixes: a8411784 ('mfd: cros_ec: Use a zero-length array for command data')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: NOlof Johansson <olof@lixom.net>

Fixes a regression caused by a stupid thinko from "disp/sor/gf119: both
links use the same training register".
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

There is a lock order issue in acpi_load_tables(). The namespace lock
is held before holding the interpreter lock.

With ACPI_MUTEX_DEBUG enabled in the kernel, this is printed to the
log during boot:

  [    0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns [ACPI_MTX_Namespace], wants [ACPI_MTX_Interpreter] (20160422/utmutex-263)
  [    0.885881] ACPI Error: Could not acquire AML Interpreter mutex (20160422/exutils-95)
  [    0.893846] ACPI Error: Mutex [0x0] is not acquired, cannot release (20160422/utmutex-326)
  [    0.894019] ACPI Error: Could not release AML Interpreter mutex (20160422/exutils-133)

The issue has been introduced by the following commit:

  Commit: 2f38b1b1
  ACPICA Commit: bfe03ffcde8ed56a7eae38ea0b188aeb12f9c52e
  Subject: ACPICA: Namespace: Fix a regression that MLC support triggers
           dead lock in dynamic table loading

Which fixed a deadlock issue for acpi_ns_load_table() in
acpi_ex_add_table() but didn't take care of the lock order in
acpi_ns_load_table() correctly.

Originally (before the above commit), ACPICA used the
namespace/interpreter locks in the following 2 key code
paths:

 1. Table loading:
 acpi_ns_load_table
	L(Namespace)
		acpi_ns_parse_table
			acpi_ns_one_complete_parse
	U(Namespace)
 2. Object evaluation:
 acpi_ns_evaluate
	L(Interpreter)
	acpi_ps_execute_method
		U(Interpreter)
		acpi_ns_load_table
			L(Namespace)
			U(Namespace)
		acpi_ev_initialize_region
			L(Namespace)
			U(Namespace)
		address_space.setup
			L(Namespace)
			U(Namespace)
		address_space.handler
			L(Namespace)
			U(Namespace)
		acpi_os_wait_semaphore
		acpi_os_acquire_mutex
		acpi_os_sleep
		L(Interpreter)
	U(Interpreter)

During runtime, while acpi_ns_evaluate is called, the lock order is
always Interpreter -> Namespace.

In turn, the problematic commit acquires the locks in the following
order:

 3. Table loading:
 acpi_ns_load_table
	L(Namespace)
		acpi_ns_parse_table
		L(Interpreter)
			acpi_ns_one_complete_parse
		U(Interpreter)
	U(Namespace)

To fix the lock order issue, move the interpreter lock to
acpi_ns_load_table() to ensure the lock order correctness:

 4. Table loading:
 acpi_ns_load_table
	L(Interpreter)
	L(Namespace)
		acpi_ns_parse_table
			acpi_ns_one_complete_parse
	U(Namespace)
	U(Interpreter)

However, this doesn't fix the current design issues related to the
namespace lock. For example, we can notice that in acpi_ns_evaluate(),
outside of acpi_ns_load_table(), the namespace objects may be created
by the named object creation control methods. And the creation of
the method-owned namespace objects are not locked by the namespace
lock. This patch doesn't try to fix such kind of existing issues.

Fixes: 2f38b1b1 (ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading)
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL
pointer dereference when rsp->msix is NULL:

[    5.622457] NULL pointer dereference at 0000000000000050
[    5.622457] IP: [<ffffffff8155e614>] qla24xx_process_response_queue+0x44/0x4b0
[    5.622457] PGD 0
[    5.622457] Oops: 0000 [#1] SMP
[    5.622457] Modules linked in:
[    5.622457] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.6.3-x86_64 #1
[    5.622457] Hardware name: HP ProLiant DL360 G5, BIOS P58 05/02/2011
[    5.622457] task: ffff8801a88f3740 ti: ffff8801a8954000 task.ti: ffff8801a8954000
[    5.622457] RIP: 0010:[<ffffffff8155e614>]  [<ffffffff8155e614>] qla24xx_process_response_queue+0x44/0x4b0
[    5.622457] RSP: 0000:ffff8801afb03de8  EFLAGS: 00010002
[    5.622457] RAX: 0000000000000000 RBX: 0000000000000032 RCX: 00000000ffffffff
[    5.622457] RDX: 0000000000000002 RSI: ffff8801a79bf8c8 RDI: ffff8800c8f7e7c0
[    5.622457] RBP: ffff8801afb03e68 R08: 0000000000000000 R09: 0000000000000000
[    5.622457] R10: 00000000ffff8c47 R11: 0000000000000002 R12: ffff8801a79bf8c8
[    5.622457] R13: ffff8800c8f7e7c0 R14: ffff8800c8f60000 R15: 0000000000018013
[    5.622457] FS:  0000000000000000(0000) GS:ffff8801afb00000(0000) knlGS:0000000000000000
[    5.622457] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.622457] CR2: 0000000000000050 CR3: 0000000001e07000 CR4: 00000000000006e0
[    5.622457] Stack:
[    5.622457]  ffff8801afb03e30 ffffffff810c0f2d 0000000000000086 0000000000000002
[    5.622457]  ffff8801afb03e28 ffffffff816570e1 ffff8800c8994628 0000000000000002
[    5.622457]  ffff8801afb03e60 ffffffff816772d4 b47c472ad6955e68 0000000000000032
[    5.622457] Call Trace:
[    5.622457]  <IRQ>
[    5.622457]  [<ffffffff810c0f2d>] ? __wake_up_common+0x4d/0x80
[    5.622457]  [<ffffffff816570e1>] ? usb_hcd_resume_root_hub+0x51/0x60
[    5.622457]  [<ffffffff816772d4>] ? uhci_hub_status_data+0x64/0x240
[    5.622457]  [<ffffffff81560d00>] qla24xx_intr_handler+0xf0/0x2e0
[    5.622457]  [<ffffffff810d569e>] ? get_next_timer_interrupt+0xce/0x200
[    5.622457]  [<ffffffff810c89b4>] handle_irq_event_percpu+0x64/0x100
[    5.622457]  [<ffffffff810c8a77>] handle_irq_event+0x27/0x50
[    5.622457]  [<ffffffff810cb965>] handle_edge_irq+0x65/0x140
[    5.622457]  [<ffffffff8101a498>] handle_irq+0x18/0x30
[    5.622457]  [<ffffffff8101a276>] do_IRQ+0x46/0xd0
[    5.622457]  [<ffffffff817f8fff>] common_interrupt+0x7f/0x7f
[    5.622457]  <EOI>
[    5.622457]  [<ffffffff81020d38>] ? mwait_idle+0x68/0x80
[    5.622457]  [<ffffffff8102114a>] arch_cpu_idle+0xa/0x10
[    5.622457]  [<ffffffff810c1b97>] default_idle_call+0x27/0x30
[    5.622457]  [<ffffffff810c1d3b>] cpu_startup_entry+0x19b/0x230
[    5.622457]  [<ffffffff810324c6>] start_secondary+0x136/0x140
[    5.622457] Code: 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 47 58 a8 02 0f 84 c5 00 00 00 48 8b 46 50 49 89 f4 65 8b 15 34 bb aa 7e <39> 50 50 74 11 89 50 50 48 8b 46 50 8b 40 50 41 89 86 60 8b 00
[    5.622457] RIP  [<ffffffff8155e614>] qla24xx_process_response_queue+0x44/0x4b0
[    5.622457]  RSP <ffff8801afb03de8>
[    5.622457] CR2: 0000000000000050
[    5.622457] ---[ end trace fa2b19c25106d42b ]---
[    5.622457] Kernel panic - not syncing: Fatal exception in interrupt

The affected code was introduced by commit cdb898c5
(qla2xxx: Add irq affinity notification).

Only dereference rsp->msix when it has been set so the machine can boot
fine. Possibly rsp->msix is unset because:
[    3.479679] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 8.07.00.33-k.
[    3.481839] qla2xxx [0000:13:00.0]-001d: : Found an ISP2432 irq 17 iobase 0xffffc90000038000.
[    3.484081] qla2xxx [0000:13:00.0]-0035:0: MSI-X; Unsupported ISP2432 (0x2, 0x3).
[    3.485804] qla2xxx [0000:13:00.0]-0037:0: Falling back-to MSI mode -258.
[    3.890145] scsi host0: qla2xxx
[    3.891956] qla2xxx [0000:13:00.0]-00fb:0: QLogic QLE2460 - PCI-Express Single Channel 4Gb Fibre Channel HBA.
[    3.894207] qla2xxx [0000:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ 0000:13:00.0 hdma+ host#=0 fw=7.03.00 (9496).
[    5.714774] qla2xxx [0000:13:00.0]-500a:0: LOOP UP detected (4 Gbps).
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Acked-by: NQuinn Tran <quinn.tran@qlogic.com>
CC: <stable@vger.kernel.org>  # 4.5+
Fixes: cdb898c5Signed-off-by: NJames Bottomley <jejb@linux.vnet.ibm.com>

Change t4fw_version.h to update latest firmware version number
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

GCC complains on unused-but-set-variable, clean this up.

Fixes: 23898c76 ('net/mlx5: E-Switch, Modify node guid on vf set MAC')
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Acked-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, link notifications are not sent by
bond_set_slave_link_state() upon enslavement if
the slave is enslaved when up.

This happens because slave->link default init value
is 0, which is the same as BOND_LINK_UP, resulting
in bond_set_slave_link_state() ignoring this transition.

This patch sets the default value of slave->link to
BOND_LINK_NOCHANGE, assuring it will count as a state
transition and thus trigger notification logic.
Signed-off-by: NAviv Heller <avivh@mellanox.com>
Reviewed-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The RTL8152 doesn't have U1U2 and U2P3 features, so use different
runtime functions for RTL812 and RTL8153 by adding autosuspend_en()
to rtl_ops.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 1e4a8064.

This creates more problems than it solves right now. Compile
testing needs to go in with patches fixing the problems it
uncovers.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit fbde2d7d ("MIPS: Add generic SMP IPI support") introduced
code which calls irq_find_matching_host with a NULL node parameter in
order to discover IPI IRQ domains which are not associated with the DT
root node's interrupt parent. This suggests that implementations of IPI
IRQ domains should effectively ignore the node parameter if it is NULL
and search purely based upon the bus token. Commit 2af70a96
("irqchip/mips-gic: Add a IPI hierarchy domain") did not do this when
implementing the GIC IPI IRQ domain, and on MIPS Boston boards this
leads to no IPI domain being discovered and a NULL pointer dereference
when attempting to send an IPI:

  CPU 0 Unable to handle kernel paging request at virtual address 0000000000000040, epc == ffffffff8016e70c, ra == ffffffff8010ff5c
  Oops[#1]:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc6-00223-gad0d1b6 #945
  task: a8000000ff066fc0 ti: a8000000ff068000 task.ti: a8000000ff068000
  $ 0   : 0000000000000000 0000000000000001 ffffffff80730000 0000000000000003
  $ 4   : 0000000000000000 ffffffff8057e5b0 a800000001e3ee00 0000000000000000
  $ 8   : 0000000000000000 0000000000000023 0000000000000001 0000000000000001
  $12   : 0000000000000000 ffffffff803323d0 0000000000000000 0000000000000000
  $16   : 0000000000000000 0000000000000000 0000000000000001 ffffffff801108fc
  $20   : 0000000000000000 ffffffff8057e5b0 0000000000000001 0000000000000000
  $24   : 0000000000000000 ffffffff8012de28
  $28   : a8000000ff068000 a8000000ff06fbc0 0000000000000000 ffffffff8010ff5c
  Hi    : ffffffff8014c174
  Lo    : a800000001e1e140
  epc   : ffffffff8016e70c __ipi_send_mask+0x24/0x11c
  ra    : ffffffff8010ff5c mips_smp_send_ipi_mask+0x68/0x178
  Status: 140084e2        KX SX UX KERNEL EXL
  Cause : 00800008 (ExcCode 02)
  BadVA : 0000000000000040
  PrId  : 0001a920 (MIPS I6400)
  Process swapper/0 (pid: 1, threadinfo=a8000000ff068000, task=a8000000ff066fc0, tls=0000000000000000)
  Stack : 0000000000000000 0000000000000000 0000000000000001 ffffffff801108fc
            0000000000000000 ffffffff8057e5b0 0000000000000001 ffffffff8010ff5c
            0000000000000001 0000000000000020 0000000000000000 0000000000000000
            0000000000000000 ffffffff801108fc 0000000000000000 0000000000000001
            0000000000000001 0000000000000000 0000000000000000 ffffffff801865e8
            a8000000ff0c7500 a8000000ff06fc90 0000000000000001 0000000000000002
            ffffffff801108fc ffffffff801868b8 0000000000000000 ffffffff801108fc
            0000000000000000 0000000000000003 ffffffff8068c700 0000000000000001
            ffffffff80730000 0000000000000001 a8000000ff00a290 ffffffff80110c50
            0000000000000003 a800000001e48308 0000000000000003 0000000000000008
            ...
  Call Trace:
  [<ffffffff8016e70c>] __ipi_send_mask+0x24/0x11c
  [<ffffffff8010ff5c>] mips_smp_send_ipi_mask+0x68/0x178
  [<ffffffff801865e8>] generic_exec_single+0x150/0x170
  [<ffffffff801868b8>] smp_call_function_single+0x108/0x160
  [<ffffffff80110c50>] cps_boot_secondary+0x328/0x394
  [<ffffffff80110534>] __cpu_up+0x38/0x90
  [<ffffffff8012de4c>] bringup_cpu+0x24/0xac
  [<ffffffff8012df40>] cpuhp_up_callbacks+0x58/0xdc
  [<ffffffff8012e648>] cpu_up+0x118/0x18c
  [<ffffffff806dc158>] smp_init+0xbc/0xe8
  [<ffffffff806d4c18>] kernel_init_freeable+0xa0/0x228
  [<ffffffff8056c908>] kernel_init+0x10/0xf0
  [<ffffffff80105098>] ret_from_kernel_thread+0x14/0x1c

Fix this by allowing the GIC IPI IRQ domain to match purely based upon
the bus token if the node provided is NULL.

Fixes: 2af70a96 ("irqchip/mips-gic: Add a IPI hierarchy domain")
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20160705132600.27730-2-paul.burton@imgtec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

When mapping an interrupt to a VP(E) we must use the identifier for the
VP that the hardware expects, and this does not always match up with the
Linux CPU number. Commit d46812bb ("irqchip: mips-gic: Use HW IDs
for VPE_OTHER_ADDR") corrected this for the cases that existed at the
time it was written, but commit 2af70a96 ("irqchip/mips-gic: Add a
IPI hierarchy domain") added another case before the former patch was
merged. This leads to incorrectly using Linux CPU numbers when mapping
interrupts to VPs, which breaks on certain systems such as those with
multi-core I6400 CPUs. Fix by adding the appropriate call to
mips_cm_vp_id() to retrieve the expected VP identifier.

Fixes: d46812bb ("irqchip: mips-gic: Use HW IDs for VPE_OTHER_ADDR")
Fixes: 2af70a96 ("irqchip/mips-gic: Add a IPI hierarchy domain")
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20160705132600.27730-1-paul.burton@imgtec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

A qeth_card contains a napi_struct linked to the net_device during
device probing. This struct must be deleted when removing the qeth
device, otherwise Panic on oops can occur when qeth devices are
repeatedly removed and added.

Fixes: a1c3ed4c ("qeth: NAPI support for l2 and l3 discipline")
Cc: stable@vger.kernel.org # v2.6.37+
Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
Tested-by: NAlexander Klein <ALKL@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit a788a4a0.

This patch is wrong, the type returned doesn't fit
what the error pointer macros expect.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is likely that checking 'fman->fifo_offset' instead of
'fman->cam_offset' is expected here.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Several Lenovo users have reported problems with their Sierra
Wireless EM7455 modem. The driver has loaded successfully and
the MBIM management channel has appeared to work, including
establishing a connection to the mobile network. But no frames
have been received over the data interface.

The problem affects all EM7455 and MC7455, and is assumed to
affect other modems based on the same Qualcomm chipset and
baseband firmware.

Testing narrowed the problem down to what seems to be a
firmware timing bug during initialization. Adding a short sleep
while probing is sufficient to make the problem disappear.
Experiments have shown that 1-2 ms is too little to have any
effect, while 10-20 ms is enough to reliably succeed.
Reported-by: NStefan Armbruster <ml001@armbruster-it.de>
Reported-by: NRalph Plawetzki <ralph@purejava.org>
Reported-by: NAndreas Fett <andreas.fett@secunet.com>
Reported-by: NRasmus Lerdorf <rasmus@lerdorf.com>
Reported-by: NSamo Ratnik <samo.ratnik@gmail.com>
Reported-and-tested-by: NAleksander Morgado <aleksander@aleksander.es>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For ipv6+udp+geneve encapsulation data, the max_mtu should subtract
sizeof(ipv6hdr), instead of sizeof(iphdr).
Signed-off-by: NHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 923b93e4.

Make sure consumers do not overwrite gpio flags for pins that have
already been claimed.

While adding support for gpio drivers to refuse a request using
unsupported flags, the order of when the requested flag was checked and
the new flags were applied was reversed to that consumers could
overwrite flags for already requested gpios.

This not only affects device-tree setups where two drivers could request
the same gpio using conflicting configurations, but also allowed user
space to clear gpio flags for already claimed pins simply by attempting
to export them through the sysfs interface. By for example clearing the
FLAG_ACTIVE_LOW flag this way, user space could effectively change the
polarity of a signal.

Reverting this change obviously prevents gpio drivers from doing sanity
checks on the flags in their request callbacks. Fortunately only one
recently added driver (gpio-tps65218 in v4.6) appears to do this, and a
follow up patch could restore this functionality through a different
interface.

Cc: stable <stable@vger.kernel.org>	# 4.4
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This fixes the issue descirbe in bug 117531
(https://bugzilla.kernel.org/show_bug.cgi?id=117531).
It's a regression introduced in linux 4.5 that causes a Oops at load of
gpio_sch and prevents powering off the computer.

The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
gpio_chip data is initialized with the pointer to the sch_gpio struct. As
sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
the Oops.

The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
sch_gpio struct directly instead of a gpio_chip, which avoids the call to
gpiochip_get_data.

Thanks Mika for your patience with me :-)

Cc: stable@vger.kernel.org
Signed-off-by: NColin Pitrat <colin.pitrat@gmail.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Snooze is a poll idle state in powernv and pseries platforms. Snooze
has a timeout so that if a CPU stays in snooze for more than target
residency of the next available idle state, then it would exit
thereby giving chance to the cpuidle governor to re-evaluate and
promote the CPU to a deeper idle state. Therefore whenever snooze
exits due to this timeout, its last_residency will be target_residency
of the next deeper state.

Commit e93e59ce "cpuidle: Replace ktime_get() with local_clock()"
changed the math around last_residency calculation. Specifically,
while converting last_residency value from nano- to microseconds, it
carries out right shift by 10. Because of that, in snooze timeout
exit scenarios last_residency calculated is roughly 2.3% less than
target_residency of the next available state. This pattern is picked
up by get_typical_interval() in the menu governor and therefore
expected_interval in menu_select() is frequently less than the
target_residency of any state other than snooze.

Due to this we are entering snooze at a higher rate, thereby
affecting the single thread performance.

Fix this by using more precise division via ktime_us_delta().

Fixes: e93e59ce "cpuidle: Replace ktime_get() with local_clock()"
Reported-by: NAnton Blanchard <anton@samba.org>
Bisected-by: NShilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NBalbir Singh <bsingharora@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Per VT-d spec Section 10.4.2 ("Capability Register"), the maximum
number of possible domains is 64K; indeed this is the maximum value
that the cap_ndoms() macro will expand to.  Since the value 65536
will not fix in a u16, the 'did' variable must be promoted to an
int, otherwise the test for < 65536 will always be true and the
loop will never end.

The symptom, in my case, was a hung machine during suspend.

Fixes: 3bd4f911 ("iommu/vt-d: Fix overflow of iommu->domains array")
Signed-off-by: NAaron Campbell <aaron@monkey.org>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

When initializing the PHY control register, the FIFO depth bits are
written without reading the previous register value, i.e. all other
bits are overwritten with zero. This disables automatic MDI-X
configuration, which is enabled by default. Fix initialization by doing
a read/modify/write operation.
Signed-off-by: NStefan Hauser <stefan@shauser.net>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The interrupt worker code for the enc28j60 relies only on the TXIF flag to
determinate if the packet transmission was completed. However the datasheet
specifies in section 12.1.3 that TXERIF will clear the TXRTS after a
transmit abort. Also in section 12.1.4 that TXIF will be set
when TXRTS transitions from '1' to '0'. Therefore the TXIF flag is enabled
during transmission errors.

This causes a race condition, since the worker code will invoke
enc28j60_tx_clear() -> netif_wake_queue(), potentially invoking the
ndo_start_xmit function to send a new packet. The enc28j60_send_packet function
uses a workqueue that invokes enc28j60_hw_tx(). In between this function is
called, the worker from the interrupt handler will enter the path for error
handler because of the TXERIF flag, causing to invoke enc28j60_tx_clear() again
and releasing the packet scheduled for transmission, causing a kernel crash with
due a NULL pointer.

These crashes due a NULL pointer were observed under stress conditions of the
device. A BUG_ON() sequence was used to validate the issue was fixed, and has
been running without problems for 2 years now.
Signed-off-by: NDiego Dompe <dompe@hpe.com>
Acked-by: NSergio Valverde <sergio.valverde@hpe.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

(resent due to overhelpful mail client corrupting patch)

At least on Meson GXBB, the CORE_IRQ_MTL_RX_OVERFLOW interrupt is thrown
with the stmmac1000 driver, which does not support set_rx_tail_ptr. With
this patch and the clock fixes, 1G ethernet works on ODROID-C2.
Signed-off-by: NMatt Corallo <git@bluematt.me>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since commit 103544d8 (ACPI,PCI,IRQ: reduce resource requirements)
the penalty values are calculated on the fly rather than at boot time.

This works fine for PCI interrupts but not so well for ISA interrupts.

The information on whether or not an ISA interrupt is in use is not
available to the pci_link.c code directly.  That information is
obtained from the outside via acpi_penalize_isa_irq().  [If its
"active" argument is true, then the IRQ is in use by ISA.]

Since the current code relies on PCI Link objects for determination
of penalties, we are factoring in the PCI penalty twice after
acpi_penalize_isa_irq() function is called.

To avoid that, limit the newly added functionality to just PCI
interrupts so that old behavior is still maintained.

Fixes: 103544d8 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Tested-by: NWim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Trying to make the ISA and PCI init functionality common turned out
to be a bad idea, because the ISA path depends on external
functionality.

Restore the previous behavior and limit the refactoring to PCI
interrupts only.

Fixes: 1fcb6a81 "ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()"
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Tested-by: NWim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The change introduced in commit 103544d8 (ACPI,PCI,IRQ: reduce
resource requirements) omitted the initially applied PCI_POSSIBLE
penalty when the IRQ is active.

Incorrect calculation of the penalty leads the ACPI code to assigning
a wrong interrupt number to a PCI INTx interrupt.

This would not be as bad as it sounds in theory.  It would just cause
the interrupts to be shared and result in performance penalty.

However, some drivers (like the parallel port driver) don't like
interrupt sharing and in the above case they will causes all of
the PCI drivers wanting to share the interrupt to be unable to
request it.

The issue has not been caught in testing because the behavior is
platform-specific and depends on the peripherals ending up sharing
the IRQ and their drivers.

Before the above commit the code would add the PCI_POSSIBLE value
divided by the number of possible IRQ users to the IRQ penalty
during initialization.

Later in that code path, if the IRQ is chosen as the active IRQ or
if it is used by ISA; additional penalties are added.

Fixes: 103544d8 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Tested-by: NWim Osterholt <wim@djo.tudelft.nl>
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On 64bits kernels, device stats are 64bits wide, not 32bits.

Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Avoid recursions of dev_queue_xmit() to the wrong net device when
frames are unprotected, since at that time skb->dev still points to
our own macsec dev and unlike macsec_encrypt_finish() dev pointer
doesn't get updated to real underlying device.

Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NSabrina Dubroca <sd@queasysnail.net>
Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>