From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io>
Cc: Michael Riesch <michael.riesch@collabora.com>,
Tarang Raval <tarang.raval@siliconsignals.io>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] media: i2c: imx415: Drop redundant runtime PM callbacks
Date: Sat, 28 Mar 2026 15:53:27 +0200 [thread overview]
Message-ID: <acfdV6sRfP9HGIxV@kekkonen.localdomain> (raw)
In-Reply-To: <MA0P287MB21780F5BC2F8113A10B6F0718854A@MA0P287MB2178.INDP287.PROD.OUTLOOK.COM>
Hi Elgin,
On Sat, Mar 28, 2026 at 06:11:43AM +0000, Elgin Perumbilly wrote:
> Hi Michael, Sakari,
> Sorry for the late reply, and thanks for the feedback.
>
> >Hi Elgin, Sakari,
> >
> >On 3/25/26 13:28, Sakari Ailus wrote:
> >> Hi Michael,
> >>
> >> On Tue, Mar 24, 2026 at 08:42:31PM +0100, Michael Riesch wrote:
> >>> Hi Elgin,
> >>>
> >>> Thanks for the patch but...
> >>>
> >>> On 3/24/26 13:45, Elgin Perumbilly wrote:
> >>>> Replace runtime_suspend/resume wrappers by using power helpers
> >>>> directly with DEFINE_RUNTIME_DEV_PM_OPS().
> >>>
> >>> ...why? What advantage does this refactoring bring?
> >>
> >> It looks like patch removes two redundant functions, doesn't it? :-)
> >
> >Well yes. 10 lines saved. Not sure whether this was the biggest issue
> >with this driver -- surely it was not a big issue for me.
> >
> >Elgin, I was wondering whether this change is within a certain context
> >or whether there is something I fail to recognize.
> >
> >Anyway, if you absolutely want this change: I feel it would be nicer if
> >you left the imx415_runtime_{resume,suspend} and moved the bit of code
> >from imx415_power_{on,off} to them. Reasons for that may be mostly
> >aesthetical -- I claim better readability that way.
>
> The intent of this change is to remove redundant runtime PM
> wrappers and simplify the code, without altering behavior.
>
> If you’re okay with this approach, we can proceed as is. If you
> feel it’s not necessary at this point, that’s fine as well.
Can you address Michael's comments?
Code tends to be copied to other drivers so cleaning up existing drivers is
worthwhile.
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2026-03-28 13:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 12:45 Elgin Perumbilly
2026-03-24 19:42 ` Michael Riesch
2026-03-25 12:28 ` Sakari Ailus
2026-03-25 19:36 ` Michael Riesch
2026-03-28 6:11 ` Elgin Perumbilly
2026-03-28 13:53 ` Sakari Ailus [this message]
2026-03-30 9:11 ` Elgin Perumbilly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acfdV6sRfP9HGIxV@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=elgin.perumbilly@siliconsignals.io \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=michael.riesch@collabora.com \
--cc=tarang.raval@siliconsignals.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®