Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1297966

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

From Alan Stern <stern@rowland.harvard.edu>
Newsgroups linux.kernel
Subject Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled
Date 2015-12-24 17:10 +0100
Message-ID <qJgCK-u9-7@gated-at.bofh.it> (permalink)
References <qJgjo-6R-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, 24 Dec 2015, Oliver Neukum wrote:

> On Thu, 2015-12-24 at 10:14 -0500, Alan Stern wrote:
> > On Thu, 24 Dec 2015, Oliver Neukum wrote:
> > 
> > > On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
> 
> > > But you cannot keep that setting if the system goes down
> > > or any broadcast packet would resume the whole system.
> > > Yet you cannot just disable remote wake up, as WoL packages
> > > still must trigger a remote wake up.
> > 
> > This means that sometimes you want to avoid losing packets and other 
> > times you do want to lose packets.  That is a policy decision, and 
> > therefore it should be made by the user, not the kernel.
> 
> Indeed it is and there is a tool for this with a defined
> interface called "ethtool"

No; ethtool affects the wakeup setting for system suspend, but not
for runtime suspend.  I was referring to something that would specify 
the setting for both cases.  But perhaps that doesn't make sense, 
because you never want to drop relevant packets during runtime suspend.  
If you did, you would run "ifconfig down" instead.

> > the PM core aren't adequate for what the driver needs.  The PM core 
> > distinguishes between wakeup enabled or disabled; it doesn't 
> > distinguish among different levels of wakekup.
> 
> True and sanely it cannot. We could only distinguish between drivers
> which need their devices to be resumed before the system suspends and
> the rest.
> Or we tell driver coders to use the notifier chains.

"Resume before system suspend" sounds like a reasonable thing to
implement, for devices that have multiple levels of wakeup settings.  
Would you like to post a proposal on linux-pm for this?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled Hayes Wang <hayeswang@realtek.com> - 2015-12-22 10:50 +0100
  Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Oliver Neukum <oneukum@suse.com> - 2015-12-22 12:10 +0100
    RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled Hayes Wang <hayeswang@realtek.com> - 2015-12-23 04:40 +0100
      Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Oliver Neukum <oneukum@suse.de> - 2015-12-23 09:30 +0100
        RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled Hayes Wang <hayeswang@realtek.com> - 2015-12-23 10:30 +0100
          Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Oliver Neukum <oneukum@suse.com> - 2015-12-23 11:50 +0100
            RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled Hayes Wang <hayeswang@realtek.com> - 2015-12-23 12:20 +0100
          RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled Alan Stern <stern@rowland.harvard.edu> - 2015-12-24 02:40 +0100
            Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Oliver Neukum <oneukum@suse.com> - 2015-12-24 08:20 +0100
              Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Alan Stern <stern@rowland.harvard.edu> - 2015-12-24 16:20 +0100
                Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Oliver Neukum <oneukum@suse.com> - 2015-12-24 16:50 +0100
                Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled Alan Stern <stern@rowland.harvard.edu> - 2015-12-24 17:10 +0100

csiph-web