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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9F153C6FD1D for ; Tue, 4 Apr 2023 13:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/EtJU8nhZJrryCnrG1s+oayVQy4ZWJx14xEc17MEjcE=; b=0un+FvIVTVDa8U B/aJt2K0l+sM7sXccMuEJJghp4GxfbYrJjL9j8PbvrBBQfh4EKhXUJV7pETNAgESR4OZVF9+vgDgy PGPGf/LsugNcracoa7Aa4qnc3pzoEtC6N0d75X2uxUKLl+r1XgI2FtK4HZzJim6W9E2B+4DzkSbOW Btfha2or7ZvU/qZkTDzGgytletjP52wvbUvmvqMueCXkYb6qUsJhljOp1VqCBy53tQmKOFE1H5Ptq IxkoEGlW2TYcQVFgY+GUzNcoX3oC/NDCVMRMk3JpPqXg7MxuLFRlErHzr/GBd2zbioSeUFv1lEs2B +hVg6tySEq6RkvuWYa6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pjh48-001a1R-0R; Tue, 04 Apr 2023 13:51:16 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pjh45-001Zyn-00 for linux-arm-kernel@lists.infradead.org; Tue, 04 Apr 2023 13:51:14 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E19286345C; Tue, 4 Apr 2023 13:51:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 170C9C4339B; Tue, 4 Apr 2023 13:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1680616270; bh=M01kLJmuFwVJVH5Fd0jHURY66CemX7oncliKZevP7g0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fZw4cbD5umDKL/ZgCvOKS5mpwCGR1BQ72STMVfgjCvL67KREjRVIEZmqVvDB8kqED bGD9pkjFw8YLyi8S10/+HeO11YvX1wNqbgoqIA2MhWfZYy+uphB+8exKR4ZUng1kj7 dIOuCdpMDWX3ARB9MwpySfrJKcHrjLWNdsjdNd/8= Date: Tue, 4 Apr 2023 15:51:07 +0200 From: Greg KH To: Jonathan Cameron Cc: Mark Rutland , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Will Deacon , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com, Dan Williams , Shaokun Zhang , Yicong Yang , Jiucheng Xu , Khuong Dinh , Robert Richter , Atish Patra , Anup Patel , Andy Gross , Bjorn Andersson , Frank Li , Shuai Xue , Vineet Gupta , Shawn Guo , Fenghua Yu , Dave Jiang , Wu Hao , Tom Rix , linux-fpga@vger.kernel.org, Suzuki K Poulose , Liang Kan Subject: Re: [PATCH 00/32] Add parents to struct pmu -> dev Message-ID: <2023040447-music-purgatory-1985@gregkh> References: <20230404134225.13408-1-Jonathan.Cameron@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230404134225.13408-1-Jonathan.Cameron@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230404_065113_087449_14EA87C2 X-CRM114-Status: GOOD ( 16.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 04, 2023 at 02:41:53PM +0100, Jonathan Cameron wrote: > These are the low hanging fruit following GregKH's feedback that > all the devices registered via perf_pmu_register() should have parents. > > Note that this causes potential ABI breakage. > > It may fall in the category of it isn't breakage if no one notices > but I can't be certain of that. Whilst it is arguable that > no one should be been accessing PMUs except via the event_source > bus, there was documentation suggesting /sys/devices/ for particular > PMUs (because it was a shorter path?) devices can always move around /sys/devices/ as there is not a guarantee that they will ever be in the same place. That's what /sys/class/ is used to find (and /sys/bus/ in some cases.) And even then, the naming scheme is variable, and can and will change (i.e. bus ids), so that too is not required to stay the same. thanks for doing this work, I'll add it to my review queue... greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel