RE: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure

[Stuart Yoder]

> -----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