Received: by 10.223.185.116 with SMTP id b49csp3763606wrg; Tue, 13 Feb 2018 07:24:46 -0800 (PST) X-Google-Smtp-Source: AH8x226XIP0KP6tOUfflh45Us52jMlBbKeSY9ynKp4wGDQjz3SvKqX59OYCs0LHTzOwu/GGCc7bn X-Received: by 2002:a17:902:aa8e:: with SMTP id d14-v6mr1420177plr.94.1518535486218; Tue, 13 Feb 2018 07:24:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518535486; cv=none; d=google.com; s=arc-20160816; b=vrA1yWPjmC4HYAjnDOLSuvvT66wPJAvPFBW0jtksNh/57kiBck/KB16AkJRDsM0v4Q bk7kskejDDzZZD9pmVKAYEr/Gn7T5BRMVT4396q+SMTS9Anx9pDyejaqo+GM0icfJNKE 7wh8KDay3uPj5NTxGRYZKd2TAJQtAwsG8NMIPtsdOUYO0axm0+dkBVylevzHrzxJdBej rDDfsl4K9Qoc1j5+CqFSf23dEeJtkTYeQR0CX37TfxZEkt0Opy27DNWjmtjwhRIZx+Fu NwnqbSi5spkyIY8DV5TRM2Z+Qbt0RS2De5qV9nlQ850OUUeQr0R/X2hCZt4MUVbKY6E6 NXFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=TJT6jQSxRMBfqrJ7Vz3n+fxa/vMTuTjjWryuMXXpX5k=; b=zIfhjSMoveRH25vlYtLi4cVtCLpcOOugFSvdpb5FA+/2O/XflEAi0nqGbwDy2SZZLG ikX3wsRp9xOfyQiiDIqs0xBNBcRN3OiVorF9MUQ2IMNCKsgu1QXalHlLUP/9YRdjWOXN ApVkWDEamImpm/ddjNhc4RTELmawTg8mNhzxej9XFYs3yoxlZu+H3Ioy4SpK+fhio/c0 EFBSQaH+1/WR5qVO81V610py6MAEol4wuDwToRZsgfhhFHQ1hQn+T4m9ER4XtXPTNKoK U9YwNwKqoOkwkBtPFmbE4tSHEpKDQY76gmyvanPmkL1GBX1VuRWvD2C7FTw6lmoQnIs1 bnPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DBkxg630; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v15si8104244pfk.397.2018.02.13.07.24.19; Tue, 13 Feb 2018 07:24:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DBkxg630; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965021AbeBMPXF (ORCPT + 99 others); Tue, 13 Feb 2018 10:23:05 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:43500 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964913AbeBMPXE (ORCPT ); Tue, 13 Feb 2018 10:23:04 -0500 Received: by mail-wr0-f193.google.com with SMTP id b52so18958528wrd.10; Tue, 13 Feb 2018 07:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TJT6jQSxRMBfqrJ7Vz3n+fxa/vMTuTjjWryuMXXpX5k=; b=DBkxg6301eImVEWGXI11ActVAIystuX0g93Cw9ATCiEc9KbI64tD3gAWtEJ+1mQkf4 Wb6ygVr8+gLvFXmC5v/7BC54wX1FskSnGtDNsIpkpWU8pXR1th13lZ9MAg6ZViUK4zG6 2Ht8oAFUEC8kvDDrcq9zu8gt5w/V92mQFsNXwS2fpeZKuaNmKHmcLOH0LEDf4QpwziVe nyN8/4bZF/BHXv3D6qfItewKxscIs7CYdN3pYdBe7duyyOdSTTwnWqlWguxlsGaHZ0zy P9N50GcGsDAP1PDFPpS2qruyK0YZ8Kp8NqekdhvwG4ymNoQsHPVBWHOw/nUx1k7ZzLFx KjZg== 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=TJT6jQSxRMBfqrJ7Vz3n+fxa/vMTuTjjWryuMXXpX5k=; b=aJ22oDftC1tAYiUv0ozP/TcFPaFkDpIQR6tySW/2tISmYV1TNzeqXta7tOKMpyTXAC MrgQKVWRDz04s35/LOH8j7JNmyzfVJzsxQwEWoEb37C4l9JuNuOZZRL29DmWeKmXQWT/ LtpzMNnfV+7By4LVkxe2j4MLim3vYojyJNQI+HtRyFV3kxcKm/65K2nF6d+SXCdX8IqW y+GxJd85HxklpPkeMOb7khusrszTptiY8OE33tDK0n7MQD6zTq2gB7+nZh82qiOpDX0o YqNIHFmLlj1Guu8qMce3mIyNCaZgMW/JrySAtCfFHoFjGSWn4DOCzqcYhFwUVdjjdUbc X/zg== X-Gm-Message-State: APf1xPAOUzJQhd1mlF8qLVhlKvA8EUd38/IFIHd39gQSG6mQFmEvCbUH lpDd0zcThCA9tIYJpb5b0gRu0PB9 X-Received: by 10.223.160.207 with SMTP id n15mr1627968wrn.25.1518535382307; Tue, 13 Feb 2018 07:23:02 -0800 (PST) Received: from [192.168.2.73] (p578F04D2.dip0.t-ipconnect.de. [87.143.4.210]) by smtp.gmail.com with ESMTPSA id e5sm3062148wre.97.2018.02.13.07.23.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 07:23:01 -0800 (PST) Subject: Re: [linux-sunxi] [PATCH v2] rtc: ac100: Fix ac100 determine rate bug To: Chen-Yu Tsai , Maxime Ripard Cc: Alessandro Zummo , Alexandre Belloni , linux-kernel , linux-sunxi , linux-rtc@vger.kernel.org References: <20180213121414.7000-1-embed3d@gmail.com> <20180213133201.kwq4aatpts7nerc2@flea.lan> From: Philipp Rossak Message-ID: <8142b42d-bf8d-0903-e26e-1499f95e51d5@gmail.com> Date: Tue, 13 Feb 2018 16:23:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13.02.2018 14:44, Chen-Yu Tsai wrote: > On Tue, Feb 13, 2018 at 9:32 PM, Maxime Ripard > wrote: >> On Tue, Feb 13, 2018 at 01:14:14PM +0100, Philipp Rossak wrote: >>> This patch fixes a bug, that prevents the Allwinner A83T and the A80 >>> from a successful boot. You can find the shortend trace below: >> >> Since when is it there? >> The bug is there since v4.16-rc1 and appeared after the clk branch was merged. ^^ Should I add this info also in the commit message? >>> Unable to handle kernel NULL pointer dereference at virtual address >>> 00000000 >>> pgd = (ptrval) >>> [00000000] *pgd=00000000 >>> Internal error: Oops: 5 [#1] SMP ARM >>> Modules linked in: >>> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2 >>> Hardware name: Allwinner sun8i Family >>> Workqueue: events deferred_probe_work_func >>> PC is at clk_hw_get_rate+0x0/0x34 >>> LR is at ac100_clkout_determine_rate+0x48/0x19c >>> >>> [ ... ] >>> >>> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c) >>> (ac100_clkout_determine_rate) from (clk_core_set_rate_nolock+0x3c/0x1a0) >>> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88) >>> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364) >>> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0) >>> >>> To fix that bug, we first check if the return of the >>> clk_hw_get_parent_by_index is non zero. If it is zero we skip that >>> clock parent. >>> >>> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198 >>> >>> Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support") >> >> Should it be sent to stable? >> >>> Signed-off-by: Philipp Rossak >>> --- >>> >>> Changes in v2: >>> * add tag Fixes: ... to commit message >>> * add comment to if statement why we are doing this check >>> >>> drivers/rtc/rtc-ac100.c | 12 +++++++++++- >>> 1 file changed, 11 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c >>> index 8ff9dc3fe5bf..ba73201d8cc1 100644 >>> --- a/drivers/rtc/rtc-ac100.c >>> +++ b/drivers/rtc/rtc-ac100.c >>> @@ -183,7 +183,17 @@ static int ac100_clkout_determine_rate(struct clk_hw *hw, >>> >>> for (i = 0; i < num_parents; i++) { >>> struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i); >>> - unsigned long tmp, prate = clk_hw_get_rate(parent); >>> + unsigned long tmp, prate; >>> + >>> + /* >>> + * We purposefully left open the possibility to use the clock >>> + * from the codec side but it is not implemented right now. >>> + * Thus we need to check if the parent exists. >>> + */ >>> + if (!parent) >>> + continue; >>> + >>> + prate = clk_hw_get_rate(parent); >> >> clk_hw_get_num_parents should return the exact number of parents, >> which is going to be 1 if you only have one parent, like all DTS seems >> to have. >> >> If not, then it should be explained in the comment and / or fixed >> properly. > > The clock has two parents. One is a fixed clock internally registered > by the driver. This is actually an external crystal, and we should > probably add a device node and the works for it. The other parent > is a clock from the codec side, which we properly declare and > reference in the device tree. This clock, though defined, is not > implemented in any driver (because we don't have any ATM). > > This second missing clock is what's causing issues here. The clk core > looks for the parent by name, can't find one that is registered, and > returns NULL. > > I guess the comment above is still not clear enough? I can get more detailed in the comment. I thought about this: The clock has two parents, one is a fixed clock which is internally registered by the ac100 driver. The other parent is a clock from the codec side of the chip, which we properly declare and reference in the devicetree and is not implemented in any driver right now. If the clock core looks for the parent of that second missing clock, it can't one that is registered and returns NULL. Thus we need to check if the parent exists before we get the parent rate. Is that ok for you? Philipp > > ChenYu > >> Maxime >> >> -- >> Maxime Ripard, Bootlin (formerly Free Electrons) >> Embedded Linux and Kernel engineering >> http://bootlin.com