From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id C0D272C00E7 for ; Thu, 5 Jul 2012 01:20:03 +1000 (EST) From: Tabi Timur-B04825 To: Zhao Chenhui-B35336 Subject: Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync Date: Wed, 4 Jul 2012 15:19:54 +0000 Message-ID: <4FF45F19.2080607@freescale.com> References: <1341310879-5468-1-git-send-email-chenhui.zhao@freescale.com> <20120704031426.GA6133@localhost.localdomain> <4FF3B5B6.8090400@freescale.com> <20120704034545.GA6196@localhost.localdomain> In-Reply-To: <20120704034545.GA6196@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Cc: Wood Scott-B07421 , Li Yang-R58472 , Zhao Chenhui-B35336 , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Zhao Chenhui wrote: > On Tue, Jul 03, 2012 at 10:17:12PM -0500, Tabi Timur-B04825 wrote: >> Zhao Chenhui wrote: >>> If the guts variable is NULL, it indicates there is error in dts or ker= nel. >>> We should fix the error, rather than ignore it. >> >> And that's why there's a warning message. Crashing the kernel is not >> going to fix anything. >> > > This error likely crashes the kenel somewhere. Can you test this, please? The point I'm trying to make is that it's wrong to intentionally halt the=20 kernel unless you're sure that it's the best option. A missing device=20 tree node is supposed to only disable a given feature, not break everything= . --=20 Timur Tabi Linux kernel developer at Freescale From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754353Ab2GDPV3 (ORCPT ); Wed, 4 Jul 2012 11:21:29 -0400 Received: from [213.199.154.141] ([213.199.154.141]:24964 "EHLO db3outboundpool.messaging.microsoft.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750841Ab2GDPVS convert rfc822-to-8bit (ORCPT ); Wed, 4 Jul 2012 11:21:18 -0400 X-Forefront-Antispam-Report: CIP:70.37.183.190;KIP:(null);UIP:(null);IPV:NLI;H:mail.freescale.net;RD:none;EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz98dI1432Izz1202hzzz2dh2a8h668h839h8e2h8e3hd25he5bhf0ahbe9i) From: Tabi Timur-B04825 To: Zhao Chenhui-B35336 CC: Zhao Chenhui-B35336 , "linuxppc-dev@lists.ozlabs.org" , Wood Scott-B07421 , "galak@kernel.crashing.org" , "linux-kernel@vger.kernel.org" , Li Yang-R58472 , Li Yang-R58472 Subject: Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync Thread-Topic: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync Thread-Index: AQHNWRnaavpowtpO5UeeCNsHPM8rhJcYx9kAgAAAxACAAAf8gIAAwfCA Date: Wed, 4 Jul 2012 15:19:54 +0000 Message-ID: <4FF45F19.2080607@freescale.com> References: <1341310879-5468-1-git-send-email-chenhui.zhao@freescale.com> <20120704031426.GA6133@localhost.localdomain> <4FF3B5B6.8090400@freescale.com> <20120704034545.GA6196@localhost.localdomain> In-Reply-To: <20120704034545.GA6196@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 x-originating-ip: [70.112.118.223] Content-Type: text/plain; charset=US-ASCII Content-ID: <78306915DEC017449CCE46EF212EF36B@mgd.freescale.com> Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 X-OriginatorOrg: freescale.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Zhao Chenhui wrote: > On Tue, Jul 03, 2012 at 10:17:12PM -0500, Tabi Timur-B04825 wrote: >> Zhao Chenhui wrote: >>> If the guts variable is NULL, it indicates there is error in dts or kernel. >>> We should fix the error, rather than ignore it. >> >> And that's why there's a warning message. Crashing the kernel is not >> going to fix anything. >> > > This error likely crashes the kenel somewhere. Can you test this, please? The point I'm trying to make is that it's wrong to intentionally halt the kernel unless you're sure that it's the best option. A missing device tree node is supposed to only disable a given feature, not break everything. -- Timur Tabi Linux kernel developer at Freescale