From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933794AbdBQM0e (ORCPT ); Fri, 17 Feb 2017 07:26:34 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37638 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932941AbdBQM0d (ORCPT ); Fri, 17 Feb 2017 07:26:33 -0500 Subject: Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change To: Pan Xinhui , Michael Ellerman References: <1487144990-5969-1-git-send-email-xinhui.pan@linux.vnet.ibm.com> <87shnek9hd.fsf@concordia.ellerman.id.au> <72cfff06-bd93-a727-0b93-31dfa3a7ac65@linux.vnet.ibm.com> <8466dffc-d75c-d83a-2a4f-d567721db7d5@linux.vnet.ibm.com> <87h93tjqrn.fsf@concordia.ellerman.id.au> Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, paulus@samba.org, npiggin@gmail.com From: "Guilherme G. Piccoli" Date: Fri, 17 Feb 2017 10:25:34 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17021712-0028-0000-0000-00000196B3ED X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17021712-0029-0000-0000-00001493B716 Message-Id: <1eca9e4a-f120-e3bf-1358-b4f18ab6262f@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-17_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702170117 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/17/2017 07:30 AM, Pan Xinhui wrote: > > > ÔÚ 2017/2/17 14:05, Michael Ellerman дµÀ: >> Pan Xinhui writes: >>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >>> index 9c0e17c..f6e5c3d 100644 >>> --- a/arch/powerpc/xmon/xmon.c >>> +++ b/arch/powerpc/xmon/xmon.c >>> @@ -76,6 +76,7 @@ static int xmon_gate; >>> #endif /* CONFIG_SMP */ >>> >>> static unsigned long in_xmon __read_mostly = 0; >>> +static int xmon_off = !IS_ENABLED(CONFIG_XMON_DEFAULT); >> >> I think the logic would probably clearer if we invert this to become >> xmon_on. >> > yep, make sense. > >>> @@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void) >>> __initcall(setup_xmon_sysrq); >>> #endif /* CONFIG_MAGIC_SYSRQ */ >>> >>> -static int __initdata xmon_early, xmon_off; >>> +static int __initdata xmon_early; >>> >>> static int __init early_parse_xmon(char *p) >>> { >>> if (!p || strncmp(p, "early", 5) == 0) { >>> /* just "xmon" is equivalent to "xmon=early" */ >>> - xmon_init(1); >>> xmon_early = 1; >>> + xmon_off = 0; >>> } else if (strncmp(p, "on", 2) == 0) >>> - xmon_init(1); >>> + xmon_off = 0; >> >> You've just changed the timing of when xmon gets enabled for the above >> two cases, from here which is called very early, to xmon_setup() which >> is called much later in boot. >> >> That effectively disables xmon for most of the boot, which we do not >> want to do. >> > Although it is not often that kernel got stucked during boot. Yes, the behavior changed anyway. Will fix that in v3. Pan/Michael, I'm working my patches on top of Pan's. So, I sent his V2 on my series, as patch #1. Guess the workflow is better/easier if we can work the patches on the series exclusively, since each time Pan's patch is changed, I need to refactor my patches. Pan, if possible send your V3 to me, I'll refactor my series on top of it and send again on the list. Or if you or Michael have better suggestions of workflow, let me know. Thanks, Guilherme > >> cheers >> >