Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1412622pxy; Fri, 23 Apr 2021 07:31:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxiUzkbC74Mdr/2E7qjbgjEGpUBWoPV7lPDm8jAMSvSOmyadHXk5B5ksNcjoqgHzOEyqjl X-Received: by 2002:a17:906:cb1:: with SMTP id k17mr4522174ejh.307.1619188281830; Fri, 23 Apr 2021 07:31:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619188281; cv=none; d=google.com; s=arc-20160816; b=tQ1G6kLK1O/AQPourYzqrQFVT84kxNrOQjvvsQK/QsIe1l2DSOWYEAb1Ue1i2SwZM2 S64jqNEsbUMpVnh5U1LtGVr2XhOAHWmTXV4uqbq9IeBfcwfn5ns7YUSkGw21WU2pkSbu sslY1B0Rke8CAzJxosFY5K4ydFRACV4RlabQItXFj3GLQ6XFuAok+oZJhYR9VMOTG4On 2kRrmcuY+Dlo0pKi+BBKpQTRAdq2ZjYC6FCj6GRP+mvPbNdXpwcceZ4N8Hr1y2hgRU8u eYEu24sJLFRe5PMVX1oYMJnXtG+Al6KWlgIUX/mUDJZJ07NBW3NgVYHLgwoEG/aqRuGG pHYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=mWXcm7X3RjbSoE95VEDi9grwUS/7yfg6yPkRWfDaQPY=; b=NAu6q057XfNpVdda1rpN/dZGspu1FLGl//xmda6rP8MDiW++aueJ6wDO+hTQu+u2H0 4GuwsOwtLKzd88BWEBZpxmdLGgTzWHkUL3bZzjMiQLblPA+5BLarjkRmHlKjgDpmYh2h mAZCotJC0K/Ev5IcW4ajg379T7M7ejVcWkiOBEQYm8zD9pvr8dzLHj9CDYPFJxbwcZ1J PoTnC3Vr33tgnMFxOMnwncWZkzOsUGXQMqBnBw5Q03G2opUAZ2zOI1H07vB5mznDeOr9 4tNwYF+LZMiGfI/HvdMo6G6STzG0oLyOgTokEVuwFr1I9JaNTJfLHlqyZwGna25TXpBn ZJzw== 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 x18si6502243ejd.75.2021.04.23.07.30.55; Fri, 23 Apr 2021 07:31:21 -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 S238411AbhDWOac (ORCPT + 99 others); Fri, 23 Apr 2021 10:30:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:45478 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbhDWOab (ORCPT ); Fri, 23 Apr 2021 10:30:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 55D45B133; Fri, 23 Apr 2021 14:29:53 +0000 (UTC) Date: Fri, 23 Apr 2021 16:29:41 +0200 From: Borislav Petkov To: Calvin Walton Cc: Chen Yu , Terry Bowman , lenb@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, wei.huang2@amd.com, aros@gmx.com, rui.zhang@intel.com Subject: Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors Message-ID: References: <20210419195812.147710-1-terry.bowman@amd.com> <20210420020336.GA386151@chenyu-desktop> <20210420080701.GA2326@zn.tnic> <20210420131541.GA388877@chenyu-desktop> <4cbb1eff77de1e843912267ade4686cfa1acd610.camel@kepstin.ca> <20210420143754.GA390118@chenyu-desktop> <5cf35f3742d1181421d955174b1aa9434d042c96.camel@kepstin.ca> <20210423121607.GA426003@chenyu-desktop> <20210423121934.GC24710@zn.tnic> <23f75aaf3d37cbad6f8ed7bd970434e4a2dc388e.camel@kepstin.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23f75aaf3d37cbad6f8ed7bd970434e4a2dc388e.camel@kepstin.ca> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 23, 2021 at 10:00:14AM -0400, Calvin Walton wrote: > So, there's two problems with that: > 1. This function needs to be able to return an error value that cannot be > confused with a valid MSR. This is currently done by returning a > negative number. If an unsigned value is used, a different way of > indicating errors needs to be written. > 2. We are not using CPU instructions to access MSRs direction. Instead > they are being read from /dev/msr. So the "offset" value is actually a > seek into the /dev/msr file (using pread), and thus is of type off_t. Ah right, that's the /dev/msr thing. Then off_t is correct, forget what I said. Thx. -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg