summaryrefslogtreecommitdiffstats
path: root/drivers/tty/serial/8250/8250_pci.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "8250: add support for ASIX devices with a FIFO bug"Jiaqing Zhao2023-06-211-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit eb26dfe8aa7eeb5a5aa0b7574550125f8aa4c3b3. Commit eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug") merged on Jul 13, 2012 adds a quirk for PCI_VENDOR_ID_ASIX (0x9710). But that ID is the same as PCI_VENDOR_ID_NETMOS defined in 1f8b061050c7 ("[PATCH] Netmos parallel/serial/combo support") merged on Mar 28, 2005. In pci_serial_quirks array, the NetMos entry always takes precedence over the ASIX entry even since it was initially merged, code in that commit is always unreachable. In my tests, adding the FIFO workaround to pci_netmos_init() makes no difference, and the vendor driver also does not have such workaround. Given that the code was never used for over a decade, it's safe to revert it. Also, the real PCI_VENDOR_ID_ASIX should be 0x125b, which is used on their newer AX99100 PCIe serial controllers released on 2016. The FIFO workaround should not be intended for these newer controllers, and it was never implemented in vendor driver. Fixes: eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug") Cc: stable <stable@kernel.org> Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230619155743.827859-1-jiaqing.zhao@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: Add support for Advantech PCI-1611U cardVitaliy Tomin2023-05-131-0/+5
| | | | | | | | | | | | | | | | | Add support for Advantech PCI-1611U card Advantech provides opensource drivers for this and many others card based on legacy copy of 8250_pci driver called adv950 https://www.advantech.com/emt/support/details/driver?id=1-TDOIMJ It is hard to maintain to run as out of tree module on newer kernels. Just adding PCI ID to kernel 8250_pci works perfect. Signed-off-by: Vitaliy Tomin <tomin@iszf.irk.ru> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230423034512.2671157-1-tomin@iszf.irk.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Add serial8250_pci_setup_port definition in 8250_pcilib.cKumaravel Thiagarajan2023-02-081-22/+3
| | | | | | | | | | | | Move implementation of setup_port func() to serial8250_pci_setup_port. Co-developed-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Signed-off-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Signed-off-by: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230207164814.3104605-2-kumaravel.thiagarajan@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: Deassert Transmit Enable on probe in driver-specific wayLukas Wunner2022-09-251-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a UART port is newly registered, uart_configure_port() seeks to deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl. However a number of UART drivers interpret a set RTS bit as *assertion* instead of deassertion: Affected drivers include those using serial8250_em485_config() (except 8250_bcm2835aux.c) and some using mctrl_gpio (e.g. imx.c). Since the interpretation of the RTS bit is driver-specific, it is not suitable as a means to centrally deassert Transmit Enable in the serial core. Instead, the serial core must call on drivers to deassert it in their driver-specific way. One way to achieve that is to call ->rs485_config(). It implicitly deasserts Transmit Enable. So amend uart_configure_port() and uart_resume_port() to invoke uart_rs485_config(). That allows removing calls to uart_rs485_config() from drivers' ->probe() hooks and declaring the function static. Skip any invocation of ->set_mctrl() if RS485 is enabled. RS485 has no hardware flow control, so the modem control lines are irrelevant and need not be touched. When leaving RS485 mode, reset the modem control lines to the state stored in port->mctrl. That way, UARTs which are muxed between RS485 and RS232 transceivers drive the lines correctly when switched to RS232. (serial8250_do_startup() historically raises the OUT1 modem signal because otherwise interrupts are not signaled on ancient PC UARTs, but I believe that no longer applies to modern, RS485-capable UARTs and is thus safe to be skipped.) imx.c modifies port->mctrl whenever Transmit Enable is asserted and deasserted. Stop it from doing that so port->mctrl reflects the RS232 line state. 8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling ->set_mctrl(). Because that is now a no-op in RS485 mode, amend the function to call serial8250_em485_stop_tx(). fsl_lpuart.c retrieves and applies the RS485 device tree properties after registering the UART port. Because applying now happens on registration in uart_configure_port(), move retrieval of the properties ahead of uart_add_one_port(). Link: https://lore.kernel.org/all/20220329085050.311408-1-matthias.schiffer@ew.tq-group.com/ Link: https://lore.kernel.org/all/8f538a8903795f22f9acc94a9a31b03c9c4ccacb.camel@ginzinger.com/ Fixes: d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open") Cc: stable@vger.kernel.org # v4.14+ Reported-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reported-by: Roosen Henri <Henri.Roosen@ginzinger.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: Request full 16550A feature probing for OxSemi PCIe devicesMaciej W. Rozycki2022-09-221-0/+5
| | | | | | | | | | | | | | | | | | | Oxford Semiconductor PCIe (Tornado) 950 serial port devices need to operate in the enhanced mode via the EFR register for the Divide-by-M N/8 baud rate generator prescaler to be used in their native UART mode. Otherwise the prescaler is fixed at 1 causing grossly incorrect baud rates to be programmed. Accessing the EFR register requires 16550A features to have been probed for, so request this to happen regardless of SERIAL_8250_16550A_VARIANTS by setting UPF_FULL_PROBE in port flags. Fixes: 366f6c955d4d ("serial: 8250: Add proper clock handling for OxSemi PCIe devices") Cc: stable@vger.kernel.org # v5.19+ Reported-by: Anders Blomdell <anders.blomdell@control.lth.se> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209210005040.41633@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: 8250: Add support for Brainboxes PX cards.Cameron Williams2022-07-141-0/+109
| | | | | | | | | | | | | Add support for some of the Brainboxes PCIe (PX) range of serial cards, including the PX-101, PX-235/PX-246, PX-203/PX-257, PX-260/PX-701, PX-310, PX-313, PX-320/PX-324/PX-376/PX-387, PX-335/PX-346, PX-368, PX-420, PX-803 and PX-846. Signed-off-by: Cameron Williams <cang1@live.co.uk> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/AM5PR0202MB2564669252BDC59BF55A6E87C4879@AM5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: Embed rs485_supported to uart_portIlpo Järvinen2022-07-081-1/+1
| | | | | | | | | | Embed rs485_supported to uart_port to allow serial core to tweak it as needed. Reviewed-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220704094515.6831-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: take termios_rwsem for ->rs485_config() & pass termios as paramIlpo Järvinen2022-06-271-1/+1
| | | | | | | | | To be able to alter ADDRB within ->rs485_config(), take termios_rwsem before calling ->rs485_config() and pass termios. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220624204210.11112-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Remove serial_rs485 sanitizationIlpo Järvinen2022-06-101-14/+0
| | | | | | | | Serial core handles serial_rs485 sanitization and copying rs485 struct. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-29-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Fill in rs485_supported for pci_fintekIlpo Järvinen2022-06-101-0/+6
| | | | | | | | Add information on supported serial_rs485 features. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-12-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: Add uart_rs485_config()Ilpo Järvinen2022-06-101-4/+2
| | | | | | | | | | | | | | | | A few serial drivers make a call to rs485_config() themselves (all these seem to relate to init). Convert them all to use a common helper which makes it easy to make adjustments on tasks related to it as serial_rs485 struct sanitization is going to be added. In pci_fintek_setup() (in 8250_pci.c), the rs485_config() call was made with NULL, however, it can be changed to pass uart_port's rs485 struct. No other callers should pass NULL into rs485_config() so the NULL check can now be eliminated. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: Add proper clock handling for OxSemi PCIe devicesMaciej W. Rozycki2022-05-051-68/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. We currently drive the device using its default oversampling rate of 16 and the clock prescaler disabled, consequently yielding the baud base of 3906250. This base is inadequate for some of the high-speed baud rates such as 460800bps, for which the closest rate possible can be obtained by dividing the baud base by 8, yielding the baud rate of 488281.25bps, which is off by 5.9638%. This is enough for data communication to break with the remote end talking actual 460800bps, where missed stop bits have been observed. We can do better however, by taking advantage of a reduced oversampling rate, which can be set to any integer value from 4 to 16 inclusive by programming the TCR register, and by using the clock prescaler, which can be set to any value from 1 to 63.875 in increments of 0.125 in the CPR/CPR2 register pair. The prescaler has to be explicitly enabled though by setting bit 7 in the MCR or otherwise it is bypassed (in the enhanced mode that we enable) as if the value of 1 was used. Make use of these features then as follows: - Set the baud base to 15625000, reflecting the minimum oversampling rate of 4 with the clock prescaler and divisor both set to 1. - Override the `set_mctrl' and set the MCR shadow there so as to have MCR[7] always set and have the 8250 core propagate these settings. - Override the `get_divisor' handler and determine a good combination of parameters by using a lookup table with predetermined value pairs of the oversampling rate and the clock prescaler and finding a pair that divides the input clock such that the quotient, when rounded to the nearest integer, deviates the least from the exact result. Calculate the clock divisor accordingly. Scale the resulting oversampling rate (only by powers of two) if possible so as to maximise it, reducing the divisor accordingly, and avoid a divisor overflow for very low baud rates by scaling the oversampling rate and/or the prescaler even if that causes some accuracy loss. Also handle the historic spd_cust feature so as to allow one to set all the three parameters manually to arbitrary values, by keeping the low 16 bits for the divisor and then putting TCR in bits 19:16 and CPR/CPR2 in bits 28:20, sanitising the bit pattern supplied such as to clamp CPR/CPR2 values between 0.000 and 0.875 inclusive to 33.875. This preserves compatibility with any existing setups, that is where requesting a custom divisor that only has any bits set among the low 16 the oversampling rate of 16 and the clock prescaler of 33.875 will be used as with the original 8250. Finally abuse the `frac' argument to store the determined bit patterns for the TCR, CPR and CPR2 registers. - Override the `set_divisor' handler so as to set the TCR, CPR and CPR2 registers from the `frac' value supplied. Set the divisor as usual. With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX limitation imposed by `serial8250_get_baud_rate' standard baud rates below 300bps become unavailable in the regular way, e.g. the rate of 200bps requires the baud base to be divided by 78125 and that is beyond the unsigned 16-bit range. The historic spd_cust feature can still be used to obtain such rates if so required. See Documentation/tty/device_drivers/oxsemi-tornado.rst for more details. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181519450.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: Fold EndRun device support into OxSemi Tornado codeMaciej W. Rozycki2022-05-051-51/+25
| | | | | | | | | | | | | | | | The EndRun PTP/1588 dual serial port device is based on the Oxford Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set for EndRun Technologies and uses the same sequence to determine the number of ports available. Despite that we have duplicate code specific to the EndRun device. Remove redundant code then and factor out OxSemi Tornado device detection. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181516220.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 5.18-rc5 into tty-nextGreg Kroah-Hartman2022-05-021-4/+4
|\ | | | | | | | | | | We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250: Correct the clock for EndRun PTP/1588 PCIe deviceMaciej W. Rozycki2022-04-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EndRun PTP/1588 dual serial port device is based on the Oxford Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set for EndRun Technologies and is therefore driven by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. The clock rate is divided by the oversampling rate of 16 as it is supplied to the baud rate generator, yielding the baud base of 3906250. Replace the incorrect baud base of 4000000 with the right value of 3906250 then, complementing commit 6cbe45d8ac93 ("serial: 8250: Correct the clock for OxSemi PCIe devices"). Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable <stable@kernel.org> Fixes: 1bc8cde46a159 ("8250_pci: Added driver for Endrun Technologies PTP PCIe card.") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204181515270.9383@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250: Report which option to enable for blacklisted PCI devicesMaciej W. Rozycki2022-04-151-27/+40
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide information in the kernel log as to what configuration option to enable for PCI UART devices that have been blacklisted in the generic PCI 8250 UART driver and which have a dedicated driver available to handle that has been disabled. The rationale is there is no easy way for the user to map a specific PCI vendor:device pair to an individual dedicated driver while the generic driver has this information readily available and it will likely be confusing that the generic driver does not register such a port. This is unlike usual drivers, such as drivers/net/ethernet/3com/3c59x.c which handles all the hardware family members regardless of differences between them, and following an existing example where a serio driver provides suggestions as to the correct configuration options to use: psmouse serio1: synaptics: The touchpad can support a better bus than the too old PS/2 protocol. Make sure MOUSE_PS2_SYNAPTICS_SMBUS and RMI4_SMB are enabled to get a better touchpad experience. A message is then printed like: serial 0000:04:00.3: ignoring port, enable SERIAL_8250_PERICOM to handle when an affected device is encountered and the generic driver rejects it. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203310054120.44113@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tty: Add support for Brainboxes UC cards.Cameron Williams2022-01-261-2/+98
| | | | | | | | | | | | This commit adds support for the some of the Brainboxes PCI range of cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 and UC-420/431. Signed-off-by: Cameron Williams <cang1@live.co.uk> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Split out Pericom driverAndy Shevchenko2021-12-201-400/+5
| | | | | | | | | Pericom along with Acces I/O support consumes a lot of LOCs in 8250_pci.c. For the sake of easier maintenance, split it to a separate driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211122133512.8947-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: remove redundant assignment to tmp after the mask operationColin Ian King2021-12-171-1/+1
| | | | | | | | | | | | The variable tmp is being masked with a bitmask and the value is being written to port base + 0x3c. However, the masked value is being written back to tmp and tmp is never used after this. The assignmentment is redundant, replace the &= operator with just &. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewesd-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211205232822.110099-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: rewrite pericom_do_set_divisor()Jay Dolan2021-11-251-13/+17
| | | | | | | | | | | | | | | | | | | Have pericom_do_set_divisor() use the uartclk instead of a hard coded value to work with different speed crystals. Tested with 14.7456 and 24 MHz crystals. Have pericom_do_set_divisor() always calculate the divisor rather than call serial8250_do_set_divisor() for rates below baud_base. Do not write registers or call serial8250_do_set_divisor() if valid divisors could not be found. Fixes: 6bf4e42f1d19 ("serial: 8250: Add support for higher baud rates to Pericom chips") Cc: stable <stable@vger.kernel.org> Signed-off-by: Jay Dolan <jay.dolan@accesio.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211122120604.3909-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Fix ACCES entries in pci_serial_quirks arrayJay Dolan2021-11-251-1/+8
| | | | | | | | | | | | Fix error in table for PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S that caused it and PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4 to be missing their fourth port. Fixes: 78d3820b9bd3 ("serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup()") Cc: stable <stable@vger.kernel.org> Signed-off-by: Jay Dolan <jay.dolan@accesio.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211122120604.3909-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Remove empty stub pci_quatech_exit()Andy Shevchenko2021-10-261-5/+0
| | | | | | | | | The ->exit() callback is checked for presence anyway, no need to have an empty stub. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211026133452.61657-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Replace custom pci_match_id() implementationAndy Shevchenko2021-10-261-41/+31
| | | | | | | | Replace pci_quatech_amcc() with generic pci_match_id(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211026133452.61657-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Replace dev_*() by pci_*() macrosAndy Shevchenko2021-10-261-30/+22
| | | | | | | | | | PCI subsystem provides convenient shortcut macros for message printing. Use those macros instead of dev_*(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jiri Slaby <jslaby@kernel.org> Link: https://lore.kernel.org/r/20211022135147.70965-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Get rid of redundant 'else' keywordAndy Shevchenko2021-10-261-3/+3
| | | | | | | | | | The 'else' keyword is not needed when previous conditional branch returns to the upper layer. Get rid of redundant 'else' keyword in such cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jiri Slaby <jslaby@kernel.org> Link: https://lore.kernel.org/r/20211022135147.70965-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Refactor the loop in pci_ite887x_init()Andy Shevchenko2021-10-261-8/+4
| | | | | | | | | | The loop can be refactored by using ARRAY_SIZE() instead of NULL terminator. This reduces code base and makes it easier to read and understand. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jiri Slaby <jslaby@kernel.org> Link: https://lore.kernel.org/r/20211022135147.70965-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Prefer struct_size over open coded arithmeticLen Baker2021-09-141-3/+1
| | | | | | | | | | | | | | | | | | | | As noted in the "Deprecated Interfaces, Language Features, Attributes, and Conventions" documentation [1], size calculations (especially multiplication) should not be performed in memory allocator (or similar) function arguments due to the risk of them overflowing. This could lead to values wrapping around and a smaller allocation being made than the caller was expecting. Using those allocations could lead to linear overflows of heap memory and other misbehaviors. So, use the struct_size() helper to do the arithmetic instead of the argument "size + size * count" in the kzalloc() function. [1] https://www.kernel.org/doc/html/v5.14/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Len Baker <len.baker@gmx.com> Link: https://lore.kernel.org/r/20210905155728.11147-1-len.baker@gmx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 5.14-rc5 into tty-nextGreg Kroah-Hartman2021-08-091-0/+7
|\ | | | | | | | | | | We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250_pci: Avoid irq sharing for MSI(-X) interrupts.Mario Kleiner2021-07-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This attempts to fix a bug found with a serial port card which uses an MCS9922 chip, one of the 4 models for which MSI-X interrupts are currently supported. I don't possess such a card, and i'm not experienced with the serial subsystem, so this patch is based on what i think i found as a likely reason for failure, based on walking the user who actually owns the card through some diagnostic. The user who reported the problem finds the following in his dmesg output for the relevant ttyS4 and ttyS5: [ 0.580425] serial 0000:02:00.0: enabling device (0000 -> 0003) [ 0.601448] 0000:02:00.0: ttyS4 at I/O 0x3010 (irq = 125, base_baud = 115200) is a ST16650V2 [ 0.603089] serial 0000:02:00.1: enabling device (0000 -> 0003) [ 0.624119] 0000:02:00.1: ttyS5 at I/O 0x3000 (irq = 126, base_baud = 115200) is a ST16650V2 ... [ 6.323784] genirq: Flags mismatch irq 128. 00000080 (ttyS5) vs. 00000000 (xhci_hcd) [ 6.324128] genirq: Flags mismatch irq 128. 00000080 (ttyS5) vs. 00000000 (xhci_hcd) ... Output of setserial -a: /dev/ttyS4, Line 4, UART: 16650V2, Port: 0x3010, IRQ: 127 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test This suggests to me that the serial driver wants to register and share a MSI/MSI-X irq 128 with the xhci_hcd driver, whereas the xhci driver does not want to share the irq, as flags 0x00000080 (== IRQF_SHARED) from the serial port driver means to share the irq, and this mismatch ends in some failed irq init? With this setup, data reception works very unreliable, with dropped data, already at a transmission rate of only a 16 Bytes chunk every 1/120th of a second, ie. 1920 Bytes/sec, presumably due to rx fifo overflow due to mishandled or not used at all rx irq's? See full discussion thread with attempted diagnosis at: https://psychtoolbox.discourse.group/t/issues-with-iscan-serial-port-recording/3886 Disabling the use of MSI interrupts for the serial port pci card did fix the reliability problems. The user executed the following sequence of commands to achieve this: echo 0000:02:00.0 | sudo tee /sys/bus/pci/drivers/serial/unbind echo 0000:02:00.1 | sudo tee /sys/bus/pci/drivers/serial/unbind echo 0 | sudo tee /sys/bus/pci/devices/0000:02:00.0/msi_bus echo 0 | sudo tee /sys/bus/pci/devices/0000:02:00.1/msi_bus echo 0000:02:00.0 | sudo tee /sys/bus/pci/drivers/serial/bind echo 0000:02:00.1 | sudo tee /sys/bus/pci/drivers/serial/bind This resulted in the following log output: [ 82.179021] pci 0000:02:00.0: MSI/MSI-X disallowed for future drivers [ 87.003031] pci 0000:02:00.1: MSI/MSI-X disallowed for future drivers [ 98.537010] 0000:02:00.0: ttyS4 at I/O 0x3010 (irq = 17, base_baud = 115200) is a ST16650V2 [ 103.648124] 0000:02:00.1: ttyS5 at I/O 0x3000 (irq = 18, base_baud = 115200) is a ST16650V2 This patch attempts to fix the problem by disabling irq sharing when using MSI irq's. Note that all i know for sure is that disabling MSI irq's fixed the problem for the user, so this patch could be wrong and is untested. Please review with caution, keeping this in mind. Fixes: 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") Cc: Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de> Cc: stable <stable@vger.kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Link: https://lore.kernel.org/r/20210729043306.18528-1-mario.kleiner.de@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250_pci: Enumerate Elkhart Lake UARTs via dedicated driverAndy Shevchenko2021-07-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Elkhart Lake UARTs are PCI enumerated Synopsys DesignWare v4.0+ UART integrated with Intel iDMA 32-bit DMA controller. There is a specific driver to handle them, i.e. 8250_lpss. Hence, disable 8250_pci enumeration for these UARTs. Fixes: 1b91d97c66ef ("serial: 8250_lpss: Add ->setup() for Elkhart Lake ports") Fixes: 4f912b898dc2 ("serial: 8250_lpss: Enable HS UART on Elkhart Lake") Cc: stable <stable@vger.kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210713101739.36962-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250_pci: make setup_port() parameters explicitly unsignedGreg Kroah-Hartman2021-07-271-1/+1
|/ | | | | | | | | | | | The bar and offset parameters to setup_port() are used in pointer math, and while it would be very difficult to get them to wrap as a negative number, just be "safe" and make them unsigned so that static checkers do not trip over them unintentionally. Cc: Jiri Slaby <jirislaby@kernel.org> Reported-by: Jordy Zomer <jordy@pwning.systems> Link: https://lore.kernel.org/r/20210726130717.2052096-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: Correct the clock for OxSemi PCIe devicesMaciej W. Rozycki2021-06-161-64/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oxford Semiconductor PCIe (Tornado) serial port devices are driven by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. In the enhanced (650) mode, which we select in `autoconfig_has_efr' by setting the ECB bit in the EFR register, and in the absence of clock reconfiguration, which we currently don't do, the clock rate is divided only by the oversampling rate of 16 as it is supplied to the baud rate generator, yielding the baud base of 3906250. This comes from the reset values of the TCR and MCR[7] registers which are both zero[1][2][3][4], choosing the oversampling rate of 16 and the normal (divide by 1) baud rate generator prescaler respectively. This is the rate that is divided by the value held in the divisor latch to determine the baud rate used. Replace the incorrect baud base of 4000000 with the right value of 3906250 then. References: [1] "OXPCIe200 PCI Express Multi-Port Bridge", Oxford Semiconductor, Inc., DS-0045, 10 Nov 2008, Section "Reset Configuration", p. 72 [2] "OXPCIe952 PCI Express Bridge to Dual Serial & Parallel Port", Oxford Semiconductor, Inc., DS-0046, Mar 06 08, Section "Reset Configuration", p. 27 [3] "OXPCIe954 PCI Express Bridge to Quad Serial Port", Oxford Semiconductor, Inc., DS-0047, Feb 08, Section "Reset Configuration", p. 28 [4] "OXPCIe958 PCI Express Bridge to Octal Serial Port", Oxford Semiconductor, Inc., DS-0048, Feb 08, Section "Reset Configuration", p. 28 Fixes: 7106b4e333bae ("8250: Oxford Semiconductor Devices") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106100203510.5469@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250: Dissociate 4MHz Titan ports from Oxford portsMaciej W. Rozycki2021-06-161-6/+38
| | | | | | | | | | | | Oxford Semiconductor PCIe (Tornado) serial port devices have their baud base set incorrectly, however their `pciserial_board' entries have been reused for Titan serial port devices. Define own entries for the latter devices then, carrying over the settings, so that Oxford entries can be fixed. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106100142310.5469@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: handle FL_NOIRQ board flagChristian Gmeiner2021-05-271-12/+17
| | | | | | | | | | | | In commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") the way the irq gets allocated was changed. With that change the handling FL_NOIRQ got lost. Restore the old behaviour. Fixes: 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") Cc: <stable@vger.kernel.org> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Link: https://lore.kernel.org/r/20210527095529.26281-1-christian.gmeiner@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Add support for new HPE serial deviceRandy Wright2021-05-201-0/+18
| | | | | | | | | | | Add support for new HPE serial device. It is MSI enabled, but otherwise similar to legacy HP server serial devices. Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Randy Wright <rwright@hpe.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1621009614-28836-1-git-send-email-rwright@hpe.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Drop bogus __refdata annotationGeert Uytterhoeven2020-12-111-1/+1
| | | | | | | | | | | | Since commit d73dfc6a4199e0e3 ("serial: 8250_pci: remove __devexit usage") in v3.9, the 8250/16550 PCI serial driver no longer has any code or data located in initmem, hence there is no need to annotate the pci_serial_quirks structure with __refdata. Drop the annotation, to avoid suppressing future section warnings. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201211133907.2970460-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 5.9.0-rc6 into tty-nextGreg Kroah-Hartman2020-09-211-0/+10
|\ | | | | | | | | | | | | We need the tty/serial fixes in here and this resolves a merge issue in the 8250 driver. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * serial: 8250_pci: Add Realtek 816a and 816bTobias Diedrich2020-09-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These serial ports are exposed by the OOB-management-engine on RealManage-enabled network cards (e.g. AMD DASH enabled systems using Realtek cards). Because these have 3 BARs, they fail the "num_iomem <= 1" check in serial_pci_guess_board. I've manually checked the two IOMEM regions and BAR 2 doesn't seem to respond to reads, but BAR 4 seems to be an MMIO version of the IO ports (untested). With this change, the ports are detected: 0000:02:00.1: ttyS0 at I/O 0x2200 (irq = 82, base_baud = 115200) is a 16550A 0000:02:00.2: ttyS1 at I/O 0x2100 (irq = 55, base_baud = 115200) is a 16550A lspci output: 02:00.1 0700: 10ec:816a (rev 0e) (prog-if 02 [16550]) Subsystem: 17aa:5082 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin B routed to IRQ 82 IOMMU group: 11 Region 0: I/O ports at 2200 [size=256] Region 2: Memory at fd715000 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at fd704000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 01 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Vector table: BAR=4 offset=00000000 PBA: BAR=4 offset=00000800 Capabilities: [d0] Vital Product Data Not readable Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [178 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us 02:00.2 0700: 10ec:816b (rev 0e) [...same...] Signed-off-by: Tobias Diedrich <tobiasdiedrich@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200914173628.GA22508@yamamaya.is-a-geek.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | serial: 8250_pci: Remove unused function get_pci_irq()YueHaibing2020-09-161-9/+0
| | | | | | | | | | | | | | | | It is not used since commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200909135103.17768-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge 5.9-rc3 into tty-nextGreg Kroah-Hartman2020-08-311-1/+1
|\| | | | | | | | | | | We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva2020-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
* | serial: 8250_pci: Add WCH384_8S 8 port serial deviceDu Huanpeng2020-08-281-0/+56
|/ | | | | | | | | | | | Add PCI id for WCH384_8S 8 port PCI-E serial card. because this card has so many ports, you may have to check these two options before use it: CONFIG_SERIAL_8250_RUNTIME_UARTS CONFIG_SERIAL_8250_NR_UARTS Signed-off-by: Du Huanpeng <u74147@gmail.com> Link: https://lore.kernel.org/r/1598060848-27807-1-git-send-email-u74147@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Move Pericom IDs to pci_ids.hKai-Heng Feng2020-05-081-6/+0
| | | | | | | | | | Move the IDs to pci_ids.h so it can be used by next patch. Link: https://lore.kernel.org/r/20200508065343.32751-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org
* serial: 8250_pci: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200213004426.GA7886@embeddedor.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* remove ioremap_nocache and devm_ioremap_nocacheChristoph Hellwig2020-01-061-3/+3
| | | | | | | | ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
* Merge tag 'tty-5.5-rc1' of ↵Linus Torvalds2019-12-031-288/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial updates from Greg KH: "Here is the "big" tty and serial driver patches for 5.5-rc1. It's a bit later in the merge window than normal as I wanted to make sure some last-minute patches applied to it were all sane. They seem to be :) There's a lot of little stuff in here, for the tty core, and for lots of serial drivers: - reverts of uartlite serial driver patches that were wrong - msm-serial driver fixes - serial core updates and fixes - tty core fixes - serial driver dma mapping api changes - lots of other tiny fixes and updates for serial drivers All of these have been in linux-next for a while with no reported issues" * tag 'tty-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (58 commits) Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices" vcs: prevent write access to vcsu devices tty: vt: keyboard: reject invalid keycodes tty: don't crash in tty_init_dev when missing tty_port serial: stm32: fix clearing interrupt error flags tty: Fix Kconfig indentation, continued serial: serial_core: Perform NULL checks for break_ctl ops tty: remove unused argument from tty_open_by_driver() tty: Fix Kconfig indentation {tty: serial, nand: onenand}: samsung: rename to fix build warning serial: ifx6x60: add missed pm_runtime_disable serial: pl011: Fix DMA ->flush_buffer() Revert "serial-uartlite: Move the uart register" Revert "serial-uartlite: Add get serial id if not provided" Revert "serial-uartlite: Do not use static struct uart_driver out of probe()" Revert "serial-uartlite: Add runtime support" Revert "serial-uartlite: Change logic how console_port is setup" Revert "serial-uartlite: Use allocated structure instead of static ones" tty: serial: msm_serial: Use dma_request_chan() directly for channel request tty: serial: tegra: Use dma_request_chan() directly for channel request ...
| * Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"Je Yen Tam2019-11-271-288/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit fdc2de87124f5183a98ea7eced1f76dbdba22951 ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"). The commit fdc2de87124f ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices") introduced a breakage on NI-Serial PXI(e)-RS485 devices, RS-232 variants have no issue. The Linux system can enumerate the NI-Serial PXI(e)-RS485 devices, but it broke the R/W operation on the ports. However, the implementation is working on the NI internal Linux RT kernel but it does not work in the Linux main tree kernel. This is only affecting NI products, specifically the RS-485 variants. Reverting the upstream until a proper implementation that can apply to both NI internal Linux kernel and Linux mainline kernel is figured out. Signed-off-by: Je Yen Tam <je.yen.tam@ni.com> Fixes: fdc2de87124f ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191127075301.9866-1-je.yen.tam@ni.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | PCI: Add PCI_STD_NUM_BARS for the number of standard BARsDenis Efremov2019-10-141-5/+3
|/ | | | | | | | | | | | | | | | | | | | | | Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS". Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors. Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
* serial: 8250_pci: Implement MSI(-X) supportRalf Ramsauer2019-09-041-1/+26
| | | | | | | | | | | | | | | | | | | | | | There may be setups, where legacy interrupts are not available. This is the caese, e.g., when Linux runs as guest (aka. non-root cell) of the partitioning hypervisor Jailhouse. There, only MSI(-X) interrupts are available for guests. But the 8250_pci driver currently only supports legacy ints. So let's enable MSI(-X) interrupts. Nevertheless, this needs to handled with care: while many 8250 devices actually claim to support MSI(-X) interrupts it should not be enabled be default. I had at least one device in my hands with broken MSI implementation. So better introduce a whitelist with devices that are known to support MSI(-X) interrupts. I tested all devices mentioned in the patch. Signed-off-by: Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de> Link: https://lore.kernel.org/r/20190812112152.693622-1-ralf.ramsauer@oth-regensburg.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* serial: 8250_pci: Add F81504A series SupportJi-Ze Hong (Peter Hong)2019-09-041-0/+121
| | | | | | | | | | Fintek F81504A/508A/512A is PCIE to 4/8/12 UARTs device. It's support IO/MMIO/PCIE conf to access all functions. The old F81504/508/512 is only support IO. Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com> Link: https://lore.kernel.org/r/1565933249-23076-1-git-send-email-hpeter+linux_kernel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-25 01:19:24 +0000