public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: "Łukasz Czechowski" <lukasz.czechowski@thaumatec.com>,
	"Kever Yang" <kever.yang@rock-chips.com>
Cc: u-boot@lists.denx.de, trini@konsulko.com, sjg@chromium.org,
	philipp.tomsich@vrull.eu
Subject: Re: [PATCH v3 1/4] debug_uart: Replace debug functions with dummies if CONFIG_DEBUG_UART is not set
Date: Mon, 5 May 2025 15:53:23 +0200	[thread overview]
Message-ID: <c04069a9-0035-4fbb-a202-b477b495aa1e@cherry.de> (raw)
In-Reply-To: <51a9d783-6002-48b8-8565-b4e7fac8dc51@cherry.de>

Hi Łukasz,

On 1/17/25 5:18 PM, Quentin Schulz wrote:
> Hi Łukasz, Kever,
> 
> On 11/27/24 11:21 PM, Łukasz Czechowski wrote:
>> Hi Kever,
>>
>> On 2024/11/27 03:42 Kever Yang <kever.yang@rock-chips.com> wrote:
>>>
>>> Hi Lukasz,
>>>
>>>       I got a new error base on patch [1], see full log here [2].
>>
>> Looking at the file efi_stub.c that is used in the failing
>> configuration it looks to me
>> that some functions from debug_uart.h are used here for convenience
>> (i.e. printhex),
>> even though the DEBUG_UART is not used. This is contrary to my 
>> assumption that
>> DEBUG_UART_FUNCS macro should not be used if DEBUG UART is not available.
>> In order to apply the patch then, either the efi_stub code must be
>> updated to not
>> use debug functions or the assumption must be relaxed - I'm not yet
>> sure what shall be
>> the correct approach.
>>
> 
> """
> diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
> index 40fc29d9adf..5172cd78a7c 100644
> --- a/lib/efi/efi_stub.c
> +++ b/lib/efi/efi_stub.c
> @@ -83,12 +83,14 @@ void puts(const char *str)
>           putc(*str++);
>   }
> 
> +#ifdef CONFIG_DEBUG_UART
>   static void _debug_uart_putc(int ch)
>   {
>       putc(ch);
>   }
> 
>   DEBUG_UART_FUNCS
> +#endif
> 
>   void *memcpy(void *dest, const void *src, size_t size)
>   {
> """
> 
> Fixes it. It builds fine with and without CONFIG_DEBUG_UART set. Not 
> sure if it's proper but I guess that's fine?
> 
> While reading the patch again, I think we made a small oversight.
> 
> #define printhex8(value) do{}while(0);
> 
> is an issue because ch may actually have side effects.
> 
> Take for example an interrupt register where reading is acknowledging, 
> if one does:
> 
> printhex8(readl(INT_REG))
> 
> will read the register when CONFIG_DEBUG_UART is set, but not when it's 
> not.
> 
> I am not sure if and how we can handle that so that things are executed 
> but only print is not called. Is this something we should care about?
> 

Can you send a v4 that fixes that? I'm planning on having a release on 
the upcoming v2025.07 for our devices, so maybe you'll want to rebase 
for your client's product too? I'm pretty sure your client will not be 
the only one who doesn't want anything on UART in U-Boot on Rockchip :)

Cheers,
Quentin

  reply	other threads:[~2025-05-05 13:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-18 13:01 [PATCH v3 0/4] Rockchip: Allow to silent TPL/SPL debug console Lukasz Czechowski
2024-09-18 13:01 ` [PATCH v3 1/4] debug_uart: Replace debug functions with dummies if CONFIG_DEBUG_UART is not set Lukasz Czechowski
2024-09-29  1:53   ` Kever Yang
2024-09-30  8:55     ` Quentin Schulz
2024-10-25 12:30       ` Kever Yang
2024-10-25 14:13         ` Tom Rini
2024-10-25 14:27         ` Łukasz Czechowski
2024-10-25 14:56           ` Quentin Schulz
2024-10-31  9:01             ` Kever Yang
2024-11-08  9:33               ` Kever Yang
2024-11-08 20:38                 ` Łukasz Czechowski
2024-11-27  2:41   ` Kever Yang
2024-11-27 22:21     ` Łukasz Czechowski
2025-01-17 16:18       ` Quentin Schulz
2025-05-05 13:53         ` Quentin Schulz [this message]
2024-09-18 13:01 ` [PATCH v3 2/4] ram: rockchip: Fix dependency of RAM_ROCKCHIP_DEBUG Lukasz Czechowski
2024-09-18 13:01 ` [PATCH v3 3/4] rockchip: px30: Weaken dependency TPL/SPL serial Lukasz Czechowski
2024-09-18 13:01 ` [PATCH v3 4/4] rockchip: px30: Fix hard dependency to DEBUG_UART_BOARD_INIT Lukasz Czechowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c04069a9-0035-4fbb-a202-b477b495aa1e@cherry.de \
    --to=quentin.schulz@cherry.de \
    --cc=kever.yang@rock-chips.com \
    --cc=lukasz.czechowski@thaumatec.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox