- 03 Dec, 2019 40 commits
-
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 1. Out of the fields {per_napi_bytes, per_napi_packets} in struct ena_ring, only rx_ring->per_napi_packets are used to determine if napi did work for dim. This commit removes all other uses of these fields. 2. Remove ena_ring->moder_tbl_idx, which is not used by dim. 3. Remove all calls to ena_com_destroy_interrupt_moderation(), since all it did was to destroy the interrupt moderation table, which is removed as part of removing old interrupt moderation code. Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 242d81fd) Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Khaled Elmously <khalid.elmously@canonical.com> Acked-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Remove code duplication in: ena_com_update_nonadaptive_moderation_interval_tx() ena_com_update_nonadaptive_moderation_interval_rx() functions. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Add driver_supported_features to host_host info which is a new API used to communicate to the device which features are supported by the driver. Add the interrupt_moderation bit to host_info->driver_supported_features and enable it to signal the device that this driver supports interrupt moderation properly. Reserved bits are for features implemented in the future Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 1. Remove old adaptive interrupt moderation code from set/get_coalesce() 2. Add ena_update_rx_rings_intr_moderation() function for updating nonadaptive interrupt moderation intervals similarly to ena_update_tx_rings_intr_moderation(). 3. Remove checks of multiple unsupported received interrupt coalescing parameters. This makes code cleaner and cancels the need to update it every time a new coalescing parameter is invented. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Use the dim library for the rx adaptive interrupt moderation implementation Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Add intr_moder_rx_interval to struct ena_com_dev and use it as the location where the interrupt moderation rx interval is saved, instead of the interrupt moderation table. This is done as a first step before removing the old interrupt moderation code. Signed-off-by:
-
Netanel Belgazal authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Fixing a bug that the driver does not unmask the IO interrupts in ndo_open(): occasionally, the MSI-X interrupt (for one or more IO queues) can be masked when ndo_close() was called. If that is followed by ndo open(), then the MSI-X will be still masked so no interrupt will be received by the driver. Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1852637 Use dimlib.o (vs. dim.o) as the interim library object filename to avoid a clash with the actual dim.c which manifests as: make[2]: Circular lib/dim/dim.o <- lib/dim/dim.o dependency dropped. Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1852637 Import DIMLIB (lib/dim/) from mainline v5.3 as of commit f8be17b8 ("lib/dim: Fix -Wunused-const-variable warnings"). Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1852637Signed-off-by:
-
Masahiro Yamada authored
BugLink: https://bugs.launchpad.net/bugs/1852637 This macro is useful to avoid link error on 32-bit systems. We have the same definition in two drivers, so move it to include/linux/kernel.h While we are here, refactor DIV_ROUND_UP_ULL() by using DIV_ROUND_DOWN_ULL(). Link: http://lkml.kernel.org/r/1500945156-12907-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Mark Brown <broonie@kernel.org> Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (backported from commit 604df322) Signed-off-by:
-
Chris Wilson authored
BugLink: https://bugs.launchpad.net/bugs/1852637 net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the macro to bitops.h, alongside BITS_PER_BYTE, for wider usage. Link: http://lkml.kernel.org/r/20180706094458.14116-1-chris@chris-wilson.co.ukSigned-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Andy Gospodarek <gospo@broadcom.com> Cc: David S. Miller <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1851623 Although we may have multiple fonts in kernel, the small 8x16 font is chosen as default usually unless user specify the boot option. This is suboptimal for monitors with high resolutions. This patch tries to assign a bigger font for such a high resolution by calculating some penalty value. This won't change anything for a standard monitor like Full HD (1920x1080), but for a high res monitor like UHD 4K, a bigger font like TER16x32 will be chosen once when enabled in Kconfig. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit dfd19a50) Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1851623 Fix indentation, spaces, and move EXPORT_SYMBOL line to the appropriate place as a preliminary work. No actual code change. Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1853881 Ignore: yes Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1853881Signed-off-by:
-
Pavel Tatashin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 94bb804e upstream. A number of our uaccess routines ('__arch_clear_user()' and '__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they encounter an unhandled fault whilst accessing userspace. For CPUs implementing both hardware PAN and UAO, this bug has no effect when both extensions are in use by the kernel. For CPUs implementing hardware PAN but not UAO, this means that a kernel using hardware PAN may execute portions of code with PAN inadvertently disabled, opening us up to potential security vulnerabilities that rely on userspace access from within the kernel which would usually be prevented by this mechanism. In other words, parts of the kernel run the same way as they would on a CPU without PAN implemented/emulated at all. For CPUs not implementing hardware PAN and instead relying on software emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately much worse. Calling 'schedule()' with software PAN disabled means that the next task will execute in the kernel using the page-table and ASID of the previous process even after 'switch_mm()', since the actual hardware switch is deferred until return to userspace. At this point, or if there is a intermediate call to 'uaccess_enable()', the page-table and ASID of the new process are installed. Sadly, due to the changes introduced by KPTI, this is not an atomic operation and there is a very small window (two instructions) where the CPU is configured with the page-table of the old task and the ASID of the new task; a speculative access in this state is disastrous because it would corrupt the TLB entries for the new task with mappings from the previous address space. As Pavel explains: | I was able to reproduce memory corruption problem on Broadcom's SoC | ARMv8-A like this: | | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's | stack is accessed and copied. | | The test program performed the following on every CPU and forking | many processes: | | unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE, | MAP_SHARED | MAP_ANONYMOUS, -1, 0); | map[0] = getpid(); | sched_yield(); | if (map[0] != getpid()) { | fprintf(stderr, "Corruption detected!"); | } | munmap(map, PAGE_SIZE); | | From time to time I was getting map[0] to contain pid for a | different process. Ensure that PAN is re-enabled when returning after an unhandled user fault from our uaccess routines. Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Tested-by:
Pavel Tatashin <pasha.tatashin@soleen.com> [will: rewrote commit message] [will: backport for 4.4.y stable kernels] Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Huibin Hong authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit dd8fd2cb ] The rxconf and txconf structs are allocated on the stack, so make sure we zero them before filling out the relevant fields. Signed-off-by:
Huibin Hong <huibin.hong@rock-chips.com> Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 80df9be6 ] Fixes a harmless underflow issue when CCK rates are actively being used Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Thierry Reding authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 9f67f758 ] Probe deferrals aren't actual errors, so silence the error message in case the PWM cannot yet be acquired. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Timothy E Baldwin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit f18aef74 ] On at least x86 and ARM64, and as documented in the ptrace man page a skipped system call will still cause a syscall exit ptrace stop. Previous to this commit 32-bit ARM did not, resulting in strace being confused when seccomp skips system calls. This change also impacts programs that use ptrace to skip system calls. Fixes: ad75b514 ("ARM: 7579/1: arch/allow a scno of -1 to not cause a SIGILL") Signed-off-by:
Timothy E Baldwin <T.E.Baldwin99@members.leeds.ac.uk> Signed-off-by:
Eugene Syromyatnikov <evgsyr@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Trent Piepho authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 605b3bec ] spidev will make a big fuss if a device tree node binds a device by using "spidev" as the node's compatible property. However, the logic for this isn't looking for "spidev" in the compatible, but rather checking that the device is NOT compatible with spidev's list of devices. This causes a false positive if a device not named "rohm,dh2228fv", etc. binds to spidev, even if a means other than putting "spidev" in the device tree was used. E.g., the sysfs driver_override attribute. Signed-off-by:
Trent Piepho <tpiepho@impinj.com> Reviewed-by:
Jan Kundrát <jan.kundrat@cesnet.cz> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 70728c29 ] The priv->data->set can be NULL while flags contains GPIO_SYSCON_FEAT_OUT and chip->set is valid pointer. This happens in case the controller uses the default GPIO setter. Always use chip->set to access the setter to avoid possible NULL pointer dereferencing. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 51fbf14f ] The only use of KEXEC_BACKUP_SRC_END is as an argument to walk_system_ram_res(): int crash_load_segments(struct kimage *image) { ... walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END, image, determine_backup_region); walk_system_ram_res() expects "start, end" arguments that are inclusive, i.e., the range to be walked includes both the start and end addresses. KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the first address *past* the desired 0-640KB range. Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC region is [0-0x9ffff], not [0-0xa0000]. Fixes: dd5f7260 ("kexec: support for kexec on panic using new system call") Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Borislav Petkov <bp@suse.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Brijesh Singh <brijesh.singh@amd.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Ingo Molnar <mingo@redhat.com> CC: Lianbo Jiang <lijiang@redhat.com> CC: Takashi Iwai <tiwai@suse.de> CC: Thomas Gleixner <tglx@linutronix.de> CC: Tom Lendacky <thomas.lendacky@amd.com> CC: Vivek Goyal <vgoyal@redhat.com> CC: baiyaowei@cmss.chinamobile.com CC: bhe@redhat.com CC: dan.j.williams@intel.com CC: dyoung@redhat.com CC: kexec@lists.infradead.org Link: http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.stgit@bhelgaas-glaptop.roam.corp.google.comSigned-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 32ae5920 ] Shifting the u8 value[3] by an int can lead to sign-extension overflow. For example, if value[3] is 0xff and the shift is 24 then it is promoted to int and then the top bit is sign-extended so that all upper 32 bits are set. Fix this by casting value[3] to a u32 before the shift. Detected by CoverityScan, CID#1016522 ("Unintended sign extension") Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Tim Smith authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 1eb8d738 ] Flushing the workqueue can cause operations to happen which might call gfs2_log_reserve(), or get stuck waiting for locks taken by such operations. gfs2_log_reserve() can io_schedule(). If this happens, it will never wake because the only thing which can wake it is gfs2_logd() which was already stopped. This causes umount of a gfs2 filesystem to wedge permanently if, for example, the umount immediately follows a large delete operation. When this occured, the following stack trace was obtained from the umount command [<ffffffff81087968>] flush_workqueue+0x1c8/0x520 [<ffffffffa0666e29>] gfs2_make_fs_ro+0x69/0x160 [gfs2] [<ffffffffa0667279>] gfs2_put_super+0xa9/0x1c0 [gfs2] [<ffffffff811b7edf>] generic_shutdown_super+0x6f/0x100 [<ffffffff811b7ff7>] kill_block_super+0x27/0x70 [<ffffffffa0656a71>] gfs2_kill_sb+0x71/0x80 [gfs2] [<ffffffff811b792b>] deactivate_locked_super+0x3b/0x70 [<ffffffff811b79b9>] deactivate_super+0x59/0x60 [<ffffffff811d2998>] cleanup_mnt+0x58/0x80 [<ffffffff811d2a12>] __cleanup_mnt+0x12/0x20 [<ffffffff8108c87d>] task_work_run+0x7d/0xa0 [<ffffffff8106d7d9>] exit_to_usermode_loop+0x73/0x98 [<ffffffff81003961>] syscall_return_slowpath+0x41/0x50 [<ffffffff815a594c>] int_ret_from_sys_call+0x25/0x8f [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:
Tim Smith <tim.smith@citrix.com> Signed-off-by:
Mark Syms <mark.syms@citrix.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Wenwen Wang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit a26ac6c1 ] In isif_probe(), there is a while loop to get the ISIF base address and linearization table0 and table1 address. In the loop body, the function platform_get_resource() is called to get the resource. If platform_get_resource() returns NULL, the loop is terminated and the execution goes to 'fail_nobase_res'. Suppose the loop is terminated at the first iteration because platform_get_resource() returns NULL and the execution goes to 'fail_nobase_res'. Given that there is another while loop at 'fail_nobase_res' and i equals to 0, one iteration of the second while loop will be executed. However, the second while loop does not check the return value of platform_get_resource(). This can cause a NULL pointer dereference bug if the return value is a NULL pointer. This patch avoids the above issue by adding a check in the second while loop after the call to platform_get_resource(). Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Signed-off-by:
-
He Zhe authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit e6fe3e5b ] The current printk() is ready to handle log buffer size up to 2G. Give an explicit error for users who want to use larger log buffer. Also fix printk formatting to show the 2G as a positive number. Link: http://lkml.kernel.org/r/20181008135916.gg4kkmoki5bgtco5@pathway.suse.cz Cc: rostedt@goodmis.org Cc: linux-kernel@vger.kernel.org Suggested-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
He Zhe <zhe.he@windriver.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 7cea645a ] Clang warns that the address of a pointer will always evaluated as true in a boolean context. drivers/video/backlight/lm3639_bl.c:403:14: warning: address of 'pchip->cdev_torch' will always evaluate to 'true' [-Wpointer-bool-conversion] if (&pchip->cdev_torch) ~~ ~~~~~~~^~~~~~~~~~ drivers/video/backlight/lm3639_bl.c:405:14: warning: address of 'pchip->cdev_flash' will always evaluate to 'true' [-Wpointer-bool-conversion] if (&pchip->cdev_flash) ~~ ~~~~~~~^~~~~~~~~~ 2 warnings generated. These statements have been present since 2012, introduced by commit 0f59858d ("backlight: add new lm3639 backlight driver"). Given that they have been called unconditionally since then presumably without any issues, removing the always true if statements to fix the warnings without any real world changes. Link: https://github.com/ClangBuiltLinux/linux/issues/119Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Borislav Petkov authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit cf089611 ] Lianbo reported a build error with a particular 32-bit config, see Link below for details. Provide a weak copy_oldmem_page_encrypted() function which architectures can override, in the same manner other functionality in that file is supplied. Reported-by:
Lianbo Jiang <lijiang@redhat.com> Signed-off-by:
-
Shenghui Wang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 46010141 ] Recal cached_dev_sectors on cached_dev detached, as recal done on cached_dev attached. Update the cached_dev_sectors before bcache_device_detach called as bcache_device_detach will set bcache_device->c to NULL. Signed-off-by:
Shenghui Wang <shhuiw@foxmail.com> Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit e5017716 ] The "index + count" addition can overflow. Both come directly from the user. This bug leads to an information leak. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Peter Malone <peter.malone@gmail.com> Cc: Philippe Ombredanne <pombredanne@nexb.com> Cc: Mathieu Malaterre <malat@debian.org> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit d8bad911 ] I'm not sure why the code assumes that only the first put_user() needs an access_ok() check. I have made all the put_user() and get_user() calls checked. Signed-off-by:
-
Ronald Tschalär authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 757c968c ] There was a small race when removing the sbshc module where smbus_alarm() had queued acpi_smbus_callback() for deferred execution but it hadn't been run yet, so that when it did run hc had been freed and the module unloaded, resulting in an invalid paging request. A similar race existed when removing the sbs module with regards to acpi_sbs_callback() (which is called from acpi_smbus_callback()). We therefore need to ensure no callbacks are pending or executing before the cleanups are done and the modules are removed. Signed-off-by:
Ronald Tschalär <ronald@innovation.ch> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Radu Solea authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit fadd7a6e ] The DCP driver does not obey cryptlen, when doing android CTS this results in passing to hardware input stream lengths which are not multiple of block size. Add a check to prevent future erroneous stream lengths from reaching the hardware and adjust the scatterlist walking code to obey cryptlen. Also properly copy-out the IV for chaining. Signed-off-by:
Radu Solea <radu.solea@nxp.com> Signed-off-by:
Franck LENORMAND <franck.lenormand@nxp.com> Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Radu Solea authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit c709eeba ] DCP writes at least 32 bytes in the output buffer instead of hash length as documented. Add intermediate buffer to prevent write out of bounds. When requested to produce null hashes DCP fails to produce valid output. Add software workaround to bypass hardware and return valid output. Signed-off-by:
-
Borislav Petkov authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit fa112cf1 ] When building a 32-bit config which has the above MFD item as module but OLPC_XO1_PM is enabled =y - which is bool, btw - the kernel fails building with: ld: arch/x86/platform/olpc/olpc-xo1-pm.o: in function `xo1_pm_remove': /home/boris/kernel/linux/arch/x86/platform/olpc/olpc-xo1-pm.c:159: undefined reference to `mfd_cell_disable' ld: arch/x86/platform/olpc/olpc-xo1-pm.o: in function `xo1_pm_probe': /home/boris/kernel/linux/arch/x86/platform/olpc/olpc-xo1-pm.c:133: undefined reference to `mfd_cell_enable' make: *** [Makefile:1030: vmlinux] Error 1 Force MFD_CS5535 to y if OLPC_XO1_PM is enabled. Signed-off-by:
-
Martin Kepplinger authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 20bbb312 ] This is how userspace checks for touchscreen devices most reliably. Signed-off-by:
Martin Kepplinger <martink@posteo.de> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Rami Rosen authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit f4d34aa8 ] Signed-off-by:
Rami Rosen <ramirose@gmail.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Olga Kornievskaia authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 44f411c3 ] Running "./nfstest_delegation --runtest recall26" uncovers that client doesn't recover the lock when we have an appending open, where the initial open got a write delegation. Instead of checking for the passed in open context against the file lock's open context. Check that the state is the same. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
