From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757551AbcDMO5Y (ORCPT ); Wed, 13 Apr 2016 10:57:24 -0400 Received: from mail-db3on0055.outbound.protection.outlook.com ([157.55.234.55]:9076 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751829AbcDMO5W convert rfc822-to-8bit (ORCPT ); Wed, 13 Apr 2016 10:57:22 -0400 From: Stuart Yoder To: Matthias Brugger , Marc Zyngier , "gregkh@linuxfoundation.org" , "robh+dt@kernel.org" , "frowand.list@gmail.com" , "grant.likely@linaro.org" , "German.Rivera@freescale.com" , "jiang.liu@linux.intel.com" , "tglx@linutronix.de" CC: "treding@nvidia.com" , "jroedel@suse.de" , "agraf@suse.de" , "bp@suse.de" , "matthias.bgg@gmail.com" , "bhaktipriya96@gmail.com" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "devel@driverdev.osuosl.org" , "linux-arm-kernel@lists.infradead.org" Subject: RE: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure Thread-Topic: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure Thread-Index: AQHRlW+/L7JCCP7ND0uMDcmATie+r5+Hu2OAgAAHhgCAADtlgA== Date: Wed, 13 Apr 2016 14:57:17 +0000 Message-ID: References: <1460543456-11345-1-git-send-email-mbrugger@suse.com> <1460543456-11345-5-git-send-email-mbrugger@suse.com> <570E25DD.9070106@arm.com> <570E2C2C.6090900@suse.com> In-Reply-To: <570E2C2C.6090900@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [192.88.168.49] x-ms-office365-filtering-correlation-id: 004e38fb-db31-46d1-9b00-08d363abe87e x-microsoft-exchange-diagnostics: 1;HE1PR04MB1644;5:gMzGVDzLTb5NsFF4hSjT1j/+UxhJB1F5ya2n8IhIC1hMAsiObnDxkeJQBb3QIjQHN3rzI4nzJnv6hdE1+eIrSXVZL9RPj//rokIXqX6X94WioRG/G/yExbNKZud9SgwCZ5QeMWnFLydxvSRdADH7fw==;24:ZmSReOLcz00HwuoyBkdz1jFpdHGKVBVy+QKSVHCxYOgcxLVJkZQlp49X+PYdReIJCKoJRs1AIStqzM2t1ZIVg6uuSmjVVPou3cuyTzOxsH8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1644; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);SRVR:HE1PR04MB1644;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1644; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(13464003)(24454002)(377454003)(1096002)(76576001)(10400500002)(5008740100001)(122556002)(81166005)(3660700001)(5003600100002)(4326007)(1220700001)(2201001)(66066001)(93886004)(86362001)(33656002)(11100500001)(2501003)(2906002)(106116001)(74316001)(19580395003)(9686002)(6116002)(102836003)(87936001)(77096005)(54356999)(76176999)(586003)(5001770100001)(5002640100001)(92566002)(5004730100002)(2950100001)(3280700002)(50986999)(189998001)(19580405001)(7059030);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR04MB1644;H:HE1PR04MB1641.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 14:57:17.8665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1644 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Matthias Brugger [mailto:mbrugger@suse.com] > Sent: Wednesday, April 13, 2016 6:23 AM > To: Marc Zyngier ; gregkh@linuxfoundation.org; robh+dt@kernel.org; > frowand.list@gmail.com; grant.likely@linaro.org; German.Rivera@freescale.com; > jiang.liu@linux.intel.com; tglx@linutronix.de > Cc: treding@nvidia.com; Stuart Yoder ; jroedel@suse.de; agraf@suse.de; > bp@suse.de; matthias.bgg@gmail.com; bhaktipriya96@gmail.com; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; devel@driverdev.osuosl.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure > > > > On 13/04/16 12:56, Marc Zyngier wrote: > > On 13/04/16 11:30, Matthias Brugger wrote: > >> From: Matthias Brugger > >> > >> The fsl-mc driver can't be build as a module because it uses msi_* > >> functions directly. Port the driver to use the platform_msi_* > >> infrastructure instead, to allow it to be build as a module. > >> > >> Signed-off-by: Matthias Brugger > >> --- > >> .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 5 +- > >> drivers/staging/fsl-mc/bus/mc-allocator.c | 9 +- > >> drivers/staging/fsl-mc/bus/mc-msi.c | 169 +-------------------- > >> drivers/staging/fsl-mc/include/mc-sys.h | 3 + > >> 4 files changed, 14 insertions(+), 172 deletions(-) > >> > >> diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c b/drivers/staging/fsl- > mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> index 720e2b0..0eecb7e 100644 > >> --- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> +++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> @@ -25,7 +25,6 @@ static struct irq_chip its_msi_irq_chip = { > >> .irq_mask = irq_chip_mask_parent, > >> .irq_unmask = irq_chip_unmask_parent, > >> .irq_eoi = irq_chip_eoi_parent, > >> - .irq_set_affinity = msi_domain_set_affinity > >> }; > >> > >> static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain, > >> @@ -86,7 +85,7 @@ int __init its_fsl_mc_msi_init(void) > >> continue; > >> } > >> > >> - mc_msi_domain = fsl_mc_msi_create_irq_domain( > >> + mc_msi_domain = platform_msi_create_irq_domain( > >> of_node_to_fwnode(np), > >> &its_fsl_mc_msi_domain_info, > >> parent); > > > > What? We are already creating a platform MSI domain for the ITS. How is > > that going to work? If you want to convert this set of drivers to > > platform ITS, fine. But you can't randomly hack in the ITS code and pray > > for things not to fall apart. > > > > From what I see, the difference between irq-gic-v3-its-fsl-mc-msi and > the irq-gic-v3-its-platform-msi is the way ITS specific DeviceID is > created in msi_prepare. > > German, is there a reason why you use the ICID read from the DPRC as dev_id? Because it _is_ the dev_id at the hardware level. There is an fsl-mc bus specific mechanism to get that id...it's not in the device tree. Stuart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stuart Yoder Subject: RE: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure Date: Wed, 13 Apr 2016 14:57:17 +0000 Message-ID: References: <1460543456-11345-1-git-send-email-mbrugger@suse.com> <1460543456-11345-5-git-send-email-mbrugger@suse.com> <570E25DD.9070106@arm.com> <570E2C2C.6090900@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <570E2C2C.6090900@suse.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Matthias Brugger , Marc Zyngier , "gregkh@linuxfoundation.org" , "robh+dt@kernel.org" , "frowand.list@gmail.com" , "grant.likely@linaro.org" , "German.Rivera@freescale.com" , "jiang.liu@linux.intel.com" , "tglx@linutronix.de" Cc: "devel@driverdev.osuosl.org" , "devicetree@vger.kernel.org" , "bp@suse.de" , "bhaktipriya96@gmail.com" , "agraf@suse.de" , "linux-kernel@vger.kernel.org" , "jroedel@suse.de" , "matthias.bgg@gmail.com" , "treding@nvidia.com" , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org > -----Original Message----- > From: Matthias Brugger [mailto:mbrugger@suse.com] > Sent: Wednesday, April 13, 2016 6:23 AM > To: Marc Zyngier ; gregkh@linuxfoundation.org; robh+dt@kernel.org; > frowand.list@gmail.com; grant.likely@linaro.org; German.Rivera@freescale.com; > jiang.liu@linux.intel.com; tglx@linutronix.de > Cc: treding@nvidia.com; Stuart Yoder ; jroedel@suse.de; agraf@suse.de; > bp@suse.de; matthias.bgg@gmail.com; bhaktipriya96@gmail.com; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; devel@driverdev.osuosl.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure > > > > On 13/04/16 12:56, Marc Zyngier wrote: > > On 13/04/16 11:30, Matthias Brugger wrote: > >> From: Matthias Brugger > >> > >> The fsl-mc driver can't be build as a module because it uses msi_* > >> functions directly. Port the driver to use the platform_msi_* > >> infrastructure instead, to allow it to be build as a module. > >> > >> Signed-off-by: Matthias Brugger > >> --- > >> .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 5 +- > >> drivers/staging/fsl-mc/bus/mc-allocator.c | 9 +- > >> drivers/staging/fsl-mc/bus/mc-msi.c | 169 +-------------------- > >> drivers/staging/fsl-mc/include/mc-sys.h | 3 + > >> 4 files changed, 14 insertions(+), 172 deletions(-) > >> > >> diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c b/drivers/staging/fsl- > mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> index 720e2b0..0eecb7e 100644 > >> --- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> +++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> @@ -25,7 +25,6 @@ static struct irq_chip its_msi_irq_chip = { > >> .irq_mask = irq_chip_mask_parent, > >> .irq_unmask = irq_chip_unmask_parent, > >> .irq_eoi = irq_chip_eoi_parent, > >> - .irq_set_affinity = msi_domain_set_affinity > >> }; > >> > >> static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain, > >> @@ -86,7 +85,7 @@ int __init its_fsl_mc_msi_init(void) > >> continue; > >> } > >> > >> - mc_msi_domain = fsl_mc_msi_create_irq_domain( > >> + mc_msi_domain = platform_msi_create_irq_domain( > >> of_node_to_fwnode(np), > >> &its_fsl_mc_msi_domain_info, > >> parent); > > > > What? We are already creating a platform MSI domain for the ITS. How is > > that going to work? If you want to convert this set of drivers to > > platform ITS, fine. But you can't randomly hack in the ITS code and pray > > for things not to fall apart. > > > > From what I see, the difference between irq-gic-v3-its-fsl-mc-msi and > the irq-gic-v3-its-platform-msi is the way ITS specific DeviceID is > created in msi_prepare. > > German, is there a reason why you use the ICID read from the DPRC as dev_id? Because it _is_ the dev_id at the hardware level. There is an fsl-mc bus specific mechanism to get that id...it's not in the device tree. Stuart From mboxrd@z Thu Jan 1 00:00:00 1970 From: stuart.yoder@nxp.com (Stuart Yoder) Date: Wed, 13 Apr 2016 14:57:17 +0000 Subject: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure In-Reply-To: <570E2C2C.6090900@suse.com> References: <1460543456-11345-1-git-send-email-mbrugger@suse.com> <1460543456-11345-5-git-send-email-mbrugger@suse.com> <570E25DD.9070106@arm.com> <570E2C2C.6090900@suse.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > -----Original Message----- > From: Matthias Brugger [mailto:mbrugger at suse.com] > Sent: Wednesday, April 13, 2016 6:23 AM > To: Marc Zyngier ; gregkh at linuxfoundation.org; robh+dt at kernel.org; > frowand.list at gmail.com; grant.likely at linaro.org; German.Rivera at freescale.com; > jiang.liu at linux.intel.com; tglx at linutronix.de > Cc: treding at nvidia.com; Stuart Yoder ; jroedel at suse.de; agraf at suse.de; > bp at suse.de; matthias.bgg at gmail.com; bhaktipriya96 at gmail.com; linux-kernel at vger.kernel.org; > devicetree at vger.kernel.org; devel at driverdev.osuosl.org; linux-arm-kernel at lists.infradead.org > Subject: Re: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure > > > > On 13/04/16 12:56, Marc Zyngier wrote: > > On 13/04/16 11:30, Matthias Brugger wrote: > >> From: Matthias Brugger > >> > >> The fsl-mc driver can't be build as a module because it uses msi_* > >> functions directly. Port the driver to use the platform_msi_* > >> infrastructure instead, to allow it to be build as a module. > >> > >> Signed-off-by: Matthias Brugger > >> --- > >> .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 5 +- > >> drivers/staging/fsl-mc/bus/mc-allocator.c | 9 +- > >> drivers/staging/fsl-mc/bus/mc-msi.c | 169 +-------------------- > >> drivers/staging/fsl-mc/include/mc-sys.h | 3 + > >> 4 files changed, 14 insertions(+), 172 deletions(-) > >> > >> diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c b/drivers/staging/fsl- > mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> index 720e2b0..0eecb7e 100644 > >> --- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> +++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c > >> @@ -25,7 +25,6 @@ static struct irq_chip its_msi_irq_chip = { > >> .irq_mask = irq_chip_mask_parent, > >> .irq_unmask = irq_chip_unmask_parent, > >> .irq_eoi = irq_chip_eoi_parent, > >> - .irq_set_affinity = msi_domain_set_affinity > >> }; > >> > >> static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain, > >> @@ -86,7 +85,7 @@ int __init its_fsl_mc_msi_init(void) > >> continue; > >> } > >> > >> - mc_msi_domain = fsl_mc_msi_create_irq_domain( > >> + mc_msi_domain = platform_msi_create_irq_domain( > >> of_node_to_fwnode(np), > >> &its_fsl_mc_msi_domain_info, > >> parent); > > > > What? We are already creating a platform MSI domain for the ITS. How is > > that going to work? If you want to convert this set of drivers to > > platform ITS, fine. But you can't randomly hack in the ITS code and pray > > for things not to fall apart. > > > > From what I see, the difference between irq-gic-v3-its-fsl-mc-msi and > the irq-gic-v3-its-platform-msi is the way ITS specific DeviceID is > created in msi_prepare. > > German, is there a reason why you use the ICID read from the DPRC as dev_id? Because it _is_ the dev_id at the hardware level. There is an fsl-mc bus specific mechanism to get that id...it's not in the device tree. Stuart