From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-kernel@vger.kernel.org,
Andreas Noever <andreas.noever@gmail.com>,
Michael Jamet <michael.jamet@intel.com>,
Yehezkel Bernat <YehezkelShB@gmail.com>
Subject: Re: [PATCH 1/3] thunderbolt: Make the driver less verbose
Date: Wed, 5 Sep 2018 12:54:51 +0300 [thread overview]
Message-ID: <20180905095451.GI2283@lahna.fi.intel.com> (raw)
In-Reply-To: <20180905090510.fvryu6ivxagdzoyx@wunner.de>
On Wed, Sep 05, 2018 at 11:05:10AM +0200, Lukas Wunner wrote:
> On Mon, Sep 03, 2018 at 04:33:02PM +0300, Mika Westerberg wrote:
> > Currently the driver logs quite a lot to the system message buffer even
> > when doing normal operations. This information is not useful for
> > ordinary users and might even annoy some.
>
> No, the verbose logging is done on purpose to aid us in reverse-engineering
> the protocol. For example ...
>
> > - tb_port_info(port, " Unknown1: %#x Unknown2: %#x Unknown3: %#x\n",
> > - hop->unknown1, hop->unknown2, hop->unknown3);
>
> ... why do you think we're logging these seemingly stupid unknown
> bitfields? Because whenever someone posts dmesg output they
> inadvertantly post the contents of those unknown fields and we can
> then google the value of those fields on various controllers and
> machines and deduce their possible meaning.
And the majority of people get tons of completely useless messages
filling their dmesgs? No, I don't think that's a good thing.
> By muting those messages, you're taking away our reverse enginering aids
> without having released the spec, which would indeed obviate the need
> for them. Please don't do that. Release the spec, *then* you can
> mute the messages. Not the other way round.
All the possible messages are most likely logged already and available
by Googling so even if we mute the driver now, you still can find those
messages in the wild. Anything running on Alpine Ridge and higher does
not require reverse-engineering (even on Apple systems) because those
are already supported in the driver.
next prev parent reply other threads:[~2018-09-05 9:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-03 13:33 [PATCH 0/3] thunderbolt: Miscellaneous cleanups Mika Westerberg
2018-09-03 13:33 ` [PATCH 1/3] thunderbolt: Make the driver less verbose Mika Westerberg
2018-09-05 9:05 ` Lukas Wunner
2018-09-05 9:54 ` Mika Westerberg [this message]
2018-09-06 8:41 ` Lukas Wunner
2018-09-06 10:47 ` Mika Westerberg
2018-09-03 13:33 ` [PATCH 2/3] thunderbolt: Convert rest of the driver files to use SPDX identifier Mika Westerberg
2018-09-03 13:33 ` [PATCH 3/3] thunderbolt: Add Intel as copyright holder Mika Westerberg
2018-09-03 20:18 ` Yehezkel Bernat
2018-09-04 9:40 ` Mika Westerberg
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=20180905095451.GI2283@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=michael.jamet@intel.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).