Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2845149ybc; Mon, 25 Nov 2019 05:12:56 -0800 (PST) X-Google-Smtp-Source: APXvYqz5UOo0hKuW3SG0d8h/CKmV+4axC019Wxoou+rqG2pP/TeCGpK1yrBaN2ISiY5NcVV2bFXL X-Received: by 2002:a17:906:b6c3:: with SMTP id ec3mr37888053ejb.27.1574687576381; Mon, 25 Nov 2019 05:12:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574687576; cv=none; d=google.com; s=arc-20160816; b=FSlOwNr44s35Xu5wW+VWyfKdy46HfqJFhBw5MEjyx048lCB/lQ8LvQsQxikw5pNfw/ Ryhh5TswjCQXiRX3BqtEg6FB1OVGHE05yLEyMJF14BIfV8hEmKKJteT2Q2+Hck2OtVhI XoWnn69eTTnVDPaAwLqS9YkWFfQmS03MH2Hm7s7tzTlj7goUC23WabuF95+79jf28ziN pkQckfoO95hVAdSsS5//O9k0DqMkCgBLtvhK4lkKcn4R5X6L4c8l7cBQf0jj9WnUiy+w C3gD2tQ5+Hgz42MokbM5WU+QSZwxWb5WiuH9X3BZHFSREd2DGgOFd5MpMFtxyvuV2nEO rJ5w== 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; bh=dVgd8rXaXU3LYPKLv5Zu4yqTDVT8c19A7OsrM1gr3Ko=; b=Zr7IXuFBrETL9VZgWcKB9W9huKUCI+9ywDyVuUGTO1VLObOHafwIt/uHAJOYcvctT8 zlf5qH/JInkFuaDhvk9lkAppVppuJh6EPbgtHOGm7pNkRn36EkEPuj+7Vz9A1QHwl059 dsBnR+0po7MH710Legs6441+H8Vp0jVloRzBxSeEHpc4SNlAtiDaGBpm3Hx1hZJlnTDj P+l7Q+z7Dg4JTCwfnCR8NMbMrGVXbAD8DrYSHm0wNsNDg6x5mGustahDCOjkqaQp8iP+ UgULSNeYVUneBgOEdOR+HatqtyCWNbiAaPxnfDqRDh5YqSdoTd2eQshDYb28/MrxIDdm G0Cw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y24si4475365ejc.170.2019.11.25.05.12.31; Mon, 25 Nov 2019 05:12:56 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727594AbfKYNKX (ORCPT + 99 others); Mon, 25 Nov 2019 08:10:23 -0500 Received: from ns.iliad.fr ([212.27.33.1]:53878 "EHLO ns.iliad.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725823AbfKYNKX (ORCPT ); Mon, 25 Nov 2019 08:10:23 -0500 Received: from ns.iliad.fr (localhost [127.0.0.1]) by ns.iliad.fr (Postfix) with ESMTP id C272920C1C; Mon, 25 Nov 2019 14:10:21 +0100 (CET) Received: from [192.168.108.51] (freebox.vlq16.iliad.fr [213.36.7.13]) by ns.iliad.fr (Postfix) with ESMTP id ABD03206AB; Mon, 25 Nov 2019 14:10:21 +0100 (CET) Subject: Re: [PATCH v1] clk: Add devm_clk_{prepare,enable,prepare_enable} To: Russell King - ARM Linux admin Cc: Stephen Boyd , Michael Turquette , linux-clk , Linux ARM , LKML References: <1d7a1b3b-e9bf-1d80-609d-a9c0c932b15a@free.fr> <34e32662-c909-9eb3-e561-3274ad0bf3cc@free.fr> <20191125125530.GP25745@shell.armlinux.org.uk> From: Marc Gonzalez Message-ID: Date: Mon, 25 Nov 2019 14:10:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191125125530.GP25745@shell.armlinux.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP ; ns.iliad.fr ; Mon Nov 25 14:10:21 2019 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/11/2019 13:55, Russell King - ARM Linux admin wrote: > It's also worth reading https://lore.kernel.org/patchwork/patch/755667/ > and considering whether you really are using the clk_prepare() and > clk_enable() APIs correctly. Wanting these devm functions suggests > you aren't... In that older thread, you wrote: > If you take the view that trying to keep clocks disabled is a good way > to save power, then you'd have the clk_prepare() or maybe > clk_prepare_enable() in your run-time PM resume handler, or maybe even > deeper in the driver... the original design goal of the clk API was to > allow power saving and clock control. > > With that in mind, getting and enabling the clock together in the > probe function didn't make sense. > > I feel that aspect has been somewhat lost, and people now regard much > of the clk API as a bit of a probe-time nuisance. In the few drivers I've written, I call clk_prepare_enable() at probe. And since clk_prepare_enable() is the only non-devm function in probe, I need either a remove function, or an explicit registration step. You seem to be saying I'm using the clk API in the wrong way? Regards.