| Message ID | tencent_7B71486CE305DF8AE084B6BB6313EE550C06@qq.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b | expand |
On Thu, Jun 20, 2024 at 11:04:28AM +0800, Yangyu Chen wrote: > Events 0x96 and 0x9b can be installed on counter 7 only. Fix this to avoid > getting the wrong counter value. > > Signed-off-by: Yangyu Chen <cyy@cyyself.name> > --- > drivers/perf/apple_m1_cpu_pmu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c > index f322e5ca1114..b8127e5428e1 100644 > --- a/drivers/perf/apple_m1_cpu_pmu.c > +++ b/drivers/perf/apple_m1_cpu_pmu.c > @@ -107,12 +107,12 @@ static const u16 m1_pmu_event_affinity[M1_PMU_PERFCTR_LAST + 1] = { > [M1_PMU_PERFCTR_UNKNOWN_93] = ONLY_5_6_7, > [M1_PMU_PERFCTR_UNKNOWN_94] = ONLY_5_6_7, > [M1_PMU_PERFCTR_UNKNOWN_95] = ONLY_5_6_7, > - [M1_PMU_PERFCTR_UNKNOWN_96] = ONLY_5_6_7, > + [M1_PMU_PERFCTR_UNKNOWN_96] = BIT(7), > [M1_PMU_PERFCTR_UNKNOWN_97] = BIT(7), > [M1_PMU_PERFCTR_UNKNOWN_98] = ONLY_5_6_7, > [M1_PMU_PERFCTR_UNKNOWN_99] = ONLY_5_6_7, > [M1_PMU_PERFCTR_UNKNOWN_9a] = BIT(7), > - [M1_PMU_PERFCTR_UNKNOWN_9b] = ONLY_5_6_7, > + [M1_PMU_PERFCTR_UNKNOWN_9b] = BIT(7), > [M1_PMU_PERFCTR_UNKNOWN_9c] = ONLY_5_6_7, > [M1_PMU_PERFCTR_UNKNOWN_9f] = BIT(7), > [M1_PMU_PERFCTR_UNKNOWN_bf] = ONLY_5_6_7, It would be great if somebody with access to M1 hardware (and/or any PMU insight) could Test or Ack this, please. Cheers, Will
On Mon, 01 Jul 2024 15:01:48 +0100, Will Deacon <will@kernel.org> wrote: > > On Thu, Jun 20, 2024 at 11:04:28AM +0800, Yangyu Chen wrote: > > Events 0x96 and 0x9b can be installed on counter 7 only. Fix this to avoid > > getting the wrong counter value. > > > > Signed-off-by: Yangyu Chen <cyy@cyyself.name> > > --- > > drivers/perf/apple_m1_cpu_pmu.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c > > index f322e5ca1114..b8127e5428e1 100644 > > --- a/drivers/perf/apple_m1_cpu_pmu.c > > +++ b/drivers/perf/apple_m1_cpu_pmu.c > > @@ -107,12 +107,12 @@ static const u16 m1_pmu_event_affinity[M1_PMU_PERFCTR_LAST + 1] = { > > [M1_PMU_PERFCTR_UNKNOWN_93] = ONLY_5_6_7, > > [M1_PMU_PERFCTR_UNKNOWN_94] = ONLY_5_6_7, > > [M1_PMU_PERFCTR_UNKNOWN_95] = ONLY_5_6_7, > > - [M1_PMU_PERFCTR_UNKNOWN_96] = ONLY_5_6_7, > > + [M1_PMU_PERFCTR_UNKNOWN_96] = BIT(7), > > [M1_PMU_PERFCTR_UNKNOWN_97] = BIT(7), > > [M1_PMU_PERFCTR_UNKNOWN_98] = ONLY_5_6_7, > > [M1_PMU_PERFCTR_UNKNOWN_99] = ONLY_5_6_7, > > [M1_PMU_PERFCTR_UNKNOWN_9a] = BIT(7), > > - [M1_PMU_PERFCTR_UNKNOWN_9b] = ONLY_5_6_7, > > + [M1_PMU_PERFCTR_UNKNOWN_9b] = BIT(7), > > [M1_PMU_PERFCTR_UNKNOWN_9c] = ONLY_5_6_7, > > [M1_PMU_PERFCTR_UNKNOWN_9f] = BIT(7), > > [M1_PMU_PERFCTR_UNKNOWN_bf] = ONLY_5_6_7, > > It would be great if somebody with access to M1 hardware (and/or any > PMU insight) could Test or Ack this, please. I'm a bit concerned by this. I originally generated this table by hacking the counter setup so that it would try and count everywhere, and then feed the observations back into the driver. So either my methodology was flaky (not unlikely), but I'd then expect more of these mis-assignments, or this applies to an implementation that is different from the one I wrote this driver against (the original M1). Could it be that this for M2 only, and not M1? Or another flavour of M1? Either way, it would be good to understand how this has been established. In the meantime, I'll try and resurrect my original experiment and see if I spot the same issue. Thanks, M.
On Mon, 01 Jul 2024 15:19:59 +0100, Marc Zyngier <maz@kernel.org> wrote: > > On Mon, 01 Jul 2024 15:01:48 +0100, > Will Deacon <will@kernel.org> wrote: > > > > On Thu, Jun 20, 2024 at 11:04:28AM +0800, Yangyu Chen wrote: > > > Events 0x96 and 0x9b can be installed on counter 7 only. Fix this to avoid > > > getting the wrong counter value. > > > > > > Signed-off-by: Yangyu Chen <cyy@cyyself.name> > > > --- > > > drivers/perf/apple_m1_cpu_pmu.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c > > > index f322e5ca1114..b8127e5428e1 100644 > > > --- a/drivers/perf/apple_m1_cpu_pmu.c > > > +++ b/drivers/perf/apple_m1_cpu_pmu.c > > > @@ -107,12 +107,12 @@ static const u16 m1_pmu_event_affinity[M1_PMU_PERFCTR_LAST + 1] = { > > > [M1_PMU_PERFCTR_UNKNOWN_93] = ONLY_5_6_7, > > > [M1_PMU_PERFCTR_UNKNOWN_94] = ONLY_5_6_7, > > > [M1_PMU_PERFCTR_UNKNOWN_95] = ONLY_5_6_7, > > > - [M1_PMU_PERFCTR_UNKNOWN_96] = ONLY_5_6_7, > > > + [M1_PMU_PERFCTR_UNKNOWN_96] = BIT(7), > > > [M1_PMU_PERFCTR_UNKNOWN_97] = BIT(7), > > > [M1_PMU_PERFCTR_UNKNOWN_98] = ONLY_5_6_7, > > > [M1_PMU_PERFCTR_UNKNOWN_99] = ONLY_5_6_7, > > > [M1_PMU_PERFCTR_UNKNOWN_9a] = BIT(7), > > > - [M1_PMU_PERFCTR_UNKNOWN_9b] = ONLY_5_6_7, > > > + [M1_PMU_PERFCTR_UNKNOWN_9b] = BIT(7), > > > [M1_PMU_PERFCTR_UNKNOWN_9c] = ONLY_5_6_7, > > > [M1_PMU_PERFCTR_UNKNOWN_9f] = BIT(7), > > > [M1_PMU_PERFCTR_UNKNOWN_bf] = ONLY_5_6_7, > > > > It would be great if somebody with access to M1 hardware (and/or any > > PMU insight) could Test or Ack this, please. > > I'm a bit concerned by this. > > I originally generated this table by hacking the counter setup so that > it would try and count everywhere, and then feed the observations back > into the driver. > > So either my methodology was flaky (not unlikely), but I'd then expect > more of these mis-assignments, or this applies to an implementation > that is different from the one I wrote this driver against (the > original M1). Could it be that this for M2 only, and not M1? Or > another flavour of M1? > > Either way, it would be good to understand how this has been > established. > > In the meantime, I'll try and resurrect my original experiment and see > if I spot the same issue. A quick experiment shows that these events are counting on all 3 expected counters: maz@mary-lou:~$ sudo taskset -c 8 perf stat -e r096:u -e r096:u -e r096:u sleep 5 Performance counter stats for 'sleep 5': 10,775 r096:u 10,775 r096:u 10,775 r096:u 5.000110823 seconds time elapsed 0.000340000 seconds user 0.000000000 seconds sys maz@mary-lou:~$ sudo taskset -c 8 perf stat -e r09b:u -e r09b:u -e r09b:u sleep 5 Performance counter stats for 'sleep 5': 41,927 r09b:u 41,927 r09b:u 41,927 r09b:u 5.000109771 seconds time elapsed 0.000339000 seconds user 0.000000000 seconds sys This is on M2 Pro, by the way, and I also checked that my M1 Ultra counts the exact same way. Yangyu, can you please clarify how you came to the conclusion that these events didn't count anywhere other than counter 7? M.
> Yangyu, can you please clarify how you came to the conclusion that > these events didn't count anywhere other than counter 7? > IIRC, I came across some web page that says events 0x96 and 0x9b can only be installed on counter 7 to count Apple AMX, but I can't find the page now. Since AMX is not usable in Linux, I don't know if this will affect some other instructions that are usable in Linux. There are some other reasons, but I can't say in public. Even though I can't find the actual usage, I think using count 7 only for these 2 events is safer. If this reason is insufficient, we can ignore this patch until we find other evidence that this affinity affects some instructions usable in Linux. Thanks, Yangyu Chen
On Tue, 02 Jul 2024 11:22:21 +0100, Yangyu Chen <cyy@cyyself.name> wrote: > > > Yangyu, can you please clarify how you came to the conclusion that > > these events didn't count anywhere other than counter 7? > > > > IIRC, I came across some web page that says events 0x96 and 0x9b > can only be installed on counter 7 to count Apple AMX, but I can't > find the page now. Since AMX is not usable in Linux, I don't know > if this will affect some other instructions that are usable in > Linux. As you said, AMX cannot be used with Linux, and that's unlikely to ever change. But when it comes to the standard ARM ISA, we can only witness counters 5,6 and 7 being incremented with at the exact same rate. So reading between the lines, what I understand is that AMX instructions would only have their effects counted in counter 7 for these events, while other instructions would be counted in all 3 counters. By extension, such behaviour could be applied to SME on HW that supports it (wild guess). > There are some other reasons, but I can't say in public. Fair enough, I'm not asking for the disclosure of anything that isn't public (the least I know, the better). > Even though I can't find the actual usage, I think using count 7 > only for these 2 events is safer. If this reason is insufficient, > we can ignore this patch until we find other evidence that this > affinity affects some instructions usable in Linux. I honestly don't mind. The whole thing is a black box, and is more useful as an interrupt generator than an actual PMU, due to the lack of freely available documentation. If the PMU maintainers want to merge this, I won't oppose it. Thanks, M.
On Tue, Jul 02, 2024 at 11:58:00AM +0100, Marc Zyngier wrote: > On Tue, 02 Jul 2024 11:22:21 +0100, > Yangyu Chen <cyy@cyyself.name> wrote: > > > > > Yangyu, can you please clarify how you came to the conclusion that > > > these events didn't count anywhere other than counter 7? > > > > > > > IIRC, I came across some web page that says events 0x96 and 0x9b > > can only be installed on counter 7 to count Apple AMX, but I can't > > find the page now. Since AMX is not usable in Linux, I don't know > > if this will affect some other instructions that are usable in > > Linux. > > As you said, AMX cannot be used with Linux, and that's unlikely to > ever change. But when it comes to the standard ARM ISA, we can only > witness counters 5,6 and 7 being incremented with at the exact same > rate. > > So reading between the lines, what I understand is that AMX > instructions would only have their effects counted in counter 7 for > these events, while other instructions would be counted in all 3 > counters. > > By extension, such behaviour could be applied to SME on HW that > supports it (wild guess). > > > There are some other reasons, but I can't say in public. > > Fair enough, I'm not asking for the disclosure of anything that isn't > public (the least I know, the better). > > > Even though I can't find the actual usage, I think using count 7 > > only for these 2 events is safer. If this reason is insufficient, > > we can ignore this patch until we find other evidence that this > > affinity affects some instructions usable in Linux. > > I honestly don't mind. > > The whole thing is a black box, and is more useful as an interrupt > generator than an actual PMU, due to the lack of freely available > documentation. If the PMU maintainers want to merge this, I won't > oppose it. I'd rather leave the code as-is than tweak specific counters based on a combination of guesswork and partial information. Of course, if somebody who knows better wants to fix up all of the mappings (because this surely isn't the only corner-case), then we can take that. But at least what we have today has _some_ sort of consistent rationale behind it. Will
> On Jul 2, 2024, at 20:13, Will Deacon <will@kernel.org> wrote: > > On Tue, Jul 02, 2024 at 11:58:00AM +0100, Marc Zyngier wrote: >> On Tue, 02 Jul 2024 11:22:21 +0100, >> Yangyu Chen <cyy@cyyself.name> wrote: >>> >>>> Yangyu, can you please clarify how you came to the conclusion that >>>> these events didn't count anywhere other than counter 7? >>>> >>> >>> IIRC, I came across some web page that says events 0x96 and 0x9b >>> can only be installed on counter 7 to count Apple AMX, but I can't >>> find the page now. Since AMX is not usable in Linux, I don't know >>> if this will affect some other instructions that are usable in >>> Linux. >> >> As you said, AMX cannot be used with Linux, and that's unlikely to >> ever change. But when it comes to the standard ARM ISA, we can only >> witness counters 5,6 and 7 being incremented with at the exact same >> rate. >> >> So reading between the lines, what I understand is that AMX >> instructions would only have their effects counted in counter 7 for >> these events, while other instructions would be counted in all 3 >> counters. >> >> By extension, such behaviour could be applied to SME on HW that >> supports it (wild guess). >> >>> There are some other reasons, but I can't say in public. >> >> Fair enough, I'm not asking for the disclosure of anything that isn't >> public (the least I know, the better). >> >>> Even though I can't find the actual usage, I think using count 7 >>> only for these 2 events is safer. If this reason is insufficient, >>> we can ignore this patch until we find other evidence that this >>> affinity affects some instructions usable in Linux. >> >> I honestly don't mind. >> >> The whole thing is a black box, and is more useful as an interrupt >> generator than an actual PMU, due to the lack of freely available >> documentation. If the PMU maintainers want to merge this, I won't >> oppose it. > > I'd rather leave the code as-is than tweak specific counters based on > a combination of guesswork and partial information. > > Of course, if somebody who knows better wants to fix up all of the > mappings (because this surely isn't the only corner-case), then we can > take that. But at least what we have today has _some_ sort of consistent > rationale behind it. Actually, anyone who has macOS software can learn the whole affinity table of PMU. The detailed information can be extracted from a plist file stored in the macOS root filesystem. I also provide that script [1] to extract this information. However, I can't directly use this information for legal concerns. Would this be acceptable if the information I provide matches Apple's information? I can't say whether it matches or not in public. I can only say we can easily find someone who uploaded this file to the internet. [1] https://github.com/cyyself/m1-pmu-gen > > Will
On Tue, Jul 02, 2024 at 08:43:16PM +0800, Yangyu Chen wrote: > > > > On Jul 2, 2024, at 20:13, Will Deacon <will@kernel.org> wrote: > > > > On Tue, Jul 02, 2024 at 11:58:00AM +0100, Marc Zyngier wrote: > >> On Tue, 02 Jul 2024 11:22:21 +0100, > >> Yangyu Chen <cyy@cyyself.name> wrote: > >>> > >>>> Yangyu, can you please clarify how you came to the conclusion that > >>>> these events didn't count anywhere other than counter 7? > >>>> > >>> > >>> IIRC, I came across some web page that says events 0x96 and 0x9b > >>> can only be installed on counter 7 to count Apple AMX, but I can't > >>> find the page now. Since AMX is not usable in Linux, I don't know > >>> if this will affect some other instructions that are usable in > >>> Linux. > >> > >> As you said, AMX cannot be used with Linux, and that's unlikely to > >> ever change. But when it comes to the standard ARM ISA, we can only > >> witness counters 5,6 and 7 being incremented with at the exact same > >> rate. > >> > >> So reading between the lines, what I understand is that AMX > >> instructions would only have their effects counted in counter 7 for > >> these events, while other instructions would be counted in all 3 > >> counters. > >> > >> By extension, such behaviour could be applied to SME on HW that > >> supports it (wild guess). > >> > >>> There are some other reasons, but I can't say in public. > >> > >> Fair enough, I'm not asking for the disclosure of anything that isn't > >> public (the least I know, the better). > >> > >>> Even though I can't find the actual usage, I think using count 7 > >>> only for these 2 events is safer. If this reason is insufficient, > >>> we can ignore this patch until we find other evidence that this > >>> affinity affects some instructions usable in Linux. > >> > >> I honestly don't mind. > >> > >> The whole thing is a black box, and is more useful as an interrupt > >> generator than an actual PMU, due to the lack of freely available > >> documentation. If the PMU maintainers want to merge this, I won't > >> oppose it. > > > > I'd rather leave the code as-is than tweak specific counters based on > > a combination of guesswork and partial information. > > > > Of course, if somebody who knows better wants to fix up all of the > > mappings (because this surely isn't the only corner-case), then we can > > take that. But at least what we have today has _some_ sort of consistent > > rationale behind it. > > Actually, anyone who has macOS software can learn the whole affinity > table of PMU. The detailed information can be extracted from a plist > file stored in the macOS root filesystem. I also provide that script > [1] to extract this information. > > However, I can't directly use this information for legal concerns. > Would this be acceptable if the information I provide matches Apple's > information? I can't say whether it matches or not in public. I can > only say we can easily find someone who uploaded this file to the > internet. > > [1] https://github.com/cyyself/m1-pmu-gen I can't say I feel hugely comfortable with this, so I'll leave the code as-is unless a patch shows up fixing all the events. Thanks for the reply, though. You've clearly spent a bunch of effort on this and it's a pity we can't easily apply your results to the driver :/ Will
On 2024/07/08 21:00, Will Deacon wrote: > On Tue, Jul 02, 2024 at 08:43:16PM +0800, Yangyu Chen wrote: >> >> >>> On Jul 2, 2024, at 20:13, Will Deacon <will@kernel.org> wrote: >>> >>> On Tue, Jul 02, 2024 at 11:58:00AM +0100, Marc Zyngier wrote: >>>> On Tue, 02 Jul 2024 11:22:21 +0100, >>>> Yangyu Chen <cyy@cyyself.name> wrote: >>>>> >>>>>> Yangyu, can you please clarify how you came to the conclusion that >>>>>> these events didn't count anywhere other than counter 7? >>>>>> >>>>> >>>>> IIRC, I came across some web page that says events 0x96 and 0x9b >>>>> can only be installed on counter 7 to count Apple AMX, but I can't >>>>> find the page now. Since AMX is not usable in Linux, I don't know >>>>> if this will affect some other instructions that are usable in >>>>> Linux. >>>> >>>> As you said, AMX cannot be used with Linux, and that's unlikely to >>>> ever change. But when it comes to the standard ARM ISA, we can only >>>> witness counters 5,6 and 7 being incremented with at the exact same >>>> rate. >>>> >>>> So reading between the lines, what I understand is that AMX >>>> instructions would only have their effects counted in counter 7 for >>>> these events, while other instructions would be counted in all 3 >>>> counters. >>>> >>>> By extension, such behaviour could be applied to SME on HW that >>>> supports it (wild guess). >>>> >>>>> There are some other reasons, but I can't say in public. >>>> >>>> Fair enough, I'm not asking for the disclosure of anything that isn't >>>> public (the least I know, the better). >>>> >>>>> Even though I can't find the actual usage, I think using count 7 >>>>> only for these 2 events is safer. If this reason is insufficient, >>>>> we can ignore this patch until we find other evidence that this >>>>> affinity affects some instructions usable in Linux. >>>> >>>> I honestly don't mind. >>>> >>>> The whole thing is a black box, and is more useful as an interrupt >>>> generator than an actual PMU, due to the lack of freely available >>>> documentation. If the PMU maintainers want to merge this, I won't >>>> oppose it. >>> >>> I'd rather leave the code as-is than tweak specific counters based on >>> a combination of guesswork and partial information. >>> >>> Of course, if somebody who knows better wants to fix up all of the >>> mappings (because this surely isn't the only corner-case), then we can >>> take that. But at least what we have today has _some_ sort of consistent >>> rationale behind it. >> >> Actually, anyone who has macOS software can learn the whole affinity >> table of PMU. The detailed information can be extracted from a plist >> file stored in the macOS root filesystem. I also provide that script >> [1] to extract this information. >> >> However, I can't directly use this information for legal concerns. >> Would this be acceptable if the information I provide matches Apple's >> information? I can't say whether it matches or not in public. I can >> only say we can easily find someone who uploaded this file to the >> internet. >> >> [1] https://github.com/cyyself/m1-pmu-gen > > I can't say I feel hugely comfortable with this, so I'll leave the code > as-is unless a patch shows up fixing all the events. > > Thanks for the reply, though. You've clearly spent a bunch of effort on > this and it's a pity we can't easily apply your results to the driver :/ > > Will > Putting on my "reverse engineering hardware for over a decade" hat on: Facts about hardware are not copyrightable. If they were, our entire effort would be legally questionable to begin with (as would all Linux porting efforts to undocumented hardware). Data files can be, but if the information contained within them is purely non-copyrightable (as an affinity mapping for PMU events would be), then it is entirely legal and acceptable to use that information to create a patch, as long as the information itself was legitimately obtained (which it can be for any macOS user, which by extension means any owner of an AS Mac since macOS is implicitly licensed). In other words, if you have macOS, and you run those scripts and generate some patches for Linux that add the event definitions and mappings, then it would not cause any copyright infringement concerns for the Linux kernel side and they can be licensed GPLv2. I have acquaintances who have consulted lawyers about this issue and am very confident in this interpretation. More specifically, I'm told there is legal advice that hardware register names are not copyrightable (which goes beyond pure hardware facts as there is some freedom to choose naming schemes). PMU event names are analogous here. The big no-nos are ripping and redistributing files from macOS verbatim (when that is necessary, we treat it as firmware and already have a process in place to avoid redistribution, e.g. what we do for camera sensor calibration blobs, but that is not the case here), using *leaked/stolen* information (not legitimately obtained, e.g. actual internal documentation that was stolen), and potentially decompiling/reverse engineering actual executable code (things get very complicated in this case, but it is not impossible to do legally). For more details, we have a page on our copyright policy for the Asahi project and how to avoid running into legal issues: https://asahilinux.org/copyright/ TL;DR I would not have any copyright concerns about submission of a patch adding all the PMU definitions (general event names and affinity mappings). - Hector
diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c index f322e5ca1114..b8127e5428e1 100644 --- a/drivers/perf/apple_m1_cpu_pmu.c +++ b/drivers/perf/apple_m1_cpu_pmu.c @@ -107,12 +107,12 @@ static const u16 m1_pmu_event_affinity[M1_PMU_PERFCTR_LAST + 1] = { [M1_PMU_PERFCTR_UNKNOWN_93] = ONLY_5_6_7, [M1_PMU_PERFCTR_UNKNOWN_94] = ONLY_5_6_7, [M1_PMU_PERFCTR_UNKNOWN_95] = ONLY_5_6_7, - [M1_PMU_PERFCTR_UNKNOWN_96] = ONLY_5_6_7, + [M1_PMU_PERFCTR_UNKNOWN_96] = BIT(7), [M1_PMU_PERFCTR_UNKNOWN_97] = BIT(7), [M1_PMU_PERFCTR_UNKNOWN_98] = ONLY_5_6_7, [M1_PMU_PERFCTR_UNKNOWN_99] = ONLY_5_6_7, [M1_PMU_PERFCTR_UNKNOWN_9a] = BIT(7), - [M1_PMU_PERFCTR_UNKNOWN_9b] = ONLY_5_6_7, + [M1_PMU_PERFCTR_UNKNOWN_9b] = BIT(7), [M1_PMU_PERFCTR_UNKNOWN_9c] = ONLY_5_6_7, [M1_PMU_PERFCTR_UNKNOWN_9f] = BIT(7), [M1_PMU_PERFCTR_UNKNOWN_bf] = ONLY_5_6_7,
Events 0x96 and 0x9b can be installed on counter 7 only. Fix this to avoid getting the wrong counter value. Signed-off-by: Yangyu Chen <cyy@cyyself.name> --- drivers/perf/apple_m1_cpu_pmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)