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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7E649C63797 for ; Tue, 17 Jan 2023 14:15:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qlVSfYoavoxrvh+qrSu5g0zwWjaGdqeR78pcZGnYO+I=; b=St65e0kRCWJCkc 9Cyn8lToUnKjQxWl7HUGcv8lP1XJYOEdtuX4mIYVHXfDi/Q3ZCB6Z8J0gLqGAI4Kji2DiCf4grLun l20pCxs9TWNwHLeh3BSr4AqbuSBwy8n7i/haNfPqiOTqOe1PALqh2WYZ7gDuMgyI5LCl+EUF/3PMb TUc7CY1WfvRmwtX+3eawULho7Hsi0ThYh52gCA/LY3G5qJFvy3FYqD8TFZjVp69h/64egC4YOgpQX UWvfU1WMut4axsUATs0Gi29trHWAdMX0bPPkKvHNQjCiinUggJag+DDJcecybSM85W7m2N8v0hi1Z yzFvVZ0oNKTLVICDamZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pHmjg-00EZad-Rx; Tue, 17 Jan 2023 14:14:49 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pHmjd-00EZZ3-P4 for linux-arm-kernel@lists.infradead.org; Tue, 17 Jan 2023 14:14:47 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 30EE5AD7; Tue, 17 Jan 2023 06:15:23 -0800 (PST) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 818313F67D; Tue, 17 Jan 2023 06:14:40 -0800 (PST) Date: Tue, 17 Jan 2023 14:14:30 +0000 From: Cristian Marussi To: Dan Carpenter Cc: linux-arm-kernel@lists.infradead.org Subject: Re: [bug report] firmware: arm_scmi: Call Raw mode hooks from the core stack Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230117_061445_935637_2268F6DC X-CRM114-Status: GOOD ( 16.46 ) 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: , 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 Tue, Jan 17, 2023 at 01:29:13PM +0300, Dan Carpenter wrote: > Hello Cristian Marussi, > Hi Dan, > The patch ffb07d58dcba: "firmware: arm_scmi: Call Raw mode hooks from > the core stack" from Jan 13, 2023, leads to the following Smatch > static checker warning: > > drivers/firmware/arm_scmi/driver.c:2732 scmi_probe() > error: 'info->dbg' dereferencing possible ERR_PTR() > > drivers/firmware/arm_scmi/driver.c > 2630 static int scmi_probe(struct platform_device *pdev) > 2631 { > 2632 int ret; > 2633 struct scmi_handle *handle; > 2634 const struct scmi_desc *desc; > 2635 struct scmi_info *info; > 2636 struct device *dev = &pdev->dev; > 2637 struct device_node *child, *np = dev->of_node; > 2638 > 2639 desc = of_device_get_match_data(dev); > 2640 if (!desc) > 2641 return -EINVAL; > 2642 > 2643 info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL); > 2644 if (!info) > 2645 return -ENOMEM; > 2646 > 2647 info->id = ida_alloc_min(&scmi_id, 0, GFP_KERNEL); > 2648 if (info->id < 0) > 2649 return info->id; > 2650 > 2651 info->dev = dev; > 2652 info->desc = desc; > 2653 info->bus_nb.notifier_call = scmi_bus_notifier; > 2654 info->dev_req_nb.notifier_call = scmi_device_request_notifier; > 2655 INIT_LIST_HEAD(&info->node); > 2656 idr_init(&info->protocols); > 2657 mutex_init(&info->protocols_mtx); > 2658 idr_init(&info->active_protocols); > 2659 mutex_init(&info->devreq_mtx); > 2660 > 2661 platform_set_drvdata(pdev, info); > 2662 idr_init(&info->tx_idr); > 2663 idr_init(&info->rx_idr); > 2664 > 2665 handle = &info->handle; > 2666 handle->dev = info->dev; > 2667 handle->version = &info->version; > 2668 handle->devm_protocol_acquire = scmi_devm_protocol_acquire; > 2669 handle->devm_protocol_get = scmi_devm_protocol_get; > 2670 handle->devm_protocol_put = scmi_devm_protocol_put; > 2671 > 2672 /* System wide atomic threshold for atomic ops .. if any */ > 2673 if (!of_property_read_u32(np, "atomic-threshold-us", > 2674 &info->atomic_threshold)) > 2675 dev_info(dev, > 2676 "SCMI System wide atomic threshold set to %d us\n", > 2677 info->atomic_threshold); > 2678 handle->is_transport_atomic = scmi_is_transport_atomic; > 2679 > 2680 if (desc->ops->link_supplier) { > 2681 ret = desc->ops->link_supplier(dev); > 2682 if (ret) > 2683 goto clear_ida; > 2684 } > 2685 > 2686 /* Setup all channels described in the DT at first */ > 2687 ret = scmi_channels_setup(info); > 2688 if (ret) > 2689 goto clear_ida; > 2690 > 2691 ret = bus_register_notifier(&scmi_bus_type, &info->bus_nb); > 2692 if (ret) > 2693 goto clear_txrx_setup; > 2694 > 2695 ret = blocking_notifier_chain_register(&scmi_requested_devices_nh, > 2696 &info->dev_req_nb); > 2697 if (ret) > 2698 goto clear_bus_notifier; > 2699 > 2700 ret = scmi_xfer_info_init(info); > 2701 if (ret) > 2702 goto clear_dev_req_notifier; > 2703 > 2704 if (scmi_top_dentry) { > 2705 info->dbg = scmi_debugfs_common_setup(info); > > The scmi_debugfs_common_setup() has messed up returns. > > It returns both NULL and error pointers for errors. It checks debugfs > functions and the returns for those are generally supposed to be > ignored. I have written a blog about mixing error pointers and NULL > which also explains this historical/psychology based reason why debugfs > does not follow the normal pattern: > > https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/ > Right. I'll fix dropping all unneded debugfs checks and repost as a reply patch so that Sudeep can re-submit on next quickly. I'm still puzzled why I regularly do not catch these errors on my smatch setup running kchecker which does only reports me a bunch of errors on core bitops code. (I have recently pulled updated smatch branch...) Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel