Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1302063rwb; Fri, 19 Aug 2022 00:52:25 -0700 (PDT) X-Google-Smtp-Source: AA6agR5IcoBFGDQiSFLRt+fpizwIhMVSMmZNFCtGzivwHnMQWKZLN6Xjbo516O/f5gTtF70JGE5Z X-Received: by 2002:a05:6402:194e:b0:442:c81c:ca25 with SMTP id f14-20020a056402194e00b00442c81cca25mr5259154edz.137.1660895545192; Fri, 19 Aug 2022 00:52:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660895545; cv=none; d=google.com; s=arc-20160816; b=dcevqR2lEQ5+U8nY9rzesU4XOTRvkma3vDYLlETe5nGB3rnxx7lh2dwrveS5uYh6x5 8oDuGzM0sinkc7g4nCZXnVwWpJTaafneo0Dcn/LOLZtxDPzIUBUIWQFdpaFxEZ+Eypu0 7o1GVPmZ0pOL/2iYvQcVFvAR6Q8In44H3GNMPp4iOCaWVf+K/J2e4avDi0T3HF6umWzt Pe+UGjBS/FQChKPx8wcqBro1Js9xW2QGPKef3jn4orQt8n9sYdkT3WZeEq4vhrzDqEvr OuhSXTqHLQgDbfnLkNEa11hOvu2UMjmuLcE/UWH7yfCJHhhWKvkZpBK4UBx7kv4Q8PdA /9CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=6R3OY9pB9ScWtk/mI0ye3zYhk3qlam6F3BUst8642dI=; b=JXs8aPI71SZKVevTKTQToQAbWrA1TA6VCzNoZC5V/Llx4Ls8fbpSl5xOvDDn1I0BXj Zcj8m1xj98Da0A3SMqpC3t4/M8zwkq2LJH52kO/DF7fHpKOGLv2LjQRAGDRqXBDMBkAd Z46JQykGUEEuhuFy2SNva8UVhgOaWJGG6Xj3CU90lNmpsHQA7yvQWzbZVV7rM++uKq0l 60JPzq8gdq1rGjqmVIY9vBrK+ZEYUvtALkrjtgpHEvyjGjLV81nRY6DF5v+Af6ysBEZ4 uXlHAdoRUa51kwErS1dWC+5ov3M97cjxFHC+1RAptffuGUxLB3MeSv7xReUP5oxuGrGE OQLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qw24-20020a1709066a1800b00731646d634esi2507521ejc.802.2022.08.19.00.51.57; Fri, 19 Aug 2022 00:52:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345627AbiHSHft (ORCPT + 99 others); Fri, 19 Aug 2022 03:35:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346683AbiHSHfV (ORCPT ); Fri, 19 Aug 2022 03:35:21 -0400 X-Greylist: delayed 1133 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 19 Aug 2022 00:35:19 PDT Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 806F982FB8; Fri, 19 Aug 2022 00:35:19 -0700 (PDT) Received: (Authenticated sender: jacopo@jmondi.org) by mail.gandi.net (Postfix) with ESMTPSA id 9667A20002; Fri, 19 Aug 2022 07:35:14 +0000 (UTC) Date: Fri, 19 Aug 2022 09:35:12 +0200 From: Jacopo Mondi To: Marco Felsch Cc: mchehab@kernel.org, sakari.ailus@linux.intel.com, laurent.pinchart+renesas@ideasonboard.com, jacopo+renesas@jmondi.org, akinobu.mita@gmail.com, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 4/4] media: mt9m111: remove .s_power callback Message-ID: <20220819073512.ulud7ppnrudxewdn@uno.localdomain> References: <20220818144712.997477-1-m.felsch@pengutronix.de> <20220818144712.997477-4-m.felsch@pengutronix.de> <20220818161408.76ofg2rjvp5whtof@uno.localdomain> <20220819071832.3mr7u7jhp2ud4fv6@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220819071832.3mr7u7jhp2ud4fv6@pengutronix.de> X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,TVD_SUBJ_WIPE_DEBT,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marco On Fri, Aug 19, 2022 at 09:18:32AM +0200, Marco Felsch wrote: > Hi Jacopo, > > thanks for your fast feedback :) > > On 22-08-18, Jacopo Mondi wrote: > > Hi Marco > > > > On Thu, Aug 18, 2022 at 04:47:12PM +0200, Marco Felsch wrote: > > > This is in preparation of switching to the generic dev PM mechanism. > > > Since the .s_power callback will be removed in the near future move the > > > powering into the .s_stream callback. So this driver no longer depends > > > on the .s_power mechanism. > > > > > > Signed-off-by: Marco Felsch > > > > If you want to move to runtime_pm, I would implement it first and have > > s_power call the _resume and _suspend routines, as some platform > > drivers still use s_power() and some of them might depend on it. > > Do we really have platforms which depend on this? IMHO if that is the $ git grep "v4l2_subdev_call(.*, s_power" drivers/media/platform/ | cut -d : -f1 | uniq | wc -l 8 > case than we should fix those platfoms. Since new drivers shouldn't use > this callback anymore. Patches are clearly welcome I guess.. > > In my case, I worked on [1] and wondered why the sensor was enabled > before I told him to do so. Since I didn't implement the s_power() > callback, I had no chance to get enabled before. > I'm not sure I got this part > Can we please decide: > - Do we wanna get rid of the s_power() callback? I think that would be everyone's desire, but drivers have to be moved away from it > - If not, how do we handle those devices then with drivers not > implementing this callback? By maintaining compatibility. I suggested to move to runtime_pm() and wrap _resume/_suspend in s_power(). My understanding is that the two (runtime_pm/s_power) are mutually exclusive, but even if that was not the case, runtime_pm is reference counted, hence as long as calls are balanced this should work, right ? > > [1] https://lore.kernel.org/all/20220818143307.967150-1-m.felsch@pengutronix.de/ > > > It's a slippery slope.. I would love to get rid of s_power() but if > > any platform uses it with this sensor, it would stop working after > > this change. > > > > > --- > > > drivers/media/i2c/mt9m111.c | 7 ++++++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c > > > index cd74c408e110..8e8ba5a8e6ea 100644 > > > --- a/drivers/media/i2c/mt9m111.c > > > +++ b/drivers/media/i2c/mt9m111.c > > > @@ -1065,7 +1065,6 @@ static const struct v4l2_ctrl_ops mt9m111_ctrl_ops = { > > > }; > > > > > > static const struct v4l2_subdev_core_ops mt9m111_subdev_core_ops = { > > > - .s_power = mt9m111_s_power, > > > .log_status = v4l2_ctrl_subdev_log_status, > > > .subscribe_event = v4l2_ctrl_subdev_subscribe_event, > > > .unsubscribe_event = v4l2_event_subdev_unsubscribe, > > > @@ -1136,8 +1135,14 @@ static int mt9m111_enum_mbus_code(struct v4l2_subdev *sd, > > > static int mt9m111_s_stream(struct v4l2_subdev *sd, int enable) > > > { > > > struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev); > > > + int ret; > > > > > > mt9m111->is_streaming = !!enable; > > > + > > > + ret = mt9m111_s_power(sd, enable); > > > + if (ret) > > > + return ret; > > > + > > > return 0; > > > } > > > > > > -- > > > 2.30.2 > > > > >