Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp255119imm; Thu, 6 Sep 2018 01:47:46 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda2RlIrSvBy4Q6u5ejlCD/+U5hnglFMpMFbGmYlXKx3cTD3mDXJ+qS8lpNyJy//KWjyiGu9 X-Received: by 2002:a63:6fca:: with SMTP id k193-v6mr1643565pgc.360.1536223666717; Thu, 06 Sep 2018 01:47:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536223666; cv=none; d=google.com; s=arc-20160816; b=NcEvwOVTY0YgmBuvW+TUfYU0TT29XFhgeQI4E+FJFytL5QODOfsIKxGFfxJ9iQV6i4 A99SrXNtHrl0bfbw6K6EGe1E6hhlpYrdRHC7k4JQA5stUYjPvlT0MYSeS31CP71aUW6g yA0sOUbusiYF7P2sDwfW6OStBy/wrw1t9ncAVvqYz/ELiPlk0VtyKItjGu7/DXmej983 b7qkgUx8Txq0vRq+K7T/48cDFdJiQ6okAgknBz+wJHTFpDZmMf7zeA/fDVIbLSOMJphS sK+MBfUYJL3LMXOijVNMvBHtIpEOZ3oTDRm5IZ+7xjxMpHPCM1rPhCXeekJTbTlnVz5u /fNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ZaAXh3hICSRJ2qfeGbdPjgfxIsSxoDVrJF5tPU16P3w=; b=lbmkkCJ+UHftxje6Hl3sQwBn8/N96jjwPlpSXu+p4MeHd5MOmRLy40t2ua2/9hkaHd RFCcbxe4UrXNvM8x29/EVVS0/bNUTFYpFnGFjqh0cyUrsYuU52Eo/nNKfAzW8AJxkfjI 8JPWg6Gb4+vPjdTXSMFaTFATB8dKBJZ2XdGLuM0BQwk7XrMp2TbrLLJr/QSwS3s6b/14 zfybRCZPOXbgtE9xciG4UA/9wyVoG/loc9w5j05C4kwFbf9KsAOtigLbgelILSab79ZZ DC22wglmHNtK5RDQsj+wHm4GcvitkPMHECGQJeAKyCabNAP9B3zUQ92276QZ1NndT9E6 sPdA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h9-v6si4445504pgk.121.2018.09.06.01.47.00; Thu, 06 Sep 2018 01:47:46 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728255AbeIFNQG (ORCPT + 99 others); Thu, 6 Sep 2018 09:16:06 -0400 Received: from bmailout1.hostsharing.net ([83.223.95.100]:57219 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728127AbeIFNQG (ORCPT ); Thu, 6 Sep 2018 09:16:06 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 7ED5D3000253B; Thu, 6 Sep 2018 10:41:43 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 5A403216617; Thu, 6 Sep 2018 10:41:43 +0200 (CEST) Date: Thu, 6 Sep 2018 10:41:43 +0200 From: Lukas Wunner To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Andreas Noever , Michael Jamet , Yehezkel Bernat Subject: Re: [PATCH 1/3] thunderbolt: Make the driver less verbose Message-ID: <20180906084143.sah4njyft7z5squb@wunner.de> References: <20180903133304.70362-1-mika.westerberg@linux.intel.com> <20180903133304.70362-2-mika.westerberg@linux.intel.com> <20180905090510.fvryu6ivxagdzoyx@wunner.de> <20180905095451.GI2283@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180905095451.GI2283@lahna.fi.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 05, 2018 at 12:54:51PM +0300, Mika Westerberg wrote: > 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. As you know the OS-controlled tunnel manager is far from feature complete. I think the "majority of people" are perfectly willing to accept verbose logging if it helps us fill in those gaps. You make it sound like logfiles are spammed all the time, but messages are in fact only logged on driver initialization and hotplug. We wouldn't be in this situation if we had a proper Thunderbolt spec. It wasn't *my* idea to keep it under wraps. So please leave the messages at info level so as not to hinder our work. As for your claim that the "majority of people" find the messages useless", I rather suspect that you, personally, find them useless because you complained about noisiness of the driver before: "I don't think we want to log anything with info level to be honest. The driver currently already is pretty noisy so adding even more information there just makes it worse ;-) I would rather convert debugging information to use tracepoints and get rid of the tb_*_info() things completely." https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1401181.html And guess what I responded: "The noisiness has value in that it helps with reverse-engineering: Just google for dmesg output and check what other machines are reporting for unknown registers. :-) If there was public documentation available or Intel would be okay with answering specific questions (as you've done with the 0x30 attribute id), then the value obviously diminishes." > Anything running on Alpine Ridge and higher does > not require reverse-engineering (even on Apple systems) because those > are already supported in the driver. Long term it may be worthwhile to move to OS-controlled tunnel management even when ICM-controlled tunnel management is available as the latter might not support features of the former, e.g. correlation of PCI devices with Thunderbolt ports: https://github.com/l1k/linux/commit/d024c6e7e80e Thanks, Lukas