[PATCH] arm64: Enable 48bit VA
by Jeremy Linton
The existing 42-bit VA used in fedora is quite limiting. Lets
turn on 48-bit VA's now that the core mozjs/polkit fixes are in
place.
Signed-off-by: Jeremy Linton <jeremy.linton(a)arm.com>
---
config-arm64 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/config-arm64 b/config-arm64
index 4156910..15027e3 100644
--- a/config-arm64
+++ b/config-arm64
@@ -1,6 +1,9 @@
CONFIG_64BIT=y
CONFIG_ARM64=y
+CONFIG_ARM64_VA_BITS_48=y
+CONFIG_ARM64_VA_BITS=48
+
# arm64 only SoCs
CONFIG_ARCH_HISI=y
CONFIG_ARCH_QCOM=y
--
2.5.5
7 years, 1 month
[PATCH 0/5] drm/i915/skl: Backport watermark fixes for 4.8.y
by Lyude
Hey! Hans de Geode requested that I also send this patch series to you guys.
These are the fixes for most (maybe even all) of the issues with display
flickering that users have been seeing on Skylake systems. They've already been
submitted for inclusion in 4.8.y.
Original message
Now that these have finally made it into 4.9, it's time to finally backport
these fixes. Skylake has been a mess in multi-monitor setups for a while now
because up until recently we've been updating the watermarks on Skylake just
like we would for previous generations of Intel GPUs. This means updating
attributes for each plane, and then only after they've been updated writing
their new watermark values.
The problem with this approach is Skylake has double buffered watermark
registers that are flipped at the same time as the rest of the plane registers.
This means that the original approach will leave planes active with new
attributes but without the required watermark programming that would ensure the
display pipe reads enough data from each plane. As a result, pipes start to
underrun and the user's displays starts to flicker heavily. Usually in response
to plugging in new monitors, or moving cursors from one screen to another
(which triggers a plane and watermark update).
Additionally, issues were found with the original code for configuring ddb,
display data buffer, allocations between display planes on Skylake. On Skylake
all planes have space allocated to them in the ddb, and the hardware requires
that these allocations never overlap at any point in time. Because ddb
allocations were not updated alongside plane attributes despite also being
double buffered registers armed by plane updates, planes were likely to get
stuck momentarily with ddb allocations that overlapped one another. This would
also lead to pipe underruns and display flickering.
The new approach fixes this problem by making sure that on Skylake, attributes
for display planes are always updated at the same time as the watermarks, and
pipes are updated in an order that ensures their ddb allocations don't
overlap at any point between plane updates. This ensures the display pipes are
always programmed correctly, and dramatically reduces the chance of display
flickering.
(note: my e-mail has changed since these patches were upstreamed, and I updated
the e-mails in these patches to reflect this. if this is wrong I will be happy
to update and resend the patches).
Lyude (4):
drm/i915/skl: Update plane watermarks atomically during plane updates
drm/i915: Move CRTC updating in atomic_commit into it's own hook
drm/i915/skl: Update DDB values atomically with wms/plane attrs
drm/i915/skl: Don't try to update plane watermarks if they haven't
changed
Paulo Zanoni (1):
drm/i915/gen9: only add the planes actually affected by ddb changes
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 189 +++++++++++++++++++-----
drivers/gpu/drm/i915/intel_drv.h | 12 ++
drivers/gpu/drm/i915/intel_pm.c | 271 ++++++++++++++---------------------
drivers/gpu/drm/i915/intel_sprite.c | 14 ++
5 files changed, 289 insertions(+), 199 deletions(-)
--
2.7.4
7 years, 1 month
Re: [PATCH 0/5] drm/i915/skl: Backport watermark fixes for 4.8.y
by Hans de Goede
Hi Lyude,
Thanks for doing this, can you also send this set to:
Kernel Fedora <kernel(a)lists.fedoraproject.org>
And ask the kernel team to pick it up ?
Regards,
Hans
On 26-10-16 21:36, Lyude wrote:
> Now that these have finally made it into 4.9, it's time to finally backport
> these fixes. Skylake has been a mess in multi-monitor setups for a while now
> because up until recently we've been updating the watermarks on Skylake just
> like we would for previous generations of Intel GPUs. This means updating
> attributes for each plane, and then only after they've been updated writing
> their new watermark values.
>
> The problem with this approach is Skylake has double buffered watermark
> registers that are flipped at the same time as the rest of the plane registers.
> This means that the original approach will leave planes active with new
> attributes but without the required watermark programming that would ensure the
> display pipe reads enough data from each plane. As a result, pipes start to
> underrun and the user's displays starts to flicker heavily. Usually in response
> to plugging in new monitors, or moving cursors from one screen to another
> (which triggers a plane and watermark update).
>
> Additionally, issues were found with the original code for configuring ddb,
> display data buffer, allocations between display planes on Skylake. On Skylake
> all planes have space allocated to them in the ddb, and the hardware requires
> that these allocations never overlap at any point in time. Because ddb
> allocations were not updated alongside plane attributes despite also being
> double buffered registers armed by plane updates, planes were likely to get
> stuck momentarily with ddb allocations that overlapped one another. This would
> also lead to pipe underruns and display flickering.
>
> The new approach fixes this problem by making sure that on Skylake, attributes
> for display planes are always updated at the same time as the watermarks, and
> pipes are updated in an order that ensures their ddb allocations don't
> overlap at any point between plane updates. This ensures the display pipes are
> always programmed correctly, and dramatically reduces the chance of display
> flickering.
>
> (note: my e-mail has changed since these patches were upstreamed, and I updated
> the e-mails in these patches to reflect this. if this is wrong I will be happy
> to update and resend the patches).
>
> Lyude (4):
> drm/i915/skl: Update plane watermarks atomically during plane updates
> drm/i915: Move CRTC updating in atomic_commit into it's own hook
> drm/i915/skl: Update DDB values atomically with wms/plane attrs
> drm/i915/skl: Don't try to update plane watermarks if they haven't
> changed
>
> Paulo Zanoni (1):
> drm/i915/gen9: only add the planes actually affected by ddb changes
>
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 189 +++++++++++++++++++-----
> drivers/gpu/drm/i915/intel_drv.h | 12 ++
> drivers/gpu/drm/i915/intel_pm.c | 271 ++++++++++++++---------------------
> drivers/gpu/drm/i915/intel_sprite.c | 14 ++
> 5 files changed, 289 insertions(+), 199 deletions(-)
>
7 years, 1 month
Refresh Secure Boot patchset
by Josh Boyer
The upstream 0-day bot found an issue with the existing patchset in the
rawhide kernel. Everything builds fine as a whole, but if one were to
bisect the patches, a build would break because the shim GUID is used
in a patch before it is actually defined.
Fix this by inserting a patch in the series to explicitly define that
and the image security database GUIDs. This posting is a refresh of the
whole series, for completeness.
josh
7 years, 1 month
Supported way to require that a service be stopped prior to
installing an .rpm package?
by Jeff
Hello,
My team is building and maintaining a fairly complex software stack that is being packaged via rpm. As part of the requirements, the service provided by the .rpm file must be stopped prior to installation / update of the package.
Is there any supported / recommended way to do this? Currently the team uses the %pre section to check if the service is running and fail if so, but this seems a bit ugly.
7 years, 1 month
Re: Welcome to the "kernel" mailing list
by Jeff
jhally(a)gmail.com
On Tue, Oct 25, 2016 at 7:23 PM, <kernel-request(a)lists.fedoraproject.org>
wrote:
> Welcome to the "kernel" mailing list!
>
> To post to this list, send your email to:
>
> kernel(a)lists.fedoraproject.org
>
> You can make such adjustments via email by sending a message to:
>
> kernel-request(a)lists.fedoraproject.org
>
> with the word 'help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions. You will
> need your password to change your options, but for security purposes,
> this email is not included here. There is also a button on your
> options page that will send your current password to you.
7 years, 1 month
Kernel configurations for Fedora
by Laura Abbott
The Fedora kernel has had roughly the same system for generating
the kernel configuration for a very long time. There are a series
of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
is not set etc.) that get combined to generate the final config
files. This has gotten unsustainable for several reasons:
- When the system was first introduced, the only supported
arches were x86_32 and x86_64. Fedora now supports enough
other arches that we have a config-$arch-generic in addition to
config-generic
- It's difficult to tell what is actually enabled since
there are several layers of configuration combining (I have to
look at config-generic, then config-$arch-generic, then
the final config-$specific file to see what the option actually
is)
- Keeping the files organized requires manual work and pruning
I've been thinking about alternatives to the existing config
generation. One proposal was to take advantage of the upstream
kernel now supporting config fragments and keep some part of
the fedora configuration upstream. This would have the disadvantage
of requiring the configuration to be kept in sync with upstream.
Another option is to switch to a system of generation where
each configuration option is kept in a separate file. There
is no sorting or organization necessary. This would result
in a lot of small files for all the arches Fedora supports though.
Anyone have experiences with or opinions about the kernel
configuration generation? The goal is to only change the way
the configurations are generated and not the options that are
enabled.
Thanks,
Laura
7 years, 1 month
[kernel-tests] 01/01: Fix path thinko in sysfs-perms error path
by git repository hosting
This is an automated email from the git hooks/post-receive script.
jforbes pushed a commit to branch master
in repository kernel-tests.
commit f8e401a2694e94b6fae424474cad16eae7bbe87d
Author: Justin M. Forbes <jforbes(a)redhat.com>
Date: Fri Oct 21 14:50:06 2016 -0500
Fix path thinko in sysfs-perms error path
---
default/sysfs-perms/runtest.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/default/sysfs-perms/runtest.sh b/default/sysfs-perms/runtest.sh
index 351af76..54c4c28 100755
--- a/default/sysfs-perms/runtest.sh
+++ b/default/sysfs-perms/runtest.sh
@@ -6,7 +6,7 @@ COUNT=$(find /sys -type f -perm 666 | ./ignore-files.sh | wc -l)
if [ "$COUNT" != "0" ]; then
echo Found world-writable files in sysfs.
- find /sys -type f -perm 666 | ignore-files.sh
+ find /sys -type f -perm 666 | ./ignore-files.sh
exit -1
fi
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 1 month
[PATCH] Add Mellanox LEDs support
by Yotam Gigi
This driver enables to control the leds on Mellanox switches.
Signed-off-by: Yotam Gigi <yotamg(a)mellanox.com>
---
config-generic | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config-generic b/config-generic
index 4ef2afd..e9f493d 100644
--- a/config-generic
+++ b/config-generic
@@ -5525,7 +5525,7 @@ CONFIG_LEDS_WM831X_STATUS=m
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_LP55XX_COMMON is not set
# CONFIG_LEDS_PM8058 is not set
-# CONFIG_LEDS_MLXCPLD is not set
+CONFIG_LEDS_MLXCPLD=y
CONFIG_DMADEVICES=y
CONFIG_DMA_ENGINE=y
--
2.4.11
7 years, 1 month
[PATCH] Skip selftest in some Asus laptops
by Marcos Paulo de Souza
This patch was already picked up for 4.9, but it can help a lot of users
in the meantime.
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com>
---
PatchList.txt | 1 +
i8042-skip-selftest-asus-laptops.patch | 373 +++++++++++++++++++++++++++++++++
kernel.spec | 2 +
3 files changed, 376 insertions(+)
create mode 100644 i8042-skip-selftest-asus-laptops.patch
diff --git a/PatchList.txt b/PatchList.txt
index 3a7fd73..3cce44a 100644
--- a/PatchList.txt
+++ b/PatchList.txt
@@ -76,3 +76,4 @@ firmware-Drop-WARN-from-usermodehelper_read_trylock-.patch
drm-i915-turn-off-wc-mmaps.patch
+i8042-skip-selftest-asus-laptops.patch
diff --git a/i8042-skip-selftest-asus-laptops.patch b/i8042-skip-selftest-asus-laptops.patch
new file mode 100644
index 0000000..351556e
--- /dev/null
+++ b/i8042-skip-selftest-asus-laptops.patch
@@ -0,0 +1,373 @@
+From 930e19248e9b61da36c967687ca79c4d5f977919 Mon Sep 17 00:00:00 2001
+From: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com>
+Date: Sat, 1 Oct 2016 12:07:35 -0700
+Subject: Input: i8042 - skip selftest on ASUS laptops
+
+On suspend/resume cycle, selftest is executed to reset i8042 controller.
+But when this is done in Asus devices, subsequent calls to detect/init
+functions to elantech driver fails. Skipping selftest fixes this problem.
+
+An easier step to reproduce this problem is adding i8042.reset=1 as a
+kernel parameter. On Asus laptops, it'll make the system to start with the
+touchpad already stuck, since psmouse_probe forcibly calls the selftest
+function.
+
+This patch was inspired by John Hiesey's change[1], but, since this problem
+affects a lot of models of Asus, let's avoid running selftests on them.
+
+All models affected by this problem:
+A455LD
+K401LB
+K501LB
+K501LX
+R409L
+V502LX
+X302LA
+X450LCP
+X450LD
+X455LAB
+X455LDB
+X455LF
+Z450LA
+
+[1]: https://marc.info/?l=linux-input&m=144312209020616&w=2
+
+Fixes: "ETPS/2 Elantech Touchpad dies after resume from suspend"
+(https://bugzilla.kernel.org/show_bug.cgi?id=107971)
+
+Signed-off-by: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com>
+Cc: stable(a)vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
+---
+ Documentation/kernel-parameters.txt | 9 +++-
+ drivers/input/serio/i8042-io.h | 2 +-
+ drivers/input/serio/i8042-ip22io.h | 2 +-
+ drivers/input/serio/i8042-ppcio.h | 2 +-
+ drivers/input/serio/i8042-sparcio.h | 2 +-
+ drivers/input/serio/i8042-unicore32io.h | 2 +-
+ drivers/input/serio/i8042-x86ia64io.h | 96 +++++++++++++++++++++++++++++++--
+ drivers/input/serio/i8042.c | 55 +++++++++++++++----
+ 8 files changed, 150 insertions(+), 20 deletions(-)
+
+diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
+index 0b3de80..3475b32 100644
+--- a/Documentation/kernel-parameters.txt
++++ b/Documentation/kernel-parameters.txt
+@@ -1409,7 +1409,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
+ i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
+ controllers
+ i8042.notimeout [HW] Ignore timeout condition signalled by controller
+- i8042.reset [HW] Reset the controller during init and cleanup
++ i8042.reset [HW] Reset the controller during init, cleanup and
++ suspend-to-ram transitions, only during s2r
++ transitions, or never reset
++ Format: { 1 | Y | y | 0 | N | n }
++ 1, Y, y: always reset controller
++ 0, N, n: don't ever reset controller
++ Default: only on s2r transitions on x86; most other
++ architectures force reset to be always executed
+ i8042.unlock [HW] Unlock (ignore) the keylock
+ i8042.kbdreset [HW] Reset device connected to KBD port
+
+diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
+index a5eed2a..34da81c 100644
+--- a/drivers/input/serio/i8042-io.h
++++ b/drivers/input/serio/i8042-io.h
+@@ -81,7 +81,7 @@ static inline int i8042_platform_init(void)
+ return -EBUSY;
+ #endif
+
+- i8042_reset = 1;
++ i8042_reset = I8042_RESET_ALWAYS;
+ return 0;
+ }
+
+diff --git a/drivers/input/serio/i8042-ip22io.h b/drivers/input/serio/i8042-ip22io.h
+index ee1ad27..08a1c10 100644
+--- a/drivers/input/serio/i8042-ip22io.h
++++ b/drivers/input/serio/i8042-ip22io.h
+@@ -61,7 +61,7 @@ static inline int i8042_platform_init(void)
+ return -EBUSY;
+ #endif
+
+- i8042_reset = 1;
++ i8042_reset = I8042_RESET_ALWAYS;
+
+ return 0;
+ }
+diff --git a/drivers/input/serio/i8042-ppcio.h b/drivers/input/serio/i8042-ppcio.h
+index f708c75..1aabea4 100644
+--- a/drivers/input/serio/i8042-ppcio.h
++++ b/drivers/input/serio/i8042-ppcio.h
+@@ -44,7 +44,7 @@ static inline void i8042_write_command(int val)
+
+ static inline int i8042_platform_init(void)
+ {
+- i8042_reset = 1;
++ i8042_reset = I8042_RESET_ALWAYS;
+ return 0;
+ }
+
+diff --git a/drivers/input/serio/i8042-sparcio.h b/drivers/input/serio/i8042-sparcio.h
+index afcd1c1..6231d63 100644
+--- a/drivers/input/serio/i8042-sparcio.h
++++ b/drivers/input/serio/i8042-sparcio.h
+@@ -130,7 +130,7 @@ static int __init i8042_platform_init(void)
+ }
+ }
+
+- i8042_reset = 1;
++ i8042_reset = I8042_RESET_ALWAYS;
+
+ return 0;
+ }
+diff --git a/drivers/input/serio/i8042-unicore32io.h b/drivers/input/serio/i8042-unicore32io.h
+index 73f5cc1..4557475 100644
+--- a/drivers/input/serio/i8042-unicore32io.h
++++ b/drivers/input/serio/i8042-unicore32io.h
+@@ -61,7 +61,7 @@ static inline int i8042_platform_init(void)
+ if (!request_mem_region(I8042_REGION_START, I8042_REGION_SIZE, "i8042"))
+ return -EBUSY;
+
+- i8042_reset = 1;
++ i8042_reset = I8042_RESET_ALWAYS;
+ return 0;
+ }
+
+diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
+index 68f5f4a..f4bfb4b 100644
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -510,6 +510,90 @@ static const struct dmi_system_id __initconst i8042_dmi_nomux_table[] = {
+ { }
+ };
+
++/*
++ * On some Asus laptops, just running self tests cause problems.
++ */
++static const struct dmi_system_id i8042_dmi_noselftest_table[] = {
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "A455LD"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "K401LB"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "K501LB"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "K501LX"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "R409L"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "V502LX"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X302LA"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X450LCP"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X450LD"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X455LAB"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X455LDB"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X455LF"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Z450LA"),
++ },
++ },
++ { }
++};
+ static const struct dmi_system_id __initconst i8042_dmi_reset_table[] = {
+ {
+ /* MSI Wind U-100 */
+@@ -1072,12 +1156,18 @@ static int __init i8042_platform_init(void)
+ return retval;
+
+ #if defined(__ia64__)
+- i8042_reset = true;
++ i8042_reset = I8042_RESET_ALWAYS;
+ #endif
+
+ #ifdef CONFIG_X86
+- if (dmi_check_system(i8042_dmi_reset_table))
+- i8042_reset = true;
++ /* Honor module parameter when value is not default */
++ if (i8042_reset == I8042_RESET_DEFAULT) {
++ if (dmi_check_system(i8042_dmi_reset_table))
++ i8042_reset = I8042_RESET_ALWAYS;
++
++ if (dmi_check_system(i8042_dmi_noselftest_table))
++ i8042_reset = I8042_RESET_NEVER;
++ }
+
+ if (dmi_check_system(i8042_dmi_noloop_table))
+ i8042_noloop = true;
+diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
+index b4d3408..674a760 100644
+--- a/drivers/input/serio/i8042.c
++++ b/drivers/input/serio/i8042.c
+@@ -48,9 +48,39 @@ static bool i8042_unlock;
+ module_param_named(unlock, i8042_unlock, bool, 0);
+ MODULE_PARM_DESC(unlock, "Ignore keyboard lock.");
+
+-static bool i8042_reset;
+-module_param_named(reset, i8042_reset, bool, 0);
+-MODULE_PARM_DESC(reset, "Reset controller during init and cleanup.");
++enum i8042_controller_reset_mode {
++ I8042_RESET_NEVER,
++ I8042_RESET_ALWAYS,
++ I8042_RESET_ON_S2RAM,
++#define I8042_RESET_DEFAULT I8042_RESET_ON_S2RAM
++};
++static enum i8042_controller_reset_mode i8042_reset = I8042_RESET_DEFAULT;
++static int i8042_set_reset(const char *val, const struct kernel_param *kp)
++{
++ enum i8042_controller_reset_mode *arg = kp->arg;
++ int error;
++ bool reset;
++
++ if (val) {
++ error = kstrtobool(val, &reset);
++ if (error)
++ return error;
++ } else {
++ reset = true;
++ }
++
++ *arg = reset ? I8042_RESET_ALWAYS : I8042_RESET_NEVER;
++ return 0;
++}
++
++static const struct kernel_param_ops param_ops_reset_param = {
++ .flags = KERNEL_PARAM_OPS_FL_NOARG,
++ .set = i8042_set_reset,
++};
++#define param_check_reset_param(name, p) \
++ __param_check(name, p, enum i8042_controller_reset_mode)
++module_param_named(reset, i8042_reset, reset_param, 0);
++MODULE_PARM_DESC(reset, "Reset controller on resume, cleanup or both");
+
+ static bool i8042_direct;
+ module_param_named(direct, i8042_direct, bool, 0);
+@@ -1019,7 +1049,7 @@ static int i8042_controller_init(void)
+ * Reset the controller and reset CRT to the original value set by BIOS.
+ */
+
+-static void i8042_controller_reset(bool force_reset)
++static void i8042_controller_reset(bool s2r_wants_reset)
+ {
+ i8042_flush();
+
+@@ -1044,8 +1074,10 @@ static void i8042_controller_reset(bool force_reset)
+ * Reset the controller if requested.
+ */
+
+- if (i8042_reset || force_reset)
++ if (i8042_reset == I8042_RESET_ALWAYS ||
++ (i8042_reset == I8042_RESET_ON_S2RAM && s2r_wants_reset)) {
+ i8042_controller_selftest();
++ }
+
+ /*
+ * Restore the original control register setting.
+@@ -1110,7 +1142,7 @@ static void i8042_dritek_enable(void)
+ * before suspending.
+ */
+
+-static int i8042_controller_resume(bool force_reset)
++static int i8042_controller_resume(bool s2r_wants_reset)
+ {
+ int error;
+
+@@ -1118,7 +1150,8 @@ static int i8042_controller_resume(bool force_reset)
+ if (error)
+ return error;
+
+- if (i8042_reset || force_reset) {
++ if (i8042_reset == I8042_RESET_ALWAYS ||
++ (i8042_reset == I8042_RESET_ON_S2RAM && s2r_wants_reset)) {
+ error = i8042_controller_selftest();
+ if (error)
+ return error;
+@@ -1195,7 +1228,7 @@ static int i8042_pm_resume_noirq(struct device *dev)
+
+ static int i8042_pm_resume(struct device *dev)
+ {
+- bool force_reset;
++ bool want_reset;
+ int i;
+
+ for (i = 0; i < I8042_NUM_PORTS; i++) {
+@@ -1218,9 +1251,9 @@ static int i8042_pm_resume(struct device *dev)
+ * off control to the platform firmware, otherwise we can simply restore
+ * the mode.
+ */
+- force_reset = pm_resume_via_firmware();
++ want_reset = pm_resume_via_firmware();
+
+- return i8042_controller_resume(force_reset);
++ return i8042_controller_resume(want_reset);
+ }
+
+ static int i8042_pm_thaw(struct device *dev)
+@@ -1481,7 +1514,7 @@ static int __init i8042_probe(struct platform_device *dev)
+
+ i8042_platform_device = dev;
+
+- if (i8042_reset) {
++ if (i8042_reset == I8042_RESET_ALWAYS) {
+ error = i8042_controller_selftest();
+ if (error)
+ return error;
+--
+cgit v0.12
+
diff --git a/kernel.spec b/kernel.spec
index b54e34f..00ffcd9 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -593,6 +593,8 @@ Patch502: firmware-Drop-WARN-from-usermodehelper_read_trylock-.patch
# Patch503: drm-i915-turn-off-wc-mmaps.patch
+Patch504: i8042-skip-selftest-asus-laptops.patch
+
Patch508: kexec-uefi-copy-secure_boot-flag-in-boot-params.patch
#CVE-2016-3134 rhbz 1317383 1317384
--
2.7.4
7 years, 1 month