From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DE08C7618B for ; Mon, 29 Jul 2019 13:51:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF23A206DD for ; Mon, 29 Jul 2019 13:51:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=onstation.org header.i=@onstation.org header.b="kbsI0aGk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727328AbfG2NvP (ORCPT ); Mon, 29 Jul 2019 09:51:15 -0400 Received: from onstation.org ([52.200.56.107]:35686 "EHLO onstation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726281AbfG2NvO (ORCPT ); Mon, 29 Jul 2019 09:51:14 -0400 Received: from localhost (c-98-239-145-235.hsd1.wv.comcast.net [98.239.145.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: masneyb) by onstation.org (Postfix) with ESMTPSA id EC8B83E910; Mon, 29 Jul 2019 13:51:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=onstation.org; s=default; t=1564408274; bh=89xXheC+LLFYyAGIZ9A+v7CcZyeg5IL9Z5vUpZcHPb8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kbsI0aGkwYytIrBOPD/CK+DXISYKi28m6BHuin/ZTIMgn3x17Vakg34uk1Wx0bumG K6AhnmXln3A7avFH4ZPkG2sIJBeVqWBfdw3u+IvSGH2HhCJ+49kmuUKSCQ4gzCwUzt quVBmys2OrnS790WbkkIQ9oMPDLtyjWRNLbG1pKU= Date: Mon, 29 Jul 2019 09:51:13 -0400 From: Brian Masney To: Jonathan Cameron Cc: Chuhong Yuan , Jonathan Cameron , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iio: tsl2772: Use device-managed API Message-ID: <20190729135113.GA3049@onstation.org> References: <20190726123058.22915-1-hslester96@gmail.com> <20190727125749.63297c28@archlinux> <20190728083141.GA14194@onstation.org> <20190729080307.GA360@onstation.org> <20190729120802.000025e8@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190729120802.000025e8@huawei.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 29, 2019 at 12:08:02PM +0100, Jonathan Cameron wrote: > On Mon, 29 Jul 2019 04:03:07 -0400 > Brian Masney wrote: > > There are devm_regulator_*() variants of the regulator API available > > that you can use. Lots of other APIs in the kernel have devm variants > > to simply drivers. > I don't think there are any devm_ versions of regulator disable. > > IIRC the argument made when this last came up was that it was rarely correct > to be as course grained as a lot of IIO drivers are. We should probably > do runtime pm and turn these regulators off a lot more frequently. > > The reality is that it is an optimization that doesn't get done in > IIO drivers that often as we mostly just want them to work and many > usecases aren't actually power constrained, > > So we end up doing a lot of devm_add_action_or_reset to power down the > regulators. That makes sense. I have an out-of-tree patch where I started to add runtime pm support to the tsl2772 driver around the time I was working on the staging cleanup. I was unsure of how to do this when the user configures an interrupt threshold via sysfs since we don't want to completely power off the chip in that case. At the time, I couldn't find any other examples in IIO that showed how to do that. I should dust off that patch and send it out as a RFC to get some feedback. Brian