I will refrain from making further comments for separate lines or code blocks, I think what we all see here is clear.
Basically I don't understand this methodology to create a new file while adding support for INTRNG :-).
As far as I know (please correct me if I'm wrong), for INTRNG we need a set of callbacks such as enable interrupt, disable interrupt, post-filter, pre-ithread, etc. These are basically what we do now in GIC/ITS, if_pic.m so minor changes should be required to modify existing code and add missing routines required by INTRNG.
So how would you justify a need for a new file, moving the code around, changing names and definitions, etc.?

I wanted to change many of the internal functions to handle the differences between the old interrupt handling code and intrng, e.g. the its_cmd_ now take a struct gicv3_its_irqsrc * as this fully describes the interrupt.

I have also used this a chance to reduce the interdependence between the GICv3 and ITS drivers, e.g. we could build a kernel without ITS support if needed. We should also be able to change the GICv3 driver around if needed as the ITS driver should only know about a few public interfaces.

I get that we have new API, new callbacks to provide, new interrupt description, etc. but this doesn't explain all other modifications that do not change the functionality but rather naming, code location, etc. I can see the differences such as using

desc.cmd_desc_movi.id = girq->gi_irq - girq->gi_its_dev->lpis.lpi_base;

in movi command instead of i.e.

irq = irq - its_dev->lpis.lpi_base;
its_cmd_movi(sc, its_dev, col, irq);

but that is not something that cannot be applied on-top of the current ITS implementation, don't you think?

I'm intending on pushing the struct gicv3_its_irqsrc * further into the code, but am also trying to touch the common headers as little as possible so some further cleanups will need to wait until we only have a single driver.

Again, I would prefer a patch against existing ITS code not instead of it. This would allow us to track the diff properly and here it's hardly possible. Most of my previous remarks still apply ;-).

In D6437#140235, @zbb wrote:

Again, I would prefer a patch against existing ITS code not instead of it. This would allow us to track the diff properly and here it's hardly possible. Most of my previous remarks still apply ;-).

Many of the remarks are how I've done things different than the existing driver. This is expected when one of the goals was to reduce the knowledge of the internals of the GICv3 driver.

In D6437#140473, @andrew wrote:

In D6437#140235, @zbb wrote:

Again, I would prefer a patch against existing ITS code not instead of it. This would allow us to track the diff properly and here it's hardly possible. Most of my previous remarks still apply ;-).

Many of the remarks are how I've done things different than the existing driver. This is expected when one of the goals was to reduce the knowledge of the internals of the GICv3 driver.

I would say few remarks were to the new code and they were explained. Most of the remarks however are for the existing code modifications that were not explained.
For example how does that reduces knowledge of GICv3 driver:

- #define	 ITS_FLAGS_CMDQ_FLUSH           (1UL << 0)
+ #define        ITS_FLAGS_CMDQ_FLUSH           0x00000001

There is no sense to make such remarks line by line but I think it is pretty obvious what I'm asking you to explain, isn't it?
Why can't we have a patch adding INTRNG support for the existing GICv3/ITS drivers instead we move the code around, change names of the variables and redefine macros in order to create a new file?

For example when you get to the point when you would like to add superpages support to pmap I presume you will not create a new file, let's say "p-map.c" with the old code modified to support superpages and containing other modifications such as redefinition of bit masks, macros, variable names and code moved from one function to the upper level function, etc.? I suspect you would add the patch for the existing pmap.c file that will allow it to utilize superpages. That is why I'm curious why the approach here is different.

In D6437#140787, @zbb wrote:

For example when you get to the point when you would like to add superpages support to pmap I presume you will not create a new file, let's say "p-map.c" with the old code modified to support superpages and containing other modifications such as redefinition of bit masks, macros, variable names and code moved from one function to the upper level function, etc.? I suspect you would add the patch for the existing pmap.c file that will allow it to utilize superpages. That is why I'm curious why the approach here is different.

Adding supperpages is different, there is no change in the interface to add support. If the pmap interface was to be significantly changed I would expect to create a new file to handle the change. This is not the case with superpages.