From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH] vfio-pci: PCI hot reset interface Date: Tue, 20 Aug 2013 08:44:40 +1000 Message-ID: <1376952280.25016.87.camel@pasglop> References: <20130814200845.21923.64284.stgit@bling.home> <1376521578.13642.65.camel@ul30vt.home> <1376937682.2657.15.camel@ul30vt.home> <1376943632.2657.25.camel@ul30vt.home> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Bjorn Helgaas , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Alexander Viro , linux-fsdevel To: Alex Williamson Return-path: In-Reply-To: <1376943632.2657.25.camel@ul30vt.home> Sender: linux-pci-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 2013-08-19 at 14:20 -0600, Alex Williamson wrote: > I try to handle the slot as opaque, only caring that the slot pointer > matches, so I think our implementation is ok... so long as we only get > one driver claiming to manage a slot, but that's not a vfio problem ;) > Thanks, By why bother with slots ? Why do you even think about slots in that context ? slots are a badly defined thing in our current PCI stack, pretty much intricated with hotplug. I don't see why the reset semantics would be tied to slots at all. The only case where it *might* make some sense (and even then ...) is if you want to start exposing slot power control and PERST but that would imply a pile of platform specific gunk anyway. Ben.