From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753304AbbJOOz2 (ORCPT ); Thu, 15 Oct 2015 10:55:28 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:50365 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbbJOOzZ (ORCPT ); Thu, 15 Oct 2015 10:55:25 -0400 From: Arnd Bergmann To: Eric Auger Cc: Christoffer Dall , linux-arm-kernel@lists.infradead.org, eric.auger@st.com, alex.williamson@redhat.com, b.reynal@virtualopensystems.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, thomas.lendacky@amd.com, patches@linaro.org, suravee.suthikulpanit@amd.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] VFIO: platform: AMD xgbe reset module Date: Thu, 15 Oct 2015 16:55:13 +0200 Message-ID: <37917545.AP0MxbQBzK@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <561FBC31.3020900@linaro.org> References: <1444836792-2405-1-git-send-email-eric.auger@linaro.org> <5270338.MbsQ1bGczu@wuerfel> <561FBC31.3020900@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:OsbSPh+wjkf9TFP8bds20EVJOnfEiQuiMfj5PgKtMeYKFWG12DO iiA5VkxLMPEIKUlSvKHtty31kLWisXS24V0r8QhO8EaNNVp3yTTVggAwjK92zKp2ble8RaI frbTtRKihA7fcD+tbW/CblFDaP4R9IwqcJ32jtFq2xzvXxKTsvHw3h0jhVHpTJOGTSY3pIN 4eDGUOltiYtqxiRytdDHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:D07WFzHTJKg=:kdZUMwlGga7IFlkn5+9z8s pk1WNGh7LIUQOjf7HzUpnWesHBW+QekYAv7RQ5ox/hLBlhqRvJBcv408+YgIaELlF8QKaSM8R RaB+RwOZ3zgc+4nU1d3JTEVSNr9DCCgmz2ghYvx7kmigPs0HEFhG++bOJ8Wf5uJ7X3ix9gsgZ g3hN1oxyJDwbhMFHk20mXwO4wXq5Rk6sHeA2EFgYqNxjah86qUIzDeq8o0Y52E6KRUSBy8yVl DC+eSB20bqlyyJhkJ3RSRZjMLkRPEpHSMwBFXbBFwxg7aCp73GGpV00eL45NfIup4hNgFekY5 /k1jlO3AnjfPBOG8TvaSJS/6BtfxbJn9OaVGC9ktuwmZVBUsiPHtrTjnJSfqcS7p1O8ELmp7G 82fZ+x69Q1OlZKvQGnUrxeAMQPBtKdnOTbvhHUW0eihW4PBrWssnKtCAZiv63gjCKDhWZpyzB ZJkbzH08eCsk7xwrtjhGi7nhwH0j3fDXGuVNqtFtLHY/htGNEn51H4+r7TxAyW5GpvcF6Lszm hZHd2TDeIlGkOs9x5BCc+hi+4l1yJgyQkxBEdGMeNGrpgO4e5hEUXrjTW19badAs2rRDeV05P DYaVvjiLVGGlimmNIZcnL1vK+76NGuLAT+4Xd3HMG4mowJwXv2h9kDQ3PmUJLJeZkFMBHLZW6 NmnBu9cx9nChMiSG4ZHQdrK/z8+yvEkH/riLIF9GY0VRXa46bSVR13BWAXKAqogQT1Qw2f4sS 7NXKPWl6Tk2E7eeE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 15 October 2015 16:46:09 Eric Auger wrote: > > > > This is where we'd need a little more changes for this approach. Instead > > of unbinding the device from its driver, the idea would be that the > > driver remains bound as far as the driver model is concerned, but > > it would be in a quiescent state where no other subsystem interacts with > > it (i.e. it gets unregistered from networking core or whichever it uses). > > Currently we use the same mechanism as for PCI, ie. unbind the native > driver and then bind VFIO platform driver in its place. Don't you think > changing this may be a pain for user-space tools that are designed to > work that way for PCI? > > My personal preference would be to start with your first proposal since > it looks (to me) less complex and "unknown" that the 2d approach. We certainly can't easily change from one approach to the other without breaking user expectations, so the decision needs to be made carefully. The main observation here is that platform devices are unlike PCI in this regard because they need extra per-device code. I have argued in the past that we should not reuse the "VFIO" name here because it's actually something else. On the other hand, there are a lot of commonalities, we just have to make sure we don't try to force the code into one model that doesn't really work just to make it look more like PCI VFIO. Arnd