Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbdFSRxf (ORCPT ); Mon, 19 Jun 2017 13:53:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751438AbdFSRxd (ORCPT ); Mon, 19 Jun 2017 13:53:33 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1171A80C25 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=alex.williamson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1171A80C25 Date: Mon, 19 Jun 2017 11:53:30 -0600 From: Alex Williamson To: Russell King - ARM Linux Cc: kvm@vger.kernel.org, eric.auger@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 8/9] amba: Export amba_bustype Message-ID: <20170619115330.6f068dd4@w520.home> In-Reply-To: <20170619173109.GI4902@n2100.armlinux.org.uk> References: <20170619170323.14047.26504.stgit@gimli.home> <20170619171529.14047.92652.stgit@gimli.home> <20170619173109.GI4902@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 19 Jun 2017 17:53:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1888 Lines: 55 On Mon, 19 Jun 2017 18:31:10 +0100 Russell King - ARM Linux wrote: > This patch on its own doesn't make much sense to me... any chance of > seeing the full series please? Hi Russell, Please find it here: https://lkml.org/lkml/2017/6/19/808 Patches 7 and 9: https://lkml.org/lkml/2017/6/19/813 https://lkml.org/lkml/2017/6/19/812 Are particularly relevant. The gist of it is that we want to get to the driver_override field of the device in order to force a no-match for a driver bind when we're in a situation where binding to a host driver could compromise the system integrity (user owned devices and host owned devices in the same iommu group). driver_override is handled in a common way, but is not part of struct device, it's part of the containing structure, so we identify the bustype and therefore device container to get to the override. The bustype is typically exported and some bus drivers like PCI even offer convenient helpers like dev_is_pci() to facilitate this sort of matching. Thanks, Alex > On Mon, Jun 19, 2017 at 11:15:29AM -0600, Alex Williamson wrote: > > This allows modules to match struct device.bus to amba_bustype for the > > purpose of casting the device to an amba_device with to_amba_device(). > > > > Signed-off-by: Alex Williamson > > Reported-by: Eric Auger > > Cc: Russell King > > --- > > drivers/amba/bus.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c > > index a56fa2a1e9aa..4e118cd3ddf3 100644 > > --- a/drivers/amba/bus.c > > +++ b/drivers/amba/bus.c > > @@ -197,6 +197,7 @@ struct bus_type amba_bustype = { > > .uevent = amba_uevent, > > .pm = &amba_pm, > > }; > > +EXPORT_SYMBOL_GPL(amba_bustype); > > > > static int __init amba_init(void) > > { > > >