arm_pmu: fix lockdep issues with ACPI systems
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/5 | arm_pmu: have armpmu_alloc() take GFP flags | +0 | 1 reply | |
| 3/5 | arm_pmu: acpi: check for mismatched PPIs | +0 | 1 reply | |
| 3/5 | arm_pmu: acpi: check for mismatched PPIs | +0 | 0 replies | |
| 4/5 | arm_pmu: note IRQs/PMUs per-cpu | +0 | 1 reply | |
| 5/5 | arm_pmu: acpi: request IRQs up-front | +0 | 1 reply | |
| 5/5 | arm_pmu: acpi: request IRQs up-front | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] arm_pmu: fix lockdep issues with ACPI systems
Quoted 4 lines · Mark Rutland
Currently the
arm_pmuACPI code is somewhat dubious. It attempts ot allocate memory any manpiulate IRQs in a hotplug callback, which is an atomic context.
Quoted 8 lines
These patches (based on the arm64 for-next/core branch [1]) attempt to address this by moving work out of hotplug callback, requiring a reorganisation of the common
arm_pmucode.I've given these a boot-test on a Juno R1 system, both with DT and ACPI. In either case the PMU works as expected, and lockdep seems happy.
I've pushed the series out to my arm64/acpi-pmu-lockdep branch [2].
This mostly looks ok to me; I've left some minor comments on individual patches. My main concern is taking this as a fix, because there's an awful lot here.
Is there anything simpler we can do for 4.15/stable?
Will