On 10/24/2016 05:46 AM, Yuriy Kolerov wrote:
> This function takes a cpu number and a virq number and registers an
> appropriate handler per cpu. However smp_ipi_irq_setup is incorrectly
> used in several places of ARC platform code - hwirq is passed instead of
> virq. There is a code with an
Hi Yuriy,
On 10/24/2016 05:46 AM, Yuriy Kolerov wrote:
> This function takes a cpu number and a virq number and registers an
> appropriate handler per cpu. However smp_ipi_irq_setup is incorrectly
> used in several places of ARC platform code - hwirq is passed instead
> of virq. This patch is
Hi Daniel,
> -Original Message-
> From: linux-snps-arc [mailto:linux-snps-arc-boun...@lists.infradead.org] On
> Behalf Of Alexey Brodkin
> Sent: 19 октября 2016 г. 12:33
> To: dri-de...@lists.freedesktop.org; arch...@codeaurora.org;
> eugeniy.palt...@synopsys.com
> Cc:
Originally an initial distribution mode (its value resides in Device Tree)
for each common interrupt is set in idu_irq_xlate. This leads to the
following problems. idu_irq_xlate may be called several times during parsing
of the Device Tree and it is semantically wrong to configure an initial
Multicore ARC configurations use IDU (Interrupt Distribution Unit) for
distributing of common interrupts. In fact IDU is a interrupt controller
on top of main per core interrupt controller.
All common IRQs are physically and linearly mapped to per core
interrupts. E.g. <0, 1, 2, 3> common IDU
This function takes a cpu number and a virq number and registers an
appropriate handler per cpu. However smp_ipi_irq_setup is incorrectly
used in several places of ARC platform code - hwirq is passed instead of
virq. There is a code with an example of inccorect usage of smp_ipi_irq_setup:
From: Colin Ian King
arc_usr_cmpxchg currently returns an uninitialized value in ret
on a failed access_ok call. Instead, return -EFAULT.
Signed-off-by: Colin Ian King
---
arch/arc/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1
On Sat, Oct 22, 2016 at 03:14:04PM +0300, Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
>
> Therefore