Received: by 10.192.165.148 with SMTP id m20csp746398imm; Wed, 2 May 2018 08:10:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpkCG2cGcXEbkkZWLr8VW8gwDIdsqpixtqw3gVYYw5HD38KvV7sXmywXglnfrVzYZpvQjwq X-Received: by 10.98.75.139 with SMTP id d11mr19801967pfj.244.1525273830355; Wed, 02 May 2018 08:10:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525273830; cv=none; d=google.com; s=arc-20160816; b=W23eGhXOL7+Ym0YV0tWRPd4+vkzDjbN8VgTnK95dzdP/S5zDbdKD3TZ+vaXOYEGpGo eaL3vOwt6WqP2R5yEXDSRHjh41YAv5qk0S/hyZScB0kfo982KKmuA19QZf25R1Q7QzW0 7l76BMLx0scpN8tE5yy+XoflOlpcg1BA4stjhkgnbGtWkAO1RXMltvzWrPtrxFEbvtw5 OzZo/VJ2/dNxgQPOr3xEJ+N0ZUEiP0+swZAW5ApBJu0lk4etgEyKf/PktQXQscC2kggl TALuEyZMLATjayKGxeauuhHSXGAiCsvjCGU7QXiyNg6VUtncldh6DthpRlcakvuzTQJa dzDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=ZzFVgdexRgXQ11+VlUyKkr7OpXW9zn5AaIK4XSVinwM=; b=PkVJnN/RuXFZabMuSOdFETdRPM2u0Gt432zaO1hkC4qqx+IM2aT/GSQXOzsCXjXaVj Wb5+2jqCtrtcDioIO3fm1vPwsJBsW4OKysMQeYo+xbDzPULQs8dKK2ZiLXPfYSFWlKQC h4nDD/KvlbOWvO5Xcm+CK+Y592Bd3bJ7QdACx1pl/ZpxSCjmDRpgJUX1mCYr8A8opk3u xsTY8D40vqVIZWJoJBnz7W628xqA1Qq+sHsKPWZTzcZY/ykhjbEMKyCXV15AL7wrjE6e 7eJcKqSLoGDLNUcTtPQwF9mZKT0awwP+ZW9KX93VwK1ILPiTPg9U1z9Htvn87wO4fQxn D0PQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=C99ARqCZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bd8-v6si11227546plb.156.2018.05.02.08.10.15; Wed, 02 May 2018 08:10:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=C99ARqCZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751731AbeEBPJg (ORCPT + 99 others); Wed, 2 May 2018 11:09:36 -0400 Received: from fllnx209.ext.ti.com ([198.47.19.16]:10401 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbeEBPJX (ORCPT ); Wed, 2 May 2018 11:09:23 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id w42F8IuW022527; Wed, 2 May 2018 10:08:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1525273698; bh=hoHvxJ6JsLvBoK4uJ00oRHgQ11QHwEsPJgsvsVoTV5I=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=C99ARqCZLtnjwskezIjcHSLfBEdq2dFulf98JCjSn5lztXsviy1/5E2jLncINjrsH k1y8c3qSx+a00I2BzmCxY3lQHKXgD3oNlFm8GJwoVzo1GAvLvYHNfUTllZvnj93DX6 7YIxA+NvCETZF/Qb17SvfCd8WfXPU0xzdznIcMWU= Received: from DFLE106.ent.ti.com (dfle106.ent.ti.com [10.64.6.27]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w42F8IPX015244; Wed, 2 May 2018 10:08:18 -0500 Received: from DFLE114.ent.ti.com (10.64.6.35) by DFLE106.ent.ti.com (10.64.6.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 2 May 2018 10:08:18 -0500 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Wed, 2 May 2018 10:08:18 -0500 Received: from [172.24.190.172] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w42F87GJ024631; Wed, 2 May 2018 10:08:08 -0500 Subject: Re: [PATCH v9 03/27] clk: davinci: psc: allow for dev == NULL To: David Lechner , , , CC: Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Kevin Hilman , Bartosz Golaszewski , Adam Ford , References: <20180427001745.4116-1-david@lechnology.com> <20180427001745.4116-4-david@lechnology.com> <8940259b-5811-ce9f-8262-17d39ca0a46f@ti.com> <94d4cfc5-0ea7-e642-c7e3-8d549bdef8ce@lechnology.com> From: Sekhar Nori Message-ID: <3cec9c1f-48fd-1c16-b642-eb93e41446fc@ti.com> Date: Wed, 2 May 2018 20:38:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <94d4cfc5-0ea7-e642-c7e3-8d549bdef8ce@lechnology.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 02 May 2018 07:19 AM, David Lechner wrote: > On 05/01/2018 09:02 AM, Sekhar Nori wrote: >> On Friday 27 April 2018 05:47 AM, David Lechner wrote: >>> +static inline void *_devm_kzalloc(struct device *dev, size_t size, >>> gfp_t flags) >>> +{ >>> +    if (dev) >>> +        return devm_kzalloc(dev, size, flags); >>> + >>> +    return kzalloc(size, flags); >>> +} >> >> I have the same question on the utility of this. A memory allocation >> error so early on is not going to result in a bootable system anyway. >> So, I wonder if its better to just BUG() in such cases. That will >> actually help faster debug than returning an error back. I know the push >> back on using BUG(), but clock drivers are special, and I think thats >> why its seems to be used quite a bit already. >> > > Same reply here as well. On DA850/DA830, you might not get a console, > but you will "boot" even if one of the PSC devices fails though. Was not thinking of failure to boot due to clocks being disabled, but the fact that you are not able to allocate a small amount of memory so early in boot process. The chances of successful boot after memory allocation failures like that are close to zero. > WARN() is probably just as good as BUG() in this case too. Okay, but with WARN() you would continue to proceed to try to boot which is not going to be much fruitful (and might actually muddle the first failure). But up to you on this. Thanks, Sekhar