device */
+ __u8 mac_address[ETH_ALEN]; /* Generated MAC address for peer device */
};
/*
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
On Monday, July 29, 2013 12:34:24 PM Joe Perches wrote:
On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also
On Monday, September 23, 2013 04:28:49 PM Bjorn Helgaas wrote:
[+cc Rafael, linux-pm]
On Mon, Sep 23, 2013 at 1:36 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 23 Sep 2013, Andy Lutomirski wrote:
I've been getting this on several recent kernel revisions. Is it
interesting?
pm_qos_no_power_off manipulation only affecting one
device.
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Sarah Sharp sarah.a.sh...@linux.intel.com
Signed-off-by: Dan Williams dan.j.willi...@intel.com
is that it can happen at any time
and that's why the .suspend() and .resume() callbacks are needed (and this
also means that they can't be the same as .runtime_suspend() and
.runtime_resume() in general).
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center
On Wednesday, November 13, 2013 02:16:03 PM Alan Stern wrote:
On Wed, 13 Nov 2013, Ulf Hansson wrote:
The PM core was preventing devices from going inactive during system
suspend. Remove this constraint and moreover try to inactivate devices
by invoking pm_runtime_idle() before proceeding
)
+ pm_runtime_put(dev);
+
return error;
}
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
the USB device in and if so,
whether or not any of the numbers in /sys/firmware/acpi/interrupts/gpe*
grows at the same time.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb
On Thursday, February 21, 2013 03:52:11 PM Sarah Sharp wrote:
On Thu, Feb 21, 2013 at 11:54:55PM +0100, Rafael J. Wysocki wrote:
On Thursday, February 21, 2013 01:41:45 PM Sarah Sharp wrote:
Hi Rafael,
Hi,
I'm running into some issues with PCI D3
Do you mean D3hot?
I
and the output of acpidump from the
affected machine?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
must have pulled in the acpi bits the same time as the usb pull,
because I don't recall seeing this problem before last night.
Can you please check if the problem is still there in the master branch of
the linux-pm.git tree alone?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open
{} \;
and send the output?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Friday, February 22, 2013 04:30:25 PM Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki r...@sisk.pl wrote:
It won't revert, there's more stuff on top of it. And it is a fix, so
reverting it is not really a good idea anyway.
Rafael, please don't *ever* write
, there are some in your
dmesg too. I'll try to come up with a fix for current mainline, but all
the acpi stuff is quite obscure to me and the patch does not revert
cleanly, maybe Rafael (in CC) has some idea!
May I see the bisection log, BTW?
Rafael
--
I speak only for myself.
Rafael J. Wysocki
On Friday, February 22, 2013 05:10:43 PM Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki r...@sisk.pl wrote:
The problem is, though, that even if bisection turns up something, it
doesn't
automatically mean that this particular commit is the one that caused
On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
Well, this did the trick in my case:
--- 8 ---
diff --git a/drivers/acpi/power.c b
On Saturday, February 23, 2013 12:49:14 PM Fabio Baltieri wrote:
Hello Rafael,
On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
The new
On Saturday, February 23, 2013 03:48:59 PM Fabio Baltieri wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: ACPI / PM: Take unusual configurations of power resources into
account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After PCI has stopped using the .find_bridge() callback in
struct acpi_bus_type, the only remaining users of it are SATA and
USB. However, SATA only pretends to be a user, because it points
that callback to a stub always returning -ENODEV
On Wednesday, February 27, 2013 02:20:32 PM Greg Kroah-Hartman wrote:
On Wed, Feb 27, 2013 at 11:06:52PM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After PCI has stopped using the .find_bridge() callback in
struct acpi_bus_type, the only remaining
On Wednesday, February 27, 2013 03:31:08 PM Yinghai Lu wrote:
On Wed, Feb 27, 2013 at 2:20 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Feb 27, 2013 at 11:06:52PM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After PCI has stopped
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After PCI and USB have stopped using the .find_bridge() callback in
struct acpi_bus_type, the only remaining user of it is SATA, but SATA
only pretends to be a user, because it points that callback to a stub
always returning -ENODEV
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way it is used by USB every
device in the system that doesn't have a bus type or parent is
passed to usb_acpi_find_device() for inspection
On Wednesday, February 27, 2013 06:33:13 PM Greg Kroah-Hartman wrote:
On Thu, Feb 28, 2013 at 02:11:58AM +0100, Rafael J. Wysocki wrote:
On Wednesday, February 27, 2013 02:20:32 PM Greg Kroah-Hartman wrote:
On Wed, Feb 27, 2013 at 11:06:52PM +0100, Rafael J. Wysocki wrote:
From: Rafael J
On Thursday, February 28, 2013 02:29:56 PM Yinghai Lu wrote:
On Thu, Feb 28, 2013 at 1:53 PM, Rafael J. Wysocki r...@sisk.pl wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way
On Thursday, February 28, 2013 05:13:27 PM Jeff Garzik wrote:
On 02/28/2013 04:53 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After PCI and USB have stopped using the .find_bridge() callback in
struct acpi_bus_type, the only remaining user of it is SATA
,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, March 01, 2013 12:59:23 AM Liu, Chuansheng wrote:
-Original Message-
From: Rafael J. Wysocki [mailto:r...@sisk.pl]
Sent: Friday, March 01, 2013 8:51 AM
To: Liu, Chuansheng
Cc: Alan Stern; Li, Fei; gre...@linuxfoundation.org; Lan, Tianyu;
sarah.a.sh
for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, March 14, 2013 01:06:04 PM Peter Hurley wrote:
On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I don't think I have seen this message on rc1+ (8343bce
?
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from
On Monday, March 25, 2013 04:33:02 PM Sarah Sharp wrote:
On Mon, Mar 25, 2013 at 11:14:15PM +0100, Rafael J. Wysocki wrote:
On Monday, March 25, 2013 02:35:37 PM Sarah Sharp wrote:
Alan,
Is there a way to disable runtime PM for a PCI host controller, but
still allow the system
On Tuesday, March 26, 2013 09:24:04 AM Sarah Sharp wrote:
On Tue, Mar 26, 2013 at 01:12:25PM +0100, Rafael J. Wysocki wrote:
On Monday, March 25, 2013 04:33:02 PM Sarah Sharp wrote:
On Mon, Mar 25, 2013 at 11:14:15PM +0100, Rafael J. Wysocki wrote:
On Monday, March 25, 2013 02:35:37 PM
On Sunday, March 31, 2013 03:41:11 AM Rafael J. Wysocki wrote:
[Moving the thread to the LKML.]
On Saturday, March 30, 2013 06:41:16 PM Sasha Levin wrote:
On 03/15/2013 01:06 PM, Rafael J. Wysocki wrote:
[...]
Rafael, Is there anything you would like me to test?
Please just test
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
usb: Add driver/usb/core/(port.c,hub.h) files, from
usb_port_device_release(), because (1) it is completely unnecessary
(the flags have been removed already by the PM core
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Commit b81ea1b (PM / QoS: Fix concurrency issues and memory leaks in
device PM QoS) put calls to pm_qos_sysfs_add_latency(),
pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which
On Sunday, March 31, 2013 08:29:20 PM Linus Torvalds wrote:
On Sun, Mar 31, 2013 at 3:56 PM, Rafael J. Wysocki r...@sisk.pl wrote:
So, I have two patches (on top of the Linus' tree) that will follow shortly:
Should I take these directly as patches, or expect them to show up in
a pull soon
*can* be turned off at the given
time, so the kernel can't guarantee any requests to turn devices off to be
satisfied at any given time. I believe this is the case for USB ports too.
I don't think anything has changed in that respect since then.
Thanks,
Rafael
--
I speak only for myself.
Rafael J
?
No, there aren't.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Sunday, 24 of February 2008, Adrian Bunk wrote:
This patch fixes the following compile error caused by
commit 3a2d5b700132f35401f1d9e22fe3c2cab02c2549:
Thanks, it has already been fixed in the mainline.
-- snip --
...
CC drivers/usb/host/u132-hcd.o
On Saturday, July 07, 2012, Alan Stern wrote:
On Sat, 7 Jul 2012, Oleksij Rempel wrote:
Ok, i guess i know your problem but i doubt it will be completely fixed
by changing powermanagement behavior. Two logitech cams i tested is
really easy to confuse/brake/freeze. Just turn off the
On Sunday, July 08, 2012, Alan Stern wrote:
On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
Well, the quirk does make sense. What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change in the autosuspend behavior
...@wrar.name
Tested-by: Oleksij Rempel bug-tr...@fisher-privat.net
Tested-by: Pavel Pisa p...@cmp.felk.cvut.cz
CC: sta...@vger.kernel.org
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/pci/pci-driver.c | 12
drivers/pci/pci.c|5 -
drivers/pci
On Saturday, July 21, 2012, Ming Lei wrote:
CC guys who discussed the problem in the below link in Jan. :
http://marc.info/?t=13252895602r=10w=2
On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei tom.leim...@gmail.com wrote:
The RFC patch is just for discussing if the idea of deferring
On Saturday, July 21, 2012, Ming Lei wrote:
On Sat, Jul 21, 2012 at 5:56 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, July 21, 2012, Ming Lei wrote:
CC guys who discussed the problem in the below link in Jan. :
http://marc.info/?t=13252895602r=10w=2
On Fri, Jul 20
On Friday, July 20, 2012, Ming Lei wrote:
The RFC patch is just for discussing if the idea of deferring
request_firmware is doable for addressing the issue of
request_firmware in resume path, which is caused by driver
unbind/rebind during resume.
At least usb bus is involved in such things,
On Saturday, July 21, 2012, Linus Torvalds wrote:
On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei tom.leim...@gmail.com wrote:
The RFC patch is just for discussing if the idea of deferring
request_firmware is doable for addressing the issue of
request_firmware in resume path, which is caused by
On Wednesday, July 25, 2012, Bjørn Mork wrote:
huang ying huang.ying.cari...@gmail.com writes:
Hi, Bjorn,
Thank you very much for your detailed information.
On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork bj...@mork.no wrote:
Huang Ying ying.hu...@intel.com writes:
On Wed, 2012-07-25
On Wednesday, July 25, 2012, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei ming@canonical.com wrote:
The below patch should fix the problem above.
Actually, I think we could make this even simpler.
There's nothing wrong with saying user mode is enabled *just*
it is.
Fix that by using an array of state names corresponding to the
PCI device power states instead of building the state name from
the numeric value corresponding to the given state directly.
Signed-off-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/pci/pci-acpi.c | 14 +++---
1 file
On Wednesday, July 25, 2012, Alan Stern wrote:
On Wed, 25 Jul 2012, Rafael J. Wysocki wrote:
If a PCI device is put into D3_cold by acpi_bus_set_power(),
the message printed by acpi_pci_set_power_state() says that its
power state has been changed to D4, which doesn't make sense
On Friday, July 27, 2012, Alan Stern wrote:
On Fri, 27 Jul 2012, Huang Ying wrote:
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -280,8 +280,12 @@ static long local_pci_probe(void *_ddi)
{
struct drv_dev_and_id *ddi = _ddi;
struct device *dev =
On Friday, July 27, 2012, Alan Stern wrote:
On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
On Friday, July 27, 2012, Alan Stern wrote:
On Fri, 27 Jul 2012, Huang Ying wrote:
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -280,8 +280,12 @@ static long
On Saturday, July 28, 2012, Alan Stern wrote:
On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
+ if (parent)
+ pm_runtime_put(parent);
You should use pm_runtime_put_sync(), not pm_runtime_put().
Hmm, why exactly?
Because it's more efficient to do
On Saturday, July 28, 2012, Alan Stern wrote:
On Sat, 28 Jul 2012, Rafael J. Wysocki wrote:
On Saturday, July 28, 2012, Alan Stern wrote:
On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
+ if (parent)
+ pm_runtime_put(parent);
You should
On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
On Sunday, July 29, 2012, Alan Stern wrote:
On Sun, 29 Jul 2012, Rafael J. Wysocki wrote:
The difference is, if you use _put_sync(), you need to wait the extra 10
ms
for local_pci_probe() to return (if the parent is actually
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness of it is quite questionable,
because
either we want
On Tuesday, July 31, 2012, Rafael J. Wysocki wrote:
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness
On Wednesday, August 01, 2012, Alan Stern wrote:
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current
On Friday, August 03, 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
I don't know about that -- the logic involved in doing the processing
within the resume callback isn't terribly complicated. At least, not
much more complicated than the logic involved
On Friday, August 03, 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
I don't know about that -- the logic involved in doing the processing
within the resume callback isn't terribly complicated. At least, not
much
On Saturday, August 04, 2012, Alan Stern wrote:
On Sat, 4 Aug 2012, Rafael J. Wysocki wrote:
That wasn't what he meant. What if the code needs to run in the _same_
context as the caller? For example, with a spinlock held.
I see. I think it wouldn't be unreasonable to require
On Monday, August 06, 2012, Alan Stern wrote:
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote:
[...]
What about the appended experimental patch?
For now, I think it would be best to start with a single func argument.
If it turns out that anyone really needs to have two separate
arguments
On Tuesday, August 07, 2012, Ming Lei wrote:
On Mon, Aug 6, 2012 at 10:47 PM, Alan Stern st...@rowland.harvard.edu wrote:
No, no, you have completely misunderstood the whole point of this
change.
Sorry, you are right. And the callback should be renamed as
'.runtime_post_resume', which
On Monday, August 06, 2012, Rafael J. Wysocki wrote:
On Monday, August 06, 2012, Alan Stern wrote:
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote:
[...]
What about the appended experimental patch?
For now, I think it would be best to start with a single func argument.
If it turns
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Yes, I agree, but I don't think it may make .runtime_post_resume
not doable, do I?
No more device PM callbacks, please.
IMO, what the patch is doing is to introduce one
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 11:42 PM, Alan Stern st...@rowland.harvard.edu wrote:
No, that's really not what the patch is doing.
The idea behind the new API is that func will be called as soon as we
know the device is at full power. That could be
On Tuesday, August 07, 2012, Alan Stern wrote:
On Tue, 7 Aug 2012, Rafael J. Wysocki wrote:
All those changes (and some of the following ones) are symptoms of a
basic mistake in this approach.
Every time you say something like this (i.e. liks someone who knows
better)
s
On Wednesday, August 08, 2012, Ming Lei wrote:
On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote:
[...]
and you want to move something out of previous
On Thursday, August 09, 2012, Ming Lei wrote:
On Thu, Aug 9, 2012 at 4:16 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday, August 08, 2012, Alan Stern wrote:
To be honest, I agree on the idea:
The runtime-resume method does nothing but bring the device
back to full
On Thursday, August 09, 2012, Ming Lei wrote:
On Thu, Aug 9, 2012 at 6:46 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, August 09, 2012, Ming Lei wrote:
driver-runtime_resume should be allowed to do I/O things after
the device has been woken up inside driver callback, shouldn't
On Friday, August 10, 2012, Ming Lei wrote:
On Fri, Aug 10, 2012 at 3:41 AM, Rafael J. Wysocki r...@sisk.pl wrote:
It just isn't guaranteed that the subsystem callback won't do anything
after driver-runtime_resume completion. I agree that it isn't likely
to happen.
In fact
Hi,
The usb-wwan driver triggers a NULL pointer dereference oops after resume
from system suspend on my Toshiba Portege R500, but since that driver
hasn't changed since v3.5 and it is only used by the option driver, I suppose
that the latter is responsible for that.
This is a clear regression
On Friday, September 21, 2012, Sarah Sharp wrote:
Two weeks ago at Linux Plumbers Conference, I presented about the Intel
Lynx Point USB port power off mechanism. This email is a report out of
what was discussed, and a kick off point for further discussion.
LPC Report out
--
On Friday, September 21, 2012, Sarah Sharp wrote:
On Fri, Sep 21, 2012 at 04:09:13PM -0400, Alan Stern wrote:
On Thu, 20 Sep 2012, Sarah Sharp wrote:
Two weeks ago at Linux Plumbers Conference, I presented about the Intel
Lynx Point USB port power off mechanism. This email is a report
On Friday, September 21, 2012, Peter Stuge wrote:
Sarah Sharp wrote:
If userspace really wants the port off (e.g. to disconnect and
reconnect a misbehaving device), then it can set the sysfs file
to off.
And unless all ganged ports are also off it will fail. Userspace will
On Sunday, September 23, 2012, Lan Tianyu wrote:
于 2012/9/23 3:54, Rafael J. Wysocki 写道:
On Friday, September 21, 2012, Peter Stuge wrote:
Sarah Sharp wrote:
If userspace really wants the port off (e.g. to disconnect and
reconnect a misbehaving device), then it can set the sysfs file
On Sunday, September 23, 2012, Peter Stuge wrote:
Rafael J. Wysocki wrote:
Well, we actually need to handle power domains appropriately.
..
Some work in that direction has been done in the ARM space, where we have
much more direct access to hardware, and I suppose it may be extended
On Sunday, September 23, 2012, Lan Tianyu wrote:
于 2012/9/22 20:08, Rafael J. Wysocki 写道:
So, my current idea is why don't we handle that through PM QoS? I mean we
have
a means to specify per-device PM QoS wakeup latency constraits and expose
it to
user space on a per-device basis
On Monday, September 24, 2012, Arjan van de Ven wrote:
On 9/23/2012 8:33 PM, Rafael J. Wysocki wrote:
On Sunday, September 23, 2012, Peter Stuge wrote:
Rafael J. Wysocki wrote:
Well, we actually need to handle power domains appropriately.
..
Some work in that direction has been done
On Monday, September 24, 2012, Arjan van de Ven wrote:
On 9/24/2012 12:13 AM, Alan Stern wrote:
Therefore all we need is an API for individual devices, not for
domains. Of course, userspace may want to know which devices all
belong to the same power domain.
agreed on both.
I'd like
On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Sarah Sharp wrote:
Two weeks ago at Linux Plumbers Conference, I presented about the Intel
Lynx Point USB port power off mechanism. This email is a report out of
what was discussed, and a kick off
On Monday, September 24, 2012, Greg KH wrote:
On Mon, Sep 24, 2012 at 10:46:30AM -0700, Greg KH wrote:
On Mon, Sep 24, 2012 at 03:18:19PM +0200, Rafael J. Wysocki wrote:
On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Sarah Sharp wrote:
Two
On Monday, September 24, 2012, Lan Tianyu wrote:
On 2012/9/24 21:18, Rafael J. Wysocki wrote:
On Saturday, September 22, 2012, Rafael J. Wysocki wrote:
On Friday, September 21, 2012, Sarah Sharp wrote:
Two weeks ago at Linux Plumbers Conference, I presented about the Intel
Lynx Point USB
On Monday, September 24, 2012, Alan Stern wrote:
On Mon, 24 Sep 2012, Rafael J. Wysocki wrote:
I don't mean this.
Suppose that there are two ports on the hub, A and B, and there's only one
power resource used to put A _and_ B into D3cold. Then, when you call
acpi_bus_set_power
again. :-)
Thanks,
Rafael
Rafael J. Wysocki r...@sisk.pl schrieb:
On Friday 05 of October 2012 10:42:11 Alan Stern wrote:
Rafael:
You are invited to take a look at Bugzilla #48331. It appears to be
a
PM problem; the log says:
Oct 3 11:16:37 aragorn kernel: [49179.190249
Sorry for the delay, I have been distracted by a number of things.
On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
On Monday, September 24, 2012, Alan Stern wrote:
On Mon, 24 Sep 2012, Rafael J. Wysocki wrote
);
+ pm_runtime_put_autosuspend(udev-dev);
It looks like you could just call pm_runtime_idle(udev-dev) after the barrier
without the _get and _put around it. Wouldn't that work?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center
On Thursday, May 08, 2014 08:56:24 AM Dan Williams wrote:
On Thu, May 8, 2014 at 4:09 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
Unconditionally wake up the child device when the power session is
recovered.
[cut
to both system suspend/resume and runtime PM, though.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Wednesday, November 20, 2013 12:23:03 PM Pavel Machek wrote:
On Wed 2013-11-20 11:52:05, Ulf Hansson wrote:
On 19 November 2013 16:35, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 19 Nov 2013, Ulf Hansson wrote:
At the moment, system PM is already affecting behaviour of
.
SET_RUNTIME_PM_OPS is intended to be used inside of a struct dev_pm_ops
definition along the lines of UNIVERSAL_DEV_PM_OPS (although the latter
was a mistake, sadly).
So actually what we need is a sane replacement for UNIVERSAL_DEV_PM_OPS
in my opinion.
Thanks!
--
I speak only for myself.
Rafael J
the port active on enable.
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Well, while this generally won't hurt, I'm not sure how it helps either,
because device_(disable|enable)_wakeup() don't touch any hardware and
(for now) they are only about
On 11/22/2013 8:29 PM, Dan Williams wrote:
On Fri, Nov 22, 2013 at 7:50 AM, Rafael J. Wysocki
rafael.j.wyso...@intel.com wrote:
On 11/22/2013 10:08 AM, Dan Williams wrote:
usbcore blocks powering off hub ports while a downstream source is
wakeup enabled. Once wakeup is disabled usbcore can
On 11/23/2013 1:16 AM, Dan Williams wrote:
On Fri, Nov 22, 2013 at 4:06 PM, Rafael J. Wysocki
rafael.j.wyso...@intel.com wrote:
On 11/22/2013 8:29 PM, Dan Williams wrote:
On Fri, Nov 22, 2013 at 7:50 AM, Rafael J. Wysocki
rafael.j.wyso...@intel.com wrote:
On 11/22/2013 10:08 AM, Dan Williams
int pm_generic_freeze_noirq(struct device *dev);
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote:
On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 25, 2013 01:40:21 PM Ulf Hansson wrote:
To put devices into low power state during sleep, it sometimes makes
sense at subsystem-level to re
On Tuesday, November 26, 2013 04:09:44 PM Alan Stern wrote:
On Tue, 26 Nov 2013, Rafael J. Wysocki wrote:
On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote:
On 26 November 2013 00:10, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 25, 2013 01:40:21 PM Ulf
On Wednesday, November 27, 2013 12:44:35 AM Ulf Hansson wrote:
On 26 November 2013 22:09, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 26 Nov 2013, Rafael J. Wysocki wrote:
On Tuesday, November 26, 2013 10:48:56 AM Ulf Hansson wrote:
On 26 November 2013 00:10, Rafael J. Wysocki r
1 - 100 of 251 matches
Mail list logo
