- 28 Nov, 2023 5 commits
-
-
Jiri Slaby (SUSE) authored
'str_cr' contains a single character: \r. There is no need to declare it as array. Instead, pass the character (as a string) to callback_puts() directly. This ensures the string is in proper .rodata (const) section and makes the code more obvious. Signed-off-by:
"Jiri Slaby (SUSE)" <jirislaby@kernel.org> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: linux-alpha@vger.kernel.org Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231127123713.14504-5-jirislaby@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby (SUSE) authored
'need_cr' is a flag, so type it properly to be a 'bool'. Move the declaration into the loop too. That ensures the variable is initialized properly even if the code was moved somehow. Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: linux-alpha@vger.kernel.org Reviewed-by:
-
Jiri Slaby (SUSE) authored
Similarly to 'buf' in the previous patch, there is no need to have a separate counter ('remaining') in srmcons_do_write(). 'count' can be used directly which simplifies the code a bit. Note that the type of the current count ('c') is changed from 'long' to 'size_t' so that: 1) it is prepared for the upcoming change of 'count's type, and 2) is unsigned. Signed-off-by: -
Jiri Slaby (SUSE) authored
The return value of srmcons_do_write() is ignored as all characters are pushed. So make srmcons_do_write() to return void. Signed-off-by:
-
Jiri Slaby (SUSE) authored
After commit 87888fb9 ("tty: Remove baudrate dead code & make ktermios params const"), the 'tty' parameter is only read in tty_get_baud_rate(). Therefore, we can make 'tty' accepted in the function 'const' for clarity. The "the terminal bit flags may be updated." part of the tty_get_baud_rate()'s kernel-doc is dropped as it is no longer true. Because of the same commit above. And it was misplaced anyway. Signed-off-by:
-
- 25 Nov, 2023 22 commits
-
-
Jiri Slaby (SUSE) authored
There is no need to have a separate iterator ('cur') through 'buf' in srmcons_do_write(). 'buf' can be used directly which simplifies the code a bit. Signed-off-by: -
Jiri Slaby (SUSE) authored
DUMP()'s only use is commented out. Remove the macro completely along with this unused use. Signed-off-by:
-
Jiri Slaby (SUSE) authored
This means: * move outbuf to the end of struct hvc_struct and convert from pointer to flexible array (the structure is smaller now) * use struct_size() at the allocation site * align outbuf in the struct instead of ALIGN() at kzalloc() And apart from the above, use u8 instead of char (which are the same thanks to -funsigned-char). The former is now preferred over the latter. It makes the code easier to understand. Signed-off-by:
-
Jiri Slaby (SUSE) authored
'serial_table' is global, so there is no need to initialize it to NULLs at the module load. Drop this unneeded for loop. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231121092258.9334-11-jirislaby@kernel.orgSigned-off-by:
-
Jiri Slaby (SUSE) authored
It's preferred NOT to emit anything during the module load and unload (in case the un/load was successful). So drop these prints from hso along with global 'version'. It even contains no version after all. Signed-off-by:
-
Jiri Slaby (SUSE) authored
We can pass 'buf' directly to goldfish_tty_rw() using simple (unsigned long) cast. There is no need to obfuscate the code by another variable with double casts. Signed-off-by:
-
Jiri Slaby (SUSE) authored
There is a helper for memcpy(buffer)+memset(the_rest). Use it for simplicity. And add a comment why we are doing the copy in the first place. Signed-off-by:
-
Jiri Slaby (SUSE) authored
'oe' is a yes-no flag, switch it to boolean. And rename to overrun. All for the code to be more obvious. Signed-off-by:
-
Jiri Slaby (SUSE) authored
The 'out' label is just before 'return'. So return immediately and drop both the label and the return. This makes the code more straightforward. Signed-off-by:
-
Jiri Slaby (SUSE) authored
Both tty_kref_get() and tty_get_baud_rate() note about locking in their Return kernel-doc clause. Extract this info into a separate "Locking" paragraph -- the same as we do for other tty functions. Signed-off-by:
-
Jiri Slaby (SUSE) authored
'mbz' in tiocsti() is used only to pass TTY_NORMAL to tty_ldisc_ops::receive_buf(). But that can be achieved easier by simply passing NULL to ::receive_buf(). So drop this 'mbz'. Signed-off-by:
-
Jiri Slaby (SUSE) authored
tty_write_message() has only one user: quotas. In particular, there the use depends on CONFIG_PRINT_QUOTA_WARNING. And that is deprecated and marked as BROKEN already too. So make tty_write_message() dependent on that very config option. This action in fact drops tty_write_message() from the vmlinux binary. Good riddance. Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20231121092258.9334-2-jirislaby@kernel.orgSigned-off-by:
-
Jiri Slaby (SUSE) authored
Commits 95713967 ("tty: make tty_operations::write()'s count size_t") and dcaafbe6 ("tty: propagate u8 data to tty_operations::put_char()") changed types of characters to u8, but omitted to fix the documentation. Fix the latter now. Signed-off-by:
-
Hugo Villeneuve authored
The comment wording can be confusing, as txlen will return the number of bytes available in the FIFO, which can be less than the maximum theoretical Tx FIFO size. Change the comment so that it is unambiguous. Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231122175957.3875102-1-hugo@hugovil.comSigned-off-by:
-
Hugo Villeneuve authored
The comment wording can be confusing, as txlen will return the number of bytes available in the FIFO, which can be less than the maximum theoretical Tx FIFO size. Change the comment so that it is unambiguous. Signed-off-by:
-
Tony Lindgren authored
This reverts commit 81a61051. With tty and serdev controller moved to be children of the serial core port device, runtime PM usage count of the serdev controller now propagates to the serial hardware controller parent device as expected. Cc: Maximilian Luz <luzmaximilian@gmail.com> Cc: Rob Herring <robh@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231113080758.30346-2-tony@atomide.comSigned-off-by:
-
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:
-
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:
-
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 13 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 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:
-
