Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 5 Sep 2018 12:54:51 +0300
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
Message-ID: <20180905095451.GI2283@lahna.fi.intel.com>
References: <20180903133304.70362-1-mika.westerberg@linux.intel.com>
 <20180903133304.70362-2-mika.westerberg@linux.intel.com>
 <20180905090510.fvryu6ivxagdzoyx@wunner.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180905090510.fvryu6ivxagdzoyx@wunner.de>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.