From patchwork Fri Apr 23 17:13:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tudor Ambarus X-Patchwork-Id: 12221119 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=-16.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham 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 59BC6C433ED for ; Fri, 23 Apr 2021 17:14:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2A26A613D8 for ; Fri, 23 Apr 2021 17:14:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243292AbhDWROh (ORCPT ); Fri, 23 Apr 2021 13:14:37 -0400 Received: from esa.microchip.iphmx.com ([68.232.154.123]:11222 "EHLO esa.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbhDWROg (ORCPT ); Fri, 23 Apr 2021 13:14:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1619198040; x=1650734040; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QIoM99CY+uivITKsW95n7kgBLB9Nzc9i1eVPqL+LXCU=; b=i87Q/ntYJWlGLil4DpLPPsmVEnp/6AxQ8l+ulx0ASp4VKdvbovBN/j9E VEn5NPfG88bHMgueSv0Lmzy43cPMo2uf3CUCcKeymVh1U0u0/BHQhZ3ZI xA6NlJLOdnADF+AOBPlGWNTsp7b7WLKNqXMLNfyr7QvThEVxvqlIWIDDe 6lW0aH+l7KaLHu5CkwiTzujBcrbOZQa/qp+jwjrG2+oyOm0pm338paU72 SZQ3uXt6qZptICJc5p1ceBhnWkcY3CQ3xqm6e748CuIzKkyUI87+Ot82t aq+TOgErLBPQeqFrSoyrbwPb+JOG4Ka+vBhalQ7Z03OIr3fu4JXpZEZ6Q Q==; IronPort-SDR: T9EqCRHM/Xfwb2+swXmRa0ogKVHe4KIeSvYd56sR/kQkjK4iGNCGr3cRnUeTcSPrMDi/GggrgG IrwTy5bfH9hoAc3v1A5h7fnZgPWIXbptO5ehsQ/3Pb8malF41VXFLEJgJeRlNUUBVgQVRJSDSc ABv2Fio3Mfn4eKgmn62Qdiyc4jUn3tYqoQv6V58QQGFfdqXBFcvdCPJ2LRFZFhIRMjEGcA/zkl epQ/+h+uAlqwJy/l1q7VqI0Bb+adNZjSh8HUbpyUJbzJbA3UzSloI0KUCOR8UGZzIleUOuyjeP ISw= X-IronPort-AV: E=Sophos;i="5.82,246,1613458800"; d="scan'208";a="52301948" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 23 Apr 2021 10:13:59 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 23 Apr 2021 10:13:51 -0700 Received: from ROB-ULT-M18064N.mchp-main.com (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2176.2 via Frontend Transport; Fri, 23 Apr 2021 10:13:44 -0700 From: Tudor Ambarus To: , , , , , , , , , , , , , , , , , , CC: , , , , , , , , , , , Tudor Ambarus , Marek Szyprowski Subject: [PATCH 1/2] clk: Do not register provider with a NULL dev->of_node Date: Fri, 23 Apr 2021 20:13:33 +0300 Message-ID: <20210423171335.262316-2-tudor.ambarus@microchip.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210423171335.262316-1-tudor.ambarus@microchip.com> References: <20210423171335.262316-1-tudor.ambarus@microchip.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org commit 6579c8d97ad7 ("clk: Mark fwnodes when their clock provider is added") revealed that clk/bcm/clk-raspberrypi.c driver calls devm_of_clk_add_hw_provider(), with a NULL dev->of_node. devm_of_clk_add_hw_provider() should not register the provider with a NULL dev->of_node, as there is no of_node. Apart of the NULL pointer dereference that will result when calling fwnode_dev_initialized() in of_clk_add_hw_provider(), another problem is that when two drivers calling of_clk_add_hw_provider() with np = NULL, their unregistration order is not guaranteed to be correct. Avoid all the problems and just return -ENODEV when the callers of devm_of_clk_add_hw_provider() use a NULL dev->of_node, which seems the natural way to do. Reported-by: Marek Szyprowski Fixes: 6579c8d97ad7 ("clk: Mark fwnodes when their clock provider is added") Signed-off-by: Tudor Ambarus --- drivers/clk/clk.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index e2ec1b745243..8b5077cc5e67 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -4634,11 +4634,10 @@ static struct device_node *get_clk_provider_node(struct device *dev) * @get: callback for decoding clk_hw * @data: context pointer for @get callback * - * Registers clock provider for given device's node. If the device has no DT - * node or if the device node lacks of clock provider information (#clock-cells) - * then the parent device's node is scanned for this information. If parent node - * has the #clock-cells then it is used in registration. Provider is - * automatically released at device exit. + * Registers clock provider for given device's node. If the device node lacks + * of clock provider information (#clock-cells) then the parent device's node is + * scanned for this information. If parent node has the #clock-cells then it is + * used in registration. Provider is automatically released at device exit. * * Return: 0 on success or an errno on failure. */ @@ -4650,6 +4649,9 @@ int devm_of_clk_add_hw_provider(struct device *dev, struct device_node **ptr, *np; int ret; + if (!dev->of_node) + return -ENODEV; + ptr = devres_alloc(devm_of_clk_release_provider, sizeof(*ptr), GFP_KERNEL); if (!ptr) From patchwork Fri Apr 23 17:13:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tudor Ambarus X-Patchwork-Id: 12221121 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=-16.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 0CC68C433ED for ; Fri, 23 Apr 2021 17:14:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D39EB613C4 for ; Fri, 23 Apr 2021 17:14:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243337AbhDWROk (ORCPT ); Fri, 23 Apr 2021 13:14:40 -0400 Received: from esa.microchip.iphmx.com ([68.232.154.123]:11222 "EHLO esa.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbhDWROk (ORCPT ); Fri, 23 Apr 2021 13:14:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1619198043; x=1650734043; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wqgq7pqsXLy9APhVwMMB3KE4tW51aVfTECKn3WOERfU=; b=LO1ojkegWj5z77zftm1dIr8CGcQiuYduaJicDrsUk+K7H+yz5jMlkIg2 OBkzcciVa9wYCthf2ilqQeUbFurL7UN/Kxou+v/el0TK5wMickVVH7dO8 zAFpdBFeQcFwctQcY6mx3VXGqJC3bqevA/wqacU5PY1wQOwmu7Czu1gA0 Ap762g/e5Lcch80mGCgBdioXej0SXuQTePq/FUy2z+ZdgEuJ11BExmikO K6Iz10pPuDQkp92rkG/duQAO7z9euaIyhxu4rrjA4R0IesqEquYQKyhrH OfxUPnqOaNq690kpJzbRmYrD01xZ9GAp5UEriNMW3hxYrWjIy5trQOzto A==; IronPort-SDR: 3tvSmtPWm/TnnbjXHVqeskJ0XLo8TbMcIZrsiniZgIrC7PY3wK2pXk+AXOpj+ZnJkuD8Eff73/ My9PEZT+xFTs5b9QhDEvy8Q25Xm7aTV+7/H3Aziy6ROKBxkqvERD3eZSGTA6Qv1vx8dv8MYrFv e1Dz9sadfdbxkWz3/pOCcx3rgrfZCH4+Z2asUHiVxS6v2UHSfOuK+AZ9DFkdBYU7TRMCmx21d/ REgTPr4B5FMCXFs0fwqoxZe1Y3vbX+5HQqtv0zYm7MUDRaCSIv5JESGyS7sDitPLK/a/SeNGyM SpM= X-IronPort-AV: E=Sophos;i="5.82,246,1613458800"; d="scan'208";a="52301960" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 23 Apr 2021 10:14:02 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 23 Apr 2021 10:13:58 -0700 Received: from ROB-ULT-M18064N.mchp-main.com (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2176.2 via Frontend Transport; Fri, 23 Apr 2021 10:13:52 -0700 From: Tudor Ambarus To: , , , , , , , , , , , , , , , , , , CC: , , , , , , , , , , , Tudor Ambarus , Marek Szyprowski Subject: [PATCH 2/2] clk: bcm: rpi: Do not call devm_of_clk_add_hw_provider with a NULL dev->of_node Date: Fri, 23 Apr 2021 20:13:34 +0300 Message-ID: <20210423171335.262316-3-tudor.ambarus@microchip.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210423171335.262316-1-tudor.ambarus@microchip.com> References: <20210423171335.262316-1-tudor.ambarus@microchip.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org devm_of_clk_add_hw_provider() expects, as the "_of_" string indicates, a non NULL dev->of_node, otherwise it will return -ENODEV. Since this driver can be probed either through the old-fashioned platform device registration or through a DT node that is a child of the firmware node, call devm_of_clk_add_hw_provider() only when the DT node is present. Reported-by: Marek Szyprowski Fixes: 6579c8d97ad7 ("clk: Mark fwnodes when their clock provider is added") Signed-off-by: Tudor Ambarus --- drivers/clk/bcm/clk-raspberrypi.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c index dd3b71eafabf..84a4e14babff 100644 --- a/drivers/clk/bcm/clk-raspberrypi.c +++ b/drivers/clk/bcm/clk-raspberrypi.c @@ -337,10 +337,12 @@ static int raspberrypi_clk_probe(struct platform_device *pdev) if (ret) return ret; - ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, - clk_data); - if (ret) - return ret; + if (dev->of_node) { + ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, + clk_data); + if (ret) + return ret; + } rpi->cpufreq = platform_device_register_data(dev, "raspberrypi-cpufreq", -1, NULL, 0);