Some Micrel KSZ8041NL PHY chips exhibit continous RX errors after
using the power down mode bit (0.11). If the PHY is taken out of
power down mode in a certain temperature range, the PHY enters a
weird state which leads to continously reporting RX errors. In that
state, the MAC is not able to receive or send any Ethernet frames
and the activity LED is constantly blinking. Since Linux is using
the suspend callback when the interface is taken down, ending up
in that state can easily happen during a normal startup.

Micrel confirmed the issue, caused by abnormal clock recovery when
using power down mode. Even the latest revision (A4, Revision ID
0x1513) seems to suffer that problem.

Remove the suspend/resume callback to avoid using the power down
mode completely.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
(cherry picked from commit a76182f34d2963ee5dca3bc026cbddb44b19be7c)

Deferred probes shouldn't cause error messages in the boot log. Avoid
printing with dev_err() in case EPROBE_DEFER is the return value.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

The dma_required_mask might overestimate the memory size, or might not match
up with the CMA area placement for other reasons. Get the information about
CMA area placement directly from CMA where it is available, but keep the
dma_required_mask as an approximate fallback for architectures where CMA is
not available.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

Make them usable in modules. Some drivers want to know where their
device CMA area is located to make better decisions about the DMA
programming.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

This is the 5.2.7 stable release

commit 4c92057661a3412f547ede95715641d7ee16ddac upstream

Add documentation to the Spectre document about the new swapgs variant of
Spectre v1.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f36cf386e3fec258a341d446915862eded3e13d8 upstream

Intel provided the following information:

 On all current Atom processors, instructions that use a segment register
 value (e.g. a load or store) will not speculatively execute before the
 last writer of that segment retires. Thus they will not use a
 speculatively written segment value.

That means on ATOMs there is no speculation through SWAPGS, so the SWAPGS
entry paths can be excluded from the extra LFENCE if PTI is disabled.

Create a separate bug flag for the through SWAPGS speculation and mark all
out-of-order ATOMs and AMD/HYGON CPUs as not affected. The in-order ATOMs
are excluded from the whole mitigation mess anyway.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64dbc122b20f75183d8822618c24f85144a5a94d upstream

Somehow the swapgs mitigation entry code patch ended up with a JMPQ
instruction instead of JMP, where only the short jump is needed.  Some
assembler versions apparently fail to optimize JMPQ into a two-byte JMP
when possible, instead always using a 7-byte JMP with relocation.  For
some reason that makes the entry code explode with a #GP during boot.

Change it back to "JMP" as originally intended.

Fixes: 18ec54fdd6d1 ("x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations")
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>