From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753204AbbJOOAq (ORCPT ); Thu, 15 Oct 2015 10:00:46 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:62415 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750759AbbJOOAo (ORCPT ); Thu, 15 Oct 2015 10:00:44 -0400 From: Arnd Bergmann To: Christoffer Dall Cc: Eric Auger , 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 15:59:56 +0200 Message-ID: <5270338.MbsQ1bGczu@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151015121228.GA965@cbox> References: <1444836792-2405-1-git-send-email-eric.auger@linaro.org> <7287273.XGFpHqQ9fN@wuerfel> <20151015121228.GA965@cbox> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:iGJC5P6cYynClIfpr0j3bItJtXb409LyoTdTEb++9Xg0U9IeFmt UE1J9DE9HFINffocpoeq6Nfm+ut9jREJHNMpgsFU7jK+9X7BAKM+ksKJ/6OqJc5+55mFK9B XUX7nXpWFimPLN2+cBCIMBfvbnTkkjcCA4RWn0PTl67CnnAIZ6+DDDzryBnhi+aFfV1X5V6 W/ycnXCRh8eMDUkr3JYMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:crHCcFilh2c=:isNhIXi4vnGu0GbqhIrUCL gkqC6kWdXgLCgo5gYWBvdFKg9MBkipfrFOiW973A4SMZMRAu23Rf3iIZavG3TWO+RxBrHI+8Z TcCVLhbF3tqZRa8hDllVdq5GEymLnxncdJpUfyiaL9Tb9lT2elMYeUImaeiHXm2iHFFBeCSCo M/B9GDwf2AgJbmaWSoFrN0JuQX7wSHila6/oL7a6L287enZblxGKNVeNfWSM0UiENG6VJ3rHQ 0mVIdanf053O5EpS3vBXSmN70LaboRxuSHHhczaE6yjzUEczdQ6bu9jRFnQztiLiKrp9TQ9aw cfC7E2xacF4X7q9f6ZD2ZyekebT6T+kXNxK8N1AIKoAnaio1e1mGyDh6079gGqka4KOPLFu4J aAOt1Fi+cUtzzbg0NjId57IIeR8s9ydt0AzuUDleF8Bxrk4evTwdJ454Eui8c1z5F0BxMESoq CWaxjsl1gdcLp7b3fVizIY2qRzBIVRuekEjPXl36Pn8TUak24QgHtm8oqkmhQ2J5/ke4kUw1Y A0IOjaz7m6Wqdt0DoEQRhlcdt4xERkCKsVTFhMpUhH9ECfKOgTALuCEgrJSSnKtC4G2Tql4X9 yheymSyzvrCBrsfxEZ/i/SMGWGZjjb3UCkRwlCJUv+pEjy6H3nm6ZAZt+3SJzSuFr3zO4Spd6 ucp+W69DDM6/krJYlFQf8FQVPdQ38lHAl7eMVqTNJHaag9gUbqMt6SODADmLO3BUdNELcwt0M 7TiyrzN6FNq246gz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 15 October 2015 14:12:28 Christoffer Dall wrote: > > > > enum vfio_platform_op { > > VFIO_PLATFORM_BIND, > > VFIO_PLATFORM_UNBIND, > > VFIO_PLATFORM_RESET, > > }; > > > > struct platform_driver { > > int (*probe)(struct platform_device *); > > int (*remove)(struct platform_device *); > > ... > > int (*vfio_manage)(struct platform_device *, enum vfio_platform_op); > > struct device_driver driver; > > }; > > > > This would integrate much more closely into the platform driver framework, > > just like the regular vfio driver integrates into the PCI framework. > > Unlike PCI however, you can't just use the generic driver framework to > > unbind the driver, because you still need device specific code. > > > Thanks for these suggestions, really helpful. > > What I don't understand in the latter example is how VFIO knows which > struct platform_driver to interact with? This would assume that the driver remains bound to the device, so VFIO gets a pointer to the device from somewhere (as it does today) and then follows the dev->driver pointer to get to the platform_driver. > Also, just so I'm sure I understand correctly, VFIO_PLATFORM_UNBIND is > then called by VFIO before the VFIO driver unbinds from the device > (unbinding the platform driver from the device being a completely > separate thing)? 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). Arnd