Now that perf supports giving the PMU device a parent, we can use our
platform device to make the relationship between CMN instances and PMU
IDs trivially discoverable, from either nominal direction:
root@crazy-taxi:~# ls /sys/devices/platform/ARMHC600:00 | grep cmn
arm_cmn_0
root@crazy-taxi:~# realpath /sys/bus/event_source/devices/arm_cmn_0/..
/sys/devices/platform/ARMHC600:00
Signed-off-by: Robin Murphy <[email protected]>
---
drivers/perf/arm-cmn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 7ef9c7e4836b..b2c607cf3ad7 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -2482,6 +2482,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
cmn->cpu = cpumask_local_spread(0, dev_to_node(cmn->dev));
cmn->pmu = (struct pmu) {
.module = THIS_MODULE,
+ .parent = cmn->dev,
.attr_groups = arm_cmn_attr_groups,
.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
.task_ctx_nr = perf_invalid_context,
--
2.39.2.101.g768bb238c484.dirty
On Tue, 09 Apr 2024 18:15:17 +0100, Robin Murphy wrote:
> Now that perf supports giving the PMU device a parent, we can use our
> platform device to make the relationship between CMN instances and PMU
> IDs trivially discoverable, from either nominal direction:
>
> root@crazy-taxi:~# ls /sys/devices/platform/ARMHC600:00 | grep cmn
> arm_cmn_0
> root@crazy-taxi:~# realpath /sys/bus/event_source/devices/arm_cmn_0/..
> /sys/devices/platform/ARMHC600:00
>
> [...]
Applied to will (for-next/perf), thanks!
[1/1] perf/arm-cmn: Set PMU device parent
https://git.kernel.org/will/c/8f9f5041c646
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
On Tue, 9 Apr 2024 18:15:17 +0100
Robin Murphy <[email protected]> wrote:
> Now that perf supports giving the PMU device a parent, we can use our
> platform device to make the relationship between CMN instances and PMU
> IDs trivially discoverable, from either nominal direction:
>
> root@crazy-taxi:~# ls /sys/devices/platform/ARMHC600:00 | grep cmn
> arm_cmn_0
> root@crazy-taxi:~# realpath /sys/bus/event_source/devices/arm_cmn_0/..
> /sys/devices/platform/ARMHC600:00
>
> Signed-off-by: Robin Murphy <[email protected]>
Nice. I'd forgotten all about this :(
https://lore.kernel.org/all/[email protected]/
still has a bunch of these + there were many I never looked into.
Guess I should respin that series though probably 50% at least still apply.
J
> ---
> drivers/perf/arm-cmn.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index 7ef9c7e4836b..b2c607cf3ad7 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -2482,6 +2482,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
> cmn->cpu = cpumask_local_spread(0, dev_to_node(cmn->dev));
> cmn->pmu = (struct pmu) {
> .module = THIS_MODULE,
> + .parent = cmn->dev,
> .attr_groups = arm_cmn_attr_groups,
> .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> .task_ctx_nr = perf_invalid_context,
On Wed, 10 Apr 2024 18:04:03 +0100
Jonathan Cameron <[email protected]> wrote:
> On Tue, 9 Apr 2024 18:15:17 +0100
> Robin Murphy <[email protected]> wrote:
>
> > Now that perf supports giving the PMU device a parent, we can use our
> > platform device to make the relationship between CMN instances and PMU
> > IDs trivially discoverable, from either nominal direction:
> >
> > root@crazy-taxi:~# ls /sys/devices/platform/ARMHC600:00 | grep cmn
> > arm_cmn_0
> > root@crazy-taxi:~# realpath /sys/bus/event_source/devices/arm_cmn_0/..
> > /sys/devices/platform/ARMHC600:00
> >
> > Signed-off-by: Robin Murphy <[email protected]>
> Nice. I'd forgotten all about this :(
>
> https://lore.kernel.org/all/[email protected]/
> still has a bunch of these + there were many I never looked into.
>
> Guess I should respin that series though probably 50% at least still apply.
Ironically other than this one, almost the only ones that didn't go in cleanly
are the hisilicon drivers where there was some churn.
Will, if you 'want' to pick any of those up directly feel free, if not I'll sent
them out again in a few days time (and check there weren't any requests for
changes buried in that rather extensive thread!)
Jonathan
>
> J
>
>
> > ---
> > drivers/perf/arm-cmn.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> > index 7ef9c7e4836b..b2c607cf3ad7 100644
> > --- a/drivers/perf/arm-cmn.c
> > +++ b/drivers/perf/arm-cmn.c
> > @@ -2482,6 +2482,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
> > cmn->cpu = cpumask_local_spread(0, dev_to_node(cmn->dev));
> > cmn->pmu = (struct pmu) {
> > .module = THIS_MODULE,
> > + .parent = cmn->dev,
> > .attr_groups = arm_cmn_attr_groups,
> > .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> > .task_ctx_nr = perf_invalid_context,
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 2024-04-10 6:04 pm, Jonathan Cameron wrote:
> On Tue, 9 Apr 2024 18:15:17 +0100
> Robin Murphy <[email protected]> wrote:
>
>> Now that perf supports giving the PMU device a parent, we can use our
>> platform device to make the relationship between CMN instances and PMU
>> IDs trivially discoverable, from either nominal direction:
>>
>> root@crazy-taxi:~# ls /sys/devices/platform/ARMHC600:00 | grep cmn
>> arm_cmn_0
>> root@crazy-taxi:~# realpath /sys/bus/event_source/devices/arm_cmn_0/..
>> /sys/devices/platform/ARMHC600:00
>>
>> Signed-off-by: Robin Murphy <[email protected]>
> Nice. I'd forgotten all about this :(
Yeah, I hadn't realised the core change actually got merged until I
stumbled across it by chance yesterday, otherwise I'd have followed up
far sooner... If only your series had been a day or two later, I'd have
posted the original device_move() version of this one back then, and it
might even have looked reasonable for a moment :)
Cheers,
Robin.
> https://lore.kernel.org/all/[email protected]/
> still has a bunch of these + there were many I never looked into.
>
> Guess I should respin that series though probably 50% at least still apply.
>
> J
>
>
>> ---
>> drivers/perf/arm-cmn.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
>> index 7ef9c7e4836b..b2c607cf3ad7 100644
>> --- a/drivers/perf/arm-cmn.c
>> +++ b/drivers/perf/arm-cmn.c
>> @@ -2482,6 +2482,7 @@ static int arm_cmn_probe(struct platform_device *pdev)
>> cmn->cpu = cpumask_local_spread(0, dev_to_node(cmn->dev));
>> cmn->pmu = (struct pmu) {
>> .module = THIS_MODULE,
>> + .parent = cmn->dev,
>> .attr_groups = arm_cmn_attr_groups,
>> .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
>> .task_ctx_nr = perf_invalid_context,
>
On Wed, Apr 10, 2024 at 06:12:26PM +0100, Jonathan Cameron wrote:
> On Wed, 10 Apr 2024 18:04:03 +0100
> Jonathan Cameron <[email protected]> wrote:
>
> > On Tue, 9 Apr 2024 18:15:17 +0100
> > Robin Murphy <[email protected]> wrote:
> >
> > > Now that perf supports giving the PMU device a parent, we can use our
> > > platform device to make the relationship between CMN instances and PMU
> > > IDs trivially discoverable, from either nominal direction:
> > >
> > > root@crazy-taxi:~# ls /sys/devices/platform/ARMHC600:00 | grep cmn
> > > arm_cmn_0
> > > root@crazy-taxi:~# realpath /sys/bus/event_source/devices/arm_cmn_0/..
> > > /sys/devices/platform/ARMHC600:00
> > >
> > > Signed-off-by: Robin Murphy <[email protected]>
> > Nice. I'd forgotten all about this :(
> >
> > https://lore.kernel.org/all/[email protected]/
> > still has a bunch of these + there were many I never looked into.
> >
> > Guess I should respin that series though probably 50% at least still apply.
>
> Ironically other than this one, almost the only ones that didn't go in cleanly
> are the hisilicon drivers where there was some churn.
>
> Will, if you 'want' to pick any of those up directly feel free, if not I'll sent
> them out again in a few days time (and check there weren't any requests for
> changes buried in that rather extensive thread!)
It's probably best to send a new series regardless, but I'm happy to
pick up anything touching drivers/perf/ if they don't depend on any core
changes.
Will