linux-kernel - Re: [PATCH] DTS: DMA: Fix DMA3 interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1386700403.10013.109.camel@snotra.buserror.net>
Date:	Tue, 10 Dec 2013 12:33:23 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Hongbo Zhang <hongbo.zhang@...escale.com>
CC:	<benh@...nel.crashing.org>, <linuxppc-dev@...ts.ozlabs.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] DTS: DMA: Fix DMA3 interrupts

On Tue, 2013-12-10 at 18:33 +0800, Hongbo Zhang wrote:
> Scott,
> This issue is due to the non-continuous MPIC register, I think there is 
> two ways to fix it.
> 
> The first one is as what we are discussing, in fact the Bman/Qman DT 
> author had introduced this way, and I had to follow it, it is a trick, 
> adding 208 is a bit ugly I think, and even difficult to explain it to 
> customers etc, but this way changes less codes.
> 
> The second one is editing MPIC related codes without adding 208 to high 
> interrupts. The point of translate interrupt number to MPIC register 
> address is a so called 'isu' mechanism, we can do like the following 
> example codes, then the tricky adding 208 isn't needed any more.
> 
> Which one do you prefer?
> In fact I myself prefer the second, if the idea is acceptable, I will 
> send a patch instead of this one. (and also alone with the internal 
> patch decreasing 208 for the Bman/Qman)
> 
> void __init corenet_ds_pic_init(void)
> {
>      ......
> 
>      mpic = mpic_alloc(NULL, 0, flags, 0, 512, "OpenPIC");
>      BUG_ON(mpic == NULL);
> 
> // Add this start
>      for (i = 0; i < 17; i++) {
>          if (i < 11)
>              addr_off = 0x10000 + 0x20 * 16 * i;
>          else
>              addr_off = 0x13000 + 0x20 * 16 * (i - 11);  /* scape the 
> address not for interrupts */
>          mpic_assign_isu(mpic, i, mpic->paddr + addr_off);
>      }
> // Add this end
> 
>      mpic_init(mpic);
> }

NACK

We already have a binding that states that the interrupt number is based
on the register offset, rather than whatever arbitrary numbers hardware
documenters decide to use next week.

While I'm not terribly happy with the usability of this, especially now
that it's not a simple "add 16", redefining the existing binding is not
OK (and in any case the code above seems obfuscatory).  If we decide to
do something other than continue with register offset divided by 32,
then we need to define a new interrupt type (similar to current defined
types of error interrupt, timer, and IPI) for the new numberspace -- and
it should be handled when decoding that type of interrupt specifier,
rather than with the isu mechanism.

-Scott



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