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 pa
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 ju
On Thu, 24 Dec 2015, Oliver Neukum wrote:
> On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
>
> > I don't understand why the wakeup conditions are different. It seems
> > to me that the choice of which packets will generate a wakeup ought to
> > depend on the user's selection, not on the ki
On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
> I don't understand why the wakeup conditions are different. It seems
> to me that the choice of which packets will generate a wakeup ought to
> depend on the user's selection, not on the kind of suspend. For
> instance, if the user says that
On Wed, 23 Dec 2015, Hayes Wang wrote:
> Oliver Neukum [mailto:oneu...@suse.de]
> > Sent: Wednesday, December 23, 2015 4:20 PM
> [...]
> > No, step (2) does not exist. Calls to suspend() and [reset_]resume()
> > always balance. Usually a driver shouldn't care about system suspend.
> > The way the
Oliver Neukum [mailto:oneu...@suse.com]
> Sent: Wednesday, December 23, 2015 6:46 PM
[...]
> That is indeed a problem and I need to think a bit about finding
> a good solution. If you are happy with an inelegant solution, you can
> use a pm_notifier, which will tell you that the system is going
> t
On Wed, 2015-12-23 at 09:20 +, Hayes Wang wrote:
> Oliver Neukum [mailto:oneu...@suse.de]
> > Sent: Wednesday, December 23, 2015 4:20 PM
> [...]
> > No, step (2) does not exist. Calls to suspend() and [reset_]resume()
> > always balance. Usually a driver shouldn't care about system suspend.
> >
Oliver Neukum [mailto:oneu...@suse.de]
> Sent: Wednesday, December 23, 2015 4:20 PM
[...]
> No, step (2) does not exist. Calls to suspend() and [reset_]resume()
> always balance. Usually a driver shouldn't care about system suspend.
> The way the driver is currently coded will also fail for Port-Po
On Wed, 2015-12-23 at 03:31 +, Hayes Wang wrote:
> Oliver Neukum [mailto:oneu...@suse.com]
> [...]
> > It is clear to me that you cannot get away with using the same operation
> > for resume() and reset_resume() in your driver. It is fundamentally
> > impossible. Firmware cannot fix it.
>
> I
Oliver Neukum [mailto:oneu...@suse.com]
[...]
> It is clear to me that you cannot get away with using the same operation
> for resume() and reset_resume() in your driver. It is fundamentally
> impossible. Firmware cannot fix it.
I would think how to fix it.
> Sorry for the length of the explanati
On Tue, 2015-12-22 at 09:48 +, Hayes Wang wrote:
> Peter Wu [mailto:pe...@lekensteyn.nl]
> > Sent: Tuesday, December 08, 2015 10:33 PM
> [...]
> > I found another problem with runtime PM. When a device is suspended via
> > autosuspend and a system suspend takes place, there is no network I/O
>
Peter Wu [mailto:pe...@lekensteyn.nl]
> Sent: Tuesday, December 08, 2015 10:33 PM
[...]
> I found another problem with runtime PM. When a device is suspended via
> autosuspend and a system suspend takes place, there is no network I/O
> after resume. Triggering a renegotiation (ethtool -r eth1) bri
On Tue, 2015-12-08 at 15:33 +0100, Peter Wu wrote:
> Can you have a look? I guess that reset_resume needs different
> treatment, but don't know how to do it properly as suspend is not
> called
> before system reset (because the device is apparently already in
> suspended state).
>
> I think that t
From: Peter Wu
Date: Tue, 8 Dec 2015 12:17:42 +0100
> When an interface is brought up which was previously suspended (via
> runtime PM), it would hang. This happens because napi_disable is called
> before napi_enable.
>
> Solve this by avoiding napi_enable in the resume during open function
> (
On Tue, Dec 08, 2015 at 12:39:12PM +, Hayes Wang wrote:
> Peter Wu [mailto:pe...@lekensteyn.nl]
> > Sent: Tuesday, December 08, 2015 7:18 PM
> >
> > When an interface is brought up which was previously suspended (via
> > runtime PM), it would hang. This happens because napi_disable is called
>
Peter Wu [mailto:pe...@lekensteyn.nl]
> Sent: Tuesday, December 08, 2015 7:18 PM
>
> When an interface is brought up which was previously suspended (via
> runtime PM), it would hang. This happens because napi_disable is called
> before napi_enable.
>
> Solve this by avoiding napi_enable in the re
16 matches
Mail list logo
