- 25 Nov, 2023 6 commits
-
-
Tony Lindgren authored
Let's move tty and serdev controller to be children of the serial core port device. This way the runtime PM usage count of a child device propagates to the serial hardware device. The tty and serdev devices are associated with a specific serial port of a serial hardware controller device, and we now have serial core hierarchy of controllers and ports. The tty device moves happily with just a change of the parent device and update of device_find_child() handling. The serdev device init needs some changes to separate the serial hardware controller device from the parent device. With this change the tty devices move under sysfs similar to this x86_64 qemu example of a diff of "find /sys -name ttyS*": /sys/class/tty/ttyS0 /sys/class/tty/ttyS3 /sys/class/tty/ttyS1 -/sys/devices/pnp0/00:04/tty/ttyS0 -/sys/devices/platform/serial8250/tty/ttyS2 -/sys/devices/platform/serial8250/tty/ttyS3 -/sys/devices/platform/serial8250/tty/ttyS1 +/sys/devices/pnp0/00:04/00:04:0/00:04:0.0/tty/ttyS0 +/sys/devices/platform/serial8250/serial8250:0/serial8250:0.3/tty/ttyS3 +/sys/devices/platform/serial8250/serial8250:0/serial8250:0.1/tty/ttyS1 +/sys/devices/platform/serial8250/serial8250:0/serial8250:0.2/tty/ttyS2 If a serdev device is used instead of a tty, it moves in a similar way. Suggested-by:
Johan Hovold <johan@kernel.org> Cc: Maximilian Luz <luzmaximilian@gmail.com> Cc: Rob Herring <robh@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231113080758.30346-1-tony@atomide.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomas Mudrunka authored
This way we can do: `echo _reisub > /proc/sysrq-trigger` Instead of: `for i in r e i s u b; do echo "$i" > /proc/sysrq-trigger; done;` This can be very useful when trying to execute sysrq combo remotely or from userspace. When sending keys in multiple separate writes, userspace (eg. bash or ssh) can be killed before whole combo is completed. Therefore putting all keys in single write is more robust approach. Signed-off-by:
Tomas Mudrunka <tomas.mudrunka@gmail.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20231120111451.527952-1-tomas.mudrunka@gmail.comSigned-off-by:
-
Manikanta Guntupalli authored
Device number 204 has a range of minors on major number. uart_register_driver is failing due to lack of minor numbers when more number of uart ports used. So, to avoid minor number limitation on 204 major number use dynamic major allocation when more than 4 uart ports used otherwise use static major allocation. https://docs.kernel.org/arch/arm/sa1100/serial_uart.htmlSigned-off-by:
Manikanta Guntupalli <manikanta.guntupalli@amd.com> Link: https://lore.kernel.org/r/20231116134003.3762725-3-manikanta.guntupalli@amd.comSigned-off-by:
-
Manikanta Guntupalli authored
Describe when uartlite driver uses static/dynamic allocation for major number based on maximum number of uartlite serial ports. Signed-off-by:
-
Philipp Stanner authored
tty/vt currently uses memdup_user() and vmemdup_array_user() to copy userspace arrays. Whereas there is no danger of overflowing, the call to vmemdup_user() currently utilizes array_size() to calculate the array size nevertheless. This is not useful because array_size() would return SIZE_MAX and pass it to vmemdup_user() in case of (the impossible) overflow. string.h from the core-API now provides the wrappers memdup_array_user() and vmemdup_array_user() to copy userspace arrays in a standardized manner. Additionally, they also perform generic overflow-checks. Use these wrappers to make it more obvious and readable that arrays are being copied. As we are at it, remove two unnecessary empty lines. Suggested-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Philipp Stanner <pstanner@redhat.com> Link: https://lore.kernel.org/r/20231103111207.74621-2-pstanner@redhat.comSigned-off-by:
-
Uwe Kleine-König authored
Since the driver was converted to use .remove_new() the return function doesn't return a value any more. So remove the obsolete documentation about the return value. Reported-by:
Michal Simek <michal.simek@amd.com> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
-
- 23 Nov, 2023 34 commits
-
-
Chester Lin authored
I am leaving SUSE so the current email address <clin@suse.com> will be disabled soon. <chester62515@gmail.com> will be my new address for handling emails, patches and pull requests from upstream and communities. Cc: Chester Lin <chester62515@gmail.com> Cc: NXP S32 Linux Team <s32@nxp.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Conor Dooley <conor+dt@kernel.org> Signed-off-by:
Chester Lin <clin@suse.com> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231115235732.13633-1-clin@suse.comSigned-off-by:
-
Christophe JAILLET authored
dma_request_slave_channel() is deprecated. dma_request_chan() should be used directly instead. Switch to the preferred function and update the error handling accordingly. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/d6773b9bd88dbbbea06bc6d5cd59aa117b1ee2ee.1700416841.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
dma_request_slave_channel() is deprecated. dma_request_chan() should be used directly instead. Switch to the preferred function and update the error handling accordingly. Signed-off-by:
-
Christophe JAILLET authored
dma_request_slave_channel() is deprecated. dma_request_chan() should be used directly instead. Switch to the preferred function and update the error handling accordingly. Signed-off-by:
-
Christophe JAILLET authored
dma_request_slave_channel() is deprecated. dma_request_chan() should be used directly instead. Switch to the preferred function and update the error handling accordingly. Signed-off-by:
-
Christophe JAILLET authored
dma_request_slave_channel() is deprecated. dma_request_chan() should be used directly instead. Switch to the preferred function and update the error handling accordingly. Signed-off-by:
-
Hugo Villeneuve authored
With this current driver regmap implementation, it is hard to make sense of the register addresses displayed using the regmap debugfs interface, because they do not correspond to the actual register addresses documented in the datasheet. For example, register 1 is displayed as registers 04 thru 07: $ cat /sys/kernel/debug/regmap/spi0.0/registers 04: 10 -> Port 0, register offset 1 05: 10 -> Port 1, register offset 1 06: 00 -> Port 2, register offset 1 -> invalid 07: 00 -> port 3, register offset 1 -> invalid ... The reason is that bits 0 and 1 of the register address correspond to the channel (port) bits, so the register address itself starts at bit 2, and we must 'mentally' shift each register address by 2 bits to get its real address/offset. Also, only channels 0 and 1 are supported by the chip, so channel mask combinations of 10b and 11b are invalid, and the display of these registers is useless. This patch adds a separate regmap configuration for each port, similar to what is done in the max310x driver, so that register addresses displayed match the register addresses in the chip datasheet. Also, each port now has its own debugfs entry. Example with new regmap implementation: $ cat /sys/kernel/debug/regmap/spi0.0-port0/registers 1: 10 2: 01 3: 00 ... $ cat /sys/kernel/debug/regmap/spi0.0-port1/registers 1: 10 2: 01 3: 00 As an added bonus, this also simplifies some operations (read/write/modify) because it is no longer necessary to manually shift register addresses. Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231030211447.974779-1-hugo@hugovil.comSigned-off-by:
-
Hugo Villeneuve authored
Fix coding style. No functional changes. Signed-off-by:
-
Samuel Holland authored
They are only used within this file, so they should have static linkage. Signed-off-by:
Samuel Holland <samuel.holland@sifive.com> Link: https://lore.kernel.org/r/20231113023122.1185407-1-samuel.holland@sifive.comSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Link: https://lore.kernel.org/r/20231105214406.3765906-6-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The function hvc_remove() returns zero unconditionally. Make it return void instead to make it obvious that the caller doesn't need to do any error handling. Accordingly drop the error handling from hvc_opal_remove(). Signed-off-by:
-
Lad Prabhakar authored
The SCI block on the RZ/Five SoC is identical to one found on the RZ/G2UL SoC. "renesas,r9a07g043-sci" compatible string will be used on the RZ/Five SoC so to make this clear and to keep this file consistent, update the comment to include RZ/Five SoC. No driver changes are required as generic compatible string "renesas,sci" will be used as a fallback on RZ/Five SoC. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20231115212431.32872-1-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Sean Anderson authored
Use @ and - to conform with kernel-doc style. Reported-by:
kernel test robot <yujie.liu@intel.com> Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Link: https://lore.kernel.org/r/20231106152428.3641883-1-sean.anderson@seco.comSigned-off-by:
-
Jiri Slaby (SUSE) authored
clang-struct [1] found struct serial_cfg_mem's members unused. In fact, the whole structure is unused since commit 6ae3b84d ("serial_cs: use pcmcia_loop_config() and pre-determined values"). Drop it completely. [1] https://github.com/jirislaby/clang-structSigned-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231121103626.17772-7-jirislaby@kernel.orgSigned-off-by:
-
Jiri Slaby (SUSE) authored
clang-struct [1] found rp2_uart_port::ignore_rx unused. It was actually never used. Not even in introductory commit 7d9f49af ("serial: rp2: New driver for Comtrol RocketPort 2 cards"). [1] https://github.com/jirislaby/clang-structSigned-off-by:
-
Jiri Slaby (SUSE) authored
clang-struct [1] found jsm_board::type and ::jsm_board_entry unused. ::jsm_board_entry is unused since 614a7d6a ("fix up newly added jsm driver") ::type was never used as far as I can tell. Even when the driver was introduced in the pre-git era. Remove them both. [1] https://github.com/jirislaby/clang-structSigned-off-by:
-
Jiri Slaby (SUSE) authored
clang-struct [1] found board_ops::get_uart_bytes_left() and ::send_immediate_char() unused. Both are only set but never called. And it has been like that since the git history, so drop both the members along with the cls+neo implementations. [1] https://github.com/jirislaby/clang-structSigned-off-by:
-
Jiri Slaby (SUSE) authored
clang-struct [1] found ipw_dev::attribute_memory unused. As far as I can see it was never used since the driver merge. Drop it. [1] https://github.com/jirislaby/clang-structSigned-off-by:
David Sterba <dsterba@suse.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Reviewed-by:
-
Jiri Slaby (SUSE) authored
clang-struct [1] found raw3215_info::ubuffer unused. It's actually not used since 2004 when we switched to kernel buffers. [1] https://github.com/jirislaby/clang-structSigned-off-by:
Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lore.kernel.org/r/20231110152927.70601-41-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
