Message ID | 20221229184011.62925-1-samuel@sholland.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2540129wrt; Thu, 29 Dec 2022 10:42:23 -0800 (PST) X-Google-Smtp-Source: AMrXdXv74SbiNV7SHXiCXZ/KWQ/kAXF7FtAVjqHe+dw+syA0uo9r306WpTSRTMd50qiU1GGUMGc8 X-Received: by 2002:a17:90b:3ec4:b0:225:d605:6163 with SMTP id rm4-20020a17090b3ec400b00225d6056163mr20199960pjb.8.1672339343085; Thu, 29 Dec 2022 10:42:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672339343; cv=none; d=google.com; s=arc-20160816; b=wnJd3VMDhQ4xzows3JdhMEcjkmVx/X1EgGhQJS2Z30unLLHoXxQysEIYIVdNe9oOOb U0Gfisg18NQ+379WM+0yGQJXRd6DQnPiI+lio++P4Rr9qG08PRrJBelSeHdu6+bkNEQs Ogh3NTZTm9Y2G/spsJPWglRSaGWclMCRt4dOp8CM41aN0eU1+kIWkVzhTa4glMTGMqly wXMAAf8zsYh+sFHQf9KUsVdWsmfdGNmm+HtcgOEgx6jhwfps0CNmIVWzImCSR8TFd3qm cZmcMH1UMO/X3/L6vRIDVLfQ/lwB457Vn7NTm1q68mZsk45HjYlCuoO+zFZmrBQcszAs VwSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:feedback-id:dkim-signature :dkim-signature; bh=Ub6/Sg6MtwK7zSZLvDEMExGoikMh9KjbbFTpe8DKeuA=; b=TjmZY4jq6p99PvlHfMq9PhSfjmN1y9zBf3Kk52t9sAv0Bx5P+1Lo3l/HT80HGE9epg DlzBbM9cbC+e1jogQRJEzsaZUkfgzxdfaZwPOVkhGhczMyePmwebR9b0cye9k9IpLnln POKwvQ7jvbpwD4lMS3vLYdHpmLPQ8L4UJ2Sg5vFCYgzMRBzlnWmh/+ldv32Td0/HBHKL D/gjk5pHYMjKIri25Tx9R5rKJIh+cZM0Pl8dUhek7h7JqC3+XobAOpvQFGDu3rX/U76x vXvETOizsI478Os9uar2XRVM9AiDruT7PSlCthetRrLNv0Et8BPGnmAr2alh+aIyMC8f iJLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sholland.org header.s=fm3 header.b=gw+eCMVA; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=d0Ax4PSW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sholland.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pf7-20020a17090b1d8700b00213587b200esi19055496pjb.189.2022.12.29.10.42.08; Thu, 29 Dec 2022 10:42:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sholland.org header.s=fm3 header.b=gw+eCMVA; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=d0Ax4PSW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sholland.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233803AbiL2Skg (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Thu, 29 Dec 2022 13:40:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233575AbiL2SkR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 29 Dec 2022 13:40:17 -0500 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8FD5116A; Thu, 29 Dec 2022 10:40:16 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id B239432007F1; Thu, 29 Dec 2022 13:40:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 29 Dec 2022 13:40:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= cc:cc:content-transfer-encoding:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1672339213; x=1672425613; bh=Ub6/Sg6MtwK7zSZLvDEMExGoi kMh9KjbbFTpe8DKeuA=; b=gw+eCMVAO9wS/xum4K/FmCm8RLK+HPddgKot9F+6C aXmo+a4J5GbZ/4SQIPdakBOJYRFUnQhvcCA+XVB3SsHzW7NAbSKmotc1ujaD8Y8O vODRxqEvuCsmehC/Kuw9s3h+FY5gHJw4Yv7M1xcQvrhv0JgzDaTBQ/n8yOdkv9ih snRcMti+ltyPcsj+T1ccNfpLLo9W9MEPcGfts8/Uwt7rK4IKydVggD/NcJ4MRpyw hrg9P8FNnY6UQuTZikUJctqGNE+CoVjT+qg2qpg7IVSZ6teE6iotZcmOmwO56qIB o7fhNWNkESC72HMpJ/UQPuUiNBu1yaKj2eX60W9W35MNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1672339213; x=1672425613; bh=Ub6/Sg6MtwK7zSZLvDEMExGoikMh9KjbbFT pe8DKeuA=; b=d0Ax4PSWdXTAOophmW8FbmoPkGdXa0JFRPff+iWnGGT7jU9VIfw h8SOWIcNDDSZJU2hvODYDoyQXuCvff9dL3p+Nbi2FKaXqqDFTmcZlkPBJZ2HcSqB VejGcWgf7H3NgVKWEDhSA4hnna7Ql7SCrAF1rKyykrC7z55lsegk3KZZ+1EPdRnY 4e1RCKjRR4ulSAMhOmvBlawaDFBHayMO7BcmhKqo0eqIgzNT4Q22Hzd+E0eUfe1i yOh/UuZu7xBn9CoESjRPiboWUdUgF96SZjHM4Uybo+HqxjL4VfUIwqxJBQAAcK6Q oQNF34KNhHa8kjFqHBojTrORJbg7NwAKi0A== X-ME-Sender: <xms:Dd-tY1c6jzUb0hyju4GwDZH1oft3CCyXVijpSqpDl8cv9-oeZaLONA> <xme:Dd-tYzMdkP4pG3FMiD8k0KyIYSz4Cunbh8dTw5pJ6NDPWp730s8rAgRDuSeEORT6T 7hE0zH2Iq6or7o4uQ> X-ME-Received: <xmr:Dd-tY-iY_PkIGgF9HXiucJrEOXJIwGOTiXLJvE6hoUFdTR_npT4Tu7eX48PQZ1mtF6WL8IwAIQmAsBYQUvP4-S8x39NunvRzLQTRQFdtQfkHc0EHPVviKKWJdq-b0NbC13ugGQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrieeggdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofgggfestdekredtredttdenucfhrhhomhepufgrmhhuvghl ucfjohhllhgrnhguuceoshgrmhhuvghlsehshhholhhlrghnugdrohhrgheqnecuggftrf grthhtvghrnhepkeevlefhjeeuleeltedvjedvfeefteegleehueejffehgffffeekhefh hfekkeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshgrmhhuvghlsehshhholhhlrghnugdrohhrgh X-ME-Proxy: <xmx:Dd-tY-_2sMylYYXdONF5dVioDiH-G7zAxEGZbB-xlJY6MtoNNh9lrw> <xmx:Dd-tYxuiy0caaCttUucdX2r-jxGouwl5xMJuVdAysE6NLSz-rYtILA> <xmx:Dd-tY9HjIuGchgcq7GWs9miG1a7fPwA8s6O30AdaGVZA5nNiYxosDg> <xmx:Dd-tYy9aVxAJWBiIe_B5URbRY-pyuR4RBWvGvJzZY8nMmvk50fNIwA> Feedback-ID: i0ad843c9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Dec 2022 13:40:12 -0500 (EST) From: Samuel Holland <samuel@sholland.org> To: Alessandro Zummo <a.zummo@towertech.it>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com> Cc: linux-arm-kernel@lists.infradead.org, linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev, Samuel Holland <samuel@sholland.org> Subject: [PATCH 1/2] rtc: sun6i: Prevent an out-of-bounds read Date: Thu, 29 Dec 2022 12:40:10 -0600 Message-Id: <20221229184011.62925-1-samuel@sholland.org> X-Mailer: git-send-email 2.37.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753574898942971113?= X-GMAIL-MSGID: =?utf-8?q?1753574898942971113?= |
Series |
[1/2] rtc: sun6i: Prevent an out-of-bounds read
|
|
Commit Message
Samuel Holland
Dec. 29, 2022, 6:40 p.m. UTC
If there is more than one parent clock in the devicetree, the
driver sets .num_parents to a larger value than the number of array
elements, which causes an out-of-bounds read in the clock framework.
Fix this by coercing the parent count to a Boolean value, like the
driver expects.
Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator")
Signed-off-by: Samuel Holland <samuel@sholland.org>
---
drivers/rtc/rtc-sun6i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Dne četrtek, 29. december 2022 ob 19:40:10 CET je Samuel Holland napisal(a): > If there is more than one parent clock in the devicetree, the > driver sets .num_parents to a larger value than the number of array > elements, which causes an out-of-bounds read in the clock framework. Is there any DT with more than one parent? I think more fixes are needed if this is the case. Best regards, Jernej > > Fix this by coercing the parent count to a Boolean value, like the > driver expects. > > Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator") > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > drivers/rtc/rtc-sun6i.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > index ed5516089e9a..a22358a44e32 100644 > --- a/drivers/rtc/rtc-sun6i.c > +++ b/drivers/rtc/rtc-sun6i.c > @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct device_node > *node, > > init.parent_names = parents; > /* ... number of clock parents will be 1. */ > - init.num_parents = of_clk_get_parent_count(node) + 1; > + init.num_parents = !!of_clk_get_parent_count(node) + 1; > of_property_read_string_index(node, "clock-output-names", 0, > &init.name);
Hi Jernej, On 1/5/23 11:26, Jernej Škrabec wrote: > Dne četrtek, 29. december 2022 ob 19:40:10 CET je Samuel Holland napisal(a): >> If there is more than one parent clock in the devicetree, the >> driver sets .num_parents to a larger value than the number of array >> elements, which causes an out-of-bounds read in the clock framework. > > Is there any DT with more than one parent? I think more fixes are needed if > this is the case. H616 and newer expect more than one parent, to accurately represent the RTC clock tree, but they use the CCU driver instead of this code. This bug is preventing us from relaxing `maxItems` in the binding for H6 and older SoCs, even if Linux does not use the additional parent clocks. I want to fix this bug now, to give us the option (if beneficial) of relaxing the binding in the long-term future. Regards, Samuel >> Fix this by coercing the parent count to a Boolean value, like the >> driver expects. >> >> Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator") >> Signed-off-by: Samuel Holland <samuel@sholland.org> >> --- >> >> drivers/rtc/rtc-sun6i.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c >> index ed5516089e9a..a22358a44e32 100644 >> --- a/drivers/rtc/rtc-sun6i.c >> +++ b/drivers/rtc/rtc-sun6i.c >> @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct device_node >> *node, >> >> init.parent_names = parents; >> /* ... number of clock parents will be 1. */ >> - init.num_parents = of_clk_get_parent_count(node) + 1; >> + init.num_parents = !!of_clk_get_parent_count(node) + 1; >> of_property_read_string_index(node, "clock-output-names", 0, >> &init.name); > > > >
Dne sobota, 07. januar 2023 ob 18:15:47 CET je Samuel Holland napisal(a): > Hi Jernej, > > On 1/5/23 11:26, Jernej Škrabec wrote: > > Dne četrtek, 29. december 2022 ob 19:40:10 CET je Samuel Holland napisal(a): > >> If there is more than one parent clock in the devicetree, the > >> driver sets .num_parents to a larger value than the number of array > >> elements, which causes an out-of-bounds read in the clock framework. > > > > Is there any DT with more than one parent? I think more fixes are needed > > if > > this is the case. > > H616 and newer expect more than one parent, to accurately represent the > RTC clock tree, but they use the CCU driver instead of this code. If I understand that correctly, second clock would be 24 MHz crystal? In any case, if multiple parents are possible, check needs to be added to see if parent clocks include 32 kHz clock or not. > > This bug is preventing us from relaxing `maxItems` in the binding for H6 > and older SoCs, even if Linux does not use the additional parent clocks. > I want to fix this bug now, to give us the option (if beneficial) of > relaxing the binding in the long-term future. I wouldn't call it a bug, since it works just fine for currently defined binding. Do you have DT binding change in pipeline? Best regards, Jernej > > Regards, > Samuel > > >> Fix this by coercing the parent count to a Boolean value, like the > >> driver expects. > >> > >> Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator") > >> Signed-off-by: Samuel Holland <samuel@sholland.org> > >> --- > >> > >> drivers/rtc/rtc-sun6i.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > >> index ed5516089e9a..a22358a44e32 100644 > >> --- a/drivers/rtc/rtc-sun6i.c > >> +++ b/drivers/rtc/rtc-sun6i.c > >> @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct > >> device_node *node, > >> > >> init.parent_names = parents; > >> /* ... number of clock parents will be 1. */ > >> > >> - init.num_parents = of_clk_get_parent_count(node) + 1; > >> + init.num_parents = !!of_clk_get_parent_count(node) + 1; > >> > >> of_property_read_string_index(node, "clock-output-names", 0, > >> > >> &init.name);
Hello, What should I do with this series, I'm not sure you came to an agreement. Also, 2/2 doesn't apply so you'd have to rebase. On 29/12/2022 12:40:10-0600, Samuel Holland wrote: > If there is more than one parent clock in the devicetree, the > driver sets .num_parents to a larger value than the number of array > elements, which causes an out-of-bounds read in the clock framework. > > Fix this by coercing the parent count to a Boolean value, like the > driver expects. > > Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator") > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > drivers/rtc/rtc-sun6i.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > index ed5516089e9a..a22358a44e32 100644 > --- a/drivers/rtc/rtc-sun6i.c > +++ b/drivers/rtc/rtc-sun6i.c > @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node, > > init.parent_names = parents; > /* ... number of clock parents will be 1. */ > - init.num_parents = of_clk_get_parent_count(node) + 1; > + init.num_parents = !!of_clk_get_parent_count(node) + 1; > of_property_read_string_index(node, "clock-output-names", 0, > &init.name); > > -- > 2.37.4 >
Hi Jernej, On 1/8/23 13:39, Jernej Škrabec wrote: > Dne sobota, 07. januar 2023 ob 18:15:47 CET je Samuel Holland napisal(a): >> On 1/5/23 11:26, Jernej Škrabec wrote: >>> Dne četrtek, 29. december 2022 ob 19:40:10 CET je Samuel Holland napisal(a): >>>> If there is more than one parent clock in the devicetree, the >>>> driver sets .num_parents to a larger value than the number of array >>>> elements, which causes an out-of-bounds read in the clock framework. >>> >>> Is there any DT with more than one parent? I think more fixes are needed >>> if >>> this is the case. >> >> H616 and newer expect more than one parent, to accurately represent the >> RTC clock tree, but they use the CCU driver instead of this code. > > If I understand that correctly, second clock would be 24 MHz crystal? In any That is correct. > case, if multiple parents are possible, check needs to be added to see if > parent clocks include 32 kHz clock or not. Right, if we allow other clock inputs, we need to check specifically for "ext-osc32k", or a single clock input without clock-names, not just the presence of the clocks property. (A hypothetical new binding would have to require clock-names even for a single clock to distinguish the old binding with only "ext-osc32k" from the new binding with only "hosc".) >> This bug is preventing us from relaxing `maxItems` in the binding for H6 >> and older SoCs, even if Linux does not use the additional parent clocks. >> I want to fix this bug now, to give us the option (if beneficial) of >> relaxing the binding in the long-term future. > > I wouldn't call it a bug, since it works just fine for currently defined > binding. Do you have DT binding change in pipeline? This would be a far future change, so as to not break the "old kernel + new DT" scenario. Maybe it's not even worth doing. But I really don't like the unbounded assignment to num_parents here. Regards, Samuel >>>> Fix this by coercing the parent count to a Boolean value, like the >>>> driver expects. >>>> >>>> Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator") >>>> Signed-off-by: Samuel Holland <samuel@sholland.org> >>>> --- >>>> >>>> drivers/rtc/rtc-sun6i.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c >>>> index ed5516089e9a..a22358a44e32 100644 >>>> --- a/drivers/rtc/rtc-sun6i.c >>>> +++ b/drivers/rtc/rtc-sun6i.c >>>> @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct >>>> device_node *node, >>>> >>>> init.parent_names = parents; >>>> /* ... number of clock parents will be 1. */ >>>> >>>> - init.num_parents = of_clk_get_parent_count(node) + 1; >>>> + init.num_parents = !!of_clk_get_parent_count(node) + 1; >>>> >>>> of_property_read_string_index(node, "clock-output-names", 0, >>>> >>>> &init.name);
On 2/9/23 16:49, Alexandre Belloni wrote: > Hello, > > What should I do with this series, I'm not sure you came to an > agreement. > Also, 2/2 doesn't apply so you'd have to rebase. I will send v2 after the merge window, possibly including only patch 2. Regards, Samuel > On 29/12/2022 12:40:10-0600, Samuel Holland wrote: >> If there is more than one parent clock in the devicetree, the >> driver sets .num_parents to a larger value than the number of array >> elements, which causes an out-of-bounds read in the clock framework. >> >> Fix this by coercing the parent count to a Boolean value, like the >> driver expects. >> >> Fixes: 3855c2c3e546 ("rtc: sun6i: Expose the 32kHz oscillator") >> Signed-off-by: Samuel Holland <samuel@sholland.org> >> --- >> >> drivers/rtc/rtc-sun6i.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c >> index ed5516089e9a..a22358a44e32 100644 >> --- a/drivers/rtc/rtc-sun6i.c >> +++ b/drivers/rtc/rtc-sun6i.c >> @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node, >> >> init.parent_names = parents; >> /* ... number of clock parents will be 1. */ >> - init.num_parents = of_clk_get_parent_count(node) + 1; >> + init.num_parents = !!of_clk_get_parent_count(node) + 1; >> of_property_read_string_index(node, "clock-output-names", 0, >> &init.name); >> >> -- >> 2.37.4 >> >
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c index ed5516089e9a..a22358a44e32 100644 --- a/drivers/rtc/rtc-sun6i.c +++ b/drivers/rtc/rtc-sun6i.c @@ -294,7 +294,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node, init.parent_names = parents; /* ... number of clock parents will be 1. */ - init.num_parents = of_clk_get_parent_count(node) + 1; + init.num_parents = !!of_clk_get_parent_count(node) + 1; of_property_read_string_index(node, "clock-output-names", 0, &init.name);