Hi,
I booted Ubuntu13.10 onto ASUS T100 Tablet and upgraded it with upstream
kernel (3.14.0-rc7+). There is a thermal device under
/sys/devices/platform/asus-nb-wmi.
root@t100:~/linux# tree /sys/class/hwmon/
/sys/class/hwmon/
├── hwmon0 - ../../devices/platform/coretemp.0/hwmon/hwmon0
└──
When the xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platform may get a spurious wakeup, even if PCI PME# is disabled.
http://marc.info/?l=linux-usbm=138194006009255w=2
Signed-off-by: Lu
, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
USB: xHCI: bus power management implementation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb
.
With this quirk set, wakeup capability will be ignored during
device configure.
This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hub.c | 6 --
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 3
On 8/29/2014 7:59 PM, Sergei Shtylyov wrote:
Hello.
On 8/29/2014 8:26 AM, Lu Baolu wrote:
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
.
With this quirk set, wakeup capability will be ignored during
device configure.
This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hub.c | 6 --
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 3
This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
This has been discussed at http://www.spinics.net/lists/linux-usb/msg114986.html
It also includes a patch to fix a comment in drivers/usb/host/xhci.h.
Lu Baolu (3):
usb: xhci: Revert xhci: clear root port wake on bits
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means Device is non-removable.
Reported-by: Juro Bystricky jurobystri...@hotmail.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-pci.c | 42 ++
drivers/usb/host/xhci.h | 6 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 280dde9..3e7441a
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Reported-by: Dmitry Nezhevenko d...@inhex.net
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means Device is non-removable.
Reported-by: Juro Bystricky jurobystri...@hotmail.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi Mathias,
This patch series has been acked by Alan Stern. There seems no further
comments from others. Can you please pull in it?
Thanks,
-baolu
On 2014年11月06日 10:50, Lu Baolu wrote:
This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
This has been discussed
On 2014年11月25日 21:11, George Cherian wrote:
Pass the quir flag XHCI_DRD_SUPPORT from DWC3 host to xhci platform driver.
quir to quirk
Regards,
Baolu
This enables xhci driver to handle deallocation's differently while in DRD mode.
Pass the quirk flag XHCI_NEEDS_LHC_RESET from DWC3 host to
On 10/31/2014 10:28 PM, Alan Stern wrote:
On Fri, 31 Oct 2014, Lu Baolu wrote:
xhci: clear root port wake on bits if controller isn't wake-up capable
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_pci_suspend needs to clear all root port wake on bits
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means Device is non-removable.
Reported-by: Juro Bystricky jurobystri...@hotmail.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
xhci controllers.
Lu Baolu (3):
usb: xhci: Revert xhci: clear root port wake on bits if controller
isn't wake-up capable
usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
usb: xhci: fix comment for PORT_DEV_REMOVE
drivers/usb/host/xhci-hub.c | 5 +
drivers/usb/host
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Reported-by: Dmitry Nezhevenko d...@inhex.net
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers
-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..cd57aae 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host
On 11/5/2014 12:58 AM, Alan Stern wrote:
On Tue, 4 Nov 2014, Lu Baolu wrote:
xhci: clear root port wake on bits if controller isn't wake-up capable
When system is being suspended, if host device is not wakeup capable,
xhci_suspend() needs to clear all root port wake on bits. Otherwise,
some
wake-up capable to allowed to do wakeup
in both comments and patch description.
* Add Suggested-by: Alan Stern
Changes in v2:
* Should not be a quirk.
* Should be applied to all xhci controllers.
Lu Baolu (3):
usb: xhci: Revert xhci: clear root port wake on bits if controller
isn't wake
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means Device is non-removable.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Juro Bystricky jurobystri...@hotmail.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 44 +++-
drivers/usb/host/xhci.h
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Dmitry Nezhevenko d...@inhex.net
---
drivers
On 11/6/2014 5:24 AM, Alan Stern wrote:
On Wed, 5 Nov 2014, Lu Baolu wrote:
xhci: clear root port wake on bits if controller isn't allowed to do wakeup
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits
.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 42
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means Device is non-removable.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Juro Bystricky jurobystri...@hotmail.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
.
- Should be applied to all xhci controllers.
Lu Baolu (3):
usb: xhci: Revert xhci: clear root port wake on bits if controller
isn't wake-up capable
usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
usb: xhci: fix comment for PORT_DEV_REMOVE
drivers/usb/host/xhci
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Dmitry Nezhevenko d...@inhex.net
---
drivers
On 03/12/2015 04:46 PM, Mathias Nyman wrote:
On 12.03.2015 03:39, Lu Baolu wrote:
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
On 03/12/2015 03:54 PM, Greg Kroah-Hartman wrote:
On Thu, Mar 12, 2015 at 09:39:06AM +0800, Lu Baolu wrote:
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event
to user.
This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a (Intel xhci: Support EHCI/xHCI port switching.).
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Cc: sta...@vger.kernel.org
Hi Alan,
Do you have any comments for this patch?
Thanks,
Baolu
On 03/06/2015 04:12 PM, Lu Baolu wrote:
Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends
On 03/11/2015 02:49 AM, Alan Stern wrote:
On Tue, 10 Mar 2015, Mathias Nyman wrote:
Mathias:
Your patch description says this:
The endpoint might already processesed some TRBs on the endpiont ring
before we soft reset the endpoint.
Make sure we set the dequeue pointer to where we were
to user.
This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a (Intel xhci: Support EHCI/xHCI port switching.).
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Tested-by: Alistair Grant
. As the result, the xHC
looks like dead to user.
The patch is to apply XHCI_AVOID_BEI to Intel VallyView and Lynx Point
LP devices. And it should be backported to kernels as old as 3.0, that
contains the commit 69e848c2090a (Intel xhci: Support EHCI/xHCI port
switching.)
Signed-off-by: Lu Baolu baolu
On 03/18/2015 08:40 PM, Heikki Krogerus wrote:
+
+/**
+ * ulpi_register_driver - unregister a driver with the ULPI bus
Hi Heikki,
ulpi_register_driver should be changed to ulpi_unregister_driver.
Thanks,
Baolu
+ * @drv: driver to unregister
+ *
+ * Unregisters a driver with the ULPI bus.
+
in
xhci_clear_port_change_bit().
[Mathias Nyman contributed the idea. The commit log is based on patch
posted at http://marc.info/?l=linux-kernelm=142323612321434w=2]
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Cc: stable sta...@vger.kernel.org # v3.2+
---
drivers/usb/host/xhci-hub.c | 9 -
1 file
for power savings and there may be increased latency
for restarting an endpoint. The precise impact will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Lu Baolu (3):
usb: add a hcd notify entry in hc_driver
usb: xhci: implement hc_driver
, it will ring doorbells for all endpoints
unconditionally. XHC may use these hints to optimize its operation
on endpoint state cashes.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci.c | 28
drivers/usb
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through the new notify entry in hc_driver.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 47
for power savings and there may be increased latency
for restarting an endpoint. The precise impact will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/generic.c | 10
Hi Alan,
Thanks for your review comments. Below has my response inline.
On 05/04/2015 10:28 PM, Alan Stern wrote:
On Mon, 4 May 2015, Lu Baolu wrote:
This patch adds a new entry pointer in hc_driver. With this new entry,
USB core can notify host driver when something happens and host driver
On 05/05/2015 10:50 PM, Alan Stern wrote:
On Tue, 5 May 2015, Lu, Baolu wrote:
The order that software should do during device suspend/resume is
defined in 4.15.1.1 of xHCI spec 1.1.
Spec 4.15.1.1:
Software shall stop all endpoints of a device using the Stop Endpoint
Command and setting
the suspend. device_resume will be called when a USB device is just
resumed. It will ring doorbells of all endpoint unconditionally. XHC may
use these suspend/resume hints to optimize its operation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers
name specific to the activity in question
- no need to export hcd_notify
- put the callback in the right place
Lu Baolu (3):
usb: notify hcd when USB device suspend or resume
usb: xhci: implement device_suspend/device_resume entries
usb: xhci: remove stop device and ring doorbell in hub
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend/device_resume interfaces.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c
will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 29 +
drivers/usb/core/hub.c | 16
include/linux/usb/hcd.h | 10
On 05/08/2015 04:47 AM, Greg Kroah-Hartman wrote:
On Thu, May 07, 2015 at 10:18:15AM +0800, Lu Baolu wrote:
This patch implements device_suspend/device_resume entries for xHC driver.
device_suspend will be called when a USB device is about to suspend. It
will issue a stop endpoint command
On 05/07/2015 10:34 PM, Alan Stern wrote:
On Thu, 7 May 2015, Lu, Baolu wrote:
+ void(*device_suspend)(struct usb_hcd *, struct usb_device *udev,
+ pm_message_t msg);
+ void(*device_resume)(struct usb_hcd *, struct usb_device *udev
On 05/08/2015 03:28 PM, Greg Kroah-Hartman wrote:
On Fri, May 08, 2015 at 09:23:40AM +0800, Lu, Baolu wrote:
On 05/08/2015 04:47 AM, Greg Kroah-Hartman wrote:
On Thu, May 07, 2015 at 10:18:15AM +0800, Lu Baolu wrote:
This patch implements device_suspend/device_resume entries for xHC driver
On 05/06/2015 10:35 PM, Alan Stern wrote:
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 68b1e83..621d9b7 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -383,7 +383,13 @@ struct hc_driver {
int (*find_raw_port_number)(struct usb_hcd *, int);
will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 27 +++
drivers/usb/core/hub.c | 5 +
include/linux/usb/hcd.h | 8 +++-
3
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend/device_resume interfaces.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c
' parameter in the callbacks
v2-v3:
- move two xhci specific comments from hub to xhci
- define xhci_device_suspend(resume) as NULL when no PM_CONFIG
v1-v2:
- make the callback name specific to the activity in question
- no need to export hcd_notify
- put the callback in the right place
Lu
the suspend. device_resume will be called when a USB device is just
resumed. It will ring doorbells of all endpoint unconditionally. XHC may
use these suspend/resume hints to optimize its operation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers
On 05/06/2015 10:35 PM, Alan Stern wrote:
On Wed, 6 May 2015, Lu Baolu wrote:
This patch adds two new entries in hc_driver. With these new entries,
USB core can notify host driver when a USB device is about to suspend
or just resumed.
The xHCI spec is designed to allow an xHC implementation
On 05/06/2015 10:30 PM, Alan Stern wrote:
On Wed, 6 May 2015, Lu Baolu wrote:
This patch implements device_suspend/device_resume entries for xHC driver.
device_suspend will be called when a USB device is about to suspend. It
will issue a stop endpoint command for each endpoint in this device
will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 29 +
drivers/usb/core/hub.c | 5 +
include/linux/usb/hcd.h | 10 +-
3
the suspend. device_resume will be called when a USB device is just
resumed. It will ring doorbells of all endpoint unconditionally. XHC may
use these suspend/resume hints to optimize its operation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend/device_resume interfaces.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c
specific comments from hub to xhci
- define xhci_device_suspend(resume) as NULL when no PM_CONFIG
v1-v2:
- make the callback name specific to the activity in question
- no need to export hcd_notify
- put the callback in the right place
Lu Baolu (3):
usb: notify hcd when USB device suspend
On 05/04/2015 04:14 PM, Greg Kroah-Hartman wrote:
On Mon, May 04, 2015 at 11:15:30AM +0800, Lu Baolu wrote:
This patch adds a new entry pointer in hc_driver. With this new entry,
USB core can notify host driver when something happens and host driver
is willing to be notified. One use case
On 05/11/2015 10:25 PM, Alan Stern wrote:
On Sat, 9 May 2015, Lu, Baolu wrote:
If FSC is supported, the cached Slot, Endpoint, Stream, or other
Context information are also saved.
Hence, when FSC is supported, software does not have to issue Stop
Endpoint Command to push public and private
On 05/08/2015 07:01 PM, Greg Kroah-Hartman wrote:
On Fri, May 08, 2015 at 06:26:28PM +0800, Lu Baolu wrote:
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend
On 05/08/2015 10:21 PM, Alan Stern wrote:
On Fri, 8 May 2015, Lu, Baolu wrote:
On 05/07/2015 10:34 PM, Alan Stern wrote:
On Thu, 7 May 2015, Lu, Baolu wrote:
+ void(*device_suspend)(struct usb_hcd *, struct usb_device *udev,
+ pm_message_t msg
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend/device_resume interfaces.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c
will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 27 +++
drivers/usb/core/hub.c | 5
the suspend. device_resume will be called when a USB device is just
resumed. It will ring doorbells of all endpoint unconditionally. XHC may
use these suspend/resume hints to optimize its operation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers
the callback in the right place
Lu Baolu (3):
usb: notify hcd when USB device suspend or resume
usb: xhci: implement device_suspend/device_resume entries
usb: xhci: remove stop device and ring doorbell in hub control and bus
suspend
drivers/usb/core/hcd.c | 27
On 05/12/2015 11:54 PM, Alan Stern wrote:
On Tue, 12 May 2015, Lu, Baolu wrote:
I'm sorry that I confused you.
FSC is a different thing from what this patch series does.
I know that. The patch series, in its current form, is fine. Now I'm
trying to understand what you originally wanted
On 05/21/2015 03:33 PM, Heikki Krogerus wrote:
On Thu, May 21, 2015 at 01:40:43PM +0800, Lu Baolu wrote:
The intention of this change is to fix below kernel panic when
USB_ULPI_BUS was configured as buildin.
That is actually incorrect. Having the bus build-in does not cause
this panic
] kernel_init+0xe/0xf0
[0.935266] [81b0f442] ret_from_fork+0x42/0x70
[0.941315] [81affed0] ? rest_init+0x90/0x90
Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 05/21/2015 05:22 AM, David Cohen wrote:
Hi,
On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
ULPI registers it's bus at module_init so if the bus fails to register, the
A minor comment: s/it's/its/
module will fail to load and all will be well in the world.
However, if the
, which will panic the kernel.
Fix that by checking that the bus was indeed initialized before trying to
register drivers on top of it.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
On 06/04/2015 08:17 PM, Heikki Krogerus wrote:
Hi Baolu,
On Thu, May 28, 2015 at 08:50:12AM +0800, Lu, Baolu wrote:
On 05/28/2015 12:53 AM, David Cohen wrote:
Hi,
On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote:
On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote
On 06/25/2015 10:53 PM, Mathias Nyman wrote:
On 09.05.2015 04:15, Lu Baolu wrote:
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend/device_resume interfaces
On 06/12/2015 12:32 PM, Greg Kroah-Hartman wrote:
On Fri, Jun 12, 2015 at 09:29:37AM +0800, Lu Baolu wrote:
Commit 25cd2882e2fc (usb/xhci: Change how we indicate a host supports
Link PM.) removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change
...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser kevin.stras...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 7 +--
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/usb.h | 6 ++
3 files changed, 12 insertions(+), 3 deletions(-)
v1-v2
On 06/13/2015 01:43 AM, Alan Stern wrote:
On Fri, 12 Jun 2015, Lu Baolu wrote:
Commit 25cd2882e2fc (usb/xhci: Change how we indicate a host supports
Link PM.) removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser kevin.stras...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 7 +--
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/usb.h | 1 +
3 files changed, 7
...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser kevin.stras...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 6 ++
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/usb.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git
...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser kevin.stras...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 7 +--
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/usb.h | 1 +
3 files changed, 7 insertions(+), 3 deletions(-)
v1-v2 change
On 06/13/2015 11:00 PM, Alan Stern wrote:
On Sat, 13 Jun 2015, Lu Baolu wrote:
Commit 25cd2882e2fc (usb/xhci: Change how we indicate a host supports
Link PM.) removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
.
Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Acked-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v0-v5 change log:
Various changes in the commit description.
diff
On 05/26/2015 10:50 PM, Felipe Balbi wrote:
Hi,
On Mon, May 25, 2015 at 02:24:00PM +0800, Lu, Baolu wrote:
On 05/23/2015 12:08 AM, David Cohen wrote:
Hi,
On Fri, May 22, 2015 at 07:29:15PM +0800, Lu Baolu wrote:
Phy drivers and the ulpi interface providers depend on the
registeration
Phy drivers and the ulpi interface providers depend on the
registration of the ulpi bus. Ulpi registers the bus in
module_init(). This could cause unnecessary probe delays.
Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Acked-by: Heikki Krogerus
On 05/28/2015 12:53 AM, David Cohen wrote:
Hi,
On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote:
On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
Phy drivers and the ulpi interface providers depend on the
registration of the ulpi bus. Ulpi registers the bus
On 05/22/2015 11:11 AM, David Cohen wrote:
On Thu, May 21, 2015 at 08:09:54PM -0700, David Cohen wrote:
Hi,
On Fri, May 22, 2015 at 10:07:05AM +0800, Lu Baolu wrote:
Many drivers and modules depend on ULPI bus registeration to
register ULPI interfaces and drivers. It's more appropriate
On 05/22/2015 02:46 PM, Lu, Baolu wrote:
On 05/22/2015 11:11 AM, David Cohen wrote:
On Thu, May 21, 2015 at 08:09:54PM -0700, David Cohen wrote:
Hi,
On Fri, May 22, 2015 at 10:07:05AM +0800, Lu Baolu wrote:
Many drivers and modules depend on ULPI bus registeration to
register ULPI
On 05/23/2015 12:08 AM, David Cohen wrote:
Hi,
On Fri, May 22, 2015 at 07:29:15PM +0800, Lu Baolu wrote:
Phy drivers and the ulpi interface providers depend on the
registeration of the ulpi bus. Ulpi registers the bus in
module_init(). This could result in a load order issue, i.e.
It's
Hi Heikki, Sasha and others,
Please ignore this patch. I should not squash these two patches into one and
sign it off behalf of other people. I apologize for this and I'm sorry
if this lets
you feel affronted.
Thanks,
Baolu
On 05/21/2015 04:57 PM, Lu Baolu wrote:
ULPI registers its bus
of kernel panic by putting ulpi_init in
subsys_initcall().
Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common
issue by putting ulpi_init
in subsys_initcall().
Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
On 10/29/2015 08:51 PM, Sergei Shtylyov wrote:
Hello.
On 10/29/2015 5:46 AM, Lu Baolu wrote:
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint is busy with
processing TRBs. This is not correct since dequeue pointer
field
audio
noise when playing sound with USB headset connected to host
controllers which support CFC (one of xhci 1.1 features).
This patch should exist in stable kernel since v4.3.
Reported-and-tested-by: YD Tseng <yd_ts...@asmedia.com.tw>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
On 10/29/2015 10:08 PM, Mathias Nyman wrote:
On 29.10.2015 14:58, Lu, Baolu wrote:
On 10/29/2015 08:51 PM, Sergei Shtylyov wrote:
Hello.
On 10/29/2015 5:46 AM, Lu Baolu wrote:
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint
audio
noise when playing sound with USB headset connected to host
controllers which support CFC (one of xhci 1.1 features).
This patch should exist in stable kernel since v4.3.
Reported-and-tested-by: YD Tseng <yd_ts...@asmedia.com.tw>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Add Documentation/usb/xhci-dbc.txt. This document includes
development status and usage guide for USB3 debug port.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/usb/xhci-dbc.txt | 325 +
MAINTAINERS
between the
debug host and target.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
MAINTAINERS | 7 +
arch/x86/Kconfig.debug | 12 +
drivers/usb/early/Makefile | 1 +
drivers/usb/early/xhci-dbc.c | 787 +++
include/lin
have done in
drivers/usb/early/ehci-dbgp.c.
Patch 11 is a minor change to usb_debug module. This change is required to
bind usb_debug with the USB3 debug device.
Patch 12 is the design document and user guide.
Lu Baolu (12):
usb: xhci: expose xhci extended capabilities via debugfs
x86: fixmap
1 - 100 of 1892 matches
Mail list logo
