From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 885A2C433ED for ; Wed, 7 Apr 2021 16:55:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4DB9E60232 for ; Wed, 7 Apr 2021 16:55:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354388AbhDGQzp (ORCPT ); Wed, 7 Apr 2021 12:55:45 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:48349 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347854AbhDGQzj (ORCPT ); Wed, 7 Apr 2021 12:55:39 -0400 Received: from mail-wr1-f69.google.com ([209.85.221.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lUBSj-0004KA-8R for linux-kernel@vger.kernel.org; Wed, 07 Apr 2021 16:55:29 +0000 Received: by mail-wr1-f69.google.com with SMTP id u10so5753067wrm.2 for ; Wed, 07 Apr 2021 09:55:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b8tc1z+Zb7AbxJopa6NWnwQSEHNIOQUVlOv43mlLfRg=; b=mAjtGfi4oz4HEO3GHctfmCHTy0d8q/qAwLxuZpd4WA+j49s0+NOxHUEbXLenbtzb7u hs0Y6kR6NIifGLTD0g+quXRMnVa17VWdGNebyFYfPgUTVNaXu8Z2U4DqI1fTMGTZE34M dd0dwl7YLPHIVSTUu0aXMD96IXoBvkiwitOT4miQc1Ye1FnyxfpSvG77zgVvvPZOO5dK QVGWDvd4a/BszNYkOdLh7O4MAGccwIOuSzVceSo+s14AgRHspLDKCW9R/L1rWTcxXQHx 7iIIx/QFxwQwCUMuBroi9FxLPkM7KTF8D2OdS8IcErOVzPFlw36fXoUqUgvZQWo3rl9A r/FQ== X-Gm-Message-State: AOAM5321zco+PJS0ynY3pXKevIxz8ev2n0N3fPmQsayGDh3vil8S+WFd PbmL181vbaAkyDdJ8WNoc6h9KMtqHVtiGEl1HQ5roVS0qPWjqRgEfFjoltg9VINxKaNIK8zXGkM I525vMRnsOOWOh7Oj0TGH3guQT+63eYwadcELUBb7aA== X-Received: by 2002:adf:83e3:: with SMTP id 90mr5487450wre.153.1617814529040; Wed, 07 Apr 2021 09:55:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwERFh51xp45M2S6ot/dHXjHlp4ZeSuWNqmxrKD8vUxGDYwHLWs5JY0sh/0TZbZQBM0SehJTA== X-Received: by 2002:adf:83e3:: with SMTP id 90mr5487443wre.153.1617814528921; Wed, 07 Apr 2021 09:55:28 -0700 (PDT) Received: from [192.168.1.115] (xdsl-188-155-192-147.adslplus.ch. [188.155.192.147]) by smtp.gmail.com with ESMTPSA id j30sm44488457wrj.62.2021.04.07.09.55.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Apr 2021 09:55:28 -0700 (PDT) Subject: Re: [PATCH] memory: atmel-sdramc: check of_device_get_match_data() return value To: Alexandre Belloni Cc: Nicolas Ferre , Ludovic Desroches , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20210407154447.70540-1-krzysztof.kozlowski@canonical.com> From: Krzysztof Kozlowski Message-ID: <57470934-d2db-a360-8347-4debe5830f7b@canonical.com> Date: Wed, 7 Apr 2021 18:55:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/04/2021 18:19, Alexandre Belloni wrote: > Hi, > > On 07/04/2021 17:44:47+0200, Krzysztof Kozlowski wrote: >> If the driver is probed, the of_device_get_match_data() should not >> return NULL, however for sanity check its return value. >> > > As you say, there is no way this will ever be the case, I don't see the > point of checking the return value, this adds 12 bytes for nothing... > > Maybe coverity should be fixed as there are many drivers making the same > (true) assumption and I don't think this is worth the churn. There are also several drivers having this check. To me an explicit NULL check is better and more readable than non-obvious assumption that the of_device_id table contains data for each entry and there is no other bind method (like for OF+I2C drivers). Even if the case is not real, this is nice, simple and explicit code. Best regards, Krzysztof From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67A2AC433B4 for ; Wed, 7 Apr 2021 16:57:20 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11A35610E6 for ; Wed, 7 Apr 2021 16:57:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11A35610E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Iz+jcJU46Mi9lAElOKJY0DlKaWmz9ZMNhNU4UvW9m3s=; b=Y+1MEg9NB+VYURVemM3t5B6Gj TIYZy1fDLNiNNJ46k5bTBixKR966shqWP7eq8vquKWO3XCEr+212FVPA1HQz+/f0aiLE9iK+8I9oQ ZnORiJpXVBF+iMSbyMsgMX9fWobho/vh5qdhY3xFG5g40lVkix50yJQMMKnIMRqzlctRytxHbvEIY PHkiExet97ILtj6Gt5OfgCvc3S8yNFmdGdwXYyTM0fWI1brc6VUNVdlkELVOHTL3s4u3BRNeALQRG MYfxO3HKrpHMeYyMnxk5HgEOqCpvfqWCFPBJZ5tvNaTW+VEMl17qgYOBuJKbYi188feWfdK6UQKEA XNcXAvFBA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUBSp-005WFb-61; Wed, 07 Apr 2021 16:55:35 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lUBSk-005WCo-4h for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 16:55:32 +0000 Received: from mail-wr1-f72.google.com ([209.85.221.72]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lUBSj-0004KG-Gv for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 16:55:29 +0000 Received: by mail-wr1-f72.google.com with SMTP id v8so5740038wrv.7 for ; Wed, 07 Apr 2021 09:55:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b8tc1z+Zb7AbxJopa6NWnwQSEHNIOQUVlOv43mlLfRg=; b=s/eCN/RItg8B2APbCpYtA4pWinAY0qXxXTNcRmoVkF+08se+t/DbKUR91Mryc6bpu1 Zpsy5DV26Ks+JDi1BJ3fOeql6Cf/qxR7OkWTIsxNkabU0ivf6T7RvcHZOMSpm89VwVLn FagaT+Lewdj7HlSE8Y9PxQ8IP9GjRgQuPVs60QRv1PNrIChNqjRRUnYwYi6ABO6i881j eCep/NfuZri6oY9v5Zr77tpu0Jc+hNtbuloIOFcoFh55GW9GGxnuzTYYL0F+/g4SylL7 fKScv3If0u3sOUy/Rk4xZQqtsFwXXyU9b07CwYFaNy0Vd0ZJvwphHyX5SJ9yBTpzhR/3 H8mg== X-Gm-Message-State: AOAM533Clt5bQAHteGHtTVRip9jIUSgYjMoV4ZFUbI+eskIkHInJD8AN OiEMkEwdBLzcPfyY7pJysZE4602MWFRlhbvfIIgOymUmkH8A1/x0fk+CCnguqdw6KHhMss+Hg7c Hh9j/z6dGUylIZM3s8/xankk7d68Kz/m7O8MjvIPbvqpN+XSm6Iol X-Received: by 2002:adf:83e3:: with SMTP id 90mr5487452wre.153.1617814529040; Wed, 07 Apr 2021 09:55:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwERFh51xp45M2S6ot/dHXjHlp4ZeSuWNqmxrKD8vUxGDYwHLWs5JY0sh/0TZbZQBM0SehJTA== X-Received: by 2002:adf:83e3:: with SMTP id 90mr5487443wre.153.1617814528921; Wed, 07 Apr 2021 09:55:28 -0700 (PDT) Received: from [192.168.1.115] (xdsl-188-155-192-147.adslplus.ch. [188.155.192.147]) by smtp.gmail.com with ESMTPSA id j30sm44488457wrj.62.2021.04.07.09.55.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Apr 2021 09:55:28 -0700 (PDT) Subject: Re: [PATCH] memory: atmel-sdramc: check of_device_get_match_data() return value To: Alexandre Belloni References: <20210407154447.70540-1-krzysztof.kozlowski@canonical.com> From: Krzysztof Kozlowski Message-ID: <57470934-d2db-a360-8347-4debe5830f7b@canonical.com> Date: Wed, 7 Apr 2021 18:55:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210407_175530_579402_F0E5F01D X-CRM114-Status: GOOD ( 15.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ludovic Desroches , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 07/04/2021 18:19, Alexandre Belloni wrote: > Hi, > > On 07/04/2021 17:44:47+0200, Krzysztof Kozlowski wrote: >> If the driver is probed, the of_device_get_match_data() should not >> return NULL, however for sanity check its return value. >> > > As you say, there is no way this will ever be the case, I don't see the > point of checking the return value, this adds 12 bytes for nothing... > > Maybe coverity should be fixed as there are many drivers making the same > (true) assumption and I don't think this is worth the churn. There are also several drivers having this check. To me an explicit NULL check is better and more readable than non-obvious assumption that the of_device_id table contains data for each entry and there is no other bind method (like for OF+I2C drivers). Even if the case is not real, this is nice, simple and explicit code. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel