All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
	 linux-spi@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 Michael Walle <michael@walle.cc>,
	 linux-mtd@lists.infradead.org,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH] spi: spi-mem: Introduce a default ->exec_op() debug log
Date: Wed, 19 Mar 2025 21:08:50 +0100	[thread overview]
Message-ID: <87ldt0ye99.fsf@bootlin.com> (raw)
In-Reply-To: <a97f8ddc-c9b9-45a4-bef3-cbc01c3d07c6@sirena.org.uk> (Mark Brown's message of "Wed, 19 Mar 2025 17:39:50 +0000")

On 19/03/2025 at 17:39:50 GMT, Mark Brown <broonie@kernel.org> wrote:

> On Wed, Mar 19, 2025 at 05:56:28PM +0100, Miquel Raynal wrote:
>
>> I'd say that for this particular purpose I do not thing that trace
>> printks or events would really fit. As a developer, I'd definitely
>> always change the function calls to some direct printk calls in this
>> case. The verbose debug alternative seduced me though, so if that's okay
>> for you, I'll switch to dev_vdgb() as suggested by Tudor, which honestly
>> feels like a seducing alternative.
>
> That's fine for me.  I do have to say that I tend to end up doing the
> opposite of you and adding tracepoints to code I'm doing much with, they
> work so much better so long as you can get the buffer off the device.
> Low overhead, much bigger lookback and better tooling.

Interesting. Maybe I should consider playing a bit more with those. It's
true that the fact that you need to load the trace buffer off is always
a bit painful, but as long as network works, that should not be that
much of a burden once it's been set up.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
	 linux-spi@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 Michael Walle <michael@walle.cc>,
	 linux-mtd@lists.infradead.org,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH] spi: spi-mem: Introduce a default ->exec_op() debug log
Date: Wed, 19 Mar 2025 21:08:50 +0100	[thread overview]
Message-ID: <87ldt0ye99.fsf@bootlin.com> (raw)
In-Reply-To: <a97f8ddc-c9b9-45a4-bef3-cbc01c3d07c6@sirena.org.uk> (Mark Brown's message of "Wed, 19 Mar 2025 17:39:50 +0000")

On 19/03/2025 at 17:39:50 GMT, Mark Brown <broonie@kernel.org> wrote:

> On Wed, Mar 19, 2025 at 05:56:28PM +0100, Miquel Raynal wrote:
>
>> I'd say that for this particular purpose I do not thing that trace
>> printks or events would really fit. As a developer, I'd definitely
>> always change the function calls to some direct printk calls in this
>> case. The verbose debug alternative seduced me though, so if that's okay
>> for you, I'll switch to dev_vdgb() as suggested by Tudor, which honestly
>> feels like a seducing alternative.
>
> That's fine for me.  I do have to say that I tend to end up doing the
> opposite of you and adding tracepoints to code I'm doing much with, they
> work so much better so long as you can get the buffer off the device.
> Low overhead, much bigger lookback and better tooling.

Interesting. Maybe I should consider playing a bit more with those. It's
true that the fact that you need to load the trace buffer off is always
a bit painful, but as long as network works, that should not be that
much of a burden once it's been set up.

  reply	other threads:[~2025-03-19 20:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 20:11 [PATCH] spi: spi-mem: Introduce a default ->exec_op() debug log Miquel Raynal
2025-03-05 20:11 ` Miquel Raynal
2025-03-06  9:05 ` Tudor Ambarus
2025-03-06  9:05   ` Tudor Ambarus
2025-03-13 22:27   ` Mark Brown
2025-03-13 22:27     ` Mark Brown
2025-03-19 16:56     ` Miquel Raynal
2025-03-19 16:56       ` Miquel Raynal
2025-03-19 17:39       ` Mark Brown
2025-03-19 17:39         ` Mark Brown
2025-03-19 20:08         ` Miquel Raynal [this message]
2025-03-19 20:08           ` Miquel Raynal

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=87ldt0ye99.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.