From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1370BC77B60 for ; Wed, 29 Mar 2023 08:56:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230515AbjC2I4B (ORCPT ); Wed, 29 Mar 2023 04:56:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231358AbjC2IzX (ORCPT ); Wed, 29 Mar 2023 04:55:23 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68DFF4C0D; Wed, 29 Mar 2023 01:55:08 -0700 (PDT) Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PmgN42vb1z6J7wy; Wed, 29 Mar 2023 16:54:28 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Wed, 29 Mar 2023 09:55:05 +0100 Date: Wed, 29 Mar 2023 09:55:04 +0100 From: Jonathan Cameron To: Greg KH CC: "Liang, Kan" , , , , , , , , , , , Davidlohr Bueso , "Dave Jiang" Subject: Re: [PATCH v2 2/5] perf: Allow a PMU to have a parent. Message-ID: <20230329095504.0000411f@Huawei.com> In-Reply-To: References: <20230324171313.18448-1-Jonathan.Cameron@huawei.com> <20230324171313.18448-3-Jonathan.Cameron@huawei.com> <20230328115444.000036ea@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100005.china.huawei.com (7.191.160.25) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Mar 2023 13:01:08 +0200 Greg KH wrote: > On Tue, Mar 28, 2023 at 11:54:44AM +0100, Jonathan Cameron wrote: > > On Mon, 27 Mar 2023 13:04:08 -0400 > > "Liang, Kan" wrote: > > > > > On 2023-03-24 1:13 p.m., Jonathan Cameron wrote: > > > > Some PMUs have well defined parents such as PCI devices. > > > > As the device_initialize() and device_add() are all within > > > > pmu_dev_alloc() which is called from perf_pmu_register() > > > > there is no opportunity to set the parent from within a driver. > > > > > > > > Add a struct device *parent field to struct pmu and use that > > > > to set the parent. > > > > > > Why we want a PMU parent? Maybe I missed it. I don't see that the parent > > > is used anywhere. > > > > This allows you to identify the association between PMU and the hardware related > > device that is providing it by looking at the directory structure in sysfs rather > > than putting them directly under /sys/devices. > > > > ls -l /sys/bus/event_sources/devices/ > > > > ... armv8_pmuv3_0 -> ../../../devices/arm8_pmuv3_0 > > ... breakpoint -> ../../../devices/breakpoint > > ... cpmu0 -> ../../../devices/pci0000:0c/0000:0c:00.0/0000:0d:00.0/cpmu0/cpmu0 > > etc > > > > (the first cpmu0 is the parent registered as a child of the PCI EP and used for > > driver binding). So it's of use to userspace rather than in the kernel driver > > itself. > > > > Note that almost nothing is normally in the top level /sys/devices other than > > event_sources - because nearly all other struct device instances created by > > subsystems have parents assigned. > > > > On my system > > > > ls /sys/devices > > > > armv8_pmuv3_0 LNXSYSTEM:00 pci0000:0c pnp0 system uprobe > > breakpoint pci0000:00 platform software tracepoint virtual > > > > +CC Greg KH for input on whether / why this make sense. > > That doesn't make sense, nothing should be in /sys/devices/ EXCEPT the > root device of busses. Everything else is wrong and should have their > code fixed up (i.e. "breakpoint", "software", etc.) Thanks Greg. I was thinking to cycle back round to that once I'd got agreement on 'some' devices, but great to have clarity from the start that these should all have parents. For a few cases the parent is not immediately obvious but we'll figure it out. Jonathan > > thanks, > > greg k-h