- 24 Mar, 2020 12 commits
-
-
Hans de Goede authored
On some ACPI/x86 devices (where we use one of the ACPI IRQ pin access methods) the firmware is buggy, it does not properly reset the controller at boot, and we cannot communicate with it. Normally on ACPI/x86 devices we do not want to reset the controller at probe time since in some cases this causes the controller to loose its configuration and this is loaded into it by the system's firmware. So on these systems we leave the reset_controller_at_probe flag unset, even though we have a access to both the IRQ and reset pins and thus could reset it. In the case of the buggy firmware we have to reset the controller to actually be able to talk to it. This commit adds a special case for this, if the goodix_i2c_test() fails, and we have not reset the controller yet; and we do have a way to reset the controller then retry the i2c-test after resetting the controller. This fixes the driver failing at probe on ACPI/x86 systems with this firmware bug. Reported-and-tested-by:
Dmitry Mastykin <dmastykin@astralinux.ru> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200311191013.10826-2-hdegoede@redhat.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Hans de Goede authored
Some devices, e.g the Trekstor Primetab S11B, lose there config over a suspend/resume cycle (likely the controller loses power during suspend). This commit reads back the config version on resume and if matches the expected config version it resets the controller and resends the config we read back and saved at probe time. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
Bastien Nocera <hadess@hadess.net> Signed-off-by:
-
Hans de Goede authored
Make goodix_send_cfg() take a raw buffer as argument instead of a struct firmware *cfg, so that it can also be used to restore the config on resume if necessary. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Our goodix_check_cfg_* helpers do things like: int i, raw_cfg_len = cfg->size - 2; ... if (check_sum != cfg->data[raw_cfg_len]) { When cfg->size < 2, this will end up indexing the cfg->data array with a negative value, which will not end well. To fix this this commit adds a new GOODIX_CONFIG_MIN_LENGTH define and adds a minimum size check for firmware-config files using this new define. For consistency this commit also adds a new GOODIX_CONFIG_GT9X_LENGTH for the length used for recent gt9xx and gt1xxx chips, instead of using GOODIX_CONFIG_MAX_LENGTH for this, so that if other length defines get added in the future it will be clear that the MIN and MAX defines should contain the min and max values of all the other defines. Signed-off-by: -
Hans de Goede authored
Save a copy of the config in goodix_read_config(), this is a preparation patch for restoring the config if it was lost after a supend/resume cycle. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Move the defines to above the struct goodix_ts_data declaration, so that the MAX defines can be used inside the struct goodix_ts_data declaration. No functional changes, just moving a block of code. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Some Apollo Lake (x86, UEFI + ACPI) devices only list the reset GPIO in their _CRS table and the bit-banging of the IRQ line necessary to wake-up the controller from suspend can be done by calling 2 Goodix custom / specific ACPI methods. This commit adds support for controlling the IRQ line in this matter, allowing us to properly suspend the touchscreen controller on such devices. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
On most Bay Trail (x86, UEFI + ACPI) devices the ACPI tables do not have a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding "irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name without first manually adding mappings ourselves. These devices contain 2 GpioIo resource in their _CRS table, on all 4 such devices which I have access to, the order of the 2 GPIOs is reset, int. Note that the GPIO to which the touchscreen controller irq pin is connected is configured in direct-irq mode on these Bay Trail devices, the pinctrl-baytrail.c driver still allows controlling the pin as a GPIO in this case, but this is not necessarily the case on other X86 ACPI platforms, nor do we have a guarantee that the GPIO order is the same elsewhere, so we limit the use of a _CRS table with 2 GpioIo resources to Bay Trail devices only. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
On most Cherry Trail (x86, UEFI + ACPI) devices the ACPI tables do not have a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding "irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name without first manually adding mappings ourselves. These devices contain 1 GpioInt and 1 GpioIo resource in their _CRS table: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.PCI0.I2C2", 0x00, ResourceConsumer, , Exclusive, ) GpioInt (Edge, ActiveLow, Shared, PullDefault, 0x0000, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0013 } GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0019 } }) Return (RBUF) /* \_SB_.PCI0.I2C2.TCS1._CRS.RBUF */ } There is no fixed order for these 2. This commit adds code to check that there is 1 of each as expected and then registers a mapping matching their order using devm_acpi_dev_add_driver_gpios(). This gives us access to both GPIOs allowing us to properly suspend the controller during suspend, and making it possible to reset the controller if necessary. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Signed-off-by: -
Hans de Goede authored
Before this commit we would always reset the controller at probe when we have access to the GPIOs which are necessary to do a reset. Doing the reset requires access to the GPIOs, but just because we have access to the GPIOs does not mean that we should always reset the controller at probe. On X86 ACPI platforms the BIOS / UEFI firmware will already have reset the controller and it will have loaded the device specific config into the controller. Doing the reset sometimes causes the controller to lose its configuration, so on X86 ACPI platforms this is not a good idea. This commit adds a new reset_controller_at_probe boolean to control the reset at probe behavior. This commits sets the new bool to true when we set irq_pin_access_method to IRQ_PIN_ACCESS_GPIO, so there are no functional changes. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
At least on X86 ACPI platforms it is not necessary to load the touchscreen controller config from disk, if it needs to be loaded this has already been done by the BIOS / UEFI firmware. Even on other (e.g. devicetree) platforms the config-loading as currently done has the issue that the loaded cfg file is based on the controller model, but the actual cfg is device specific, so the cfg files are not part of linux-firmware and this can only work with a device specific OS image which includes the cfg file. And we do not need access to the GPIOs at all to load the config, if we do not have access we can still load the config. So all in all tying the decision to try to load the config from disk to being able to access the GPIOs is not desirable. This commit adds a new load_cfg_from_disk boolean to control the firmware loading instead. This commits sets the new bool to true when we set irq_pin_access_method to IRQ_PIN_ACCESS_GPIO, so there are no functional changes. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by:
-
Hans de Goede authored
Suspending Goodix touchscreens requires changing the interrupt pin to output before sending them a power-down command. Followed by wiggling the interrupt pin to wake the device up, after which it is put back in input mode. So far we have only effectively supported this on devices which use devicetree. On X86 ACPI platforms both looking up the pins; and using a pin as both IRQ and GPIO is a bit more complicated. E.g. on some devices we cannot directly access the IRQ pin as GPIO and we need to call ACPI methods to control it instead. This commit adds a new irq_pin_access_method field to the goodix_chip_data struct and adds goodix_irq_direction_output and goodix_irq_direction_input helpers which together abstract the GPIO accesses to the IRQ pin. This is a preparation patch for adding support for properly suspending the touchscreen on X86 ACPI platforms. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317 BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Signed-off-by:
-
- 06 Mar, 2020 2 commits
-
-
Johnny Chuang authored
This patch supports reporting resolution for ABS_MT_TOUCH_MAJOR event. This information is needed in showing pressure/width radius. Signed-off-by:
Johnny Chuang <johnny.chuang@emc.com.tw> Reviewed-by:
Harry Cutts <hcutts@chromium.org> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/1582766000-23023-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by:
-
Sergei A. Trusov authored
The touchscreen on the Cube I15-TC don't match the default display, with 0,0 touches being reported when touching at the top-right of the screen. Add a quirk to invert the x coordinate. Reported-and-tested-by:
Arkadiy <arkan49@yandex.ru> Signed-off-by:
Sergei A. Trusov <sergei.a.trusov@ya.ru> Reviewed-by:
-
- 01 Feb, 2020 1 commit
-
-
Lucas Stach authored
When the distance thresholds are set the controller must be in reduced reporting mode for them to have any effect on the interrupt generation. This has a potentially large impact on the number of events the host needs to process. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Andrew Duggan <aduggan@synaptics.com> Link: https://lore.kernel.org/r/20200120111628.18376-1-l.stach@pengutronix.deSigned-off-by:
-
- 27 Jan, 2020 2 commits
-
-
Benjamin Gaignard authored
Convert the Goodix binding to DT schema format using json-schema Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200108091118.5130-3-benjamin.gaignard@st.comSigned-off-by:
-
Benjamin Gaignard authored
Add touchscreen schema for common properties Signed-off-by:
-
- 22 Jan, 2020 3 commits
-
-
Thomas Bogendoerfer authored
This patch adds a platform driver for supporting keyboard and mouse interface of SGI IOC3 chips. Signed-off-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Link: https://lore.kernel.org/r/20200122135220.22354-1-tbogendoerfer@suse.deSigned-off-by:
-
Samuel Holland authored
There are many devices, including several mobile battery-powered devices, using other AXP variants as their PMIC. Allow them to use the power key as a wakeup source. Reviewed-by:
Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20200115051253.32603-3-samuel@sholland.orgSigned-off-by:
-
Samuel Holland authored
Unlike most other power button drivers, this driver unconditionally enables its wakeup IRQ. It should be using device_may_wakeup() to respect the userspace configuration of wakeup sources. Because the AXP20x MFD device uses regmap-irq, the AXP20x PEK IRQs are nested off of regmap-irq's threaded interrupt handler. The device core ignores such interrupts, so to actually disable wakeup, we must explicitly disable all non-wakeup interrupts during suspend. Signed-off-by:
-
- 21 Jan, 2020 1 commit
-
-
Alexandru Ardelean authored
In a recent change to the SPI subsystem [1], a new `delay` struct was added to replace the `delay_usecs`. This change replaces the current `delay_usecs` with `delay` for this driver. The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure that both `delay_usecs` & `delay` are used (in this order to preserve backwards compatibility). [1] commit bebcfd27 ("spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()") Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20191210141103.15910-1-alexandru.ardelean@analog.comSigned-off-by:
-
- 10 Jan, 2020 6 commits
-
-
Dmitry Torokhov authored
Sync up with mainline to get SPI "delay" API changes.
-
Marco Felsch authored
We do not have to handle the wake-irq within the driver because the pm core can handle this for us. The only use case for the suspend/resume callbacks was to handle the wake-irq so we can remove the callbacks. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Marco Felsch authored
Since day one the touch controller acts as wakeup-source. This seems to be wrong since the device supports deep-sleep mechanism [1] which requires a reset to leave it. Also some designs won't use the touchscreen as wakeup-source. According discussion [2] we decided to break backward compatibility and go the common way by using the 'wakeup-source' device-property. [1] https://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x26.pdf [2] https://patchwork.kernel.org/patch/11149037/Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Marco Felsch authored
The current driver behaviour was to enable the wakeup-source everytime. After discussion [1] we decided to change that behaviour so the device will act as wakeup-source only if the "wakeup-source" dt-property is present. The patch adds the binding documentation to enable the wakeup-source capability. [1] https://patchwork.kernel.org/patch/11149037/Signed-off-by:
-
Marco Felsch authored
It seems that the include order is historical increased and no one takes care of it. Fix this to align it with the common rule to be in a alphabetical order. Signed-off-by:
-
Philipp Zabel authored
The EP0700MLP1 returns bogus data on the first register read access (reading the threshold parameter from register 0x00): edt_ft5x06 2-0038: crc error: 0xfc expected, got 0x40 It ignores writes until then. This patch adds a dummy read after which the number of sensors and parameter read/writes work correctly. Signed-off-by:Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
- 05 Jan, 2020 7 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Paul Walmsley: "Several fixes for RISC-V: - Fix function graph trace support - Prefix the CSR IRQ_* macro names with "RV_", to avoid collisions with macros elsewhere in the Linux kernel tree named "IRQ_TIMER" - Use __pa_symbol() when computing the physical address of a kernel symbol, rather than __pa() - Mark the RISC-V port as supporting GCOV One DT addition: - Describe the L2 cache controller in the FU540 DT file One documentation update: - Add patch acceptance guideline documentation" * tag 'riscv/for-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: Documentation: riscv: add patch acceptance guidelines riscv: prefix IRQ_ macro names with an RV_ namespace clocksource: riscv: add notrace to riscv_sched_clock riscv: ftrace: correct the condition logic in function graph tracer riscv: dts: Add DT support for SiFive L2 cache controller riscv: gcov: enable gcov for RISC-V riscv: mm: use __pa_symbol for kernel symbols -
Paul Walmsley authored
Formalize, in kernel documentation, the patch acceptance policy for arch/riscv. In summary, it states that as maintainers, we plan to only accept patches for new modules or extensions that have been frozen or ratified by the RISC-V Foundation. We've been following these guidelines for the past few months. In the meantime, we've received quite a bit of feedback that it would be helpful to have these guidelines formally documented. Based on a suggestion from Matthew Wilcox, we also add a link to this file to Documentation/process/index.rst, to make this document easier to find. The format of this document has also been changed to align to the format outlined in the maintainer entry profiles, in accordance with comments from Jon Corbet and Dan Williams. Signed-off-by:
Paul Walmsley <paul.walmsley@sifive.com> Reviewed-by:
Palmer Dabbelt <palmerdabbelt@google.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Krste Asanovic <krste@berkeley.edu> Cc: Andrew Waterman <waterman@eecs.berkeley.edu> Cc: Matthew Wilcox <willy@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net>
-
Paul Walmsley authored
"IRQ_TIMER", used in the arch/riscv CSR header file, is a sufficiently generic macro name that it's used by several source files across the Linux code base. Some of these other files ultimately include the arch/riscv CSR include file, causing collisions. Fix by prefixing the RISC-V csr.h IRQ_ macro names with an RV_ prefix. Fixes: a4c3733d ("riscv: abstract out CSR names for supervisor vs machine mode") Reported-by:
Olof Johansson <olof@lixom.net> Acked-by:
-
Zong Li authored
When enabling ftrace graph tracer, it gets the tracing clock in ftrace_push_return_trace(). Eventually, it invokes riscv_sched_clock() to get the clock value. If riscv_sched_clock() isn't marked with 'notrace', it will call ftrace_push_return_trace() and cause infinite loop. The result of failure as follow: command: echo function_graph >current_tracer [ 46.176787] Unable to handle kernel paging request at virtual address ffffffe04fb38c48 [ 46.177309] Oops [#1] [ 46.177478] Modules linked in: [ 46.177770] CPU: 0 PID: 256 Comm: $d Not tainted 5.5.0-rc1 #47 [ 46.177981] epc: ffffffe00035e59a ra : ffffffe00035e57e sp : ffffffe03a7569b0 [ 46.178216] gp : ffffffe000d29b90 tp : ffffffe03a756180 t0 : ffffffe03a756968 [ 46.178430] t1 : ffffffe00087f408 t2 : ffffffe03a7569a0 s0 : ffffffe03a7569f0 [ 46.178643] s1 : ffffffe00087f408 a0 : 0000000ac054cda4 a1 : 000000000087f411 [ 46.178856] a2 : 0000000ac054cda4 a3 : 0000000000373ca0 a4 : ffffffe04fb38c48 [ 46.179099] a5 : 00000000153e22a8 a6 : 00000000005522ff a7 : 0000000000000005 [ 46.179338] s2 : ffffffe03a756a90 s3 : ffffffe00032811c s4 : ffffffe03a756a58 [ 46.179570] s5 : ffffffe000d29fe0 s6 : 0000000000000001 s7 : 0000000000000003 [ 46.179809] s8 : 0000000000000003 s9 : 0000000000000002 s10: 0000000000000004 [ 46.180053] s11: 0000000000000000 t3 : 0000003fc815749c t4 : 00000000000efc90 [ 46.180293] t5 : ffffffe000d29658 t6 : 0000000000040000 [ 46.180482] status: 0000000000000100 badaddr: ffffffe04fb38c48 cause: 000000000000000f Signed-off-by:
Zong Li <zong.li@sifive.com> Reviewed-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> [paul.walmsley@sifive.com: cleaned up patch description] Fixes: 92e0d143 ("clocksource/drivers/riscv_timer: Provide the sched_clock") Cc: stable@vger.kernel.org Signed-off-by:
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "17 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: hexagon: define ioremap_uc ocfs2: fix the crash due to call ocfs2_get_dlm_debug once less ocfs2: call journal flush to mark journal as empty after journal recovery when mount mm/hugetlb: defer freeing of huge pages if in non-task context mm/gup: fix memory leak in __gup_benchmark_ioctl mm/oom: fix pgtables units mismatch in Killed process message fs/posix_acl.c: fix kernel-doc warnings hexagon: work around compiler crash hexagon: parenthesize registers in asm predicates fs/namespace.c: make to_mnt_ns() static fs/nsfs.c: include headers for missing declarations fs/direct-io.c: include fs/internal.h for missing prototype mm: move_pages: return valid node id in status if the page is already on the target node memcg: account security cred as well to kmemcg kcov: fix struct layout for kcov_remote_arg mm/zsmalloc.c: fix the migrated zspage statistics. mm/memory_hotplug: shrink zones when offlining memory
-
Linus Torvalds authored
Merge tag 'apparmor-pr-2020-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor Pull apparmor fixes from John Johansen: - performance regression: only get a label reference if the fast path check fails - fix aa_xattrs_match() may sleep while holding a RCU lock - fix bind mounts aborting with -ENOMEM * tag 'apparmor-pr-2020-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor: apparmor: fix aa_xattrs_match() may sleep while holding a RCU lock apparmor: only get a label reference if the fast path check fails apparmor: fix bind mounts aborting with -ENOMEM
-
- 04 Jan, 2020 6 commits
-
-
John Johansen authored
aa_xattrs_match() is unfortunately calling vfs_getxattr_alloc() from a context protected by an rcu_read_lock. This can not be done as vfs_getxattr_alloc() may sleep regardles of the gfp_t value being passed to it. Fix this by breaking the rcu_read_lock on the policy search when the xattr match feature is requested and restarting the search if a policy changes occur. Fixes: 8e51f908 ("apparmor: Add support for attaching profiles via xattr, presence and value") Reported-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
John Johansen <john.johansen@canonical.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds authored
Pull MIPS fixes from Paul Burton: "A collection of MIPS fixes: - Fill the struct cacheinfo shared_cpu_map field with sensible values, notably avoiding issues with perf which was unhappy in the absence of these values. - A boot fix for Loongson 2E & 2F machines which was fallout from some refactoring performed this cycle. - A Kconfig dependency fix for the Loongson CPU HWMon driver. - A couple of VDSO fixes, ensuring gettimeofday() behaves appropriately for kernel configurations that don't include support for a clocksource the VDSO can use & fixing the calling convention for the n32 & n64 VDSOs which would previously clobber the $gp/$28 register. - A build fix for vmlinuz compressed images which were inappropriately building with -fsanitize-coverage despite not being part of the kernel proper, then failing to link due to the missing __sanitizer_cov_trace_pc() function. - A couple of eBPF JIT fixes, including disabling it for MIPS32 due to a large number of issues with the code generated there & reflecting ISA dependencies in Kconfig to enforce that systems which don't support the JIT must include the interpreter" * tag 'mips_fixes_5.5_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: Avoid VDSO ABI breakage due to global register variable MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig MIPS: BPF: Disable MIPS32 eBPF JIT MIPS: Prevent link failure with kcov instrumentation MIPS: Kconfig: Use correct form for 'depends on' mips: Fix gettimeofday() in the vdso library MIPS: Fix boot on Fuloong2 systems mips: cacheinfo: report shared CPU map -
Nick Desaulniers authored
Similar to commit 38e45d81 ("sparc64: implement ioremap_uc") define ioremap_uc for hexagon to avoid errors from -Wimplicit-function-definition. Link: http://lkml.kernel.org/r/20191209222956.239798-2-ndesaulniers@google.com Link: https://github.com/ClangBuiltLinux/linux/issues/797 Fixes: e537654b ("lib: devres: add a helper function for ioremap_uc") Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Suggested-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Brian Cain <bcain@codeaurora.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Tuowen Zhao <ztuowen@gmail.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alexios Zavras <alexios.zavras@intel.com> Cc: Allison Randal <allison@lohutok.net> Cc: Will Deacon <will@kernel.org> Cc: Richard Fontana <rfontana@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Gang He authored
Because ocfs2_get_dlm_debug() function is called once less here, ocfs2 file system will trigger the system crash, usually after ocfs2 file system is unmounted. This system crash is caused by a generic memory corruption, these crash backtraces are not always the same, for exapmle, ocfs2: Unmounting device (253,16) on (node 172167785) general protection fault: 0000 [#1] SMP PTI CPU: 3 PID: 14107 Comm: fence_legacy Kdump: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:__kmalloc+0xa5/0x2a0 Code: 00 00 4d 8b 07 65 4d 8b RSP: 0018:ffffaa1fc094bbe8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: d310a8800d7a3faf RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000dc0 RDI: ffff96e68fc036c0 RBP: d310a8800d7a3faf R08: ffff96e6ffdb10a0 R09: 00000000752e7079 R10: 000000000001c513 R11: 0000000004091041 R12: 0000000000000dc0 R13: 0000000000000039 R14: ffff96e68fc036c0 R15: ffff96e68fc036c0 FS: 00007f699dfba540(0000) GS:ffff96e6ffd80000(0000) knlGS:00000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f3a9d9b768 CR3: 000000002cd1c000 CR4: 00000000000006e0 Call Trace: ext4_htree_store_dirent+0x35/0x100 [ext4] htree_dirblock_to_tree+0xea/0x290 [ext4] ext4_htree_fill_tree+0x1c1/0x2d0 [ext4] ext4_readdir+0x67c/0x9d0 [ext4] iterate_dir+0x8d/0x1a0 __x64_sys_getdents+0xab/0x130 do_syscall_64+0x60/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f699d33a9fb This regression problem was introduced by commit e581595e ("ocfs: no need to check return value of debugfs_create functions"). Link: http://lkml.kernel.org/r/20191225061501.13587-1-ghe@suse.com Fixes: e581595e ("ocfs: no need to check return value of debugfs_create functions") Signed-off-by:Gang He <ghe@suse.com> Acked-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> [5.3+] Signed-off-by:
-
Kai Li authored
If journal is dirty when mount, it will be replayed but jbd2 sb log tail cannot be updated to mark a new start because journal->j_flag has already been set with JBD2_ABORT first in journal_init_common. When a new transaction is committed, it will be recored in block 1 first(journal->j_tail is set to 1 in journal_reset). If emergency restart happens again before journal super block is updated unfortunately, the new recorded trans will not be replayed in the next mount. The following steps describe this procedure in detail. 1. mount and touch some files 2. these transactions are committed to journal area but not checkpointed 3. emergency restart 4. mount again and its journals are replayed 5. journal super block's first s_start is 1, but its s_seq is not updated 6. touch a new file and its trans is committed but not checkpointed 7. emergency restart again 8. mount and journal is dirty, but trans committed in 6 will not be replayed. This exception happens easily when this lun is used by only one node. If it is used by multi-nodes, other node will replay its journal and its journal super block will be updated after recovery like what this patch does. ocfs2_recover_node->ocfs2_replay_journal. The following jbd2 journal can be generated by touching a new file after journal is replayed, and seq 15 is the first valid commit, but first seq is 13 in journal super block. logdump: Block 0: Journal Superblock Seq: 0 Type: 4 (JBD2_SUPERBLOCK_V2) Blocksize: 4096 Total Blocks: 32768 First Block: 1 First Commit ID: 13 Start Log Blknum: 1 Error: 0 Feature Compat: 0 Feature Incompat: 2 block64 Feature RO compat: 0 Journal UUID: 4ED3822C54294467A4F8E87D2BA4BC36 FS Share Cnt: 1 Dynamic Superblk Blknum: 0 Per Txn Block Limit Journal: 0 Data: 0 Block 1: Journal Commit Block Seq: 14 Type: 2 (JBD2_COMMIT_BLOCK) Block 2: Journal Descriptor Seq: 15 Type: 1 (JBD2_DESCRIPTOR_BLOCK) No. Blocknum Flags 0. 587 none UUID: 00000000000000000000000000000000 1. 8257792 JBD2_FLAG_SAME_UUID 2. 619 JBD2_FLAG_SAME_UUID 3. 24772864 JBD2_FLAG_SAME_UUID 4. 8257802 JBD2_FLAG_SAME_UUID 5. 513 JBD2_FLAG_SAME_UUID JBD2_FLAG_LAST_TAG ... Block 7: Inode Inode: 8257802 Mode: 0640 Generation: 57157641 (0x3682809) FS Generation: 2839773110 (0xa9437fb6) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x1) InlineData User: 0 (root) Group: 0 (root) Size: 7 Links: 1 Clusters: 0 ctime: 0x5de5d870 0x11104c61 -- Tue Dec 3 11:37:20.286280801 2019 atime: 0x5de5d870 0x113181a1 -- Tue Dec 3 11:37:20.288457121 2019 mtime: 0x5de5d870 0x11104c61 -- Tue Dec 3 11:37:20.286280801 2019 dtime: 0x0 -- Thu Jan 1 08:00:00 1970 ... Block 9: Journal Commit Block Seq: 15 Type: 2 (JBD2_COMMIT_BLOCK) The following is journal recovery log when recovering the upper jbd2 journal when mount again. syslog: ocfs2: File system on device (252,1) was not unmounted cleanly, recovering it. fs/jbd2/recovery.c:(do_one_pass, 449): Starting recovery pass 0 fs/jbd2/recovery.c:(do_one_pass, 449): Starting recovery pass 1 fs/jbd2/recovery.c:(do_one_pass, 449): Starting recovery pass 2 fs/jbd2/recovery.c:(jbd2_journal_recover, 278): JBD2: recovery, exit status 0, recovered transactions 13 to 13 Due to first commit seq 13 recorded in journal super is not consistent with the value recorded in block 1(seq is 14), journal recovery will be terminated before seq 15 even though it is an unbroken commit, inode 8257802 is a new file and it will be lost. Link: http://lkml.kernel.org/r/20191217020140.2197-1-li.kai4@h3c.comSigned-off-by:
Kai Li <li.kai4@h3c.com> Reviewed-by:
Changwei Ge <gechangwei@live.cn> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by:
-
Waiman Long authored
The following lockdep splat was observed when a certain hugetlbfs test was run: ================================ WARNING: inconsistent lock state 4.18.0-159.el8.x86_64+debug #1 Tainted: G W --------- - - -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/30/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffffffff9acdc038 (hugetlb_lock){+.?.}, at: free_huge_page+0x36f/0xaa0 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x14f/0x3b0 _raw_spin_lock+0x30/0x70 __nr_hugepages_store_common+0x11b/0xb30 hugetlb_sysctl_handler_common+0x209/0x2d0 proc_sys_call_handler+0x37f/0x450 vfs_write+0x157/0x460 ksys_write+0xb8/0x170 do_syscall_64+0xa5/0x4d0 entry_SYSCALL_64_after_hwframe+0x6a/0xdf irq event stamp: 691296 hardirqs last enabled at (691296): [<ffffffff99bb034b>] _raw_spin_unlock_irqrestore+0x4b/0x60 hardirqs last disabled at (691295): [<ffffffff99bb0ad2>] _raw_spin_lock_irqsave+0x22/0x81 softirqs last enabled at (691284): [<ffffffff97ff0c63>] irq_enter+0xc3/0xe0 softirqs last disabled at (691285): [<ffffffff97ff0ebe>] irq_exit+0x23e/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(hugetlb_lock); <Interrupt> lock(hugetlb_lock); *** DEADLOCK *** : Call Trace: <IRQ> __lock_acquire+0x146b/0x48c0 lock_acquire+0x14f/0x3b0 _raw_spin_lock+0x30/0x70 free_huge_page+0x36f/0xaa0 bio_check_pages_dirty+0x2fc/0x5c0 clone_endio+0x17f/0x670 [dm_mod] blk_update_request+0x276/0xe50 scsi_end_request+0x7b/0x6a0 scsi_io_completion+0x1c6/0x1570 blk_done_softirq+0x22e/0x350 __do_softirq+0x23d/0xad8 irq_exit+0x23e/0x2b0 do_IRQ+0x11a/0x200 common_interrupt+0xf/0xf </IRQ> Both the hugetbl_lock and the subpool lock can be acquired in free_huge_page(). One way to solve the problem is to make both locks irq-safe. However, Mike Kravetz had learned that the hugetlb_lock is held for a linear scan of ALL hugetlb pages during a cgroup reparentling operation. So it is just too long to have irq disabled unless we can break hugetbl_lock down into finer-grained locks with shorter lock hold times. Another alternative is to defer the freeing to a workqueue job. This patch implements the deferred freeing by adding a free_hpage_workfn() work function to do the actual freeing. The free_huge_page() call in a non-task context saves the page to be freed in the hpage_freelist linked list in a lockless manner using the llist APIs. The generic workqueue is used to process the work, but a dedicated workqueue can be used instead if it is desirable to have the huge page freed ASAP. Thanks to Kirill Tkhai <ktkhai@virtuozzo.com> for suggesting the use of llist APIs which simplfy the code. Link: http://lkml.kernel.org/r/20191217170331.30893-1-longman@redhat.comSigned-off-by:Waiman Long <longman@redhat.com> Reviewed-by:
Mike Kravetz <mike.kravetz@oracle.com> Acked-by:
Davidlohr Bueso <dbueso@suse.de> Acked-by:
Michal Hocko <mhocko@suse.com> Reviewed-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
