- 01 Sep, 2022 4 commits
-
-
Daniel Vetter authored
I'm scratching my head why we have this printing_lock. Digging through historical git trees shows that: - Added in 1.1.73, and I found absolutely no reason why. - Converted to atomic bitops in 2.1.125pre2, I guess as part of SMP enabling/bugfixes. - Converted to a proper spinlock in b0940003 ("vt: bitlock fix") because the hand-rolled atomic version lacked necessary memory barriers. Digging around in lore for that time period did also not shed further light. The only reason I think this might still be relevant today is that (to my understanding at least, ymmv) during an oops we might be printing without console_lock held. See console_flush_on_panic() and the comments in there - we flush out the console buffers irrespective of whether we managed to acquire the right locks. The strange thing is that this reason is fairly recent, because the console flushing was historically done without oops_in_progress set. This only changed in c7c3f05e ("panic: avoid deadlocks in re-entrant console drivers"), which removed the call to bust_spinlocks(0) (which decrements oops_in_progress again) before flushing out the console (which back then was open coded as a console_trylock/unlock pair). Note that this entire mess should be properly fixed in the printk/console layer, and not inflicted on each implementation. For now just document what's going on and check that in all other cases callers obey the locking rules. v2: WARN_CONSOLE_UNLOCKED already checks for oops_in_progress (something else that should be fixed I guess), hence remove the open-coded check I've had. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Xuezhi Zhang <zhangxuezhi1@coolpad.com> Cc: Yangxi Xiang <xyangxi5@gmail.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: nick black <dankamongmen@gmail.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: John Ogness <john.ogness@linutronix.de> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://lore.kernel.org/r/20220830144945.430528-1-daniel.vetter@ffwll.chSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Vetter authored
console_unblank() does this too (called in both places right after), and with a lot more confidence inspiring approach to locking. Reconstructing this story is very strange: In b61312d3 ("oops handling: ensure that any oops is flushed to the mtdoops console") it is claimed that a printk(" "); flushed out the console buffer, which was removed in e3e8a75d ("[PATCH] Extract and use wake_up_klogd()"). In todays kernels this is done way earlier in console_flush_on_panic with some really nasty tricks. I didn't bother to fully reconstruct this all, least because the call to bust_spinlock(0); gets moved every few years, depending upon how the wind blows (or well, who screamed loudest about the various issue each call site caused). Before that commit the only calls to console_unblank() where in s390 arch code. The other side here is the console->unblank callback, which was introduced in 2.1.31 for the vt driver. Which predates the console_unblank() function by a lot, which was added (without users) in 2.4.14.3. So pretty much impossible to guess at any motivation here. Also afaict the vt driver is the only (and always was the only) console driver implementing the unblank callback, so no idea why a call to console_unblank() was added for the mtdooops driver - the action actually flushing out the console buffers is done from console_unlock() only. Note that as prep for the s390 users the locking was adjusted in 2.5.22 (I couldn't figure out how to properly reference the BK commit from the historical git trees) from a normal semaphore to a trylock. Note that a copy of the direct unblank_screen() call was added to panic() in c7c3f05e ("panic: avoid deadlocks in re-entrant console drivers"), which partially inlined the bust_spinlocks(0); call. Long story short, I have no idea why the direct call to unblank_screen survived for so long (the infrastructure to do it properly existed for years), nor why it wasn't removed when the console_unblank() call was finally added. But it makes a ton more sense to finally do that than not - it's just better encapsulation to go through the console functions instead of doing a direct call, so let's dare. Plus it really does not make much sense to call the only unblank implementation there is twice, once without, and once with appropriate locking. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Xuezhi Zhang <zhangxuezhi1@coolpad.com> Cc: Yangxi Xiang <xyangxi5@gmail.com> Cc: nick black <dankamongmen@gmail.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com> Cc: Marco Elver <elver@google.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: David Gow <davidgow@google.com> Cc: tangmeng <tangmeng@uniontech.com> Cc: Tiezhu Yang <yangtiezhu@loongson.cn> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Petr Mladek <pmladek@suse.com> Acked-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Link: https://lore.kernel.org/r/20220830145004.430545-1-daniel.vetter@ffwll.chSigned-off-by:
-
Shaomin Deng authored
Fix double word "start start" in comments. Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Link: https://lore.kernel.org/r/20220831160934.7986-1-dengshaomin@cdjrlc.comSigned-off-by:
-
Andy Shevchenko authored
The UAPI serial_core.h is guaranteed to be included by in-kernel one (with the same name). Individual drivers do not need to include it explicitly. Remove it from the driver. Note, it's a single driver in the entire kernel that does this. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220830152313.14650-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
- 30 Aug, 2022 36 commits
-
-
Ilpo Järvinen authored
The number of bits can be calculated using tty_get_frame_size(), no need for the driver to do it on its own. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220830084925.5608-6-ilpo.jarvinen@linux.intel.comSigned-off-by:
-
Ilpo Järvinen authored
The driver features a custom frame length calculation but the result is never used. Remove it. Reviewed-by:
-
Ilpo Järvinen authored
The number of bits can be calculated using tty_get_frame_size(), no need for the driver to do it on its own. Change bits to unsigned and baud too since we're touching the declarations line anyway (the respective core functions are typed unsigned). Reviewed-by:
-
Ilpo Järvinen authored
The number of bits can be calculated using helpers in core, no need for the driver to do it on its own. The mode register is programmed with frame bits minus 1, rearrange the comments related to that "feature" closer to the actual write. Reviewed-by:
-
Ilpo Järvinen authored
The number of bits can be calculated using tty_get_frame_size(), no need for the driver to do it on its own. Also remove a comment on number of bits that doesn't match the code nor the comment on ucc_uart_pram's rx_length ("minus 1" part differs). That comment seems a verbatim copy of that in cpm_uart/cpm_uart_core.c anyway so perhaps it was just copied over w/o much thinking. Reviewed-by: -
Al Viro authored
that's the only one outside of include/uapi/linux/termios.h and it's not even needed there - we have linux/tty.h already pulled and that pulls linux/termios.h Normally I would not consider that a sufficient reason, but there's a plenty of linux/tty.h users, and this is the only one that follows that with asm/termios.h. The situation with termios.h is genuinely convoluted, and this complicates it for no good reason. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20220821010239.1554132-2-viro@zeniv.linux.org.ukSigned-off-by:
-
Al Viro authored
not really needed - UAPI mandatory-y += termios.h is sufficient... Signed-off-by:
Huacai Chen <chenhuacai@kernel.org> Link: https://lore.kernel.org/r/20220821010239.1554132-1-viro@zeniv.linux.org.ukSigned-off-by:
-
Ilpo Järvinen authored
Testing also CIRC_CNT() with CIRC_CNT_TO_END() is unnecessary because to latter alone covers all necessary cases. Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Ilpo Järvinen authored
There is no need to and tail with UART_XMIT_SIZE - 1 because tail is already on valid range. Reviewed-by:
-
Ilpo Järvinen authored
Testing also CIRC_CNT() with CIRC_CNT_TO_END() is unnecessary because to latter alone covers all necessary cases. Reviewed-by:
-
Ilpo Järvinen authored
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by:
-
Ilpo Järvinen authored
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by:
-
Ilpo Järvinen authored
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by:
-
Ilpo Järvinen authored
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by:
-
Ilpo Järvinen authored
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by:
-
Ilpo Järvinen authored
Assume previously used termios has a valid baudrate and use it directly. Reviewed-by:
Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by:
-
Ilpo Järvinen authored
Add proper spacing to comment. Reviewed-by:
-
Ilpo Järvinen authored
With the architectures currently in-tree, either: 1) CBAUDEX is zero 2) The earlier BOTHER if check covers cbaud < 1 case 3) All CBAUD bits are covered by the baud_table Thus, the check for cbaud being out-of-range for CBAUDEX case cannot ever be true. The ktermios parameters can now be made const. Reviewed-by:
-
Wolfram Sang authored
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20220818210113.7469-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Rob Herring authored
Some Samsung UARTs are in a power domain, so allow 'power-domains' property. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220823145649.3118479-1-robh@kernel.orgSigned-off-by:
-
Lad Prabhakar authored
The SCIF block on the RZ/Five SoC is identical to one found on the RZ/G2UL SoC. "renesas,scif-r9a07g043" compatible string will be used on the RZ/Five SoC so to make this clear, update the comment to include RZ/Five SoC. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220726174929.950-1-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Daniel Vetter authored
Every since the 0.99.7A release when console_register() was introduced it's become impossible to call vt_console_print (called console_print() back then still) directly. Which means the initialization issue this variable protected against is no more. Give it a send off with style and let it rest in peace. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> Cc: nick black <dankamongmen@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Yangxi Xiang <xyangxi5@gmail.com> Cc: Xuezhi Zhang <zhangxuezhi1@coolpad.com> Reviewed-by:
-
Krzysztof Kozlowski authored
reg-io-width is a standard property, so no need for defining its type Acked-by:
-
Christophe JAILLET authored
The devm_clk_get_enabled() helper: - calls devm_clk_get() - calls clk_prepare_enable() and registers what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code, the error handling paths and avoid the need of a dedicated function used with devm_add_action_or_reset(). That said, meson_uart_probe_clock() is now more or less the same as devm_clk_get_enabled(), so use this function directly instead. This also fixes an (unlikely) unchecked devm_add_action_or_reset() error. Based on my test with allyesconfig, this reduces the .o size from: text data bss dec hex filename 16350 5016 128 21494 53f6 drivers/tty/serial/meson_uart.o down to: 15415 4784 128 20327 4f67 drivers/tty/serial/meson_uart.o Reviewed-by:Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3f18638cb3cf08ed8817addca1402ed5e3bd3602.1661328361.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Ilpo Järvinen authored
No need to check non-zeroness first and then clear. Just set to zero unconditionally. Acked-by:
-
Ilpo Järvinen authored
A number of places want to clear IER with the same CAP_UUE trick. Create a helper for that. Reviewed-by:
-
Jindong Yue authored
Remove the limitation of SERIAL_FSL_LPUART=y, as we may need enable this console while SERIAL_FSL_LPUART=m. Signed-off-by:
Jindong Yue <jindong.yue@nxp.com> Signed-off-by:
Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20220802101613.30879-1-sherry.sun@nxp.comSigned-off-by:
-
Andy Shevchenko authored
Plain global GPIO numbering schema is deprecated and is being removed from the kernel. Convert this driver to use a new GPIO descriptor based schema. Signed-off-by:
-
Andy Shevchenko authored
The serial core already provides a helper to check if the given port is an enabled console. Utilize it instead of open coded variant. Reviewed-by:
-
Jason Wang authored
The double `as' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20220803104208.4127-1-wangborong@cdjrlc.comSigned-off-by:
-
Shubhrajyoti Datta authored
Some of the implementations can read only 32 bits because of the interface limitations of the port they are connected to. Add a parameter reg-io-width for supporting such platforms. Reviewed-by:
Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Link: https://lore.kernel.org/r/20220826120559.2122-3-shubhrajyoti.datta@amd.comSigned-off-by:
-
Shubhrajyoti Datta authored
Some of the implementations support only 32-bit accesses. Add a parameter reg-io-width for such platforms. Reviewed-by:
-
Shubhrajyoti Datta authored
Check the clk_enable return value. If clocks are not enabled the register accesses could hang the system so error out instead. Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20220729114748.18332-8-shubhrajyoti.datta@xilinx.comSigned-off-by:
-
Shubhrajyoti Datta authored
There is a potential infinite loop while waiting for the the TXFULL to deassert. Adds the error message and timeout to avoid infinite loop if it fails to get the TX fifo not full. Signed-off-by:
-
Shubhrajyoti Datta authored
Prevent writing to the fifo if the controller is disabled. Signed-off-by:
-
Shubhrajyoti Datta authored
Currently the ignore_status is not considered in the isr. Add a check to add the ignore_status. Fixes: 61ec9016 ("tty/serial: add support for Xilinx PS UART") Signed-off-by:
-
