> -----Original Message----- > From: Matthias Brugger [mailto:mbrugger@xxxxxxxx] > Sent: Wednesday, April 13, 2016 6:23 AM > To: Marc Zyngier <marc.zyngier@xxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; > frowand.list@xxxxxxxxx; grant.likely@xxxxxxxxxx; German.Rivera@xxxxxxxxxxxxx; > jiang.liu@xxxxxxxxxxxxxxx; tglx@xxxxxxxxxxxxx > Cc: treding@xxxxxxxxxx; Stuart Yoder <stuart.yoder@xxxxxxx>; jroedel@xxxxxxx; agraf@xxxxxxx; > bp@xxxxxxx; matthias.bgg@xxxxxxxxx; bhaktipriya96@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > 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.bgg@xxxxxxxxx> > >> > >> 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 <mbrugger@xxxxxxxx> > >> --- > >> .../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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
