kernel October 2016

kernel@lists.fedoraproject.org

18 participants
13 discussions

[PATCH] arm64: Enable 48bit VA
by Jeremy Linton 31 Oct '16

31 Oct '16

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

3 2

[PATCH 0/5] drm/i915/skl: Backport watermark fixes for 4.8.y
by Lyude 28 Oct '16

28 Oct '16

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

3 7

Re: [PATCH 0/5] drm/i915/skl: Backport watermark fixes for 4.8.y
by Hans de Goede 27 Oct '16

27 Oct '16

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(-) >

1 0

Refresh Secure Boot patchset
by Josh Boyer 26 Oct '16

26 Oct '16

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

2 21

Supported way to require that a service be stopped prior to installing an .rpm package?
by Jeff 25 Oct '16

25 Oct '16

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.

2 2

Re: Welcome to the "kernel" mailing list
by Jeff 25 Oct '16

25 Oct '16

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.

1 0

Kernel configurations for Fedora
by Laura Abbott 25 Oct '16

25 Oct '16

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

5 8

[kernel-tests] 01/01: Fix path thinko in sysfs-perms error path
by git repository hosting 21 Oct '16

21 Oct '16

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.

1 0

[PATCH] Add Mellanox LEDs support
by Yotam Gigi 19 Oct '16

19 Oct '16

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

2 2

[PATCH] Skip selftest in some Asus laptops
by Marcos Paulo de Souza 18 Oct '16

18 Oct '16

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

2 1

[PATCH] Don't list /lib/modules/$KernelVer/kernel twice
by Paul Bolle 13 Oct '16

13 Oct '16

For quite some time I see warnings like warning: File listed twice: /lib/modules/[...]/kernel when building the kernel-core rpm. This is because that directory is included both in module-dirs.list (and therefor in, basically, kernel-core.list) and in kernel_variant_files(). Tweak the find command that generates module-dirs.list so that this directory is not included in that list anymore. Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- Works as expected on my current local F24 based tree (that branched of at release 4.6.5-300). Applies cleanly to current master. But I have not tested this on that branch. kernel.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel.spec b/kernel.spec index 1b7040b503e9..8d3f630b310b 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1644,7 +1644,7 @@ BuildKernel() { # Go back and find all of the various directories in the tree. We use this # for the dir lists in kernel-core - find lib/modules/$KernelVer/kernel -type d | sort -n > module-dirs.list + find lib/modules/$KernelVer/kernel -mindepth 1 -type d | sort -n > module-dirs.list # Cleanup rm System.map -- 2.7.4

2 1

realtek wireless modules
by Peter Robinson 10 Oct '16

10 Oct '16

Hi Laura, Justin, et el, I've been playing with a handful of cheap USB wireless modules for support on the Raspberry Pi and other similar devices. I've noticed that there's a bunch of overlap regarding usb IDs between the newer (and IMO preferred) rtl8xxxu and the vendor collection of drivers so you often get both drivers loaded. I've tended to fix this by just blacklisting the vendor upstream drivers. The question is how best to deal with this in a generic way to ensure a good experience with these in Fedora? Do we cross reference all the USB IDs and disable the non rtl8xxxu drivers once they have full coverage in rtl8xxxu? Do we actively patch out the IDs supported in rtl8xxxu from associated drivers? Peter

4 4

4.8, stabilization, and F25
by Justin Forbes 07 Oct '16

07 Oct '16

We have been using the stabilization branch and copr lately to keep the stream going on a stable kernel release before we rebase a Fedora release with it. We will not be doing that with 4.8 as it is already being maintained in F25. For those wishing to run it early on F24, the F25 builds should work just fine. The 4.8.1 build is running now and will be submitted to bodhi for F25 as soon as it finishes and goes through some testing. For Fedora 24 and 23, they will be rebased to 4.8.x probably around mid month, depending on how things are looking with respect to regressions and bugs fixed. Thanks, Justin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel October 2016