- 28 4月, 2021 1 次提交
-
-
由 Linus Torvalds 提交于
It seems like Fedora 34 ends up enabling a few new gcc warnings, notably "-Wstringop-overread" and "-Warray-parameter". Both of them cause what seem to be valid warnings in the kernel, where we have array size mismatches in function arguments (that are no longer just silently converted to a pointer to element, but actually checked). This fixes most of the trivial ones, by making the function declaration match the function definition, and in the case of intel_pm.c, removing the over-specified array size from the argument declaration. At least one 'stringop-overread' warning remains in the i915 driver, but that one doesn't have the same obvious trivial fix, and may or may not actually be indicative of a bug. [ It was a mistake to upgrade one of my machines to Fedora 34 while being busy with the merge window, but if this is the extent of the compiler upgrade problems, things are better than usual - Linus ] Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 4月, 2021 2 次提交
-
-
由 Robert Hancock 提交于
Previously the XILINX_INTC config option was hidden and only auto-selected on the MicroBlaze platform. However, this IP can also be used on the Zynq and ZynqMP platforms as a secondary cascaded controller. Allow this option to be user-enabled on those platforms. Signed-off-by: NRobert Hancock <robert.hancock@calian.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210423185853.2556087-1-robert.hancock@calian.com
-
由 Alexey Klimov 提交于
From: Alexey Klimov <klimov.linux@gmail.com> Add the B550M AORUS PRO-P motherboard description to gigabyte_wmi_known_working_platforms. Signed-off-by: NAlexey Klimov <klimov.linux@gmail.com> Acked-by: NThomas Weißschuh <thomas@weissschuh.net> Link: https://lore.kernel.org/r/20210421234156.3942343-1-aklimov@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
-
- 23 4月, 2021 14 次提交
-
-
由 Andy Shevchenko 提交于
The enable1 is confusing name. Change it to clearly show what is the intention behind it. No functional changes. Fixes: 25093bde ("spi: implement SW control for CS times") Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210420131846.75983-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Joseph Chen 提交于
TCS4525 main features: - 2.7V to 5.5V Input Voltage Range; - 3MHz Constant Switching Frequency; - 5A Available Load Current; - Programmable Output Voltage: 0.6V to 1.4V in 6.25mV Steps; - PFM/PWM Operation for Optimum Increased Efficiency; Signed-off-by: NJoseph Chen <chenjh@rock-chips.com> [Ezequiel: Forward port] Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com> Link: https://lore.kernel.org/r/20210421210338.43819-3-ezequiel@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 He Ying 提交于
We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ------------[ cut here ]------------ [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a 'BUG_ON(in_nmi())' in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. Fixes: 3f1f3234 ("irqchip/gic-v3: Switch to PMR masking before calling IRQ handler") Acked-by: NMark Rutland <mark.rutland@arm.com> Signed-off-by: NHe Ying <heying24@huawei.com> [maz: rewrote commit message, corrected Fixes: tag] Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210423083516.170111-1-heying24@huawei.com Cc: stable@vger.kernel.org
-
由 Vincent Whitchurch 提交于
The jiffies-based off_on_delay implementation has a couple of problems that cause it to sometimes not actually delay for the required time: (1) If, for example, the off_on_delay time is equivalent to one jiffy, and the ->last_off_jiffy is set just before a new jiffy starts, then _regulator_do_enable() does not wait at all since it checks using time_before(). (2) When jiffies overflows, the value of "remaining" becomes higher than "max_delay" and the code simply proceeds without waiting. Fix these problems by changing it to use ktime_t instead. [Note that since jiffies doesn't start at zero but at INITIAL_JIFFIES ("-5 minutes"), (2) above also led to the code not delaying if the first regulator_enable() is called when the ->last_off_jiffy is not initialised, such as for regulators with ->constraints->boot_on set. It's not clear to me if this was intended or not, but I've preserved this behaviour explicitly with the check for a non-zero ->last_off.] Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210423114524.26414-1-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Thinh Nguyen 提交于
DWC_usb32 IP introduces a new behavior when handling NoStream event for IN endpoints. If the controller is capable of DEV_TXF_FLUSH_BYPASS, then the driver does not need to force to restart stream for IN endpoints. The controller will generate ERDY and restart the stream periodically. Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/65c3070c666cd6b8beeee62d7f8e3e704ebf2d32.1619134559.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Thinh Nguyen 提交于
DWC_usb32 introduces a new HW capability register GHWPARAMS9. Capture this in the dwc->hwparams.hwparams9 field. Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/f76cc4a9c8c4ab325f5babe03c57b039166360b0.1619134559.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dan Carpenter 提交于
The intent here was to return negative error codes but it actually returns positive values. The problem is that type promotion with ternary operations is quite complicated. "ret" is an int. "copied" is a u32. And the snoop_file_read() function returns long. What happens is that "ret" is cast to u32 and becomes positive then it's cast to long and it's still positive. Fix this by removing the ternary so that "ret" is type promoted directly to long. Fixes: 3772e5da ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJoel Stanley <joel@jms.id.au> Reviewed-by: NPatrick Venture <venture@google.com> Link: https://lore.kernel.org/r/YIE90PSXsMTa2Y8n@mwanda Link: https://lore.kernel.org/r/20210423000919.1249474-1-joel@jms.id.au' Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Jan Beulich 提交于
There's no point in comparing SBDF - we can simply compare the struct pci_dev pointers. If they weren't the same for a given device, we'd have bigger problems from having stored a stale pointer. Signed-off-by: NJan Beulich <jbeulich@suse.com> Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/158273a2-d1b9-3545-b25d-affca867376c@suse.comSigned-off-by: NJuergen Gross <jgross@suse.com>
-
由 Bjorn Helgaas 提交于
Fix misspelling of "physical". Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRoger Pau Monné <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20210126205509.2917606-1-helgaas@kernel.orgSigned-off-by: NJuergen Gross <jgross@suse.com>
-
由 Paul Durrant 提交于
Prior to commit 4a8c31a1 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the behaviour of xen-blkback when connecting to a frontend was: - read 'ring-page-order' - if not present then expect a single page ring specified by 'ring-ref' - else expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order This was correct behaviour, but was broken by the afforementioned commit to become: - read 'ring-page-order' - if not present then expect a single page ring (i.e. ring-page-order = 0) - expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order - if that didn't work then see if there's a single page ring specified by 'ring-ref' This incorrect behaviour works most of the time but fails when a frontend that sets 'ring-page-order' is unloaded and replaced by one that does not because, instead of reading 'ring-ref', xen-blkback will read the stale 'ring-ref0' left around by the previous frontend will try to map the wrong grant reference. This patch restores the original behaviour. Fixes: 4a8c31a1 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront") Signed-off-by: NPaul Durrant <pdurrant@amazon.com> Reviewed-by: NDongli Zhang <dongli.zhang@oracle.com> Reviewed-by: N"Roger Pau Monné" <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20210202175659.18452-1-paul@xen.orgSigned-off-by: NJuergen Gross <jgross@suse.com>
-
由 Boris Ostrovsky 提交于
Commit 76fc2537 ("xen/acpi-stub: Disable it b/c the acpi_processor_add is no longer called.") declared as BROKEN support for Xen ACPI stub (which is required for xen-acpi-{cpu|memory}-hotplug) and suggested that this is temporary and will be soon fixed. This was in March 2013. Further, commit cfafae94 ("xen: rename dom0_op to platform_op") renamed an interface used by memory hotplug code without updating that code (as it was BROKEN and therefore not compiled). This was in November 2015 and has gone unnoticed for over 5 year. It is now clear that this code is of no interest to anyone and therefore should be removed. Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/1618336344-3162-1-git-send-email-boris.ostrovsky@oracle.comSigned-off-by: NJuergen Gross <jgross@suse.com>
-
由 Muhammad Usama Anjum 提交于
Correct enum pci_channel_io_normal should be used instead of putting integer value 1. Fix following smatch warnings: drivers/xen/xen-pciback/pci_stub.c:805:40: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:805:40: expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:805:40: got int drivers/xen/xen-pciback/pci_stub.c:862:40: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:862:40: expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:862:40: got int drivers/xen/xen-pciback/pci_stub.c:973:31: warning: incorrect type in argument 2 (different base types) drivers/xen/xen-pciback/pci_stub.c:973:31: expected restricted pci_channel_state_t [usertype] state drivers/xen/xen-pciback/pci_stub.c:973:31: got int Signed-off-by: NMuhammad Usama Anjum <musamaanjum@gmail.com> Reviewed-by: NJuergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20210326181442.GA1735905@LEGIONSigned-off-by: NJuergen Gross <jgross@suse.com>
-
由 Eli Cohen 提交于
Set err = -ENOMEM if dma_map_sg_attrs() fails so the function reutrns error. Fixes: 94abbccd ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: NEli Cohen <elic@nvidia.com> Reported-by: Nkernel test robot <lkp@intel.com> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210411083646.910546-1-elic@nvidia.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NJason Wang <jasowang@redhat.com> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
-
由 Xie Yongji 提交于
Protect vhost device iotlb by vhost_dev->mutex. Otherwise, it might cause corruption of the list and interval tree in struct vhost_iotlb if userspace sends the VHOST_IOTLB_MSG_V2 message concurrently. Fixes: 4c8cf318("vhost: introduce vDPA-based backend") Cc: stable@vger.kernel.org Signed-off-by: NXie Yongji <xieyongji@bytedance.com> Acked-by: NJason Wang <jasowang@redhat.com> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20210412095512.178-1-xieyongji@bytedance.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 22 4月, 2021 23 次提交
-
-
由 Arnd Bergmann 提交于
Printing size_t needs a special %zx format modifier to avoid a warning like: drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here 481 | dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf); Patrice already tried to fix this, but picked %lx instead of %zx, which fixed some architectures but broke others in the same way. Using %zx works everywhere. Fixes: 18674dee ("spi: stm32-qspi: Add dirmap support") Fixes: 1b8a7d42 ("spi: stm32-qspi: Fix compilation warning in ARM64") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210422134955.1988316-1-arnd@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Vincent Whitchurch 提交于
We currently do not respect off_on_delay the first time we turn on a regulator. This is problematic since the regulator could have been turned off by the bootloader, or it could it have been turned off during the probe of the regulator driver (such as when regulator-fixed requests the enable GPIO), either of which could potentially have happened less than off_on_delay microseconds ago before the first time a client requests for the regulator to be turned on. We can't know exactly when the regulator was turned off, but initialise off_on_delay to the current time when registering the regulator, so that we guarantee that we respect the off_on_delay in all cases. Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210422083044.11479-1-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Thomas Bogendoerfer 提交于
IDT 79rc3243x SoCs have rather simple interrupt controllers connected to the MIPS CPU interrupt lines. Each of them has room for up to 32 interrupts. Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210422145330.73452-1-tsbogend@alpha.franken.de
-
由 Marc Zyngier 提交于
irq_create_strict_mappings() is a poor way to allow the use of a linear IRQ domain as a legacy one. Let's be upfront about it. Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210406093557.1073423-4-maz@kernel.org
-
由 Lorenzo Pieralisi 提交于
GIC CPU interfaces versions predating GIC v4.1 were not built to accommodate vINTID within the vSGI range; as reported in the GIC specifications (8.2 "Changes to the CPU interface"), it is CONSTRAINED UNPREDICTABLE to deliver a vSGI to a PE with ID_AA64PFR0_EL1.GIC < b0011. Check the GIC CPUIF version by reading the SYS_ID_AA64_PFR0_EL1. Disable vSGIs if a CPUIF version < 4.1 is detected to prevent using vSGIs on systems where they may misbehave. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210317100719.3331-2-lorenzo.pieralisi@arm.com
-
由 Colin Ian King 提交于
The variable retval is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Randy Dunlap 提交于
Use the 'fallthrough' macro to document that this switch case does indeed fall through to the next case. ../drivers/irqchip/irq-tb10x.c: In function 'tb10x_irq_set_type': ../drivers/irqchip/irq-tb10x.c:62:13: warning: this statement may fall through [-Wimplicit-fallthrough=] 62 | flow_type = IRQ_TYPE_LEVEL_LOW; ../drivers/irqchip/irq-tb10x.c:63:2: note: here 63 | case IRQ_TYPE_LEVEL_LOW: | ^~~~ Fixes: b06eb017 ("irqchip: Add TB10x interrupt controller driver") Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210422051620.23021-1-rdunlap@infradead.org
-
由 Dan Carpenter 提交于
The problem is that "req->actual" is a u32, "req->status" is an int, and iocb->ki_complete() takes a long. We would expect that a negative error code in "req->status" would translate to a negative long value. But what actually happens is that because "req->actual" is a u32, the error codes is type promoted to a high positive value and then remains a positive value when it is cast to long. (No sign expansion). We can fix this by casting "req->status" to long. Acked-by: NFelipe Balbi <balbi@kernel.org> Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YIE7RrBPLWc3XtMg@mwandaSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Allow more drivers to be compile tested more easily, for example, when doing subsystem-wide changes. Verified on X86_64 as well as arm, powerpc and m68k with minimal configs in order to catch missing implicit build dependencies (e.g. MAILBOX for SERIAL_TEGRA_TCU). Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210422080211.29326-1-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Fabrice Gasnier 提交于
Add the support for two optional DT properties, to configure RX and TX FIFO thresholds: - rx-threshold - tx-threshold This replaces hard-coded 8 bytes threshold. Keep 8 as the default value if not specified, for backward compatibility. Signed-off-by: NFabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: NErwan Le Ray <erwan.leray@foss.st.com> Changes in v2: Change added properties naming as proposed by Rob Herring. Link: https://lore.kernel.org/r/20210413174015.23011-5-erwan.leray@foss.st.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit c8dbdc84 ("serial: xuartps: Rewrite the interrupt handling logic") reworked the driver interrupt processing but also, without comment, added an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push() which had been removed years before. Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-27-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit de49df58 ("tty: serial: vt8500: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Tony Prisk <linux@prisktech.co.nz> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-26-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The timbuart driver has always carried a workaround for the infamous low_latency behaviour of tty_flip_buffer_push() which required not holding the port lock when the low_latency flag was set. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-25-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The sunsu driver has been carrying a workaround for the infamous low_latency behaviour of tty_flip_buffer_push() by dropping and reacquiring the port lock in the interrupt handler since 2004. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: "David S. Miller" <davem@davemloft.net> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-24-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The sifive driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push() which had been removed years before the driver was added by commit 45c054d0 ("tty: serial: add driver for the SiFive UART"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-23-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit f5ee56cc ("[PATCH] txx9 serial update") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-22-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit 53e0e670 ("tty: serial: sa1100: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-21-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit de7053c7 ("tty: serial: rp2: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-20-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The rda driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had been removed years before the driver was added by commit c10b1332 ("tty: serial: Add RDA8810PL UART driver"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-19-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The owl driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had been removed years before the driver was added by commit fc60a8b6 ("tty: serial: owl: Implement console driver"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-18-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit f77232da ("tty: serial: msm: drop uart_port->lock before calling tty_flip_buffer_push()") claimed to address a locking issue but only provided a dubious lockdep splat from an unrelated driver, which in the end turned out to be due a broken local change carried by the author. Unfortunately these patches were merged before the issue had been analysed properly so the commit messages makes no sense whatsoever. The real issue was first seen on RT which at the time effectively always set the low_latency flag for all serial drivers by patching tty_flip_buffer_push(). This in turn revealed that many drivers did not handle the infamous low_latency behaviour which meant that data was pushed immediately to the line discipline instead of being deferred to a work queue. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@linaro.org/ Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-17-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Commit fbe543b4 ("Fix a potential issue in mpc52xx uart driver") worked around the infamous low_latency behaviour of tty_flip_buffer_push() by simply dropping and reacquiring the port lock in the interrupt handler. Since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-16-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The meson driver has always carried an unnecessary workaround for the infamous low_latency behaviour of tty_flip_buffer_push(), which had already been removed by the time the driver was added by commit ff7693d0 ("ARM: meson: serial: add MesonX SoC on-chip uart driver"). Specifically, since commit a9c3f68f ("tty: Fix low_latency BUG"), tty_flip_buffer_push() always schedules a work item to push data to the line discipline and there's no need to keep any low_latency hacks around. Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210421095509.3024-15-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-