All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Jean Delvare <jdelvare@suse.de>, Tony Lindgren <tony@atomide.com>
Cc: Wolfram Sang <wsa@kernel.org>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	linux-i2c@vger.kernel.org,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v2 1/9] i2c: i801: Improve disabling runtime pm
Date: Thu, 26 Aug 2021 17:34:47 +0300	[thread overview]
Message-ID: <YSemhwn5gS7GA3sA@smile.fi.intel.com> (raw)
In-Reply-To: <20210826160021.67b7ed92@endymion>

On Thu, Aug 26, 2021 at 04:00:21PM +0200, Jean Delvare wrote:
> On Tue, 17 Aug 2021 22:15:58 +0200, Wolfram Sang wrote:

Jean, thanks for your response. My 2 cents below.

> > > > > I dunno if it's being discussed, but with this you effectively allow user to
> > > > > override the setting. It may screw things up AFAIU the comment above.
> > > >
> > > > No, this hasn't been discussed. At least not now. Thanks for the hint.
> > > > This attribute is writable for the root user, so we could argue that
> > > > the root user has several options to break the system anyway.
> 
> This is something we hear frequently when people don't want to address
> problems in their code, but that's not enough to convince me ;-)
> 
> > > But it will mean the side effect on this driver and typical (root-run) system
> > > application (systemd like?) should care now the knowledge about this
> > > side-effect. I do not think it is desired behaviour. But I'm not a maintainer
> > > and I commented here just to make everybody understand the consequences of the
> > > change.
> 
> Is systemd going to actually make any change to that attribute? I'm no
> systemd expert, but I can't see any option in the configuration files
> that would be related to autosuspend.
> 
> > Jean, are you still fine with this patch then?
> 
> My original position was that there are a few other drivers already
> doing "this". It's not like we are doing something completely new and
> using an API in a way it had never been used before, so it can't be
> that bad.
> 
> On the other hand, after taking a closer look, I'm not fully certain
> that "this" is exactly the same in all these drivers. For example, in
> blk-pm.c, pm_runtime_set_autosuspend_delay() is being called with value
> -1 initially, but with the idea that someone else (device driver, user)
> may set a positive value later. It's not a permanent disable.

Correct, it's expected that either system wide tool or user with enough
privileges may enable it.

> The 8250_omap driver,

Oh, no, please, do not use that driver as an example for runtime PM. It's
(somehow) broken there! I Cc'ed Tony in case you have more Q:s about it.
It's on a healing curve, though.

The idea behind I believe is the same, i.e. to allow user to turn it on
and off.

> however, seems to match the i2c-i801 driver here (I
> say "seems" because honestly I'm not sure I fully understand the
> comments there, but my understanding is that at least in some
> situations, enabling autosuspend later would cause problems).
> 
> That being said, it starts looking like a problem for the PM subsystem
> maintainers. Basically Heiner is trying to move away from an API which
> requires cleaning up on driver removal. This is definitely the
> direction we are collectively taking for years now (the whole devm_*
> family of functions is about exactly that). So it's considered a good
> thing.
> 
> If pm_runtime_set_autosuspend_delay() is not suitable for the task then
> maybe we need a better API. I will admit I'm at a loss when it comes to
> the many pm_runtime_* calls, I'm not going to claim I fully understand
> what each of them is doing exactly. But don't we want to simply call
> pm_runtime_dont_use_autosuspend() here?
> 
> If not and there's no suitable API for the task at the moment, then
> better do not apply this patch, and instead ask the PM subsystem
> maintainers if they would be willing to implement what we need.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-08-26 14:34 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 21:10 [PATCH v2 0/9] i2c: i801: Series with improvements Heiner Kallweit
2021-08-06 21:12 ` [PATCH v2 1/9] i2c: i801: Improve disabling runtime pm Heiner Kallweit
2021-08-10 20:37   ` Wolfram Sang
2021-08-11 15:41   ` Andy Shevchenko
2021-08-11 20:03     ` Heiner Kallweit
2021-08-12  9:48       ` Andy Shevchenko
2021-08-17 20:15         ` Wolfram Sang
2021-08-26 14:00           ` Jean Delvare
2021-08-26 14:34             ` Andy Shevchenko [this message]
2021-08-31  6:05             ` Heiner Kallweit
2021-08-31 11:26               ` Jean Delvare
2021-08-31 20:43                 ` Heiner Kallweit
2021-09-01  6:22                   ` Heiner Kallweit
2021-08-06 21:13 ` [PATCH v2 2/9] i2c: i801: make p2sb_spinlock a mutex Heiner Kallweit
2021-08-10 20:38   ` Wolfram Sang
2021-08-11 15:43   ` Andy Shevchenko
2021-08-11 20:27     ` Heiner Kallweit
2021-08-12  9:53       ` Andy Shevchenko
2021-08-06 21:14 ` [PATCH v2 3/9] i2c: i801: Remove not needed debug message Heiner Kallweit
2021-08-10 20:39   ` Wolfram Sang
2021-08-06 21:15 ` [PATCH v2 4/9] i2c: i801: Improve is_dell_system_with_lis3lv02d Heiner Kallweit
2021-08-11 15:45   ` Andy Shevchenko
2021-08-11 20:28     ` Heiner Kallweit
2021-08-12  9:55       ` Andy Shevchenko
2021-08-26 14:19         ` Jean Delvare
2021-08-26 13:21   ` Jean Delvare
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:15 ` [PATCH v2 5/9] i2c: i801: Remove not needed check for PCI_COMMAND_INTX_DISABLE Heiner Kallweit
2021-08-11 15:46   ` Andy Shevchenko
2021-08-26 15:18   ` Jean Delvare
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:16 ` [PATCH v2 6/9] i2c: i801: Improve i801_acpi_probe/remove functions Heiner Kallweit
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:17 ` [PATCH v2 7/9] i2c: i801: Improve i801_add_mux Heiner Kallweit
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:18 ` [PATCH v2 8/9] i2c: i801: Improve register_dell_lis3lv02d_i2c_device Heiner Kallweit
2021-08-11 15:52   ` Andy Shevchenko
2021-08-11 21:05     ` Heiner Kallweit
2021-08-12  9:57       ` Andy Shevchenko
2021-08-27 16:21       ` Jean Delvare
2021-09-29 20:11         ` Wolfram Sang
2021-10-01 11:46           ` Jean Delvare
2021-08-06 21:18 ` [PATCH v2 9/9] i2c: i801: Improve handling platform data for tco device Heiner Kallweit
2021-08-11 15:53   ` Andy Shevchenko
2021-10-02  7:44   ` Wolfram Sang
2021-11-29  8:58     ` Wolfram Sang
2021-11-29 19:54       ` Heiner Kallweit
2021-11-29 19:53 ` [PATCH v3] " Heiner Kallweit

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=YSemhwn5gS7GA3sA@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=hkallweit1@gmail.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jdelvare@suse.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=tony@atomide.com \
    --cc=wsa@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.