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 S1755450AbcIPFdJ (ORCPT <rfc822;w@1wt.eu>);
        Fri, 16 Sep 2016 01:33:09 -0400
Received: from mout.web.de ([217.72.192.78]:56793 "EHLO mout.web.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752293AbcIPFdA (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Sep 2016 01:33:00 -0400
Subject: Re: clk/Renesas-MSTP: Less function calls in cpg_mstp_clocks_init()
 after error detection
To: Geert Uytterhoeven <geert@linux-m68k.org>
References: <566ABCD9.1060404@users.sourceforge.net>
 <1575ddf1-bd1a-fe98-046a-a586eb30fe47@users.sourceforge.net>
 <b945de99-815a-b380-e13c-17b01e0febad@users.sourceforge.net>
 <CAMuHMdX=We-N--Fc0KWD_p8AmnBMYDW9b560VGKi+SZ5k85e9A@mail.gmail.com>
 <50646b53-663f-f77f-a79e-2422b5687688@users.sourceforge.net>
 <CAMuHMdWgK7HSqL+XWdrzDZkvmg5rb3MtykYNkS1amm5HgnOBAg@mail.gmail.com>
Cc: linux-clk <linux-clk@vger.kernel.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Michael Turquette <mturquette@baylibre.com>,
        Simon Horman <horms+renesas@verge.net.au>,
        Stephen Boyd <sboyd@codeaurora.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>,
        Julia Lawall <julia.lawall@lip6.fr>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <4a7d20c9-d080-80a4-6529-bc9fa1b7a186@users.sourceforge.net>
Date: Fri, 16 Sep 2016 07:32:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAMuHMdWgK7HSqL+XWdrzDZkvmg5rb3MtykYNkS1amm5HgnOBAg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:1XJ54DWGgZ8STSIHVHD/dc1SqAND7jdWZrbA/9MNZZOmvajPji0
 1nhdj2EH045CnLCenHAbSHlGnto2I0hjOF6XY73HmYET+sRaksDoS3SNh+BQN9d5CGchUgr
 /cRKorHLmp2J9M57x2elqhkrUaku738ju20NG4nrN7vy3tdmZoja+Zcl0SckxsQuEmsaXwU
 iKAWynF39s6+Rz/hpPQtA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:hAbhJeBSSQE=:FIunnV8Cwi1oMS2ymIp346
 TGKnJR7oPDs+KnnZVeB64giPS0R1IlYdr3Bs490qGg6pRY5gOLIbCTYKzyMbYHJqbfgwo3wjg
 xwakLSDhwDjHo21VPulBk/i1mv8h3PLW9QQwjYNyQdKqK9BZYrxNe3gKH59oB+zHO2shAUj2U
 TAh1x+NYt8vJDOno/CW4Eh714ckbMwAxFNduEEcWVJvoF0prsCRM2JJkMR6CxGqSZ/Aw9FjEX
 J/8sy53ElNAAvALU7lYBygVIHFnaxYuURtHz7BmAUGWqz2niqaIzWDIDoWWmtK6zq6zRKR8y/
 +o9JI63ORAidZ3FtAEpWEu84crCcSVNfXrcmOeGnDg678p1THUlWdeF3pGA//5gRbF9bklmj3
 eh5Ur20yv6cZeSUn2m9MuwoQGIl53rrzE5X0QFYlP0vFKnPN6pqMmxDk/aEckwz5gbAg/Z3lL
 a0FrKLLD11UJ9wcSQxRWO0Fk2keYPs7eIwwgme6NIpFFTiUccnE/Mnm48lvvswtIgrrT10Us/
 DhhjaaBNZeoYGMcn3Ubg17UHKCyxf+85BO56nFdOz1saJkBpAR+kWK5bqyDjD7NOc51M49XSU
 wxSApUoXtMyLX0WojZcAB6Y/xSR+W4vG5UhuLm+872yMMmiuXUmzeSWS94dEAGl9cxIdM6+hF
 db32OXEu3EpyOW7CFRiQVSESGcHCI1zOXC+8lrb0JwJjLO0xTPrWzVo/kAEUATuClUmKCnZRw
 pl0hpaMFYIhf+Yrnf1xykLzRmCdksbRxCv9YGeRbC/ehIgRPL6NsRfhGLEeL7H2haY58oc1JV
 eggoi7z
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> * Should it usually be determined quicker if a required resource like
>>   memory could be acquired before trying the next allocation?
> 
> Note that if memory allocation fails in this driver, the system won't
> boot at all.

Thanks for this information.


> So even not checking for allocation failures at all could be acceptable.

I find this opinion interesting somehow.

I would generally prefer to check return values from various function calls
immediately instead of keeping the discussed source code structure unchanged.

Regards,
Markus