Messages in this thread | | | Date | Wed, 12 Apr 2023 13:41:27 +0100 | Subject | Re: [PATCH 01/32] perf: Allow a PMU to have a parent | From | Robin Murphy <> |
| |
On 2023-04-06 17:44, Jonathan Cameron wrote: > On Thu, 6 Apr 2023 14:40:40 +0200 > Peter Zijlstra <peterz@infradead.org> wrote: > >> On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote: >> >>> In the long run I agree it would be good. Short term there are more instances of >>> struct pmu that don't have parents than those that do (even after this series). >>> We need to figure out what to do about those before adding checks on it being >>> set. >> >> Right, I don't think you've touched *any* of the x86 PMUs for example, >> and getting everybody that boots an x86 kernel a warning isn't going to >> go over well :-) >> > > It was tempting :) "Warning: Parentless PMU: try a different architecture." > > I'd love some inputs on what the x86 PMU devices parents should be? > CPU counters in general tend to just spin out of deep in the architecture code. > > My overall favorite is an l2 cache related PMU that is spun up in > arch/arm/kernel/irq.c init_IRQ() > > I'm just not going to try and figure out why...
I think that's simply because the PMU support was hung off the existing PL310 configuration code, which still supports non-DT boardfiles. The PMU shouldn't strictly need to be registered that early, it would just be a bunch more work to ensure that a platform device is available for it to bind to as a regular driver model driver, which wasn't justifiable at the time.
Thanks, Robin.
| |