From style(9):
No braces ({' and }') are used for control statements with zero or only a single statement unless that statement is more than a single line in which case they are permitted.

Hmm? I don't think you can call init_func(sc); here. It would be an error.
Extra indirection seemed more convenient here since:

1. we will have at least one more function here
2. we have secondary cores initialization sequence (that andrew requested to be removed from this commit) and it is more convenient to see what are the differences between those thwo
3. the overhead of writing this loop is the same as writing 3-4 times:

err = func1();
if (err != 0)
      goto error;
err = func2();
if (err != 0)
      goto error;
....

This comment is now completely detached from the code it was commenting on.

My point was that these two lines are equivelent:

(*init_func)();
init_func();

When you've got a pointer to a function, the compiler knows that, there's no need to add parens and a star to make it call through the pointer.

You can comment to the previous diff and the comment will be in the right place.
But back to the topic, I've made a quick test:

error: called object type 'gic_v3_initseq_t *' (aka 'int (**)(struct gic_v3_softc *)') is not a function or function pointer
               err = init_func(sc);
                     ~~~~~~~~~^

Oh! I completely missed that the pointer was double-indirect through the typedef. My mistake, sorry about that.

i is used as a kosher way to iterate in loop - using size_t type, whereas rid has to be int.

Although this won't work if sc->gic_redists.nregions > INT_MAX anyway - we could probably just document that fact with a KASSERT.

OK. I will remove i from this loop. Regarding gic_refists.nregions + 1 then AFAIK we have proper comment when allocating resource:

	/*
	 * Allocate array of struct resource.
	 * One entry for Distributor and all remaining for Re-Distributor.
	 */

So now we have to comment on allocation and deallocation?

This is the same "32" as in "uint32_t".
I can see a certain amount of exaggeration to define things. I don't think using

sizeof(uint32_t) * NBBY

looks better here.

Why not do this something like:

#define GICD_ICENABLER(irq) (0x0180 + (((irq) >> 5) * 4))
#define GICD_INTR_MASK(irq) (1u << ((irq) % 32))

gic_r_write(sc, 4, GICD_ICENABLER(irq), GICD_INTR_MASK(irq));

This may be more reasonable

Yes. This is taken from Linux.

Still looks better than PCPU_GET(cpuid) in line.

yes, yes READ_SPECIALREG

This can be changed to FIRST_SPI indeed.

Added macros

normally?

typically for style(9)

I don't see it mentioned in style(9), but I've always been told bitwise comparison of e.g. flags should be == 0 or != 0. This might just be tribal knowledge passed on via mailing lists / code review and should be added to style(9).

OK. I see.

I think it comes from Do not use ! for tests unless it is a boolean,....

Yes, indeed. I'll see about feeding all of these back into style(9).