All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vaibhav Gupta <vaibhavgupta40@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Jean Delvare <jdelvare@suse.de>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	linux-i2c@vger.kernel.org, Wolfram Sang <wsa@the-dreams.de>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	stable@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] i2c: i801: Fix runtime PM
Date: Mon, 31 Aug 2020 20:45:30 +0530	[thread overview]
Message-ID: <20200831151159.GA11707@gmail.com> (raw)
In-Reply-To: <20200828162640.GA2160001@bjorn-Precision-5520>

On Fri, Aug 28, 2020 at 11:26:40AM -0500, Bjorn Helgaas wrote:
> [+cc Vaibhav]
> 
> On Wed, Jun 27, 2018 at 04:23:40PM -0500, Bjorn Helgaas wrote:
> > [+cc Rafael, linux-pm, linux-kernel]
> > 
> > On Wed, Jun 27, 2018 at 10:15:50PM +0200, Jean Delvare wrote:
> > > Hi Jarkko,
> > > 
> > > On Tue, 26 Jun 2018 17:39:12 +0300, Jarkko Nikula wrote:
> > > > Commit 9c8088c7988 ("i2c: i801: Don't restore config registers on
> > > > runtime PM") nullified the runtime PM suspend/resume callback pointers
> > > > while keeping the runtime PM enabled. This causes that device stays in
> > > > D0 power state and sysfs /sys/bus/pci/devices/.../power/runtime_status
> > > > shows "error" when runtime PM framework attempts to autosuspend the
> > > > device.
> > > > 
> > > > This is due PCI bus runtime PM which checks for driver runtime PM
> > > > callbacks and returns with -ENOSYS if they are not set. Fix this by
> > > > having a shared dummy runtime PM callback that returns with success.
> > > > 
> > > > Fixes: a9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM")
> > > 
> > > I don't want to sound like I'm trying to decline all responsibility for
> > > a regression I caused, but frankly, if just using SIMPLE_DEV_PM_OPS()
> > > breaks runtime PM, then it's the PM model which is broken, not the
> > > i2c-i801 driver.
> > > 
> > > I will boldly claim that the PCI bus runtime code is simply wrong in
> > > returning -ENOSYS in the absence of runtime PM callbacks, and it should
> > > be changed to return 0 instead. Or whoever receives that -ENOSYS should
> > > not treat it as an error - whatever makes more sense.
> > > 
> > > Having to add dummy functions in every PCI driver that doesn't need to
> > > do anything special for runtime PM sounds plain stupid. It should be
> > > pretty obvious that a whole lot of drivers are going to use
> > > SIMPLE_DEV_PM_OPS() because it exists and seems to do what they want,
> > > and all of them will be bugged because the PCI core is doing something
> > > silly and unexpected.
> > > 
> > > So please let's fix it at the PCI subsystem core level. Adding Bjorn
> > > and the linux-pci list to Cc.
> > 
> > Thanks Jean.  What you describe does sound broken.  I think the PM
> > guys (cc'd) will have a better idea of how to deal with this.
> 
> Did we ever get anywhere with this?  It seems like the thread petered
> out.
This does seems worrying. I remember, few days earlier you pointed out a driver
i2c-nvidia-gpuc.c. In the code, gpu_i2c_suspend() is an empty-body function. And
comment mentioned that empty stub is necessary for runtime_pm to work.

And this driver also uses UNIVERSAL_DEV_PM_OPS.

  reply	other threads:[~2020-08-31 15:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-26 14:39 [PATCH 1/2] i2c: i801: Fix runtime PM Jarkko Nikula
2018-06-26 14:55 ` Mika Westerberg
2018-06-27 20:15 ` Jean Delvare
2018-06-27 21:23   ` Bjorn Helgaas
2020-08-28 16:26     ` Bjorn Helgaas
2020-08-31 15:15       ` Vaibhav Gupta [this message]
2020-09-01  8:19         ` Jarkko Nikula

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=20200831151159.GA11707@gmail.com \
    --to=vaibhavgupta40@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jdelvare@suse.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=stable@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /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.