- Jan 04, 2024
-
-
Hugo Villeneuve authored
Use preferred spi_get_device_match_data() instead of device_get_match_data() and spi_get_device_id() to get the driver match data. Suggested-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-8-hugo@hugovil.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hugo Villeneuve authored
Replace the explicit sc16is7xx_lines bitfield declaration with the generic macro DECLARE_BITMAP() to reserve just enough memory to contain all required bits. This also improves code self-documentation by showing the maximum number of bits required. This conversion now makes sc16is7xx_lines an array, so drop the "&" before sc16is7xx_lines in all bit access functions. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Hugo Villeneuve authored
Simplify and improve readability by replacing while(1) loop with do {} while, and by using the keep_polling variable as the exit condition, making it more explicit. Fixes: 83444987 ("sc16is7xx: Fix for multi-channel stall") Cc: <stable@vger.kernel.org> Suggested-by: -
Hugo Villeneuve authored
Commit 83444987 ("sc16is7xx: Fix for multi-channel stall") changed sc16is7xx_port_irq() from looping multiple times when there was still interrupts to serve. It simply changed the do {} while(1) loop to a do {} while(0) loop, which makes the loop itself now obsolete. Clean the code by removing this obsolete do {} while(0) loop. Fixes: 83444987 ("sc16is7xx: Fix for multi-channel stall") Cc: <stable@vger.kernel.org> Suggested-by:
-
Hugo Villeneuve authored
15 MHz is supported only by 76x variants. If the SPI clock frequency is not specified, use a safe default clock value of 4 MHz that is supported by all variants. Also use HZ_PER_MHZ macro to improve readability. Fixes: 2c837a8a ("sc16is7xx: spi interface is added") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hugo Villeneuve authored
The original comment is confusing because it implies that variants other than the SC16IS762 supports other SPI modes beside SPI_MODE_0. Extract from datasheet: The SC16IS762 differs from the SC16IS752 in that it supports SPI clock speeds up to 15 Mbit/s instead of the 4 Mbit/s supported by the SC16IS752... In all other aspects, the SC16IS762 is functionally and electrically the same as the SC16IS752. The same is also true of the SC16IS760 variant versus the SC16IS740 and SC16IS750 variants. For all variants, only SPI mode 0 is supported. Change comment and abort probing if the specified SPI mode is not SPI_MODE_0. Fixes: 2c837a8a ("sc16is7xx: spi interface is added") Cc: <stable@vger.kernel.org> Signed-off-by: -
Hugo Villeneuve authored
If an error occurs during probing, the sc16is7xx_lines bitfield may be left in a state that doesn't represent the correct state of lines allocation. For example, in a system with two SC16 devices, if an error occurs only during probing of channel (port) B of the second device, sc16is7xx_lines final state will be 00001011b instead of the expected 00000011b. This is caused in part because of the "i--" in the for/loop located in the out_ports: error path. Fix this by checking the return value of uart_add_one_port() and set line allocation bit only if this was successful. This allows the refactor of the obfuscated for(i--...) loop in the error path, and properly call uart_remove_one_port() only when needed, and properly unset line allocation bits. Also use same mechanism in remove() when calling uart_remove_one_port(). Fixes: c6434972 ("sc16is7xx: support multiple devices") Cc: <stable@vger.kernel.org> Cc: Yury Norov <yury.norov@gmail.com> Signed-off-by:
-
Lino Sanfilippo authored
The UART supports an auto-RTS mode in which the RTS pin is automatically activated during transmission. So mark this mode as being supported even if RTS is not controlled by the driver but the UART. Also the serial core expects now at least one of both modes rts-on-send or rts-after-send to be supported. This is since during sanitization unsupported flags are deleted from a RS485 configuration set by userspace. However if the configuration ends up with both flags unset, the core prints a warning since it considers such a configuration invalid (see uart_sanitize_serial_rs485()). Cc: <stable@vger.kernel.org> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Lino Sanfilippo <l.sanfilippo@kunbus.com> Link: https://lore.kernel.org/r/20240103061818.564-8-l.sanfilippo@kunbus.com Signed-off-by:
-
Lino Sanfilippo authored
The drivers RS485 support is deactivated if there is no RTS GPIO available. This is done by nullifying the ports rs485_supported struct. After that however the settings in serial_omap_rs485_supported are assigned to the same structure unconditionally, which results in an unintended reactivation of RS485 support. Fix this by moving the assignment to the beginning of serial_omap_probe_rs485() and thus before uart_get_rs485_mode() gets called. Also replace the assignment of rs485_config() to have the complete RS485 setup in one function. Fixes: e2752ae3 ("serial: omap: Disallow RS-485 if rts-gpio is not specified") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Lino Sanfilippo authored
If the imx driver cannot support RS485 it nullifies the ports rs485_supported structure. But it still calls uart_get_rs485_mode() which may set the RS485_ENABLED flag nevertheless. This may lead to an attempt to configure RS485 even if it is not supported when the flag is evaluated in uart_configure_port() at port startup. Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED flag is not supported by the caller. With this fix a check for RTS availability is now obsolete in the imx driver, since it can not evaluate to true any more. So remove this check. Furthermore the explicit nullifcation of rs485_supported is not needed, since the memory has already been set to zeros at allocation. So remove this, too. Fixes: 00d7a00e ("serial: imx: Fill in rs485_supported") Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: <stable@vger.kernel.org> Suggested-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Lino Sanfilippo authored
Some uart drivers specify a rs485_config() function and then decide later to disable RS485 support for some reason (e.g. imx and ar933). In these cases userspace may be able to activate RS485 via TIOCSRS485 nevertheless, since in uart_set_rs485_config() an existing rs485_config() function indicates that RS485 is supported. Make sure that this is not longer possible by checking the uarts rs485_supported.flags instead and bailing out if SER_RS485_ENABLED is not set. Furthermore instead of returning an empty structure return -ENOTTY if the RS485 configuration is requested via TIOCGRS485 but RS485 is not supported. This has a small impact on userspace visibility but it is consistent with the -ENOTTY error for TIOCGRS485. Fixes: e849145e ("serial: ar933x: Fill in rs485_supported") Fixes: 55e18c6b ("serial: imx: Remove serial_rs485 sanitization") Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: <stable@vger.kernel.org> Reviewed-by:
-
Lino Sanfilippo authored
Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS settings in a RS485 configuration that has been passed by userspace. If RTS-on-send and RTS-after-send are both set or unset the configuration is adjusted and RTS-after-send is disabled and RTS-on-send enabled. This however makes only sense if both RTS modes are actually supported by the driver. With commit be2e2cb1 ("serial: Sanitize rs485_struct") the code does take the driver support into account but only checks if one of both RTS modes are supported. This may lead to the errorneous result of RTS-on-send being set even if only RTS-after-send is supported. Fix this by changing the implemented logic: First clear all unsupported flags in the RS485 configuration, then adjust an invalid RTS setting by taking into account which RTS mode is supported. Cc: <stable@vger.kernel.org> Fixes: be2e2cb1 ("serial: Sanitize rs485_struct") Reviewed-by:
-
Lino Sanfilippo authored
If the RS485 feature RX-during-TX is supported by means of a GPIO set the according supported flag. Otherwise setting this feature from userspace may not be possible, since in uart_sanitize_serial_rs485() the passed RS485 configuration is matched against the supported features and unsupported settings are thereby removed and thus take no effect. Cc: <stable@vger.kernel.org> Fixes: 163f080e ("serial: core: Add option to output RS485 RX_DURING_TX state via GPIO") Reviewed-by:
-
Lino Sanfilippo authored
Both the imx and stm32 driver set the rx-during-tx GPIO in rs485_config(). Since this function is called with the port lock held, this can be a problem in case that setting the GPIO line can sleep (e.g. if a GPIO expander is used which is connected via SPI or I2C). Avoid this issue by moving the GPIO setting outside of the port lock into the serial core and thus making it a generic feature. Also with commit c54d4854 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO") the SER_RS485_RX_DURING_TX flag is only set if a rx-during-tx GPIO is _not_ available, which is wrong. Fix this, too. Furthermore reset old GPIO settings in case that changing the RS485 configuration failed. Fixes: c54d4854 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO") Fixes: ca530cfa ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO") Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Michal Simek authored
Debug Communication Channel (DCC) provides the way how to pass data between target CPU and host via JTAG interface. Every CPU has own interface for communication via dbgdtrtx_el0 and dbgdtrrx_el0 registers. Signed-off-by:
Michal Simek <michal.simek@amd.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/9d7e85914eb1cdb313b28cb019093a84dd9b4773.1703167505.git.michal.simek@amd.com Signed-off-by:
-
Stefan Wahren authored
The commit fcc446c8 ("serial: 8250_bcm2835aux: Add ACPI support") dropped the error handling for clock acquiring. But even an optional clock needs this. Fixes: fcc446c8 ("serial: 8250_bcm2835aux: Add ACPI support") Cc: stable <stable@kernel.org> Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20231220114334.4712-1-wahrenst@gmx.net Signed-off-by:
-
Rengarajan S authored
In PCI1XXXX C0 endpoint, support for Burst mode is added. pci1xxxx_handle_irq checks the burst status and based on that incoming characters are received in DWORDs, RX handling is done in pci1xxxx_rx_burst. While reading the burst status the RX error is checked and the corresponding error statistics are updated. Signed-off-by:
Rengarajan S <rengarajan.s@microchip.com> Link: https://lore.kernel.org/r/20231215151123.41812-4-rengarajan.s@microchip.com Signed-off-by:
-
Rengarajan S authored
Different Host drivers can attempt to access system registers simultaneously from different memory spaces at the same time. The syslock mechanism provides a safe option for reading UART system registers and prevents conflicts by serializing access. Added three padding bytes in the structure for memory alignment. Signed-off-by:
-
Rengarajan S authored
Structure declarations in 8250_pci1xxxx.c have been moved above the functions for code readability. Signed-off-by:
-
Raag Jadav authored
Use devm_kmemdup() helper to copy dma_param instead of doing it manually. Signed-off-by:
Raag Jadav <raag.jadav@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20240102055006.27256-1-raag.jadav@intel.com Signed-off-by:
-
Crescent CY Hsieh authored
After switching the serial interface of the Moxa RS232 PCIe boards, it fails to reset to RS232 when attempting to reload 8250_pci driver. This patch set RS232 as the default setting during the initialization of Moxa PCIe board. Signed-off-by:
Crescent CY Hsieh <crescentcy.hsieh@moxa.com> Link: https://lore.kernel.org/r/20240102053133.9795-1-crescentcy.hsieh@moxa.com Signed-off-by:
-
Vamshi Gajjela authored
Designware UART has optional feature FIFO_MODE to implement FIFO. Encoding FIFO capabilities through Component Parameter Register CPR is optional and it can be enabled using parameter UART_ADD_ENCODED_PARAMS. Driver can exercise fifo capabilities by decoding CPR if implemented or from cpr_val provided from the dw8250_platform_data otherwise. dw8250_setup_port() checks for CPR or cpr_val to determine FIFO size only when Component Version (UCV) is non-zero. Bailing out early on UCV read returning zero will leave fifosize as zero and !UART_CAP_FIFO, hence prevent early return and continue to process CPR or cpr_val for the driver to utilize FIFO. Non-zero UCV implies ADDITIONAL_FEATURES=1, preventing early return will not be an overhead here. Signed-off-by:
Vamshi Gajjela <vamshigajjela@google.com> Link: https://lore.kernel.org/r/20231231182951.877805-1-vamshigajjela@google.com Signed-off-by:
-
Christoph Niedermaier authored
There are register accesses in the function imx_uart_rs485_config(). The clock must be enabled for these accesses. This was ensured by calling it via the function uart_rs485_config() in the probe() function within the range where the clock is enabled. With the commit 7c7f9bc9 ("serial: Deassert Transmit Enable on probe in driver-specific way") it was removed from the probe() function and is now only called through the function uart_add_one_port() which is located at the end of the probe() function. But the clock is already switched off in this area. To ensure that the clock is enabled during register access, move the disabling of the clock to the very end of the probe() function. To avoid leaking enabled clocks on error also add an error path for exiting with disabling the clock. Fixes: 7c7f9bc9 ("serial: Deassert Transmit Enable on probe in driver-specific way") Cc: stable <stable@kernel.org> Signed-off-by:
Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by:
Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/20231226113647.39376-1-cniedermaier@dh-electronics.com Signed-off-by:
-
Sam Ravnborg authored
When using a leon kernel with qemu there where no console prompt. The root cause is the handling of the fifo size in the tx part of the apbuart driver. The qemu uart driver only have a very rudimentary status handling and do not report the number of chars queued in the tx fifo in the status register. So the driver ends up with a fifo size of 1. In the tx path the fifo size is divided by 2 - resulting in a fifo size of zero. The original implementation would always try to send one char, but after the introduction of uart_port_tx_limited() the fifo size is respected even for the first char. There seems to be no good reason to divide the fifo size with two - so remove this. It looks like something copied from the original amba driver. With qemu we now have a minimum fifo size of one char, so we show the prompt. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Fixes: d11cc8c3 ("tty: serial: use uart_port_tx_limited()") Cc: Andreas Larsson <andreas@gaisler.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: <linux-serial@vger.kernel.org> Cc: <sparclinux@vger.kernel.org> Link: https://lore.kernel.org/r/20231226121607.GA2622970@ravnborg.org Signed-off-by:
-
Michael Trimarchi authored
Check if port type is not PORT_UNKNOWN during poll_init. The kgdboc calls the tty_find_polling_driver that check if the serial is able to use poll_init. The poll_init calls the uart uart_poll_init that try to configure the uart with the selected boot parameters. The uart must be ready before setting parameters. Seems that PORT_UNKNOWN is already used by other functions in serial_core to detect uart status, so use the same to avoid to use it in invalid state. The crash happen for instance in am62x architecture where the 8250 register the platform driver after the 8250 core is initialized. Follow the report crash coming from KGDB Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584 584 __raw_writeb(value, PCI_IOBASE + addr); (gdb) bt This section of the code is too early because in this case the omap serial is not probed Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584 584 __raw_writeb(value, PCI_IOBASE + addr); (gdb) bt Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584 584 __raw_writeb(value, PCI_IOBASE + addr); (gdb) bt 0 _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584 1 logic_outb (value=0 '\000', addr=18446739675637874689) at lib/logic_pio.c:299 2 0xffff80008082dfcc in io_serial_out (p=0x0, offset=16760830, value=0) at drivers/tty/serial/8250/8250_port.c:416 3 0xffff80008082fe34 in serial_port_out (value=<optimized out>, offset=<optimized out>, up=<optimized out>) at ./include/linux/serial_core.h:677 4 serial8250_do_set_termios (port=0xffff8000828ee940 <serial8250_ports+1568>, termios=0xffff80008292b93c, old=0x0) at drivers/tty/serial/8250/8250_port.c:2860 5 0xffff800080830064 in serial8250_set_termios (port=0xfffffbfffe800000, termios=0xffbffe, old=0x0) at drivers/tty/serial/8250/8250_port.c:2912 6 0xffff80008082571c in uart_set_options (port=0xffff8000828ee940 <serial8250_ports+1568>, co=0x0, baud=115200, parity=110, bits=8, flow=110) at drivers/tty/serial/serial_core.c:2285 7 0xffff800080828434 in uart_poll_init (driver=0xfffffbfffe800000, line=16760830, options=0xffff8000828f7506 <config+6> "115200n8") at drivers/tty/serial/serial_core.c:2656 8 0xffff800080801690 in tty_find_polling_driver (name=0xffff8000828f7500 <config> "ttyS2,115200n8", line=0xffff80008292ba90) at drivers/tty/tty_io.c:410 9 0xffff80008086c0b0 in configure_kgdboc () at drivers/tty/serial/kgdboc.c:194 10 0xffff80008086c1ec in kgdboc_probe (pdev=0xfffffbfffe800000) at drivers/tty/serial/kgdboc.c:249 11 0xffff8000808b399c in platform_probe (_dev=0xffff000000ebb810) at drivers/base/platform.c:1404 12 0xffff8000808b0b44 in call_driver_probe (drv=<optimized out>, dev=<optimized out>) at drivers/base/dd.c:579 13 really_probe (dev=0xffff000000ebb810, drv=0xffff80008277f138 <kgdboc_platform_driver+48>) at drivers/base/dd.c:658 14 0xffff8000808b0d2c in __driver_probe_device (drv=0xffff80008277f138 <kgdboc_platform_driver+48>, dev=0xffff000000ebb810) at drivers/base/dd.c:800 15 0xffff8000808b0eb8 in driver_probe_device (drv=0xfffffbfffe800000, dev=0xffff000000ebb810) at drivers/base/dd.c:830 16 0xffff8000808b0ff4 in __device_attach_driver (drv=0xffff80008277f138 <kgdboc_platform_driver+48>, _data=0xffff80008292bc48) at drivers/base/dd.c:958 17 0xffff8000808ae970 in bus_for_each_drv (bus=0xfffffbfffe800000, start=0x0, data=0xffff80008292bc48, fn=0xffff8000808b0f3c <__device_attach_driver>) at drivers/base/bus.c:457 18 0xffff8000808b1408 in __device_attach (dev=0xffff000000ebb810, allow_async=true) at drivers/base/dd.c:1030 19 0xffff8000808b16d8 in device_initial_probe (dev=0xfffffbfffe800000) at drivers/base/dd.c:1079 20 0xffff8000808af9f4 in bus_probe_device (dev=0xffff000000ebb810) at drivers/base/bus.c:532 21 0xffff8000808ac77c in device_add (dev=0xfffffbfffe800000) at drivers/base/core.c:3625 22 0xffff8000808b3428 in platform_device_add (pdev=0xffff000000ebb800) at drivers/base/platform.c:716 23 0xffff800081b5dc0c in init_kgdboc () at drivers/tty/serial/kgdboc.c:292 24 0xffff800080014db0 in do_one_initcall (fn=0xffff800081b5dba4 <init_kgdboc>) at init/main.c:1236 25 0xffff800081b0114c in do_initcall_level (command_line=<optimized out>, level=<optimized out>) at init/main.c:1298 26 do_initcalls () at init/main.c:1314 27 do_basic_setup () at init/main.c:1333 28 kernel_init_freeable () at init/main.c:1551 29 0xffff8000810271ec in kernel_init (unused=0xfffffbfffe800000) at init/main.c:1441 30 0xffff800080015e80 in ret_from_fork () at arch/arm64/kernel/entry.S:857 Reviewed-by:Douglas Anderson <dianders@chromium.org> Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com> Link: https://lore.kernel.org/r/20231224131200.266224-1-michael@amarulasolutions.com Signed-off-by:
-
Christoph Niedermaier authored
Correct the clock error message by changing the clock name. Fixes: 1e512d45 ("serial: imx: add error messages when .probe fails") Signed-off-by:
-
Antony Pavlov authored
Prior to this patch: ~# cat /proc/interrupts ... 40: 123 0 GIC-0 72 Level altera_uart 41: 9 0 GIC-0 73 Level altera_uart After this patch: ~# cat /proc/interrupts ... 40: 6 0 GIC-0 72 Level ff200100.fpga-uart0 41: 28 0 GIC-0 73 Level ff200200.fpga-uart1 Signed-off-by:
Antony Pavlov <antonynpavlov@gmail.com> Acked-by:
Tobias Klauser <tklauser@distanz.ch> Link: https://lore.kernel.org/r/20231217195601.236002-1-antonynpavlov@gmail.com Signed-off-by:
-
Crescent CY Hsieh authored
Add "SER_RS485_MODE_RS422" flag to struct serial_rs485, so that serial port can switch interface into RS422 if supported by using ioctl command "TIOCSRS485". By treating RS422 as a mode of RS485, which means while enabling RS422 there are two flags need to be set (SER_RS485_ENABLED and SER_RS485_MODE_RS422), it would make things much easier. For example some places that checks for "SER_RS485_ENABLED" won't need to be rewritten. Signed-off-by:
-
Crescent CY Hsieh authored
This patch replaces the bit shift code with "_BITUL()" macro inside "serial_rs485" struct. Signed-off-by:
-
Vamshi Gajjela authored
Rename the variable size to temp and change its data type from unsigned int to u64 to avoid type casting in multiplication. Remove the intermediate variable frame_time and use temp instead to accommodate the nanoseconds(ns). port->frame_time is an unsigned int, therefore an explicit cast is used to improve readability. Having said this unsigned int is sufficinet to hold frame time duration in nanoseconds for all the standard baudrates. Consider 9600 baud, it takes 1/9600 seconds for one bit, for a total of 10 bits (start, 8-bit data, stop) 10/9600=1.04 ms for 1 byte transfer, frame_time here is 1041667ns. As baudrate increases frame_time decreases, say for 115200 baud it is 86806ns. To avoid costly 64-bit arithmetic we do not upconvert the type for variable frame_time as overflow happens for extremely low baudrates which are impractical and are not used in real-world applications. Signed-off-by:
-
Vamshi Gajjela authored
The function uart_fifo_timeout() returns an unsigned long value, which is the number of jiffies. Therefore, change the variable timeout in the function uart_poll_timeout() from int to unsigned long. Change the return type of the function uart_poll_timeout() from int to unsigned long to be consistent with the type of timeout values. Signed-off-by:
-
- Dec 15, 2023
-
-
Crescent CY Hsieh authored
MOXA PCIe RS422/RS485 boards will not function by default because of the initial default serial interface of all MOXA PCIe boards is set to RS232. This patch fixes the problem above by setting the initial default serial interface to RS422 for those MOXA RS422/RS485 PCIe boards. Signed-off-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20231214060234.6147-1-crescentcy.hsieh@moxa.com Signed-off-by:
-
Théo Lebrun authored
On this platform, different vendor data is used. That requires a compile-time check as we access (1) a global boolean & (2) our local vendor data. Both symbols are accessible only when CONFIG_ACPI_SPCR_TABLE is enabled. Factor the vendor data overriding to a separate function that is empty when CONFIG_ACPI_SPCR_TABLE is not defined. Suggested-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Théo Lebrun <theo.lebrun@bootlin.com> Link: https://lore.kernel.org/r/20231207-mbly-uart-v6-8-e384afa5e78c@bootlin.com Signed-off-by:
-
Théo Lebrun authored
The whole function body is encapsulated inside an if-condition. Reverse the if logic and early return to remove one indentation level. Also turn two nested ifs into a single one at the end of the function. Reviewed-by:
-
Théo Lebrun authored
Fix the following messages from checkpatch: $ ./scripts/checkpatch.pl --strict --file \ drivers/tty/serial/amba-pl011.c ERROR: do not initialise statics to false WARNING: Possible unnecessary 'out of memory' message WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to CHECK: Prefer using the BIT macro Reviewed-by: -
Théo Lebrun authored
Fix the following checkpatch warnings & checks: $ ./scripts/checkpatch.pl --strict --file \ drivers/tty/serial/amba-pl011.c CHECK: Unbalanced braces around else statement CHECK: Unnecessary parentheses around '[...]' CHECK: braces {} should be used on all arms of this statement CHECK: Comparison to NULL could be written "[...]" WARNING: Comparisons should place the constant on the right side of the test Reviewed-by: -
Théo Lebrun authored
Remove all instances of quoted strings split across lines. Fix four checkpatch warnings: $ ./scripts/checkpatch.pl --strict --file \ drivers/tty/serial/amba-pl011.c WARNING: quoted string split across lines [...] Reviewed-by: -
Théo Lebrun authored
The driver uses two TIOCMBIT macros inside pl011_{get,set}_mctrl to simplify the logic. Those look scary to checkpatch because they contain ifs without do-while loops. Avoid the macros by creating small equivalent static functions; that lets the compiler do its type checking & avoids checkpatch errors. For the second instance __assign_bit is not usable because it deals with unsigned long pointers whereas we have an unsigned int in pl011_set_mctrl. This addresses the following checkpatch warnings: $ ./scripts/checkpatch.pl --strict --file \ drivers/tty/serial/amba-pl011.c ERROR: Macros starting with if should be enclosed by a do - while loop to avoid possible if/else logic defects CHECK: Macro argument 'uartbit' may be better as '(uartbit)' to avoid precedence issues ERROR: Macros starting with if should be enclosed by a do - while loop to avoid possible if/else logic defects CHECK: Macro argument 'tiocmbit' may be better as '(tiocmbit)' to avoid precedence issues Reviewed-by: -
Théo Lebrun authored
Follow recommandations from: $ ./scripts/checkpatch.pl --strict --file \ drivers/tty/serial/amba-pl011.c We fix 5 warnings and 48 checks, all related to whitespace. Culprits are: CHECK: Alignment should match open parenthesis CHECK: Blank lines aren't necessary after an open brace '{' CHECK: Lines should not end with a '(' CHECK: Please don't use multiple blank lines CHECK: Please use a blank line after function/struct/union/enum declarations CHECK: spaces preferred around that '/' (ctx:VxV) CHECK: spaces preferred around that '|' (ctx:VxV) WARNING: Missing a blank line after declarations WARNING: please, no spaces at the start of a line Signed-off-by: -
Théo Lebrun authored
The driver uses bit shifts and hexadecimal expressions to declare constants. Replace that with the BIT(), GENMASK() & FIELD_PREP_CONST() macros to clarify intent. include/linux/amba/serial.h gets included from arch/arm/include/debug/pl01x.S. Avoid includes and macro tricks for the four defines that are involved: UART01x_DR, UART01x_FR, UART01x_FR_TXFF and UART01x_FR_BUSY. Reviewed-by:
-
