RE: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-05 Thread Gabriele Paoloni 
> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Thursday, November 05, 2015 9:36 AM
> To: Gabriele Paoloni; majun (F); Thomas Gleixner; Jiang Liu; Jason
> Cooper
> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired
> interrupt/MSI bridge driver
> 
> On 05/11/15 08:25, Gabriele Paoloni wrote:
> > Hi Marc
> >
> >> -Original Message-
> >> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org]
> >> On Behalf Of Marc Zyngier
> >> Sent: 04 November 2015 09:04
> >> To: majun (F); Thomas Gleixner; Jiang Liu; Jason Cooper
> >> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
> linux-
> >> ker...@vger.kernel.org
> >> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired
> interrupt/MSI
> >> bridge driver
> >>
> >> On 04/11/15 08:00, majun (F) wrote:
> 
> [...]
> 
> >>> I think,for a interrupt controller, msichip driver initialization
> maybe is
> >> too late
> >>> for some devices which connect to this irqchip if we use
> >> module_platform_driver.
> >>
> >> That's a consequence of this design. This is why I insisted on the
> fact
> >> that this is currently avoided by using deferred probe in drivers,
> and
> >
> > Mmm using te deferred probe would mean to rework all the drivers of
> the
> > potential devices connected to mbi-gen...would that be
> sustainable/acceptable?
> 
> I'm tempted to reply "Not my problem". Or rather, not a problem I'm
> trying to solve right now (or any time soon).
> 
> I'm pretty sure that sprinkling -EPROBE_DEFER on all possible drivers
> will result in a resounding NAK, which is is why I suggested that
> someone with a vested interest dedicates some quality time helping
> those
> who are trying to solve this issue for good.

Yes you're right, makes perfect sense

> 
> >> that it should be solved by having a probe order. Either way, this
> is
> >> not something that we can solve at that level (see the multiple
> proposal
> >> for this on the various lists).
> >
> > Could you point me to the relevant discussions for this...?
> 
> Google is, as always, your dearest friend. But here you go:
> 
> - LWN has some quality coverage of the KS discussions (assuming you're
> a
> subscriber, otherwise you'll have to wait for another week):
> http://lwn.net/Articles/662820/
> 
> - There is also Tomeu Vizoso's series, which itself builds upon other
> previous attempts at solving this: https://lwn.net/Articles/658690/
> 

Great, many thanks for pointing them out.

I'll look into these.

Thanks again

Gab

> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...

Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-05 Thread Marc Zyngier 
On 05/11/15 08:25, Gabriele Paoloni wrote:
> Hi Marc
> 
>> -Original Message-
>> From: linux-pci-ow...@vger.kernel.org 
>> [mailto:linux-pci-ow...@vger.kernel.org]
>> On Behalf Of Marc Zyngier
>> Sent: 04 November 2015 09:04
>> To: majun (F); Thomas Gleixner; Jiang Liu; Jason Cooper
>> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI
>> bridge driver
>>
>> On 04/11/15 08:00, majun (F) wrote:

[...]

>>> I think,for a interrupt controller, msichip driver initialization maybe is
>> too late
>>> for some devices which connect to this irqchip if we use
>> module_platform_driver.
>>
>> That's a consequence of this design. This is why I insisted on the fact
>> that this is currently avoided by using deferred probe in drivers, and
> 
> Mmm using te deferred probe would mean to rework all the drivers of the
> potential devices connected to mbi-gen...would that be sustainable/acceptable?

I'm tempted to reply "Not my problem". Or rather, not a problem I'm
trying to solve right now (or any time soon).

I'm pretty sure that sprinkling -EPROBE_DEFER on all possible drivers
will result in a resounding NAK, which is is why I suggested that
someone with a vested interest dedicates some quality time helping those
who are trying to solve this issue for good.

>> that it should be solved by having a probe order. Either way, this is
>> not something that we can solve at that level (see the multiple proposal
>> for this on the various lists).
> 
> Could you point me to the relevant discussions for this...?

Google is, as always, your dearest friend. But here you go:

- LWN has some quality coverage of the KS discussions (assuming you're a
subscriber, otherwise you'll have to wait for another week):
http://lwn.net/Articles/662820/

- There is also Tomeu Vizoso's series, which itself builds upon other
previous attempts at solving this: https://lwn.net/Articles/658690/

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-05 Thread Gabriele Paoloni 
Hi Marc

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
> On Behalf Of Marc Zyngier
> Sent: 04 November 2015 09:04
> To: majun (F); Thomas Gleixner; Jiang Liu; Jason Cooper
> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI
> bridge driver
> 
> On 04/11/15 08:00, majun (F) wrote:
> > Hi Marc:
> >
> > 在 2015/10/15 23:39, Marc Zyngier 写道:
> >> In order to demonstrate how to put together a wire/MSI bridge,
> >> add a dummy driver that doesn't do anything at all, except
> >> for allocating interrupts.
> >>
> >> It comes together with an even more stupid client driver that
> >> allocates an interrupt and dump the hierarchy of that interrupt.
> >>
> >> Signed-off-by: Marc Zyngier 
> >> ---
> > [...]
> >> +
> >> +static int msichip_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> >> + unsigned int nr_irqs, void *arg)
> >> +{
> >> +  int i, err;
> >> +  irq_hw_number_t hwirq;
> >> +  unsigned int type;
> >> +  struct irq_fwspec *fwspec = arg;
> >> +  void *data;
> >> +
> >> +  err = msichip_domain_translate(domain, fwspec, , );
> >> +  if (err)
> >> +  return err;
> >> +
> >
> > .translate function already called once in  irq_domain_translate(),
> > I think we don't need call this fucntion one more time here.
> 
> if you don't translate it here, how do you obtain the hwirq that you
> have to pass to irq_domain_set_hwirq_and_chip just below?
> 
> >> +  err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> >> +  if (err)
> >> +  return err;
> >> +
> >> +  data = platform_msi_get_host_data(domain);
> >> +  for (i = 0; i < nr_irqs; i++)
> >> +  irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> >> +_chip, data);
> >> +
> >> +  return 0;
> >> +}
> >> +
> > [...]
> >> +
> >> +static struct platform_driver msichip_driver = {
> >> +  .driver = {
> >> +  .name   = "msichip",
> >> +  .of_match_table = msichip_of_match,
> >> +  },
> >> +  .probe  = msichip_probe,
> >> +};
> >> +/* Do not define this as an irqchip */
> >> +module_platform_driver(msichip_driver);
> >> +
> >> +
> >
> > I think,for a interrupt controller, msichip driver initialization maybe is
> too late
> > for some devices which connect to this irqchip if we use
> module_platform_driver.
> 
> That's a consequence of this design. This is why I insisted on the fact
> that this is currently avoided by using deferred probe in drivers, and

Mmm using te deferred probe would mean to rework all the drivers of the
potential devices connected to mbi-gen...would that be sustainable/acceptable?

> that it should be solved by having a probe order. Either way, this is
> not something that we can solve at that level (see the multiple proposal
> for this on the various lists).

Could you point me to the relevant discussions for this...?

Thanks

Gab

> 
> > So, how about use the arch_initcall to register the msichip driver?
> 
> You're only pushing the problem one level up. And you'll realize that
> this is not enough for some random driver. This is not sustainable, and
> must be addressed properly.
> 
> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

RE: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-05 Thread Gabriele Paoloni 
Hi Marc

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
> On Behalf Of Marc Zyngier
> Sent: 04 November 2015 09:04
> To: majun (F); Thomas Gleixner; Jiang Liu; Jason Cooper
> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI
> bridge driver
> 
> On 04/11/15 08:00, majun (F) wrote:
> > Hi Marc:
> >
> > 在 2015/10/15 23:39, Marc Zyngier 写道:
> >> In order to demonstrate how to put together a wire/MSI bridge,
> >> add a dummy driver that doesn't do anything at all, except
> >> for allocating interrupts.
> >>
> >> It comes together with an even more stupid client driver that
> >> allocates an interrupt and dump the hierarchy of that interrupt.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>
> >> ---
> > [...]
> >> +
> >> +static int msichip_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> >> + unsigned int nr_irqs, void *arg)
> >> +{
> >> +  int i, err;
> >> +  irq_hw_number_t hwirq;
> >> +  unsigned int type;
> >> +  struct irq_fwspec *fwspec = arg;
> >> +  void *data;
> >> +
> >> +  err = msichip_domain_translate(domain, fwspec, , );
> >> +  if (err)
> >> +  return err;
> >> +
> >
> > .translate function already called once in  irq_domain_translate(),
> > I think we don't need call this fucntion one more time here.
> 
> if you don't translate it here, how do you obtain the hwirq that you
> have to pass to irq_domain_set_hwirq_and_chip just below?
> 
> >> +  err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> >> +  if (err)
> >> +  return err;
> >> +
> >> +  data = platform_msi_get_host_data(domain);
> >> +  for (i = 0; i < nr_irqs; i++)
> >> +  irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> >> +_chip, data);
> >> +
> >> +  return 0;
> >> +}
> >> +
> > [...]
> >> +
> >> +static struct platform_driver msichip_driver = {
> >> +  .driver = {
> >> +  .name   = "msichip",
> >> +  .of_match_table = msichip_of_match,
> >> +  },
> >> +  .probe  = msichip_probe,
> >> +};
> >> +/* Do not define this as an irqchip */
> >> +module_platform_driver(msichip_driver);
> >> +
> >> +
> >
> > I think,for a interrupt controller, msichip driver initialization maybe is
> too late
> > for some devices which connect to this irqchip if we use
> module_platform_driver.
> 
> That's a consequence of this design. This is why I insisted on the fact
> that this is currently avoided by using deferred probe in drivers, and

Mmm using te deferred probe would mean to rework all the drivers of the
potential devices connected to mbi-gen...would that be sustainable/acceptable?

> that it should be solved by having a probe order. Either way, this is
> not something that we can solve at that level (see the multiple proposal
> for this on the various lists).

Could you point me to the relevant discussions for this...?

Thanks

Gab

> 
> > So, how about use the arch_initcall to register the msichip driver?
> 
> You're only pushing the problem one level up. And you'll realize that
> this is not enough for some random driver. This is not sustainable, and
> must be addressed properly.
> 
> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

RE: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-05 Thread Gabriele Paoloni 
> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Thursday, November 05, 2015 9:36 AM
> To: Gabriele Paoloni; majun (F); Thomas Gleixner; Jiang Liu; Jason
> Cooper
> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired
> interrupt/MSI bridge driver
> 
> On 05/11/15 08:25, Gabriele Paoloni wrote:
> > Hi Marc
> >
> >> -Original Message-
> >> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org]
> >> On Behalf Of Marc Zyngier
> >> Sent: 04 November 2015 09:04
> >> To: majun (F); Thomas Gleixner; Jiang Liu; Jason Cooper
> >> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
> linux-
> >> ker...@vger.kernel.org
> >> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired
> interrupt/MSI
> >> bridge driver
> >>
> >> On 04/11/15 08:00, majun (F) wrote:
> 
> [...]
> 
> >>> I think,for a interrupt controller, msichip driver initialization
> maybe is
> >> too late
> >>> for some devices which connect to this irqchip if we use
> >> module_platform_driver.
> >>
> >> That's a consequence of this design. This is why I insisted on the
> fact
> >> that this is currently avoided by using deferred probe in drivers,
> and
> >
> > Mmm using te deferred probe would mean to rework all the drivers of
> the
> > potential devices connected to mbi-gen...would that be
> sustainable/acceptable?
> 
> I'm tempted to reply "Not my problem". Or rather, not a problem I'm
> trying to solve right now (or any time soon).
> 
> I'm pretty sure that sprinkling -EPROBE_DEFER on all possible drivers
> will result in a resounding NAK, which is is why I suggested that
> someone with a vested interest dedicates some quality time helping
> those
> who are trying to solve this issue for good.

Yes you're right, makes perfect sense

> 
> >> that it should be solved by having a probe order. Either way, this
> is
> >> not something that we can solve at that level (see the multiple
> proposal
> >> for this on the various lists).
> >
> > Could you point me to the relevant discussions for this...?
> 
> Google is, as always, your dearest friend. But here you go:
> 
> - LWN has some quality coverage of the KS discussions (assuming you're
> a
> subscriber, otherwise you'll have to wait for another week):
> http://lwn.net/Articles/662820/
> 
> - There is also Tomeu Vizoso's series, which itself builds upon other
> previous attempts at solving this: https://lwn.net/Articles/658690/
> 

Great, many thanks for pointing them out.

I'll look into these.

Thanks again

Gab

> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...

Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-05 Thread Marc Zyngier 
On 05/11/15 08:25, Gabriele Paoloni wrote:
> Hi Marc
> 
>> -Original Message-
>> From: linux-pci-ow...@vger.kernel.org 
>> [mailto:linux-pci-ow...@vger.kernel.org]
>> On Behalf Of Marc Zyngier
>> Sent: 04 November 2015 09:04
>> To: majun (F); Thomas Gleixner; Jiang Liu; Jason Cooper
>> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI
>> bridge driver
>>
>> On 04/11/15 08:00, majun (F) wrote:

[...]

>>> I think,for a interrupt controller, msichip driver initialization maybe is
>> too late
>>> for some devices which connect to this irqchip if we use
>> module_platform_driver.
>>
>> That's a consequence of this design. This is why I insisted on the fact
>> that this is currently avoided by using deferred probe in drivers, and
> 
> Mmm using te deferred probe would mean to rework all the drivers of the
> potential devices connected to mbi-gen...would that be sustainable/acceptable?

I'm tempted to reply "Not my problem". Or rather, not a problem I'm
trying to solve right now (or any time soon).

I'm pretty sure that sprinkling -EPROBE_DEFER on all possible drivers
will result in a resounding NAK, which is is why I suggested that
someone with a vested interest dedicates some quality time helping those
who are trying to solve this issue for good.

>> that it should be solved by having a probe order. Either way, this is
>> not something that we can solve at that level (see the multiple proposal
>> for this on the various lists).
> 
> Could you point me to the relevant discussions for this...?

Google is, as always, your dearest friend. But here you go:

- LWN has some quality coverage of the KS discussions (assuming you're a
subscriber, otherwise you'll have to wait for another week):
http://lwn.net/Articles/662820/

- There is also Tomeu Vizoso's series, which itself builds upon other
previous attempts at solving this: https://lwn.net/Articles/658690/

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-04 Thread Marc Zyngier 
On 04/11/15 08:00, majun (F) wrote:
> Hi Marc:
> 
> 在 2015/10/15 23:39, Marc Zyngier 写道:
>> In order to demonstrate how to put together a wire/MSI bridge,
>> add a dummy driver that doesn't do anything at all, except
>> for allocating interrupts.
>>
>> It comes together with an even more stupid client driver that
>> allocates an interrupt and dump the hierarchy of that interrupt.
>>
>> Signed-off-by: Marc Zyngier 
>> ---
> [...]
>> +
>> +static int msichip_domain_alloc(struct irq_domain *domain, unsigned int 
>> virq,
>> +   unsigned int nr_irqs, void *arg)
>> +{
>> +int i, err;
>> +irq_hw_number_t hwirq;
>> +unsigned int type;
>> +struct irq_fwspec *fwspec = arg;
>> +void *data;
>> +
>> +err = msichip_domain_translate(domain, fwspec, , );
>> +if (err)
>> +return err;
>> +
> 
> .translate function already called once in  irq_domain_translate(),
> I think we don't need call this fucntion one more time here.

if you don't translate it here, how do you obtain the hwirq that you
have to pass to irq_domain_set_hwirq_and_chip just below?

>> +err = platform_msi_domain_alloc(domain, virq, nr_irqs);
>> +if (err)
>> +return err;
>> +
>> +data = platform_msi_get_host_data(domain);
>> +for (i = 0; i < nr_irqs; i++)
>> +irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
>> +  _chip, data);
>> +
>> +return 0;
>> +}
>> +
> [...]
>> +
>> +static struct platform_driver msichip_driver = {
>> +.driver = {
>> +.name   = "msichip",
>> +.of_match_table = msichip_of_match,
>> +},
>> +.probe  = msichip_probe,
>> +};
>> +/* Do not define this as an irqchip */
>> +module_platform_driver(msichip_driver);
>> +
>> +
> 
> I think,for a interrupt controller, msichip driver initialization maybe is 
> too late
> for some devices which connect to this irqchip if we use 
> module_platform_driver.

That's a consequence of this design. This is why I insisted on the fact
that this is currently avoided by using deferred probe in drivers, and
that it should be solved by having a probe order. Either way, this is
not something that we can solve at that level (see the multiple proposal
for this on the various lists).

> So, how about use the arch_initcall to register the msichip driver?

You're only pushing the problem one level up. And you'll realize that
this is not enough for some random driver. This is not sustainable, and
must be addressed properly.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-04 Thread majun (F) 
Hi Marc:

在 2015/10/15 23:39, Marc Zyngier 写道:
> In order to demonstrate how to put together a wire/MSI bridge,
> add a dummy driver that doesn't do anything at all, except
> for allocating interrupts.
> 
> It comes together with an even more stupid client driver that
> allocates an interrupt and dump the hierarchy of that interrupt.
> 
> Signed-off-by: Marc Zyngier 
> ---
[...]
> +
> +static int msichip_domain_alloc(struct irq_domain *domain, unsigned int virq,
> +unsigned int nr_irqs, void *arg)
> +{
> + int i, err;
> + irq_hw_number_t hwirq;
> + unsigned int type;
> + struct irq_fwspec *fwspec = arg;
> + void *data;
> +
> + err = msichip_domain_translate(domain, fwspec, , );
> + if (err)
> + return err;
> +

.translate function already called once in  irq_domain_translate(),
I think we don't need call this fucntion one more time here.

> + err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> + if (err)
> + return err;
> +
> + data = platform_msi_get_host_data(domain);
> + for (i = 0; i < nr_irqs; i++)
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> +   _chip, data);
> +
> + return 0;
> +}
> +
[...]
> +
> +static struct platform_driver msichip_driver = {
> + .driver = {
> + .name   = "msichip",
> + .of_match_table = msichip_of_match,
> + },
> + .probe  = msichip_probe,
> +};
> +/* Do not define this as an irqchip */
> +module_platform_driver(msichip_driver);
> +
> +

I think,for a interrupt controller, msichip driver initialization maybe is too 
late
for some devices which connect to this irqchip if we use module_platform_driver.

So, how about use the arch_initcall to register the msichip driver?

Thanks!
Ma Jun









--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-04 Thread Marc Zyngier 
On 04/11/15 08:00, majun (F) wrote:
> Hi Marc:
> 
> 在 2015/10/15 23:39, Marc Zyngier 写道:
>> In order to demonstrate how to put together a wire/MSI bridge,
>> add a dummy driver that doesn't do anything at all, except
>> for allocating interrupts.
>>
>> It comes together with an even more stupid client driver that
>> allocates an interrupt and dump the hierarchy of that interrupt.
>>
>> Signed-off-by: Marc Zyngier 
>> ---
> [...]
>> +
>> +static int msichip_domain_alloc(struct irq_domain *domain, unsigned int 
>> virq,
>> +   unsigned int nr_irqs, void *arg)
>> +{
>> +int i, err;
>> +irq_hw_number_t hwirq;
>> +unsigned int type;
>> +struct irq_fwspec *fwspec = arg;
>> +void *data;
>> +
>> +err = msichip_domain_translate(domain, fwspec, , );
>> +if (err)
>> +return err;
>> +
> 
> .translate function already called once in  irq_domain_translate(),
> I think we don't need call this fucntion one more time here.

if you don't translate it here, how do you obtain the hwirq that you
have to pass to irq_domain_set_hwirq_and_chip just below?

>> +err = platform_msi_domain_alloc(domain, virq, nr_irqs);
>> +if (err)
>> +return err;
>> +
>> +data = platform_msi_get_host_data(domain);
>> +for (i = 0; i < nr_irqs; i++)
>> +irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
>> +  _chip, data);
>> +
>> +return 0;
>> +}
>> +
> [...]
>> +
>> +static struct platform_driver msichip_driver = {
>> +.driver = {
>> +.name   = "msichip",
>> +.of_match_table = msichip_of_match,
>> +},
>> +.probe  = msichip_probe,
>> +};
>> +/* Do not define this as an irqchip */
>> +module_platform_driver(msichip_driver);
>> +
>> +
> 
> I think,for a interrupt controller, msichip driver initialization maybe is 
> too late
> for some devices which connect to this irqchip if we use 
> module_platform_driver.

That's a consequence of this design. This is why I insisted on the fact
that this is currently avoided by using deferred probe in drivers, and
that it should be solved by having a probe order. Either way, this is
not something that we can solve at that level (see the multiple proposal
for this on the various lists).

> So, how about use the arch_initcall to register the msichip driver?

You're only pushing the problem one level up. And you'll realize that
this is not enough for some random driver. This is not sustainable, and
must be addressed properly.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

2015-11-04 Thread majun (F) 
Hi Marc:

在 2015/10/15 23:39, Marc Zyngier 写道:
> In order to demonstrate how to put together a wire/MSI bridge,
> add a dummy driver that doesn't do anything at all, except
> for allocating interrupts.
> 
> It comes together with an even more stupid client driver that
> allocates an interrupt and dump the hierarchy of that interrupt.
> 
> Signed-off-by: Marc Zyngier 
> ---
[...]
> +
> +static int msichip_domain_alloc(struct irq_domain *domain, unsigned int virq,
> +unsigned int nr_irqs, void *arg)
> +{
> + int i, err;
> + irq_hw_number_t hwirq;
> + unsigned int type;
> + struct irq_fwspec *fwspec = arg;
> + void *data;
> +
> + err = msichip_domain_translate(domain, fwspec, , );
> + if (err)
> + return err;
> +

.translate function already called once in  irq_domain_translate(),
I think we don't need call this fucntion one more time here.

> + err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> + if (err)
> + return err;
> +
> + data = platform_msi_get_host_data(domain);
> + for (i = 0; i < nr_irqs; i++)
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> +   _chip, data);
> +
> + return 0;
> +}
> +
[...]
> +
> +static struct platform_driver msichip_driver = {
> + .driver = {
> + .name   = "msichip",
> + .of_match_table = msichip_of_match,
> + },
> + .probe  = msichip_probe,
> +};
> +/* Do not define this as an irqchip */
> +module_platform_driver(msichip_driver);
> +
> +

I think,for a interrupt controller, msichip driver initialization maybe is too 
late
for some devices which connect to this irqchip if we use module_platform_driver.

So, how about use the arch_initcall to register the msichip driver?

Thanks!
Ma Jun









--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/