public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Dragan Simic <dsimic@manjaro.org>
To: Tom Rini <trini@konsulko.com>
Cc: Caleb Connolly <caleb.connolly@linaro.org>,
	Mark Kettenis <kettenis@openbsd.org>,
	u-boot@lists.denx.de
Subject: Re: [PATCH] iommu: dont fail silently
Date: Fri, 05 Jan 2024 18:52:35 +0100	[thread overview]
Message-ID: <eeef8ebfe876d4b36470456196d73a50@manjaro.org> (raw)
In-Reply-To: <20240105175009.GW1610741@bill-the-cat>

On 2024-01-05 18:50, Tom Rini wrote:
> On Fri, Jan 05, 2024 at 05:48:58PM +0100, Dragan Simic wrote:
>> On 2024-01-05 17:09, Caleb Connolly wrote:
>> > On 05/01/2024 14:47, Dragan Simic wrote:
>> > > On 2024-01-05 14:55, Caleb Connolly wrote:
>> > > > On 04/01/2024 17:47, Dragan Simic wrote:
>> > > > > On 2024-01-04 18:12, Caleb Connolly wrote:
>> > > > > > When attempting to probe a device which has an
>> > > > > > associated IOMMU, if the
>> > > > > > IOMMU device can't be found (no driver, disabled driver,
>> > > > > > driver failed
>> > > > > > to probe, etc) then we currently fail to probe the device with no
>> > > > > > discernable error.
>> > > > > >
>> > > > > > If we fail to hook the device up to its IOMMU, we should
>> > > > > > make sure that
>> > > > > > the user knows about it. Write some better error messages for
>> > > > > > dev_iommu_enable() to facilitate this.
>> > > > >
>> > > > > Quite frankly, I think those should remain as debug-only
>> > > > > error messages,
>> > > > > but of course with the additional details you added.  The reasoning
>> > > > > behind it would be to use debug builds while testing, to be
>> > > > > able to see
>> > > > > any error messages, and then use production, size-optimized builds
>> > > > > later.  I hope you agree.
>> > > > >
>> > > > > There are many other places where using log messages instead
>> > > > > of debug
>> > > > > messages would be really useful in the field, such as in the MMC
>> > > > > drivers, but we'd quickly start increasing the image sizes
>> > > > > if we start
>> > > > > converting those from debug to log messages.
>> > > >
>> > > > The problem is that with a debug build there are SO MANY
>> > > > messages, it's
>> > > > hard to spot actual errors in the midst of the other stuff. I would
>> > > > rather see some actual numbers to justify breaking ease-of-use
>> > > > like this.
>> > >
>> > > As a reminder, debugging can be enabled on a per-file basis, which is
>> > > usually the way it's performed.  In other words, debug messages
>> > > usually
>> > > get enabled during development only on the files you're actually
>> > > working
>> > > on, and perhaps on a few more related files.
>> >
>> > Yes, and this would be fine, but when I need to know to add "#define
>> > LOG_DEBUG" specifically to drivers/iommu/iommu-uclass.c to know that my
>> > driver failed to probe due to the IOMMU device not being found... Well,
>> > you can see how that isn't super useful in this case.
>> 
>> Oh, I see and I know it very well first hand.  For example, I spent 
>> ages
>> once debugging some MMC-related issue, just because no logs were 
>> produced
>> unless debugging was enabled.  On the other hand, pinpointing the 
>> issue with
>> the debugging enabled was a five-minute job.  That was the hard way 
>> for me
>> to learn to enable debugging first where it's required during 
>> development.
>> 
>> > Maybe adding a single error message to device_probe() if the call to
>> > dev_iommu_enable() fails would be a sensible middleground here?
>> 
>> Please, don't get me wrong, I'm not opposing an approach like that, 
>> but how
>> about maybe going one step further and introducing another debug level 
>> at
>> the same time?  That new debug level would include a small-enough 
>> subset of
>> highly important debug messages so that it could be enabled at the top 
>> level
>> during development, without breaking the image size constraints.
>> 
>> Of course, it would take time for various parts of U-Boot to migrate 
>> to
>> using that new debug level, but given enough time and taking the 
>> usability
>> into account, it probably should happen eventually.  It would be 
>> highly
>> useful during development, IMHO, while still keeping the production 
>> image
>> sizes down.
> 
> We already have "good" log levels, the issue is that code isn't using
> them consistently. I think here, a log_err is fine. I'll size check
> things when merging and worst case we'll change it to log_warn as one 
> of
> the standard "I need to reduce size" is to lower LOGLEVEL to only err,
> and discard warning and higher.

Sounds good to me, thanks for the clarification.

  reply	other threads:[~2024-01-05 17:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-04 17:12 [PATCH] iommu: dont fail silently Caleb Connolly
2024-01-04 17:47 ` Dragan Simic
2024-01-05 13:55   ` Caleb Connolly
2024-01-05 14:47     ` Dragan Simic
2024-01-05 16:09       ` Caleb Connolly
2024-01-05 16:48         ` Dragan Simic
2024-01-05 17:50           ` Tom Rini
2024-01-05 17:52             ` Dragan Simic [this message]
2024-01-19 16:09 ` Tom Rini

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=eeef8ebfe876d4b36470456196d73a50@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=caleb.connolly@linaro.org \
    --cc=kettenis@openbsd.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