> -----Original Message----- > From: Matthias Brugger [mailto:mbrug...@suse.com] > Sent: Wednesday, April 13, 2016 6:23 AM > To: Marc Zyngier <marc.zyng...@arm.com>; gre...@linuxfoundation.org; > robh...@kernel.org; > frowand.l...@gmail.com; grant.lik...@linaro.org; german.riv...@freescale.com; > jiang....@linux.intel.com; t...@linutronix.de > Cc: tred...@nvidia.com; Stuart Yoder <stuart.yo...@nxp.com>; jroe...@suse.de; > ag...@suse.de; > b...@suse.de; matthias....@gmail.com; bhaktipriy...@gmail.com; > linux-ker...@vger.kernel.org; > devicet...@vger.kernel.org; de...@driverdev.osuosl.org; > linux-arm-ker...@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 <matthias....@gmail.com> > >> > >> 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 <mbrug...@suse.com> > >> --- > >> .../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 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
