MIPS: Remove pt_regs adjustments in indirect syscall handler

If a restartable syscall is called using the indirect o32 syscall
handler - eg: syscall(__NR_waitid, ...), then it is possible for the
incorrect arguments to be passed to the syscall after it has been
restarted. This is because the syscall handler tries to shift all the
registers down one place in pt_regs so that when the syscall is restarted,
the "real" syscall is called instead. Unfortunately it only shifts the
arguments passed in registers, not the arguments on the user stack. This
causes the 4th argument to be duplicated when the syscall is restarted.

Fix by removing all the pt_regs shifting so that the indirect syscall
handler is called again when the syscall is restarted. The comment "some
syscalls like execve get their arguments from struct pt_regs" is long
out of date so this should now be safe.

Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Tested-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15856/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Gbp-Pq: Topic bugfix/mips
Gbp-Pq: Name mips-remove-pt_regs-adjustments-in-indirect-syscall-.patch

ARM: dts: exynos: Add dwc3 SUSPHY quirk

Odroid XU4 board does not enumerate SuperSpeed devices.
This patch makes exynos5 series chips use USB SUSPHY quirk,
which solves the problem.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-exynos-add-dwc3-susphy-quirk.patch

powerpc/64s: Invalidate ERAT on powersave wakeup for POWER9

On POWER9 the ERAT may be incorrect on wakeup from some stop states
that lose state. This causes random segvs and illegal instructions
when these stop states are enabled.

This patch invalidates the ERAT on wakeup on POWER9 to prevent this
from causing a problem.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Merge comment change with upstream changes]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-invalidate-erat-on-powersave-wakeup-for-power9.patch

platform/x86: ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun <yjx@flygoat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-several-models-to-no.patch

platform/x86: ideapad-laptop: Add IdeaPad V510-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad V510-15IKB does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V510-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v510-15ikb-t.patch

platform/x86: ideapad-laptop: Add Y720-15IKBN to no_hw_rfkill

Lenovo Legion Y720-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y720-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill

Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y520-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add IdeaPad V310-15ISK to no_hw_rfkill

Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v310-15isk-t.patch

platform/x86: ideapad-laptop: Add IdeaPad 310-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad 310-15IKB does not have an hw rfkill
switch. This results in hard-blocked radios after boot, resulting in
always blocked radios rendering them unusable.

Add the IdeaPad 310-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Rebhan <Sven.Rebhan@googlemail.com>
[andy: massaged commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-310-15ikb-to.patch

platform/x86: ideapad-laptop: Add Y700 15-ACZ to no_hw_rfkill DMI list

Like other Y700 models Lenovo Y700 15-ACZ does not have a physical rfkill switch.
ideapad-laptop wrongly reports all radios as blocked by hardware which causes
wireless network connections to fail.

Add this model without an rfkill switch to the no_hw_rfkill list.

Signed-off-by: Artiom Vaskov <velemas@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y700-15-acz-to-no_hw.patch

pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago systems

It turns out there are quite many Chromebooks out there that have the
same keyboard issue than Acer Chromebook. All of them are based on
Intel_Strago reference and report their DMI_PRODUCT_FAMILY as
"Intel_Strago" (Samsung Chromebook 3 and Cyan Chromebooks are exceptions
for which we add separate entries).

Instead of adding each machine to the quirk table, we use
DMI_PRODUCT_FAMILY of "Intel_Strago" that hopefully covers most of the
machines out there currently.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945
Suggested: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name pinctrl-cherryview-extend-the-chromebook-dmi-quirk-t.patch

firmware: dmi: Add DMI_PRODUCT_FAMILY identification string

Sometimes it is more convenient to be able to match a whole family of
products, like in case of bunch of Chromebooks based on Intel_Strago to
apply a driver quirk instead of quirking each machine one-by-one.

This adds support for DMI_PRODUCT_FAMILY identification string and also
exports it to the userspace through sysfs attribute just like the
existing ones.

Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gbp-Pq: Topic features/all
Gbp-Pq: Name firmware-dmi-add-dmi_product_family-identification-s.patch

ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals).  Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.

Reported-by: gmbh@gazeta.pl
Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017
Cc: stable@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch

Don't WARN about expected W+X pages on Xen

Currently Xen PV domains (or at least dom0) on amd64 tend to have a
large number of low kernel pages with W+X permissions.  It's not
obvious how to fix this, and we're not going to get any new
information by WARNing about this, but we do still want to hear about
other W+X cases.  So add a condition to the WARN_ON.

Gbp-Pq: Topic debian
Gbp-Pq: Name amd64-don-t-warn-about-expected-w+x-pages-on-xen.patch

btrfs: warn about RAID5/6 being experimental at mount time

Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]

Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch

fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS

Various free and proprietary AV products use this feature and users
apparently want it.  But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that.  So warn and taint the kernel if this feature is
actually used.

Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch

fjes: Disable auto-loading

fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device.  Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.

Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch

viafb: Autoload on OLPC XO 1.5 only

It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match.  Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.

However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch

snd-pcsp: Disable autoload

There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
  play barely recognisable renditions of sampled sound

snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that.  On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.

In case anyone finds snd-pcsp useful, we continue to build it.  But
remove the alias, to ensure it's not loaded where it's not wanted.

Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch

cdc_ncm,cdc_mbim: Use NCM by default

Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.

Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.

Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch

security,perf: Allow further restriction of perf_event_open

When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.

This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
the variable read-only.  It also allows enabling further restriction
at run-time regardless of whether the default is changed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch

add sysctl to disallow unprivileged CLONE_NEWUSER by default

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch.  Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces.  However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]

Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch

yama: Disable by default

Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch

sched: Do not enable autogrouping by default

We want to provide the option of autogrouping but without enabling
it by default yet.

Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch

fs: Enable link security restrictions by default

This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').

Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch

dccp: Disable auto-loading as mitigation against local exploits

We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.

The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch

decnet: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch

rds: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch

af_802154: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch

aufs4.9 standalone patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.9 standalone patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-standalone.patch

aufs4.9 mmap patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.9 mmap patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-mmap.patch

aufs4.9 base patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.9 base patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-base.patch

radeon: Firmware is required for DRM and KMS on R600 onward

radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.

radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.

Therefore, perform a basic check for the existence of
/lib/firmware/radeon when a device is probed, and abort if it is
missing, except for the pre-R600 case.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-firmware-is-required-for-drm-and-kms-on-r600-onward.patch

firmware: Remove redundant log messages from drivers

Now that firmware_class logs every success and failure consistently,
many other log messages can be removed from drivers.

This will probably need to be split up into multiple patches prior to
upstream submission.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware-remove-redundant-log-messages-from-drivers.patch

firmware_class: Log every success and failure against given device

The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures.  They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that.  Therefore, add specific log messages for the failure modes that
aren't currently logged.

In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise.  Therefore, also log successes.

This makes many error messages in drivers redundant, which will be
removed in later patches.

This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).

NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch

iwlwifi: Do not request unreleased firmware for IWL6000

The iwlwifi driver currently supports firmware API versions 4-6 for
these devices.  It will request the file for the latest supported
version and then fall back to earlier versions.  However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.

The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless.  So stop
requesting the unreleased firmware.

Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch

af9005: Use request_firmware() to load register init script

Read the register init script from the Windows driver.  This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.

Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch

Install perf scripts non-executable

[bwh: Forward-ported to 3.12]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-install.patch

Create manpages and binaries including the version

[bwh: Fix version insertion in perf man page cross-references and perf
man page title.  Install bash_completion script for perf with a
version-dependent name.  And do the same for trace.]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-version.patch

modpost symbol prefix setting

[bwh: The original version of this was added by Bastian Blank.  The
upstream code includes <generated/autoconf.h> so that <linux/export.h>
can tell whether C symbols have an underscore prefix.  Since we build
modpost separately from the kernel, <generated/autoconf.h> won't exist.
However, no Debian Linux architecture uses the symbol prefix, so we
can simply omit it.]

Gbp-Pq: Topic debian
Gbp-Pq: Name modpost-symbol-prefix.patch

Kbuild: kconfig: Verbose version of --listnewconfig

If the KBUILD_VERBOSE environment variable is set to non-zero, show
the default values of new symbols and not just their names.

Based on work by Bastian Blank <waldi@debian.org> and
maximilian attems <max@stro.at>.  Simplified by Michal Marek
<mmarek@suse.cz>.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name Kbuild-kconfig-Verbose-version-of-listnewconfig.patch

powerpcspe-omit-uimage

Gbp-Pq: Topic debian
Gbp-Pq: Name powerpcspe-omit-uimage.patch

Fix uImage build

[bwh: This was added without a description, but I think it is dealing
with a similar issue to powerpcspe-omit-uimage.patch]

Gbp-Pq: Topic debian
Gbp-Pq: Name arch-sh4-fix-uimage-build.patch

Partially revert "MIPS: Add -Werror to arch/mips/Kbuild"

This reverts commit 66f9ba101f54bda63ab1db97f9e9e94763d0651b.

We really don't want to add -Werror anywhere.

Gbp-Pq: Topic debian
Gbp-Pq: Name mips-disable-werror.patch

Tweak gitignore for Debian pkg-kernel using git svn.

[bwh: Tweak further for pure git]

Gbp-Pq: Topic debian
Gbp-Pq: Name gitignore.patch

kbuild: Make the toolchain variables easily overwritable

Allow make variables to be overridden for each flavour by a file in
the build tree, .kernelvariables.

We currently use this for ARCH, KERNELRELEASE, CC, and in some cases
also CROSS_COMPILE, CFLAGS_KERNEL and CFLAGS_MODULE.

This file can only be read after we establish the build tree, and all
use of $(ARCH) needs to be moved after this.

Gbp-Pq: Topic debian
Gbp-Pq: Name kernelvariables.patch

Make mkcompile_h accept an alternate timestamp string

We want to include the Debian version in the utsname::version string
instead of a full timestamp string.  However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.

Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.

Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch

Include package version along with kernel release in stack traces

For distribution binary packages we assume
$DISTRIBUTION_OFFICIAL_BUILD, $DISTRIBUTOR and $DISTRIBUTION_VERSION
are set.

Gbp-Pq: Topic debian
Gbp-Pq: Name version.patch

linux (4.9.82-1+deb9u3) stretch-security; urgency=medium

  * [powerpc] Backport more RFI flush related patches from 4.9.84.  Closes:
    #891249.
  * [powerpc] Ignore ABI change in paca.

[dgit import unpatched linux 4.9.82-1+deb9u3]

Import linux_4.9.82-1+deb9u3.debian.tar.xz

[dgit import tarball linux 4.9.82-1+deb9u3 linux_4.9.82-1+deb9u3.debian.tar.xz]

Import linux_4.9.82.orig.tar.xz

[dgit import orig linux_4.9.82.orig.tar.xz]