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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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







[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux