On Tue, 2016-03-22 at 11:13 -0400, Alan Stern wrote:
> > Indeed. In that case the point is moot. But it is correct to ask
> > the core whether the device is autosuspended at that point rather
> > than keep a private flag if you can.
>
> That's why we have pm_runtime_status_suspended().
I guess we
On Tue, 22 Mar 2016, Oliver Neukum wrote:
> On Tue, 2016-03-22 at 10:21 -0400, Alan Stern wrote:
> > I don't see any point in resuming the device just in order to collect
> > operating statistics. If it was already suspended then it wasn't
> > operating, so there will be no statistics to collec
On Tue, 2016-03-22 at 10:21 -0400, Alan Stern wrote:
> I don't see any point in resuming the device just in order to collect
> operating statistics. If it was already suspended then it wasn't
> operating, so there will be no statistics to collect.
Indeed. In that case the point is moot. But it
On Tue, 22 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 15:30 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
>
> > > We have an autosuspend timeout because we think that IO, if it will
> > > come at all, is likeliest to come soon. If, however, the IO is
> >
On Mon, 2016-03-21 at 15:30 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
>
> > We have an autosuspend timeout because we think that IO, if it will
> > come at all, is likeliest to come soon. If, however, the IO is
> > periodic that heuristics is false.
> > To save most pow
On Mon, 21 Mar 2016 woojung@microchip.com wrote:
> > > > But this leaves open the issue that querying the device too often will
> > > > prevent it from going into autosuspend. It seems to me that the best
> > > > way to deal with this is to make sure that the autosuspend timeout is
> > > > sh
> > > But this leaves open the issue that querying the device too often will
> > > prevent it from going into autosuspend. It seems to me that the best
> > > way to deal with this is to make sure that the autosuspend timeout is
> > > shorter than the interal between queries, not to make the queryi
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
> > > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> > >
> > > > One possible solution is to export a sysfs parameter to prevent
> > > > sta
On Mon, 21 Mar 2016 woojung@microchip.com wrote:
> > But this leaves open the issue that querying the device too often will
> > prevent it from going into autosuspend. It seems to me that the best
> > way to deal with this is to make sure that the autosuspend timeout is
> > shorter than the i
On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
>
> > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> >
> > > One possible solution is to export a sysfs parameter to prevent
> > > statistics collection (or more generally, to change the inte
> But this leaves open the issue that querying the device too often will
> prevent it from going into autosuspend. It seems to me that the best
> way to deal with this is to make sure that the autosuspend timeout is
> shorter than the interal between queries, not to make the querying
> conditional
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
>
> > One possible solution is to export a sysfs parameter to prevent
> > statistics collection (or more generally, to change the interval at
> > which it occurs).
>
> Surely, not performing a task
On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> One possible solution is to export a sysfs parameter to prevent
> statistics collection (or more generally, to change the interval at
> which it occurs).
Surely, not performing a task can hardly be beaten in terms of power
consumption. That
ernel.org;
> linux...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] lan78xx: Protect runtime_auto check by #ifdef
> CONFIG_PM
>
> Not that it matters anymore since David reverted the original patch,
> but my reason for not sending a similar patch was that I wasn't s
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
> > If CONFIG_PM=n:
> >
> > drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
> > drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no
> > member named ‘runti
ernel.org;
> linux...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] lan78xx: Protect runtime_auto check by #ifdef
> CONFIG_PM
Thanks for all comments.
Will look into it and submit new patch.
- Woojung
On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
> If CONFIG_PM=n:
>
> drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
> drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no
> member named ‘runtime_auto’
>
> If PM is disabled, the runtime_auto flag
On 03/20/2016 03:43 AM, Geert Uytterhoeven wrote:
If CONFIG_PM=n:
drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no member
named ‘runtime_auto’
If PM is disabled, the runtime_auto flag is not available, bu
From: Eric Dumazet
Date: Sun, 20 Mar 2016 09:35:52 -0700
> On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
>> If CONFIG_PM=n:
>>
>> drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
>> drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no
>> member
On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
> If CONFIG_PM=n:
>
> drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
> drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no member
> named ‘runtime_auto’
>
> If PM is disabled, the runtime_auto flag
If CONFIG_PM=n:
drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no member
named ‘runtime_auto’
If PM is disabled, the runtime_auto flag is not available, but auto
suspend is not enabled anyway. Hence protect t
21 matches
Mail list logo
