From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 561D5217722 for ; Mon, 24 Nov 2025 18:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764007277; cv=none; b=HJrgRCSZL9Q/SGUf36AZDKTCQxMxhGpyRnDXisark2QG5yNqUXRRQ2J9CSEpQc1ulwqRNOlzDMW+O5dyVCUo4uSjobEGxLmY28KDzCx0K1QYDrOItzIW5abXHBleA9sJ9EH1RTmH+YnFqHSfXomXad8/pARDo0eNWaiRJ4rmCqE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764007277; c=relaxed/simple; bh=I+AaiqaXKz6SLn9ciD/d6BO78PYMJzbT/zxw5hzBr7w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nNowqcvBBoNne6uPFHKOVHE/vHTel4vMd1dVYJNCD6OFRk17l8nQmfcOLx7mjfGAekbE/xIS7aBc2/Hszrv2+Rsl+P8XOHKA+wDYwJQFIkEaD8MVg/aNDBFV0N5SMyh9srMQO8pwgN7fbif7vsam9dIeuBVeeMfNVwl0+shFIJE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F0BE01477; Mon, 24 Nov 2025 10:01:06 -0800 (PST) Received: from [10.1.30.67] (unknown [10.1.30.67]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AAE793F86F; Mon, 24 Nov 2025 10:01:12 -0800 (PST) Message-ID: <0bea885c-6647-4552-a7f7-4fef260ef97c@arm.com> Date: Mon, 24 Nov 2025 18:01:10 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] perf/arm-ni: rename PMU device name To: Will Deacon , Shouping Wang Cc: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, andy.xu@hj-micro.com, peter.du@hj-micro.com References: <20251107084320.555979-1-allen.wang@hj-micro.com> <20251107084320.555979-2-allen.wang@hj-micro.com> From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025-11-24 3:47 pm, Will Deacon wrote: > On Fri, Nov 07, 2025 at 04:43:18PM +0800, Shouping Wang wrote: >> The PMU device names are arm_ni_1_*,arm_ni_2_*, etc. >> The device names change based on the order of registration >> for multiple NI instances. By naming the PMU device using >> its address, the device name can be made independent of >> the registration order. >> >> Signed-off-by: Shouping Wang >> --- >> drivers/perf/arm-ni.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/perf/arm-ni.c b/drivers/perf/arm-ni.c >> index 1615a0564031..32eabdbe877a 100644 >> --- a/drivers/perf/arm-ni.c >> +++ b/drivers/perf/arm-ni.c >> @@ -53,6 +53,7 @@ >> >> #define NI_NUM_COUNTERS 8 >> #define NI_CCNT_IDX 31 >> +#define NI_PMU_PA_SHIFT 12 >> >> /* Event attributes */ >> #define NI_CONFIG_TYPE GENMASK_ULL(15, 0) >> @@ -115,7 +116,6 @@ struct arm_ni { >> struct device *dev; >> void __iomem *base; >> enum ni_part part; >> - int id; >> int cpu; >> int num_cds; >> struct hlist_node cpuhp_node; >> @@ -560,7 +560,7 @@ static int arm_ni_init_cd(struct arm_ni *ni, struct arm_ni_node *node, u64 res_s >> .read = arm_ni_event_read, >> }; >> >> - name = devm_kasprintf(ni->dev, GFP_KERNEL, "arm_ni_%d_cd_%d", ni->id, cd->id); >> + name = devm_kasprintf(ni->dev, GFP_KERNEL, "arm_ni_%llx", res_start >> NI_PMU_PA_SHIFT); > > Doesn't this have the potential to break userspace (e.g. scripts) that > expect the current naming to be stable? Certainly on platforms where only arm_ni_0 ever exists. For multi-instance cases it's always been documented that this ID is arbitrary, and users should look at the platform device that is the sysfs parent of the PMU device(s) in order to disambiguate - from there they already have the freedom to use whatever information they like, including MMIO resources, but also interrupt numbers, ACPI _UIDs or whatever. So although changing one arbitrary value to a different arbitrary value is in theory something well-behaved users should be OK with, in practice changing it from a small decimal integer to a massive hex number may well still break parsing expectations. Thanks, Robin. > > Either way, I'll need Robin's acks for these changes. > > Will