Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2488412ybe; Sat, 14 Sep 2019 16:26:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqx0tEhOB16SX+T/kxpIsecR3gl1iRBnb/i9rFnSdXNBL5uzWz0YL6giWxuHpeS/OU6hu+aQ X-Received: by 2002:a50:9fe5:: with SMTP id c92mr54817153edf.280.1568503566072; Sat, 14 Sep 2019 16:26:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568503566; cv=none; d=google.com; s=arc-20160816; b=ytgIORbHghzWJdsBG3idJ9GQ7qGv48TQ6CMTSOOQu5ce0NR0MPZxplhPzbRn66/u/Q wVgZx+rh5AIP9W0l4x9GxYZVSMs9UtX3OM0Y6F6n9BsyiLS/vNDKqaDyh0gJ7f3HsNuH K4M9mvwT/Zhxqxz3FIcqNiHVWUhH3RbGIz0uOy2q1eBxx0x4prnuwkkG45wb6MVteuJl 6A8EoCQAUeoVM6EuR7fC2an0Co15VAHt+J4Pu7ZTUGmbdMAW4bt6Fm6W/8GyIThWhFpU 4Jf5OApOaqUju/d4Rswph7WPJOEGdGy5u6rzGDAzx1i2NZ/5h/f3qR3f811/hfteOywO sTEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=0geqN5iSTwVGR63up978VFNu4hKY/ARj/6LYpYQfiyQ=; b=cZPMSn2diEvobQVr4DXZpRhm9cEJB9W9+TW+U34KZ+v1+F85XVryyOFGhCZf0sp+f1 ORGMoM7+6kokGR1gkCKymSK4ucNcCtNUeISXHht4jEvmC6t9pun4heXTUAD++sh3IbHI uA9pMcvXt1GVBjq+XIW8HhnWBftCdjt8jE2vD9fBQDHcAEZ8zweRoNoWYSVkjEcgN87n +bxMXC9/wyvenJ7HQ65RSRPziJwJ8kU7HDMyU46CfIom+HM2Q6+sL7w3goSjaCjAPjmJ 9CxriLJWqlx+rZ6BBBWPyHtovupoBV6RCI1USAV93Syq9Ngy1lqCU5XfOYl0MhzX8HIG QT2g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-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 s22si3501172edr.222.2019.09.14.16.25.32; Sat, 14 Sep 2019 16:26:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-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-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727413AbfINR6G (ORCPT + 99 others); Sat, 14 Sep 2019 13:58:06 -0400 Received: from muru.com ([72.249.23.125]:32832 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727356AbfINR6G (ORCPT ); Sat, 14 Sep 2019 13:58:06 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id D0E9D8105; Sat, 14 Sep 2019 17:58:33 +0000 (UTC) Date: Sat, 14 Sep 2019 10:57:59 -0700 From: Tony Lindgren To: Sebastian Reichel Cc: Matt Mackall , Herbert Xu , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-crypto@vger.kernel.org, Aaro Koskinen , Adam Ford , Pali =?utf-8?B?Um9ow6Fy?= , Tero Kristo , Rob Herring , devicetree@vger.kernel.org Subject: Re: [PATCH 3/6] hwrng: omap3-rom - Call clk_prepare() on init and exit only Message-ID: <20190914175759.GV52127@atomide.com> References: <20190913220922.29501-1-tony@atomide.com> <20190913220922.29501-4-tony@atomide.com> <20190914125427.nvbrxoubvll43b3j@earth.universe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190914125427.nvbrxoubvll43b3j@earth.universe> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org * Sebastian Reichel [190914 13:01]: > Hi, > > On Fri, Sep 13, 2019 at 03:09:19PM -0700, Tony Lindgren wrote: > > Also, we should not call prepare and unprepare except during init, and > > only call enable and disable during use. > > Why? Usually clk_(un)prepare() is the part saving most power, so I > would expect the runtime resume handlers to call clk_prepare_enable > and vice versa in the suspend handler. Sure yeah fine with me, clk_prepare_enable() is more generic at the cost of some extra calls to toggle a clock gate bit :) Let's also forget the probe changes, those will get cleared with the runtime PM changes anyways. Regards, Tony