On Wed, 01 Dec 2021 16:08:13 +0000, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Wed, Dec 01, 2021 at 01:49:04PM +0000, Marc Zyngier wrote: > > In order to be able to tell the core IRQ code about the affinity > > of the PMU interrupt in later patches, compute the cpumasks of the > > P and E cores at boot time. > > > > This relies on the affinity scheme used by the vendor, which seems > > to work for the couple of SoCs that are out in the wild. > > ... but may change at any arbitrary point in future? Crystal balls are in short supply, sorry! ;-) > Can we please put the affinity in the DT, like we do for other SoCs and > devices? > > I don't think we should treat this HW specially in this regard; we certaintly > don't want other folk hard-coding system topology in their irqchip driver, and > it should be possible to do something like the ppi-partitions binding, no? The PPI partition is totally overkill here. What it deals with is multiple devices sharing a single PPI across the system. Here, we can invent our own interrupt number, so the sharing is avoided by construction (the joy of not having an interrupt controller the first place!). I'm happy to stick the affinity in the DT (after all, it is likely that other devices on these systems have the same requirements) and have it consumed by the irqchip driver. I only need to find a way that doesn't completely invalidate the existing binding... M. -- Without deviation from the norm, progress is not possible.
