Re: [PATCH V2] mips/octeon_3xxx: Fix a warning on octeon_3xxx

[David Daney <ddaney@caviumnetworks.com>]

On 03/19/2014 09:20 AM, Andreas Herrmann wrote:
> On Wed, Mar 19, 2014 at 05:51:41PM +0800, Yang,Wei wrote:
>> ping.
>
> I think, that the proper solution to avoid this warning is
> to fix the DTS information.
>

Just for the record:  The DTS is reflecting the actual routing of the 
signals within the SoC.  So I would argue that we shouldn't change it 
for these two reasons:

1) It accurately reflects reality.

2) There are deployed bootloaders that supply this to the kernel that 
are difficult to change.


> The warning started to trigger since commit
> 3da5278727a895d49a601f67fd49dffa0b80f9a5 (of/irq: Rework of_irq_count())
> was introduced.
>
> This changed of_irq_count() like this:
>
>   -       while (of_irq_to_resource(dev, nr, NULL))
>   +       while (of_irq_parse_one(dev, nr, &irq) == 0)
>
> Since then the code maps IRQs listed in the gpio-controller device
> node to its interrupt-parent, I think.
>
> Before this patch those interrupts weren't mapped at this point.
>
> I think both patches are fine to avoid the warning.  With the new
> version kind of a redundant mapping of GPIO interrupts happens (which
> will be overridden for an GPIO IRQ as soon as it is really used).
> This makes me think that the warning makes sense and the DTS needs to
> be fixed. (We should not use octeon_irq_ciu_xlat/octeon_irq_ciu_map
> for GPIO lines.)
>
> I might be wrong but maybe specifying an interrupt-parent for the
> gpio-controller (and thus listing the GPIO IRQs in the gpio-controller
> device node) was not a good choice.
>

Andreas has a slightly modified version of the V2 patch that we tested, 
and it seems to work.  I think we should go with that instead of the V2 
patch.

David Daney


>
>>