From mboxrd@z Thu Jan 1 00:00:00 1970 From: elfring@users.sourceforge.net (SF Markus Elfring) Date: Thu, 16 Jul 2015 08:40:30 +0200 Subject: ARM: OMAP2: Delete unnecessary checks before three function calls In-Reply-To: References: <5307CAA2.8060406@users.sourceforge.net> <530A086E.8010901@users.sourceforge.net> <530A72AA.3000601@users.sourceforge.net> <530B5FB6.6010207@users.sourceforge.net> <530C5E18.1020800@users.sourceforge.net> <530CD2C4.4050903@users.sourceforge.net> <530CF8FF.8080600@users.sourceforge.net> <530DD06F.4090703@users.sourceforge.net> <5317A59D.4@users.sourceforge.net> <54705EC3.90708@users.sourceforge.net> <55928739.5040809@users.sourceforge.net> Message-ID: <55A751DE.5080301@users.sourceforge.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > I have to say, I am a bit leery about applying the omap_device.c and > omap_hwmod.c changes, since the called functions -- omap_device_delete() > and clk_disable() -- don't explicitly document that NULLs are allowed > to be passed in. How are the chances to improve documentation around such implementation details? > So there's no explicit contract that callers can rely upon, to (at least > in theory) prevent those internal NULL pointer checks from being removed. Are there any additional variations to consider for source files from different processor architectures? > So I would suggest that those two functions' kerneldoc be patched first to > explicitly state that passing in a NULL pointer is allowed. Should my static source code analysis approach help you any more to clarify further open issues? > So I'll apply that change now for v4.3, touching up the commit message accordingly. Thanks for your constructive feedback. >> arch/arm/mach-omap2/omap_device.c | 3 +-- >> arch/arm/mach-omap2/omap_hwmod.c | 5 +---- >> arch/arm/mach-omap2/timer.c | 3 +-- Did Tony Lindgren pick a similar update suggestion up, too? https://lkml.org/lkml/2015/7/15/112 Regards, Markus