From: Mark Brown <broonie@kernel.org>
To: Peter Seiderer <ps.report@gmx.net>
Cc: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
Annaliese McDermond <nh6z@nh6z.net>,
Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH v1] ASoC: tlv320aic32x4: handle regmap_read error gracefully
Date: Thu, 9 Jan 2020 20:35:47 +0000 [thread overview]
Message-ID: <20200109203547.GF3702@sirena.org.uk> (raw)
In-Reply-To: <20200106214534.39378927@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
On Mon, Jan 06, 2020 at 09:45:34PM +0100, Peter Seiderer wrote:
> On Fri, 27 Dec 2019 22:52:04 +0000, Mark Brown <broonie@kernel.org> wrote:
> > On Fri, Dec 27, 2019 at 04:20:56PM +0100, Peter Seiderer wrote:
> > Please think hard before including complete backtraces in upstream
> > reports, they are very large and contain almost no useful information
> > relative to their size so often obscure the relevant content in your
> > message. If part of the backtrace is usefully illustrative then it's
> > usually better to pull out the relevant sections.
> Thanks for review..., but a little disagree here, do not know much which
> is more informative than a complete back trace for a division by zero (and
> which is the complete information/starting point for investigating the
> reason therefore) and it would be a pity to loose this valuable information?
Right, some backtrace is definitely often useful for understanding where
things broke and helping people search for problems - it's just
providing the *full* backtrace that can be an issue as a lot of it can
end up being redundant. As a rule of thumb I'd tend to say that once
you get out of the driver or subsystem you're starting to loose
relevance. For example with a probe failure like this once you get out
of the driver probe function it almost never matters exactly what the
stack in the device model core is, it's not adding anything and it's
usually more than a screenful that needs to be paged through. Cutting
that out helps people focus on the bits that matter.
> Maybe I should have added more information about why and how the failing
> regmap_read() call leads to a division by zero?
Any analysis you've done about why things got confused and broken is
definitely good to include!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-01-09 20:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-27 15:20 [PATCH v1] ASoC: tlv320aic32x4: handle regmap_read error gracefully Peter Seiderer
2019-12-27 22:52 ` Mark Brown
2020-01-06 20:45 ` Peter Seiderer
2020-01-09 20:35 ` Mark Brown [this message]
2020-01-09 20:38 ` Mark Brown
2020-01-09 22:21 ` Peter Seiderer
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=20200109203547.GF3702@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nh6z@nh6z.net \
--cc=perex@perex.cz \
--cc=ps.report@gmx.net \
--cc=tiwai@suse.com \
/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;
as well as URLs for NNTP newsgroup(s).