It is allowed for consoles to provide no write() callback. For
example ttynull does this.

Check if a write() callback is available before using it.

Signed-off-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 kernel/debug/kdb/kdb_io.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 5c7e9ba7cd6b..e9139dfc1f0a 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -576,6 +576,8 @@ static void kdb_msg_write(const char *msg, int msg_len)
 			continue;
 		if (c == dbg_io_ops->cons)
 			continue;
+		if (!c->write)
+			continue;
 		/*
 		 * Set oops_in_progress to encourage the console drivers to
 		 * disregard their internal spin locks: in the current calling
-- 
2.30.2

On (23/07/10 15:51), John Ogness wrote:
> It is allowed for consoles to provide no write() callback. For
> example ttynull does this.
> 
> Check if a write() callback is available before using it.
> 
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>

On Mon, Jul 10, 2023 at 03:51:20PM +0206, John Ogness wrote:
> It is allowed for consoles to provide no write() callback. For
> example ttynull does this.
>
> Check if a write() callback is available before using it.
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

For v1 I shared an ack rather than queuing the patch. Although reading
the thread back it is possible that was based on a misunderstanding
(https://lore.kernel.org/lkml/20230309113020.GA78621@aspen.lan/ ).

Anyhow, it looks like you have designed the new series to be picked
individually?


Daniel.

On 2023-07-11, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> For v1 I shared an ack rather than queuing the patch. Although reading
> the thread back it is possible that was based on a misunderstanding
> (https://lore.kernel.org/lkml/20230309113020.GA78621@aspen.lan/ ).
>
> Anyhow, it looks like you have designed the new series to be picked
> individually?

I understood that Petr will carry the patch. Yes, this series only
includes the non-atomic/non-threaded cleanups so that it will be easier
for Petr to send the full series off to linux-next.

For this patch there is nothing left to do. I should have removed the
kdb people/lists from the mailing. Sorry about that.

John Ogness

On Tue, Jul 11, 2023 at 11:04:11AM +0206, John Ogness wrote:
> On 2023-07-11, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> > For v1 I shared an ack rather than queuing the patch. Although reading
> > the thread back it is possible that was based on a misunderstanding
> > (https://lore.kernel.org/lkml/20230309113020.GA78621@aspen.lan/ ).
> >
> > Anyhow, it looks like you have designed the new series to be picked
> > individually?
>
> I understood that Petr will carry the patch. Yes, this series only
> includes the non-atomic/non-threaded cleanups so that it will be easier
> for Petr to send the full series off to linux-next.

No worries, that's fine for me and from my point-of-view its still:
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>


> For this patch there is nothing left to do. I should have removed the
> kdb people/lists from the mailing. Sorry about that.

To be honest I'd rather be in the loop than out (and with that title my
mail filters would jump in it anyway).


Daniel.