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

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>

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

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>

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>

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>

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>

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>

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>

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>

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

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

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

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Commit 5275ad70 ("tty: serial: mcf: 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-14-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit ec128510 ("tty: serial: lpc32xx_hs: 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-13-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 5faf75d7 ("tty: serial: icom: 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-12-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit b4d49924 ("tty: serial: bcm63xx: 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-11-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 1ecc26bd ("atmel_serial: split the interrupt handler") worked
around the infamous low_latency behaviour of tty_flip_buffer_push() by
dropping and reacquiring the port lock in the tasklet callback.

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: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-10-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 3fa12008 ("tty: serial: arc: 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: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-9-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit b16c8e3e ("tty: serial: ar933x: 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-8-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 78d34d75 ("tty: serial: apbuart: 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-7-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit ead76f32 ("ARM: 6763/1: pl011: add optional RX DMA to PL011
v2") added RX DMA support and also reproduced the workaround for the
infamous low_latency behaviour of tty_flip_buffer_push() by dropping and
reacquiring the port lock during receive processing.

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.

Note that the port lock is also dropped in the PIO path
(see pl011_rx_chars), but it is not clear whether this is still needed
by the DMA code added by the aforementioned commit.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-6-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 2389b272 ("[ARM] 4417/1: Serial: Fix AMBA drivers locking")
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.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-5-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit dd085ed8 ("tty: serial: altera: 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: Tobias Klauser <tklauser@distanz.ch>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210421095509.3024-4-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>