[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170524102821.GB9302@wunner.de>
Date: Wed, 24 May 2017 12:28:21 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andreas Noever <andreas.noever@...il.com>,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <yehezkel.bernat@...el.com>,
Amir Levy <amir.jer.levy@...el.com>,
Andy Lutomirski <luto@...nel.org>, Mario.Limonciello@...l.com,
Jared.Dominguez@...l.com,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/24] thunderbolt: Introduce thunderbolt bus and
connection manager
On Thu, May 18, 2017 at 05:38:56PM +0300, Mika Westerberg wrote:
> Thunderbolt fabric consists of one or more switches. This fabric is
> called domain and it is controlled by an entity called connection
> manager. The connection manager can be either internal (driven by a
> firmware running on the host controller) or external (software driver).
> This driver currently implements support for the latter.
>
> In order to manage switches and their properties more easily we model
> this domain structure as a Linux bus. Each host controller adds a domain
> device to this bus, and these devices are named as domainN where N
> stands for index or id of the current domain.
What is the rationale for using a bus? Do you intend to attach a driver
to each domain and/or switch? Unless you do, a class might be more
appropriate.
Thanks,
Lukas
Powered by blists - more mailing lists