| Message ID | 20230510142855.256658-1-jiaqing.zhao@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | serial: 8250_pci: remove unreachable code for ASIX devices | expand |
On Wed, May 10, 2023 at 02:28:56PM +0000, Jiaqing Zhao wrote: > PCI_VENDOR_ID_ASIX (0x9710) is the same as PCI_VENDOR_ID_NETMOS. In > pci_serial_quirks array, the NetMos entry always takes precedence over > the ASIX entry. So the code for ASIX devices is always unreachable, > even when it was initially merged. Since the NetMos vendor driver > doesn't mention such FIFO bug, it's safe to remove the code. > > This reverts commit eb26dfe8aa7e ("8250: add support for ASIX devices > with a FIFO bug"). > > Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> Please follow the documented Intel kernel developer requirements before you submit this again, based on the changes that process will require. thanks, greg k-h
On 2023-05-13 18:28, Greg Kroah-Hartman wrote: > On Wed, May 10, 2023 at 02:28:56PM +0000, Jiaqing Zhao wrote: >> PCI_VENDOR_ID_ASIX (0x9710) is the same as PCI_VENDOR_ID_NETMOS. In >> pci_serial_quirks array, the NetMos entry always takes precedence over >> the ASIX entry. So the code for ASIX devices is always unreachable, >> even when it was initially merged. Since the NetMos vendor driver >> doesn't mention such FIFO bug, it's safe to remove the code. >> >> This reverts commit eb26dfe8aa7e ("8250: add support for ASIX devices >> with a FIFO bug"). >> >> Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> > > Please follow the documented Intel kernel developer requirements before > you submit this again, based on the changes that process will require. > > thanks, > > greg k-h Sorry I am unable to find this "Intel kernel developer requirements". Is there any link or contact where I can find this information? Thank you.
On Mon, May 15, 2023 at 10:36:30AM +0800, Jiaqing Zhao wrote: > > > On 2023-05-13 18:28, Greg Kroah-Hartman wrote: > > On Wed, May 10, 2023 at 02:28:56PM +0000, Jiaqing Zhao wrote: > >> PCI_VENDOR_ID_ASIX (0x9710) is the same as PCI_VENDOR_ID_NETMOS. In > >> pci_serial_quirks array, the NetMos entry always takes precedence over > >> the ASIX entry. So the code for ASIX devices is always unreachable, > >> even when it was initially merged. Since the NetMos vendor driver > >> doesn't mention such FIFO bug, it's safe to remove the code. > >> > >> This reverts commit eb26dfe8aa7e ("8250: add support for ASIX devices > >> with a FIFO bug"). > >> > >> Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> > > > > Please follow the documented Intel kernel developer requirements before > > you submit this again, based on the changes that process will require. > > > > thanks, > > > > greg k-h > > Sorry I am unable to find this "Intel kernel developer requirements". Is > there any link or contact where I can find this information? Thank you. Contact the Intel Linux developer team and they will point you at them. This is a company-wide requirement, it is odd that your normal "Here is how you can contribute to Linux!" training at Intel did not cover it? thanks, greg k-h
On Wed, 24 May 2023, Jiaqing Zhao wrote: > On 2023-05-15 11:49, Greg Kroah-Hartman wrote: > > On Mon, May 15, 2023 at 10:36:30AM +0800, Jiaqing Zhao wrote: > >> On 2023-05-13 18:28, Greg Kroah-Hartman wrote: > >>> Please follow the documented Intel kernel developer requirements before > >>> you submit this again, based on the changes that process will require. > >>> > >>> thanks, > >>> > >>> greg k-h > >> Sorry I am unable to find this "Intel kernel developer requirements". Is > >> there any link or contact where I can find this information? Thank you. > > > > Contact the Intel Linux developer team and they will point you at them. > > This is a company-wide requirement, it is odd that your normal "Here is > > how you can contribute to Linux!" training at Intel did not cover it? > > I contacted them and there is no reply so far. Could you please tell me if > there is any general available docs about this or point out what I'm doing > wrong in this patch? Thank you very much. I've pointed him to the right direction (now that I noticed this has just gone on here).
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h index 1e8fe44a7099..eeb7b43ebe53 100644 --- a/drivers/tty/serial/8250/8250.h +++ b/drivers/tty/serial/8250/8250.h @@ -91,7 +91,6 @@ struct serial8250_config { #define UART_BUG_TXEN BIT(1) /* UART has buggy TX IIR status */ #define UART_BUG_NOMSR BIT(2) /* UART has buggy MSR status bits (Au1x00) */ #define UART_BUG_THRE BIT(3) /* UART has buggy THRE reassertion */ -#define UART_BUG_PARITY BIT(4) /* UART mishandles parity if FIFO enabled */ #define UART_BUG_TXRACE BIT(5) /* UART Tx fails to set remote DR */ diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c index c55be6fda0ca..5359679bc282 100644 --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -1232,14 +1232,6 @@ static int pci_oxsemi_tornado_setup(struct serial_private *priv, return pci_default_setup(priv, board, up, idx); } -static int pci_asix_setup(struct serial_private *priv, - const struct pciserial_board *board, - struct uart_8250_port *port, int idx) -{ - port->bugs |= UART_BUG_PARITY; - return pci_default_setup(priv, board, port, idx); -} - #define QPCR_TEST_FOR1 0x3F #define QPCR_TEST_GET1 0x00 #define QPCR_TEST_FOR2 0x40 @@ -1953,7 +1945,6 @@ pci_moxa_setup(struct serial_private *priv, #define PCI_DEVICE_ID_WCH_CH355_4S 0x7173 #define PCI_VENDOR_ID_AGESTAR 0x5372 #define PCI_DEVICE_ID_AGESTAR_9375 0x6872 -#define PCI_VENDOR_ID_ASIX 0x9710 #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e @@ -2598,16 +2589,6 @@ static struct pci_serial_quirk pci_serial_quirks[] = { .exit = pci_wch_ch38x_exit, .setup = pci_wch_ch38x_setup, }, - /* - * ASIX devices with FIFO bug - */ - { - .vendor = PCI_VENDOR_ID_ASIX, - .device = PCI_ANY_ID, - .subvendor = PCI_ANY_ID, - .subdevice = PCI_ANY_ID, - .setup = pci_asix_setup, - }, /* * Broadcom TruManage (NetXtreme) */ diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index fe8d79c4ae95..8b9ef175e44c 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2635,11 +2635,8 @@ static unsigned char serial8250_compute_lcr(struct uart_8250_port *up, if (c_cflag & CSTOPB) cval |= UART_LCR_STOP; - if (c_cflag & PARENB) { + if (c_cflag & PARENB) cval |= UART_LCR_PARITY; - if (up->bugs & UART_BUG_PARITY) - up->fifo_bug = true; - } if (!(c_cflag & PARODD)) cval |= UART_LCR_EPAR; if (c_cflag & CMSPAR) @@ -2800,8 +2797,7 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios, up->lcr = cval; /* Save computed LCR */ if (up->capabilities & UART_CAP_FIFO && port->fifosize > 1) { - /* NOTE: If fifo_bug is not set, a user can set RX_trigger. */ - if ((baud < 2400 && !up->dma) || up->fifo_bug) { + if (baud < 2400 && !up->dma) { up->fcr &= ~UART_FCR_TRIGGER_MASK; up->fcr |= UART_FCR_TRIGGER_1; } @@ -3137,8 +3133,7 @@ static int do_set_rxtrig(struct tty_port *port, unsigned char bytes) struct uart_8250_port *up = up_to_u8250p(uport); int rxtrig; - if (!(up->capabilities & UART_CAP_FIFO) || uport->fifosize <= 1 || - up->fifo_bug) + if (!(up->capabilities & UART_CAP_FIFO) || uport->fifosize <= 1) return -EINVAL; rxtrig = bytes_to_fcr_rxtrig(up, bytes); diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h index 6f78f302d272..09029cb33e74 100644 --- a/include/linux/serial_8250.h +++ b/include/linux/serial_8250.h @@ -98,7 +98,6 @@ struct uart_8250_port { struct list_head list; /* ports on this IRQ */ u32 capabilities; /* port capabilities */ unsigned short bugs; /* port bugs */ - bool fifo_bug; /* min RX trigger if enabled */ unsigned int tx_loadsz; /* transmit fifo load size */ unsigned char acr; unsigned char fcr;
PCI_VENDOR_ID_ASIX (0x9710) is the same as PCI_VENDOR_ID_NETMOS. In pci_serial_quirks array, the NetMos entry always takes precedence over the ASIX entry. So the code for ASIX devices is always unreachable, even when it was initially merged. Since the NetMos vendor driver doesn't mention such FIFO bug, it's safe to remove the code. This reverts commit eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug"). Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> --- drivers/tty/serial/8250/8250.h | 1 - drivers/tty/serial/8250/8250_pci.c | 19 ------------------- drivers/tty/serial/8250/8250_port.c | 11 +++-------- include/linux/serial_8250.h | 1 - 4 files changed, 3 insertions(+), 29 deletions(-)