Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756185AbcCUN14 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 21 Mar 2016 09:27:56 -0400
Received: from e28smtp04.in.ibm.com ([125.16.236.4]:39000 "EHLO
	e28smtp04.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755205AbcCUN1x (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 21 Mar 2016 09:27:53 -0400
X-IBM-Helo: d28relay01.in.ibm.com
X-IBM-MailFrom: shreyas@linux.vnet.ibm.com
X-IBM-RcptTo: linux-kernel@vger.kernel.org
Message-ID: <56EFF6C2.2050503@linux.vnet.ibm.com>
Date: Mon, 21 Mar 2016 18:57:30 +0530
From: Shreyas B Prabhu <shreyas@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Paul Mackerras <paulus@ozlabs.org>
CC: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
        linux-kernel@vger.kernel.org, benh@kernel.crashing.org,
        mahesh@linux.vnet.ibm.com, maddy@linux.vnet.ibm.com
Subject: Re: [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps
 in a macro
References: <1456748580-10519-1-git-send-email-shreyas@linux.vnet.ibm.com> <1456748580-10519-3-git-send-email-shreyas@linux.vnet.ibm.com> <20160317111534.GD28728@fergus.ozlabs.ibm.com> <56EC1664.8020905@linux.vnet.ibm.com> <20160319002122.GA27126@fergus.ozlabs.ibm.com>
In-Reply-To: <20160319002122.GA27126@fergus.ozlabs.ibm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: disable
x-cbid: 16032113-0013-0000-0000-00000B0DC532
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1840
Lines: 41



On 03/19/2016 05:51 AM, Paul Mackerras wrote:
> On Fri, Mar 18, 2016 at 08:23:24PM +0530, Shreyas B Prabhu wrote:
>> Hi Paul,
>>
>> On 03/17/2016 04:45 PM, Paul Mackerras wrote:
>>> On Mon, Feb 29, 2016 at 05:52:59PM +0530, Shreyas B. Prabhu wrote:
>>>> Before entering any idle state which can result in a state loss
>>>> we currently save the context in the stack before entering idle.
>>>> Encapsulate these steps in a macro IDLE_STATE_PREP. Move this
>>>> and other macros to commonly accessible location.
>>>
>>> There are two problems with this.  First, your new macro does much
>>> more than create a stack frame and save some registers.  It also
>>> messes with interrupts and potentially executes a blr instruction.
>>> That is not what people would expect from the name of the macro or the
>>> comments around it.  It also means that it would be hard to reuse the
>>> macro in another place.
>>>
>>> Secondly, I don't think this change helps readability.  Since the
>>> macro is only used in one place, it doesn't reduce the total number of
>>> lines of code, in fact it increases it slightly. 
>>
>> This patch was in preparation for support for new POWER ISA v3 idle
>> states. The idea was to have the common idle preparation steps in a
>> macro which be reused while adding support for the new idle states. With
>> this context do you think this macro with better comments make sense?
> 
> No, it still does too many disparate things.  In particular it's a bad
> idea to embed a blr inside a macro unless the name makes it very clear
> that the macro can cause a return (e.g. the macro name is
> RETURN_IF_<something>).  Yours would need to be called
> MAKE_STACK_FRAME_AND_SAVE_SPRS_AND_HARD_DISABLE_AND_RETURN_IF_IRQ_OCCURRED
> or something. :)
> 

Ok :) . I'll drop this patch and work this differently.

Thanks,
Shreyas