<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/tty, branch v6.2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF</title>
<updated>2023-01-31T14:51:52+00:00</updated>
<author>
<name>George Kennedy</name>
<email>george.kennedy@oracle.com</email>
</author>
<published>2023-01-24T16:16:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=226fae124b2dac217ea5436060d623ff3385bc34'/>
<id>226fae124b2dac217ea5436060d623ff3385bc34</id>
<content type='text'>
After a call to console_unlock() in vcs_read() the vc_data struct can be
freed by vc_deallocate(). Because of that, the struct vc_data pointer
load must be done at the top of while loop in vcs_read() to avoid a UAF
when vcs_size() is called.

Syzkaller reported a UAF in vcs_size().

BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537

CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1
Hardware name: Red Hat KVM, BIOS 1.15.0-2.module
Call Trace:
  &lt;TASK&gt;
__asan_report_load4_noabort (mm/kasan/report_generic.c:350)
vcs_size (drivers/tty/vt/vc_screen.c:215)
vcs_read (drivers/tty/vt/vc_screen.c:415)
vfs_read (fs/read_write.c:468 fs/read_write.c:450)
...
  &lt;/TASK&gt;

Allocated by task 1191:
...
kmalloc_trace (mm/slab_common.c:1069)
vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720
     drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)
con_install (drivers/tty/vt/vt.c:3383)
tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413
     drivers/tty/tty_io.c:1390)
tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)
chrdev_open (fs/char_dev.c:415)
do_dentry_open (fs/open.c:883)
vfs_open (fs/open.c:1014)
...

Freed by task 1548:
...
kfree (mm/slab_common.c:1021)
vc_port_destruct (drivers/tty/vt/vt.c:1094)
tty_port_destructor (drivers/tty/tty_port.c:296)
tty_port_put (drivers/tty/tty_port.c:312)
vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
tty_ioctl (drivers/tty/tty_io.c:2776)
...

The buggy address belongs to the object at ffff888113747800
  which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 424 bytes inside of
  1024-byte region [ffff888113747800, ffff888113747c00)

The buggy address belongs to the physical page:
page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000
     index:0x0 pfn:0x113740
head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0
     compound_pincount:0
anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
&gt; ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                   ^
  ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint

Fixes: ac751efa6a0d ("console: rename acquire/release_console_sem() to console_lock/unlock()")
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Suggested-by: Jiri Slaby &lt;jirislaby@kernel.org&gt;
Signed-off-by: George Kennedy &lt;george.kennedy@oracle.com&gt;
Link: https://lore.kernel.org/r/1674577014-12374-1-git-send-email-george.kennedy@oracle.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After a call to console_unlock() in vcs_read() the vc_data struct can be
freed by vc_deallocate(). Because of that, the struct vc_data pointer
load must be done at the top of while loop in vcs_read() to avoid a UAF
when vcs_size() is called.

Syzkaller reported a UAF in vcs_size().

BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537

CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1
Hardware name: Red Hat KVM, BIOS 1.15.0-2.module
Call Trace:
  &lt;TASK&gt;
__asan_report_load4_noabort (mm/kasan/report_generic.c:350)
vcs_size (drivers/tty/vt/vc_screen.c:215)
vcs_read (drivers/tty/vt/vc_screen.c:415)
vfs_read (fs/read_write.c:468 fs/read_write.c:450)
...
  &lt;/TASK&gt;

Allocated by task 1191:
...
kmalloc_trace (mm/slab_common.c:1069)
vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720
     drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)
con_install (drivers/tty/vt/vt.c:3383)
tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413
     drivers/tty/tty_io.c:1390)
tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)
chrdev_open (fs/char_dev.c:415)
do_dentry_open (fs/open.c:883)
vfs_open (fs/open.c:1014)
...

Freed by task 1548:
...
kfree (mm/slab_common.c:1021)
vc_port_destruct (drivers/tty/vt/vt.c:1094)
tty_port_destructor (drivers/tty/tty_port.c:296)
tty_port_put (drivers/tty/tty_port.c:312)
vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
tty_ioctl (drivers/tty/tty_io.c:2776)
...

The buggy address belongs to the object at ffff888113747800
  which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 424 bytes inside of
  1024-byte region [ffff888113747800, ffff888113747c00)

The buggy address belongs to the physical page:
page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000
     index:0x0 pfn:0x113740
head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0
     compound_pincount:0
anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
&gt; ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                   ^
  ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint

Fixes: ac751efa6a0d ("console: rename acquire/release_console_sem() to console_lock/unlock()")
Reported-by: syzkaller &lt;syzkaller@googlegroups.com&gt;
Suggested-by: Jiri Slaby &lt;jirislaby@kernel.org&gt;
Signed-off-by: George Kennedy &lt;george.kennedy@oracle.com&gt;
Link: https://lore.kernel.org/r/1674577014-12374-1-git-send-email-george.kennedy@oracle.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_dma: Fix DMA Rx rearm race</title>
<updated>2023-01-31T10:15:16+00:00</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2023-01-30T11:48:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=57e9af7831dcf211c5c689c2a6f209f4abdf0bce'/>
<id>57e9af7831dcf211c5c689c2a6f209f4abdf0bce</id>
<content type='text'>
As DMA Rx can be completed from two places, it is possible that DMA Rx
completes before DMA completion callback had a chance to complete it.
Once the previous DMA Rx has been completed, a new one can be started
on the next UART interrupt. The following race is possible
(uart_unlock_and_check_sysrq_irqrestore() replaced with
spin_unlock_irqrestore() for simplicity/clarity):

CPU0					CPU1
					dma_rx_complete()
serial8250_handle_irq()
  spin_lock_irqsave(&amp;port-&gt;lock)
  handle_rx_dma()
    serial8250_rx_dma_flush()
      __dma_rx_complete()
        dma-&gt;rx_running = 0
        // Complete DMA Rx
  spin_unlock_irqrestore(&amp;port-&gt;lock)

serial8250_handle_irq()
  spin_lock_irqsave(&amp;port-&gt;lock)
  handle_rx_dma()
    serial8250_rx_dma()
      dma-&gt;rx_running = 1
      // Setup a new DMA Rx
  spin_unlock_irqrestore(&amp;port-&gt;lock)

					  spin_lock_irqsave(&amp;port-&gt;lock)
					  // sees dma-&gt;rx_running = 1
					  __dma_rx_complete()
					    dma-&gt;rx_running = 0
					    // Incorrectly complete
					    // running DMA Rx

This race seems somewhat theoretical to occur for real but handle it
correctly regardless. Check what is the DMA status before complething
anything in __dma_rx_complete().

Reported-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Tested-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Fixes: 9ee4b83e51f7 ("serial: 8250: Add support for dmaengine")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230130114841.25749-3-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As DMA Rx can be completed from two places, it is possible that DMA Rx
completes before DMA completion callback had a chance to complete it.
Once the previous DMA Rx has been completed, a new one can be started
on the next UART interrupt. The following race is possible
(uart_unlock_and_check_sysrq_irqrestore() replaced with
spin_unlock_irqrestore() for simplicity/clarity):

CPU0					CPU1
					dma_rx_complete()
serial8250_handle_irq()
  spin_lock_irqsave(&amp;port-&gt;lock)
  handle_rx_dma()
    serial8250_rx_dma_flush()
      __dma_rx_complete()
        dma-&gt;rx_running = 0
        // Complete DMA Rx
  spin_unlock_irqrestore(&amp;port-&gt;lock)

serial8250_handle_irq()
  spin_lock_irqsave(&amp;port-&gt;lock)
  handle_rx_dma()
    serial8250_rx_dma()
      dma-&gt;rx_running = 1
      // Setup a new DMA Rx
  spin_unlock_irqrestore(&amp;port-&gt;lock)

					  spin_lock_irqsave(&amp;port-&gt;lock)
					  // sees dma-&gt;rx_running = 1
					  __dma_rx_complete()
					    dma-&gt;rx_running = 0
					    // Incorrectly complete
					    // running DMA Rx

This race seems somewhat theoretical to occur for real but handle it
correctly regardless. Check what is the DMA status before complething
anything in __dma_rx_complete().

Reported-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Tested-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Fixes: 9ee4b83e51f7 ("serial: 8250: Add support for dmaengine")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230130114841.25749-3-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_dma: Fix DMA Rx completion race</title>
<updated>2023-01-31T10:15:16+00:00</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2023-01-30T11:48:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=31352811e13dc2313f101b890fd4b1ce760b5fe7'/>
<id>31352811e13dc2313f101b890fd4b1ce760b5fe7</id>
<content type='text'>
__dma_rx_complete() is called from two places:
  - Through the DMA completion callback dma_rx_complete()
  - From serial8250_rx_dma_flush() after IIR_RLSI or IIR_RX_TIMEOUT
The former does not hold port's lock during __dma_rx_complete() which
allows these two to race and potentially insert the same data twice.

Extend port's lock coverage in dma_rx_complete() to prevent the race
and check if the DMA Rx is still pending completion before calling
into __dma_rx_complete().

Reported-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Tested-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Fixes: 9ee4b83e51f7 ("serial: 8250: Add support for dmaengine")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230130114841.25749-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__dma_rx_complete() is called from two places:
  - Through the DMA completion callback dma_rx_complete()
  - From serial8250_rx_dma_flush() after IIR_RLSI or IIR_RX_TIMEOUT
The former does not hold port's lock during __dma_rx_complete() which
allows these two to race and potentially insert the same data twice.

Extend port's lock coverage in dma_rx_complete() to prevent the race
and check if the DMA Rx is still pending completion before calling
into __dma_rx_complete().

Reported-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Tested-by: Gilles BULOZ &lt;gilles.buloz@kontron.com&gt;
Fixes: 9ee4b83e51f7 ("serial: 8250: Add support for dmaengine")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230130114841.25749-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler</title>
<updated>2023-01-31T10:15:01+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2023-01-20T16:03:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3f6c02fa712bd453871877fe1d1969625617471e'/>
<id>3f6c02fa712bd453871877fe1d1969625617471e</id>
<content type='text'>
Requesting an interrupt with IRQF_ONESHOT will run the primary handler
in the hard-IRQ context even in the force-threaded mode. The
force-threaded mode is used by PREEMPT_RT in order to avoid acquiring
sleeping locks (spinlock_t) in hard-IRQ context. This combination
makes it impossible and leads to "sleeping while atomic" warnings.

Use one interrupt handler for both handlers (primary and secondary)
and drop the IRQF_ONESHOT flag which is not needed.

Fixes: e359b4411c283 ("serial: stm32: fix threaded interrupt handling")
Reviewed-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Tested-by: Valentin Caron &lt;valentin.caron@foss.st.com&gt; # V3
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230120160332.57930-1-marex@denx.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Requesting an interrupt with IRQF_ONESHOT will run the primary handler
in the hard-IRQ context even in the force-threaded mode. The
force-threaded mode is used by PREEMPT_RT in order to avoid acquiring
sleeping locks (spinlock_t) in hard-IRQ context. This combination
makes it impossible and leads to "sleeping while atomic" warnings.

Use one interrupt handler for both handlers (primary and secondary)
and drop the IRQF_ONESHOT flag which is not needed.

Fixes: e359b4411c283 ("serial: stm32: fix threaded interrupt handling")
Reviewed-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Tested-by: Valentin Caron &lt;valentin.caron@foss.st.com&gt; # V3
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230120160332.57930-1-marex@denx.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'tty-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty</title>
<updated>2023-01-21T19:12:42+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-01-21T19:12:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bd5cc6ee8f4e823e466a075a79db3cd355cee28e'/>
<id>bd5cc6ee8f4e823e466a075a79db3cd355cee28e</id>
<content type='text'>
Pull tty/serial driver fixes from Greg KH:
 "Here are some small tty and serial driver fixes for 6.2-rc5 that
  resolve a number of tiny reported issues and some new device ids. They
  include:

   - new device id for the exar serial driver

   - speakup tty driver bugfix

   - atmel serial driver baudrate fixup

   - stm32 serial driver bugfix and then revert as the bugfix broke the
     build. That will come back in a later pull request once it is all
     worked out properly.

   - amba-pl011 serial driver rs486 mode bugfix

   - qcom_geni serial driver bugfix

  Most of these have been in linux-next with no reported problems (well,
  other than the build breakage which generated the revert), the new
  device id passed 0-day testing"

* tag 'tty-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: exar: Add support for Sealevel 7xxxC serial cards
  Revert "serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler"
  tty: serial: qcom_geni: avoid duplicate struct member init
  serial: atmel: fix incorrect baudrate setup
  tty: fix possible null-ptr-defer in spk_ttyio_release
  serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
  serial: amba-pl011: fix high priority character transmission in rs486 mode
  serial: pch_uart: Pass correct sg to dma_unmap_sg()
  tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull tty/serial driver fixes from Greg KH:
 "Here are some small tty and serial driver fixes for 6.2-rc5 that
  resolve a number of tiny reported issues and some new device ids. They
  include:

   - new device id for the exar serial driver

   - speakup tty driver bugfix

   - atmel serial driver baudrate fixup

   - stm32 serial driver bugfix and then revert as the bugfix broke the
     build. That will come back in a later pull request once it is all
     worked out properly.

   - amba-pl011 serial driver rs486 mode bugfix

   - qcom_geni serial driver bugfix

  Most of these have been in linux-next with no reported problems (well,
  other than the build breakage which generated the revert), the new
  device id passed 0-day testing"

* tag 'tty-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: exar: Add support for Sealevel 7xxxC serial cards
  Revert "serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler"
  tty: serial: qcom_geni: avoid duplicate struct member init
  serial: atmel: fix incorrect baudrate setup
  tty: fix possible null-ptr-defer in spk_ttyio_release
  serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
  serial: amba-pl011: fix high priority character transmission in rs486 mode
  serial: pch_uart: Pass correct sg to dma_unmap_sg()
  tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: exar: Add support for Sealevel 7xxxC serial cards</title>
<updated>2023-01-20T12:38:38+00:00</updated>
<author>
<name>Matthew Howell</name>
<email>matthew.howell@sealevel.com</email>
</author>
<published>2023-01-19T19:40:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=14ee78d5932afeb710c8305196a676a715bfdea8'/>
<id>14ee78d5932afeb710c8305196a676a715bfdea8</id>
<content type='text'>
Add support for Sealevel 7xxxC serial cards.

This patch:
* Adds IDs to recognize 7xxxC cards from Sealevel Systems.
* Updates exar_pci_probe() to set nr_ports to last two bytes of primary
  dev ID for these cards.

Signed-off-by: Matthew Howell &lt;matthew.howell@sealevel.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2301191440010.22558@tstest-VirtualBox
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for Sealevel 7xxxC serial cards.

This patch:
* Adds IDs to recognize 7xxxC cards from Sealevel Systems.
* Updates exar_pci_probe() to set nr_ports to last two bytes of primary
  dev ID for these cards.

Signed-off-by: Matthew Howell &lt;matthew.howell@sealevel.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2301191440010.22558@tstest-VirtualBox
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler"</title>
<updated>2023-01-20T10:18:36+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-01-20T10:16:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2cbafffbf69addd7509072f4be5917f81d238cf6'/>
<id>2cbafffbf69addd7509072f4be5917f81d238cf6</id>
<content type='text'>
This reverts commit f24771b62a83239f0dce816bddf0f6807f436235 as it is
reported to break the build.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Link: https://lore.kernel.org/r/202301200130.ttBiTzfO-lkp@intel.com
Fixes: f24771b62a83 ("serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler")
Cc: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Cc: Valentin Caron &lt;valentin.caron@foss.st.com&gt; # V3
Cc: Marek Vasut &lt;marex@denx.de&gt;
Cc: Johan Hovold &lt;johan@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit f24771b62a83239f0dce816bddf0f6807f436235 as it is
reported to break the build.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Link: https://lore.kernel.org/r/202301200130.ttBiTzfO-lkp@intel.com
Fixes: f24771b62a83 ("serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler")
Cc: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Cc: Valentin Caron &lt;valentin.caron@foss.st.com&gt; # V3
Cc: Marek Vasut &lt;marex@denx.de&gt;
Cc: Johan Hovold &lt;johan@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'printk-for-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux</title>
<updated>2023-01-19T20:32:07+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-01-19T20:32:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d368967cb1039b5c4cccb62b5a4b9468c50cd143'/>
<id>d368967cb1039b5c4cccb62b5a4b9468c50cd143</id>
<content type='text'>
Pull printk fixes from Petr Mladek:

 - Prevent a potential deadlock when configuring kgdb console

 - Fix a kernel doc warning

* tag 'printk-for-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
  kernel/printk/printk.c: Fix W=1 kernel-doc warning
  tty: serial: kgdboc: fix mutex locking order for configure_kgdboc()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull printk fixes from Petr Mladek:

 - Prevent a potential deadlock when configuring kgdb console

 - Fix a kernel doc warning

* tag 'printk-for-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
  kernel/printk/printk.c: Fix W=1 kernel-doc warning
  tty: serial: kgdboc: fix mutex locking order for configure_kgdboc()
</pre>
</div>
</content>
</entry>
<entry>
<title>tty: serial: qcom_geni: avoid duplicate struct member init</title>
<updated>2023-01-19T15:24:59+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2022-12-15T16:54:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5342ab0af45064cbdc773645b93ab70c24ee161f'/>
<id>5342ab0af45064cbdc773645b93ab70c24ee161f</id>
<content type='text'>
When -Woverride-init is enabled in a build, gcc points out that
qcom_geni_serial_pm_ops contains conflicting initializers:

drivers/tty/serial/qcom_geni_serial.c:1586:20: error: initialized field overwritten [-Werror=override-init]
 1586 |         .restore = qcom_geni_serial_sys_hib_resume,
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/tty/serial/qcom_geni_serial.c:1586:20: note: (near initialization for 'qcom_geni_serial_pm_ops.restore')
drivers/tty/serial/qcom_geni_serial.c:1587:17: error: initialized field overwritten [-Werror=override-init]
 1587 |         .thaw = qcom_geni_serial_sys_hib_resume,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Open-code the initializers with the version that was already used,
and use the pm_sleep_ptr() method to deal with unused ones,
in place of the __maybe_unused annotation.

Fixes: 35781d8356a2 ("tty: serial: qcom-geni-serial: Add support for Hibernation feature")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20221215165453.1864836-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When -Woverride-init is enabled in a build, gcc points out that
qcom_geni_serial_pm_ops contains conflicting initializers:

drivers/tty/serial/qcom_geni_serial.c:1586:20: error: initialized field overwritten [-Werror=override-init]
 1586 |         .restore = qcom_geni_serial_sys_hib_resume,
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/tty/serial/qcom_geni_serial.c:1586:20: note: (near initialization for 'qcom_geni_serial_pm_ops.restore')
drivers/tty/serial/qcom_geni_serial.c:1587:17: error: initialized field overwritten [-Werror=override-init]
 1587 |         .thaw = qcom_geni_serial_sys_hib_resume,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Open-code the initializers with the version that was already used,
and use the pm_sleep_ptr() method to deal with unused ones,
in place of the __maybe_unused annotation.

Fixes: 35781d8356a2 ("tty: serial: qcom-geni-serial: Add support for Hibernation feature")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20221215165453.1864836-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: atmel: fix incorrect baudrate setup</title>
<updated>2023-01-19T15:24:39+00:00</updated>
<author>
<name>Tobias Schramm</name>
<email>t.schramm@manjaro.org</email>
</author>
<published>2023-01-09T07:29:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5bfdd3c654bd879bff50c2e85e42f85ae698b42f'/>
<id>5bfdd3c654bd879bff50c2e85e42f85ae698b42f</id>
<content type='text'>
Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
setup") changed uart_set_options to select the correct baudrate
configuration based on the absolute error between requested baudrate and
available standard baudrate settings.
Prior to that commit the baudrate was selected based on which predefined
standard baudrate did not exceed the requested baudrate.
This change of selection logic was never reflected in the atmel serial
driver. Thus the comment left in the atmel serial driver is no longer
accurate.
Additionally the manual rounding up described in that comment and applied
via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
tty_termios_encode_baud_rate to determine the appropriate baudrate flags
this can cause baudrate selection to fail entirely because
tty_termios_encode_baud_rate will only select a baudrate if relative error
between requested and selected baudrate does not exceed +/-2%.
Fix that by requesting actual, exact baudrate used by the serial.

Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Tobias Schramm &lt;t.schramm@manjaro.org&gt;
Acked-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
setup") changed uart_set_options to select the correct baudrate
configuration based on the absolute error between requested baudrate and
available standard baudrate settings.
Prior to that commit the baudrate was selected based on which predefined
standard baudrate did not exceed the requested baudrate.
This change of selection logic was never reflected in the atmel serial
driver. Thus the comment left in the atmel serial driver is no longer
accurate.
Additionally the manual rounding up described in that comment and applied
via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
tty_termios_encode_baud_rate to determine the appropriate baudrate flags
this can cause baudrate selection to fail entirely because
tty_termios_encode_baud_rate will only select a baudrate if relative error
between requested and selected baudrate does not exceed +/-2%.
Fix that by requesting actual, exact baudrate used by the serial.

Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Tobias Schramm &lt;t.schramm@manjaro.org&gt;
Acked-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
