From: Lukas Wunner <lukas@wunner.de>
To: Andreas Noever <andreas.noever@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Michael Jamet <michael.jamet@intel.com>,
Yehezkel Bernat <YehezkelShB@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH 5/5] MAINTAINERS: Add Lukas Wunner as co-maintainer of thunderbolt
Date: Sun, 9 Sep 2018 23:42:01 +0200 [thread overview]
Message-ID: <76fccab34a66023c08b71a864a9fea77daac9742.1536517047.git.lukas@wunner.de> (raw)
In-Reply-To: <cover.1536517047.git.lukas@wunner.de>
Andreas Noever has let it be known off-list already a while ago that he
currently cannot spare as much time for Thunderbolt development as he'd
like. As a result the driver's development has become dominated by
Intel.
I would like to step up as co-maintainer to provide additional checks
and balances and prevent the driver from degenerating into an Intel-only
show. A number of things really irk me:
* I've been contributing to this driver as well as Thunderbolt-related
bits to the EFI, GPU and PCI subsystems for close to three years and
was explicitly asked by Intel to cc them on every Thunderbolt-related
patch. Yet Intel did not see fit to cc me on their changes that went
into 4.17. I literally only learned about their existence from
reading the news. In the 4.19 cycle I was only cc'ed on a subset of
their patches.
* Intel's efforts have been focussed exclusively on firmware-controlled
tunnel management (ICM). They made no contributions to OS-controlled
tunnel management. ICM cannot be used on Macs with Thunderbolt 1 + 2.
ICM requires trusting a firmware blob. ICM does not offer the same
versatility as OS-controlled tunnel management, e.g. using separate
tunnels to afford different QoS levels or correlation of Thunderbolt
ports with PCI devices. Apple chose OS-controlled tunnel management
for very valid technical reasons.
* Our OS-controlled tunnel management still lacks important features
such as daisy-chaining and DP tunnels. Each feature needs to be
reverse-engineered because there is no public spec. Intel issued a
press statement in May 2017 promising to make the specification public
"next year". More than a year has passed -- no spec. The company has
since changed leadership, who knows if they haven't silently canned
the plans for a public spec? I offered to sign an NDA and go through
a disclosure process for every patch -- no reaction.
* Reverse-engineering requires verbose logging so that we're able to
collect data on various systems and endpoint devices to deduce the
meaning of registers. Yet Intel now seeks to mute log output, thereby
curbing our reverse-engineering efforts. This exemplifies a worrying
tendency to ignore the needs of non-Intel stakeholders in the
developer community or even undermine them.
* Recent Intel contributions are maintainer self-commits without any
Reviewed-by tags, which is generally considered a bad practice.
Review comments offered by Intel-outsiders are not taken seriously.
For example the driver's initcall level has been fiddled with twice
now. A review comment pointing out the fragility of abusing initcall
levels to implement dependencies and suggesting the use of a notifier
chain instead was summarily dismissed as unnecessary unless it breaks
a third time.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a5b256b25905..8815f4639e58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14445,6 +14445,7 @@ F: drivers/platform/x86/thinkpad_acpi.c
THUNDERBOLT DRIVER
M: Andreas Noever <andreas.noever@gmail.com>
+M: Lukas Wunner <lukas@wunner.de>
M: Michael Jamet <michael.jamet@intel.com>
M: Mika Westerberg <mika.westerberg@linux.intel.com>
M: Yehezkel Bernat <YehezkelShB@gmail.com>
--
2.18.0
next prev parent reply other threads:[~2018-09-09 21:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-09 21:42 [PATCH 0/5] Thunderbolt material for v4.20 Lukas Wunner
2018-09-09 21:42 ` [PATCH 4/5] thunderbolt: Correlate PCI devices with Thunderbolt ports Lukas Wunner
2018-09-10 9:44 ` Mika Westerberg
2018-09-13 9:43 ` Yehezkel Bernat
2018-09-13 9:57 ` Mika Westerberg
2018-09-09 21:42 ` [PATCH 3/5] thunderbolt: Move upstream_port to struct tb Lukas Wunner
2018-09-09 21:42 ` [PATCH 2/5] thunderbolt: Obtain PCI slot number from DROM Lukas Wunner
2018-09-10 9:52 ` Mika Westerberg
2018-09-09 21:42 ` Lukas Wunner [this message]
2018-09-10 9:33 ` [PATCH 5/5] MAINTAINERS: Add Lukas Wunner as co-maintainer of thunderbolt Mika Westerberg
2018-09-10 10:25 ` Lukas Wunner
2018-09-10 12:13 ` Mika Westerberg
2018-09-13 8:58 ` Mika Westerberg
2018-09-13 9:43 ` Greg Kroah-Hartman
2018-09-17 22:34 ` Andreas Noever
2018-09-19 10:16 ` Mika Westerberg
2018-09-09 21:42 ` [PATCH 1/5] thunderbolt: Skip disabled ports on tunnel establishment Lukas Wunner
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=76fccab34a66023c08b71a864a9fea77daac9742.1536517047.git.lukas@wunner.de \
--to=lukas@wunner.de \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=stephen@networkplumber.org \
/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).