From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933794AbdGKVQN (ORCPT <rfc822;w@1wt.eu>);
        Tue, 11 Jul 2017 17:16:13 -0400
Received: from mga03.intel.com ([134.134.136.65]:27729 "EHLO mga03.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S933774AbdGKVQM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 11 Jul 2017 17:16:12 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.40,347,1496127600"; 
   d="scan'208";a="125938847"
Date: Tue, 11 Jul 2017 14:17:47 -0700 (PDT)
From: Shivappa Vikas <vikas.shivappa@intel.com>
X-X-Sender: vikas@vshiva-Udesk
To: Thomas Gleixner <tglx@linutronix.de>
cc: Shivappa Vikas <vikas.shivappa@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, hpa@zytor.com, peterz@infradead.org,
        ravi.v.shankar@intel.com, tony.luck@intel.com, fenghua.yu@intel.com,
        andi.kleen@intel.com
Subject: Re: [PATCH 14/21] x86/intel_rdt/cqm: Add mon_data
In-Reply-To: <alpine.DEB.2.20.1707070820200.1871@nanos>
Message-ID: <alpine.DEB.2.10.1707111411030.6175@vshiva-Udesk>
References: <1498503368-20173-1-git-send-email-vikas.shivappa@linux.intel.com> <1498503368-20173-15-git-send-email-vikas.shivappa@linux.intel.com> <alpine.DEB.2.20.1707021432030.2296@nanos> <alpine.DEB.2.10.1707061447150.3798@vshiva-Udesk>
 <alpine.DEB.2.20.1707070820200.1871@nanos>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On Thu, 6 Jul 2017, Thomas Gleixner wrote:

> On Thu, 6 Jul 2017, Shivappa Vikas wrote:
>> On Sun, 2 Jul 2017, Thomas Gleixner wrote:
>>>> +static bool __mon_event_count(u32 rmid, struct rmid_read *rr)
>>>> +{
>>>> +	u64 tval;
>>>> +
>>>> +	tval = __rmid_read(rmid, rr->evtid);
>>>> +	if (tval & (RMID_VAL_ERROR | RMID_VAL_UNAVAIL)) {
>>>> +		rr->val = tval;
>>>> +		return false;
>>>> +	}
>>>> +	switch (rr->evtid) {
>>>> +	case QOS_L3_OCCUP_EVENT_ID:
>>>> +		rr->val += tval;
>>>> +		return true;
>>>> +	default:
>>>> +		return false;
>>>
>>> I have no idea what that return code means.
>>
>> false for the invalid event id and all errors for __rmid_read. (IOW all errors
>> for __mon_event-read)
>
> Sure, but why bool? What's wrong with proper error return codes, so issues
> can be distinguished and potentially propagated in the callchain?

Ok, The error is propagated wih the rr->val actually. is this better?

Hardware throws the RMID_VAL_ERROR (bit 63) when an invalid RMID or 
event is written to event select - this case seems similar.

 	default:
 		rr->val = RMID_VAL_ERROR;
 		return -EINVAL;
 	}

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>
>
>
>
>