Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp246578pxf; Thu, 11 Mar 2021 02:59:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJzGq9aMtA6tEJ4CyRCkL1jf+gSXx9tI0Km1BR504JoJffYmGyY7BBoVItDFXkhww1+AsKHq X-Received: by 2002:a17:906:5295:: with SMTP id c21mr2488704ejm.67.1615460394763; Thu, 11 Mar 2021 02:59:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615460394; cv=none; d=google.com; s=arc-20160816; b=XCZavWOv7An64A0IBPj4H/ETbhvUh4FXpDSSO/WhDJsydGcAPQabk/SeFHxzNNmHLp dUy8W0SaA+N2eXEb/gjrlTZc10Rs+yXF3g4nVgDJ3hZ+4cX/oSz7mBYXnOo5AHDAdWg3 +CWpjLO/GCpvMJAvLebtkNvTrBQtGt1nshxMiAIiltpqJsVwxgDsqzRCFc3TWLNggmro Eu9mTadx8EOEyhgGRnSjmLygJBO2mz7lJzV8buzk0slOuyctnA/V/2b3DHRdW8lWW9Gv IU/K9o+p+qRnP6ohrVZU0CN5QGNuukh9nZuFGVBn/uQL891JS9ZvuaDXHfUejGXSJitK TYwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:cc:subject:from:to; bh=DpjiVa1HimLavEenIPI/q+EYv2EzKxamIalhRIQxRQk=; b=bP+8SMIC4iyxu51SKV6SMtOub8homvZkaV/driiUgWRKsTeh2LGphlNDgDKvQhOqgW BhuEa0crl6CeCk/usRDVE1+D/tolZdvuEBHwOVkoJbrV3CV2pJq/xWpN412F6FPplKcD Pi7raRFBo3NJToAvrnbY/sDW1nwn1sHO2/qT0AlIsuWPdWyeu4RKAYQqpZFdvViRNCSg FhvJ6c9ZEnlmkI7VWlgn3idHmkp14JOhPrCpPRAZ4udVN18vOWfoc+XaH6bNBjG8jBnm XtCXjZNopWwRZxWYO3WvO0APHU/2veNZQaDmnYU0CfB4J/wx8Kc/7lmmWi3iUisktMae u1CA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h13si1496016edq.173.2021.03.11.02.59.32; Thu, 11 Mar 2021 02:59:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232529AbhCKK5h (ORCPT + 99 others); Thu, 11 Mar 2021 05:57:37 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:54251 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232349AbhCKK5c (ORCPT ); Thu, 11 Mar 2021 05:57:32 -0500 Received: from 1.general.cking.uk.vpn ([10.172.193.212]) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lKJ0U-0000MN-Ub; Thu, 11 Mar 2021 10:57:31 +0000 To: Michal Simek From: Colin Ian King Subject: re: pinctrl: core: Handling pinmux and pinconf separately Cc: Linus Walleij , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Message-ID: Date: Thu, 11 Mar 2021 10:57:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 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 Hi, Static analysis on linux-next with Coverity has found a potential issue in drivers/pinctrl/core.c with the following commit: commit 0952b7ec1614abf232e921aac0cc2bca8e60e162 Author: Michal Simek Date: Wed Mar 10 09:16:54 2021 +0100 pinctrl: core: Handling pinmux and pinconf separately The analysis is as follows: 1234 /** 1235 * pinctrl_commit_state() - select/activate/program a pinctrl state to HW 1236 * @p: the pinctrl handle for the device that requests configuration 1237 * @state: the state handle to select/activate/program 1238 */ 1239 static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state) 1240 { 1241 struct pinctrl_setting *setting, *setting2; 1242 struct pinctrl_state *old_state = p->state; 1. var_decl: Declaring variable ret without initializer. 1243 int ret; 1244 2. Condition p->state, taking true branch. 1245 if (p->state) { 1246 /* 1247 * For each pinmux setting in the old state, forget SW's record 1248 * of mux owner for that pingroup. Any pingroups which are 1249 * still owned by the new state will be re-acquired by the call 1250 * to pinmux_enable_setting() in the loop below. 1251 */ 3. Condition 0 /* !!(!__builtin_types_compatible_p() && !__builtin_types_compatible_p()) */, taking false branch. 4. Condition !(&setting->node == &p->state->settings), taking true branch. 7. Condition 0 /* !!(!__builtin_types_compatible_p() && !__builtin_types_compatible_p()) */, taking false branch. 8. Condition !(&setting->node == &p->state->settings), taking true branch. 11. Condition 0 /* !!(!__builtin_types_compatible_p() && !__builtin_types_compatible_p()) */, taking false branch. 12. Condition !(&setting->node == &p->state->settings), taking false branch. 1252 list_for_each_entry(setting, &p->state->settings, node) { 5. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true branch. 9. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true branch. 1253 if (setting->type != PIN_MAP_TYPE_MUX_GROUP) 6. Continuing loop. 10. Continuing loop. 1254 continue; 1255 pinmux_disable_setting(setting); 1256 } 1257 } 1258 1259 p->state = NULL; 1260 1261 /* Apply all the settings for the new state - pinmux first */ 13. Condition 0 /* !!(!__builtin_types_compatible_p() && !__builtin_types_compatible_p()) */, taking false branch. 14. Condition !(&setting->node == &state->settings), taking true branch. 1262 list_for_each_entry(setting, &state->settings, node) { 15. Switch case value PIN_MAP_TYPE_CONFIGS_PIN. 1263 switch (setting->type) { 1264 case PIN_MAP_TYPE_MUX_GROUP: 1265 ret = pinmux_enable_setting(setting); 1266 break; 1267 case PIN_MAP_TYPE_CONFIGS_PIN: 1268 case PIN_MAP_TYPE_CONFIGS_GROUP: 16. Breaking from switch. 1269 break; 1270 default: 1271 ret = -EINVAL; 1272 break; 1273 } 1274 Uninitialized scalar variable (UNINIT) 17. uninit_use: Using uninitialized value ret. 1275 if (ret < 0) 1276 goto unapply_new_state; For the PIN_MAP_TYPE_CONFIGS_PIN and PIN_MAP_TYPE_CONFIGS_GROUP setting->type cases the loop can break out with ret not being set. Since ret has not been initialized it the ret < 0 check is checking against an uninitialized value. I was not sure if the PIN_MAP_TYPE_CONFIGS_PIN and PIN_MAP_TYPE_CONFIGS_GROUP cases should be setting ret and if so, what the value of ret should be set to (is it an error condition or not?). Or should ret be initialized to 0 or a default error value at the start of the function. Hence I'm reporting this issue. Colin