Hi Julien, On Fri, 7 Aug 2026 at 09:33, Julien Stephan <[email protected]> wrote: > > Le jeu. 6 août 2026 à 19:01, Simon Glass <[email protected]> a écrit : > > > > Hi Julien, > > > > On 2026-08-06T13:05:19, Julien Stephan <[email protected]> wrote: > > > dm: improve logging for missing uclass > > > > > > When a uclass definition is missing for an enabled driver, the board > > > cannot boot, and without any extra debug option enabled the following > > > error is displayed: > > > > > > initcall_run_r(): initcall initr_dm() failed ### ERROR ### Please > > > RESET the board ### > > > > > > There is a debug message using dm_warn(), which is not displayed by > > > default. Since this is a fatal error preventing the board from booting, > > > the log level should be at least ERROR. > > > > > > Signed-off-by: Julien Stephan <[email protected]> > > > > > > drivers/core/uclass.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c > > > @@ -60,8 +60,9 @@ static int uclass_add(enum uclass_id id, struct uclass > > > **ucp) > > > *ucp = NULL; > > > uc_drv = lists_uclass_lookup(id); > > > if (!uc_drv) { > > > - dm_warn("Cannot find uclass for id %d: please add the > > > UCLASS_DRIVER() declaration for this UCLASS_... id\n", > > > - id); > > > + log(LOGC_DM, LOGL_ERR, > > > + "Cannot find uclass for id %d: please add the > > > UCLASS_DRIVER() declaration for this UCLASS_... id\n", > > > + id); > > > > This file sets LOG_CATEGORY to LOGC_DM at the top, so log_err() would > > be cleaner: > > > > log_err("Cannot find uclass for id %d: please add the > > UCLASS_DRIVER() declaration for this UCLASS_... id\n", > > id); > > > > The idea with this was that by returning -EPFNOSUPPORT (unused > > elsewhere in U-Boot (he says...)) it would indicate this problem, > > without bloating the code with a large message. This code is used in > > SPL where code size is at a premium. I don't see the error number > > though, which I added here: > > > > 13123276806 initcall: Adjust the failure message and return value > > > > Hmm yes it was dropped in the initcall move back to the header file. > > > > We already have DM_WARN to help people with debugging, so perhaps > > instead we should just enable that by default in U-Boot proper? > > > > Hi Simon, > > I didn't think about the impact on SPL. I understand your point, but I > do feel a fatal error deserves a proper message. > > So what about reducing this long message to something shorter, using > log_err() as you suggested: > > log_err("uclass %d: no UCLASS_DRIVER()\n", id); > > That keeps a readable, greppable hint while cutting most of the SPL > size overhead. > > I didn't audit all the dm_warn() callers, but enabling DM_WARN by > default feels overkill. I suspect several of them are > genuinely non-fatal warnings. > > Otherwise, we could just drop this patch, since patch 2 now prints the > -EPFNOSUPPORT value on failure. > > What do you think?
I tend to agree that a message would be better. But any SPL growth is painful...perhaps we could have a Kconfig to control just this case (default y in TPL/SPL/Proper) so people can turn it off for production? Regards, SImon
