[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05d9c1db67af410981bbb9672071a237@ausx13mpc120.AMER.DELL.COM>
Date: Mon, 19 Dec 2016 17:21:39 +0000
From: <Mario.Limonciello@...l.com>
To: <mika.westerberg@...el.com>, <luto@...nel.org>
CC: <amir.jer.levy@...el.com>, <gregkh@...uxfoundation.org>,
<andreas.noever@...il.com>, <bhelgaas@...gle.com>,
<corbet@....net>, <linux-kernel@...r.kernel.org>,
<linux-pci@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <thunderbolt-linux@...el.com>,
<tomas.winkler@...el.com>, <xiong.y.zhang@...el.com>
Subject: RE: [PATCH v8 3/8] thunderbolt: Communication with the ICM (firmware)
Dell - Internal Use - Confidential
>
> There is small problem, though. On non-Apple systems the host controller only
> appears when something is connected to thunderbolt ports. So the char device
> would not be there all the time. However, I think we can still notify the
> userspace by sending an extra uevent when we detect there is a PCIe device or
> inter-domain connection plugged in.
>
Why couldn't you just create it the first time a device is plugged into a Thunderbolt
port and leave it until the module is cleaned up? If the host controller goes to sleep
an event could be sent to the daemon to let it know it disappeared and not to expect
data on the char device for now, but leave the node around.
Powered by blists - more mailing lists