Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp930163ybm; Wed, 27 May 2020 11:26:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1XJ4tLPJMTvSnY8QkRogw95O/RHYAn9tDahZ9eKZI5vJ7n4zoPE7JeMsFvR0AJ6OpSP9q X-Received: by 2002:a17:906:51b:: with SMTP id j27mr6900424eja.246.1590603979703; Wed, 27 May 2020 11:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590603979; cv=none; d=google.com; s=arc-20160816; b=Povz5T0h700vzC6NqTeMaaNJcnU/ONPcoJcHUkPDZlYQKWVQJeXTb9TGTDF4NLKARo p8C9TuBYoZplTu6q4tQJS4BpXcbbAX8CsNThV5ovdkZ8DuuRyqtAp4NwRjXkYlalr8WR rOJcY6VwHkiDY9YSgsAS0p5WVAN5kZvqe+duCNnWvNzHh2+Pp5CwpJqF/KVwU3a+lppZ zDTglGvrVHVmKUvWT/I+xvxvpmZV6hWWn5zlE9FOhQp7E87398RNIu67w//PXcnIb5BT TuKlM2Rz7++/OYXpx6P9lZcf0lRdUcEtYTA/9Rxe5EpbBh06l2hjitPJqzRxTer03q9O nKPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=6Re1Bz98oSICWOofbqjAhNGRrVfKc9SLpPmdRBfll2c=; b=NG2xlGkuPH9OnO65lhJi/icIXDMYlQtH3zCs552XPtzHKL0iX9aCf08OKGcApNYPTc BKASYIdApKlfagEjZSTSZxSyl0lUHs4rUBFSLCnoj8v/BTjvzWdiOVm6PyD70UmcPi76 OMbSLEXK5l13Xqz4ve2UvjX3sJKQ6lGKgc7BIBdkKCUQ3X4DpRajc6ZchJti0lU2K/FY Z2SawROghAsVVOd2UsBelCgb9GiwbfgSC3EcfMy/6Rz0T6OugKABNg66GaYxpLdmDQZb QT1mb/u2pRwY/bu2FSf1GNmJ8LU+H5D4Z1iBmZRtrhSVS+uJtgUIkLv4q1KtPj+NshlI 2vlw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g7si2560958ejc.469.2020.05.27.11.25.56; Wed, 27 May 2020 11:26:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389306AbgE0Of4 (ORCPT + 98 others); Wed, 27 May 2020 10:35:56 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2249 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2389205AbgE0Of4 (ORCPT ); Wed, 27 May 2020 10:35:56 -0400 Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B48B11895055C8A31AB1; Wed, 27 May 2020 15:35:53 +0100 (IST) Received: from [127.0.0.1] (10.47.6.244) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 27 May 2020 15:35:52 +0100 From: John Garry Subject: Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace To: Will Deacon , Rob Herring CC: Mark Rutland , , Joakim Zhang , "linux-kernel@vger.kernel.org" , NXP Linux Team , Shawn Guo , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Zhangshaokun References: <20200512073115.14177-1-qiangqing.zhang@nxp.com> <20200512073115.14177-2-qiangqing.zhang@nxp.com> <20200519185125.GB453195@bogus> <20200520073304.GA23534@willie-the-truck> <20200521130415.GB5949@willie-the-truck> Message-ID: <51aa7cbc-0ce2-b96d-b056-fcc6013ccecf@huawei.com> Date: Wed, 27 May 2020 15:34:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.6.244] X-ClientProxiedBy: lhreml717-chm.china.huawei.com (10.201.108.68) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>> >>>> I also really dislike this. What's the preferred way to identify the >>>> SoC >>>> from userspace? >>> >>> /proc/cpuinfo? ;) >> >> The *SoC*! >> >>> For an non-firmware specific case, I'd say soc_device should be. I'd >>> guess ACPI systems don't use it and for them it's dmidecode typically. >>> The other problem I have with soc_device is it is optional. >> > > Hi Will, > >> John -- what do you think about using soc_device to expose this >> information, >> with ACPI systems using DMI data instead? > > Generally I don't think that DMI is reliable, and I saw this as the > least preferred choice. I'm looking at the sysfs DMI info for my dev > board, and I don't even see anything like a SoC identifier. > > As for the event_source device sysfs identifier file, it would not > always contain effectively the same as the SoC ID. > > Certain PMUs which I'm interested in plan to have probe-able > identification info available in future. > BTW, Shaokun now tells me that the HiSi uncore PMU HW have such registers to identify the implementation. I didn't know. So we could add that identifier file for those PMUs as proof-of-concept, exposing that register. As for other PMUs which I'm interested in, again, future versions should have such registers to self-identify. So using something derived from the DT compat string would hopefully be the uncommon case. Cheers, John