[L] Change in coreboot[master]: sb/intel/common: Refactor _PRT generation to support GSI-based tables

[Nico Huber (Code Review)]

Attention is currently required from: Tim Wawrzynczak.

Nico Huber has posted comments on this change by Tim Wawrzynczak. ( https://review.coreboot.org/c/coreboot/+/50857?usp=email )

Change subject: sb/intel/common: Refactor _PRT generation to support GSI-based tables
......................................................................

Patch Set 22:

(1 comment)

File src/southbridge/intel/common/rcba_pirq.c:

https://review.coreboot.org/c/coreboot/+/50857/comment/a9e4344d_de9827f8?usp... :
PS22, Line 61: pin_irq_map = calloc(sizeof(struct slot_pin_irq_map), MAX_SLOTS * PCI_INT_MAX);
> > The two calloc calls are not equivalent indeed. […]

Looking at the code, the list is unordered, i.e. not a matrix of MAX_SLOTS x
PCI_INT_MAX but just a list of length MAX_SLOTS*PCI_INT_MAX. So IMO Angel is
correct, if we bikeshed this, we should do it right, then it would be
```
calloc(MAX_SLOTS * PCI_INT_MAX, sizeof(struct slot_pin_irq_map))
```

But anyway, before we discuss individual cases, is there any reason we should
care for the order of arguments at all? Even the manpage (calloc(3)) says it
has two arguments only to make overflows detectable. So the order shouldn't
matter, right? Especially not when all the arguments are constants. IMO this
discussion is not worth anything for coreboot.