From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751376AbcFFGT0 (ORCPT ); Mon, 6 Jun 2016 02:19:26 -0400 Received: from lucky1.263xmail.com ([211.157.147.131]:33094 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbcFFGTZ (ORCPT ); Mon, 6 Jun 2016 02:19:25 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: hl@rock-chips.com X-FST-TO: typ@rock-chips.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: hl@rock-chips.com X-UNIQUE-TAG: <207100fd17aa483baafe4ff4431ba09a> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [RFC PATCH v1 4/6] PM / devfreq: event: support rockchip dfi controller To: Thierry Reding References: <1464947719-6245-1-git-send-email-hl@rock-chips.com> <1464947719-6245-5-git-send-email-hl@rock-chips.com> <20160603165426.GC21013@ulmo.ba.sec> Cc: heiko@sntech.de, mark.yao@rock-chips.com, myungjoo.ham@samsung.com, mturquette@baylibre.com, sboyd@codeaurora.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kyungmin.park@samsung.com, dianders@chromium.org, dbasehore@chromium.org, huangtao@rock-chips.com, typ@rock-chips.com From: hl Message-ID: <575515E0.8080108@rock-chips.com> Date: Mon, 6 Jun 2016 14:19:12 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160603165426.GC21013@ulmo.ba.sec> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thierry, On 2016年06月04日 00:54, Thierry Reding wrote: > On Fri, Jun 03, 2016 at 05:55:17PM +0800, Lin Huang wrote: > [...] >> + ret = clk_prepare_enable(data->clk); >> + if (ret) { >> + dev_err(&pdev->dev, "failed to enable clk: %d\n", ret); >> + clk_disable_unprepare(data->clk); >> + return ret; >> + } > This is going to give you a large WARN. clk_prepare_enable() already > leaves the clock in a proper state when it fails (i.e. it calls > clk_unprepare() if the clk_enable() part failed), so calling > clk_disable_unprepare() upon failure is going to unbalance the > reference counts. Thanks for reminding, i will fix it next version. > > Thierry -- Lin Huang