Re: [PATCH 00/38] irqchip: mips-gic: Cleanup & optimisation

[Marc Zyngier <marc.zyngier@arm.com>]

Hi Paul,

On 13/08/17 05:36, Paul Burton wrote:
> This series cleans up the MIPS Global Interrupt Controller (GIC) driver
> somewhat. It moves us towards using a header in a similar vein to the
> ones we have for the MIPS Coherence Manager (CM) & Cluster Power
> Controller (CPC) which allows us to access the GIC outside of the
> irqchip driver - something beneficial already for the clocksource &
> clock event driver, and which will be beneficial for further drivers
> (eg. one for the GIC watchdog timer) and for multi-cluster work. Using
> this header is also beneficial for consistency & code-sharing.
> 
> In addition to cleanups the series also optimises the driver in various
> ways, including by using a per-CPU variable for pcpu_masks & removing
> the need to read the GIC_SH_MASK_* registers when decoding interrupts in
> gic_handle_shared_int().
> 
> This series requires my "[PATCH 00/19] MIPS: Initial multi-cluster
> support" series to be applied first.

I'm not on Cc on this one, so it is a bit hard to see what's going on.
But overall, it is incredibly difficult to follow what is going on here.
Everything seems to move around, and while I'm sure that you have
something in mind, the mix of fixes+optimizations+new features is a bit
hard to swallow (not to mention the VDSO stuff in the middle of what is
supposed to be an irqchip series).

Is there any chance you could rework this to have a more logical
ordering? Something like fixes first, new features next, and
optimizations in the end, organized by domains (arch stuff first, then
irqchip, then timer, then userspace)? Because at the moment, this is a
bit overwhelming...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...