linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Life is hard, and then you die" <ronald@innovation.ch>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Sergiu Cuciurean <sergiu.cuciurean@analog.com>,
	Lee Jones <lee.jones@linaro.org>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] Input: applespi: Add trace_event module param for early tracing.
Date: Wed, 17 Feb 2021 14:34:40 -0800	[thread overview]
Message-ID: <20210217223440.GC25685@innovation.ch> (raw)
In-Reply-To: <YC2FUwOdIoKKg1Ew@google.com>


  Hi Dmitry,

On Wed, Feb 17, 2021 at 01:06:27PM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 17, 2021 at 12:52:57PM -0800, Life is hard, and then you die wrote:
> > 
> > On Wed, Feb 17, 2021 at 12:26:18PM -0800, Dmitry Torokhov wrote:
> > > 
> > > On Wed, Feb 17, 2021 at 11:07:18AM -0800, Ronald Tschalär wrote:
> > > > The problem is that tracing can't be set via sysfs until the module is
> > > > loaded, at which point the keyboard and trackpad initialization commands
> > > > have already been run and hence tracing can't be used to debug problems
> > > > here.
> > > > 
> > > > Adding this param allows tracing to be enabled for messages sent and
> > > > received during module probing. It takes comma-separated list of events,
> > > > e.g.
> > > > 
> > > >   trace_event=applespi_tp_ini_cmd,applespi_bad_crc
> > > 
> > > You can unbind and rebind a device to a driver via sysfs as many times
> > > as needed (see bind and unbind driver sysfs attributes), so I believe

Ok yes, that works well, except for the boot-debug scenario.

> > Hmm, I'm going to have to play with that a bit, but one place it still
> > won't help I think is something we ran into in practise: init was
> > failing during boot, but was successfull later on.
> 
> Maybe compiling module as a built-in and then using kernel command line
> option to initiate the trace would work?

My personal issue with this is the fact that most folks reporting
issues are running their distro's standard kernel, which invariably
has this (and most others) compiled as a loadable module; and asking
folks to rebuild their kernel is actually quite a hurdle for them, in
particular compared to asking them to just add some boot params or
manipulating some sysfs entries. So I prefer to try to provide easy
ways for folks to be able to generate and report info back that work
and are enabled out-of-the-box on most distros.

> If this facility is really needed, it would be beneficial for other
> modules as well, and thus better implemented in the module loading code
> to activate desired tracing after loading the module but before invoking
> module init code.

I don't know if it rises to the level of "really needed" - I certainly
needed something like this to debug an issue and hence the module
param. And I figured if somebody adds/debugs additional init commands
they could find it useful too. But this may not be commonly needed
after all, or folks are using some other solution.

If there's interest, I might be able to take a stab a this in the near
future, but not sure.


  Cheers,

  Ronald


  reply	other threads:[~2021-02-17 22:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 19:07 [PATCH 1/3] Input: applespi: Don't wait for responses to commands indefinitely Ronald Tschalär
2021-02-17 19:07 ` [PATCH 2/3] Input: applespi: Fix occasional crc errors under load Ronald Tschalär
2021-02-19 19:12   ` Dmitry Torokhov
2021-02-17 19:07 ` [PATCH 3/3] Input: applespi: Add trace_event module param for early tracing Ronald Tschalär
2021-02-17 20:26   ` Dmitry Torokhov
2021-02-17 20:52     ` Life is hard, and then you die
2021-02-17 21:06       ` Dmitry Torokhov
2021-02-17 22:34         ` Life is hard, and then you die [this message]
2021-02-18  0:18   ` kernel test robot
2021-02-18  4:41   ` kernel test robot
2021-02-17 20:23 ` [PATCH 1/3] Input: applespi: Don't wait for responses to commands indefinitely Dmitry Torokhov
2021-02-17 20:45   ` Life is hard, and then you die
2021-02-19 19:12     ` Dmitry Torokhov

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=20210217223440.GC25685@innovation.ch \
    --to=ronald@innovation.ch \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gustavoars@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergiu.cuciurean@analog.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).