ci_cleanup_command_queue()
>
> We are calling it without locking, but we need to lock for accessing list.
Yeah. I can make the patch.
Best regards,
Lu Baolu
to
>> CMD_RING_STATE_RUNNING so ring will really restart in the interrupt
>> handler.
> Just for record (no chance to make patch I myself for now, sorry), while
> checking locking slightly, I noticed unrelated missing locking.
>
> xhci_cleanup_command_queue()
>
> We are calling it without locking, but we need to lock for accessing list.
Yeah. I can make the patch.
Best regards,
Lu Baolu
Hi,
On 12/21/2016 08:48 PM, Mathias Nyman wrote:
> On 21.12.2016 08:17, Lu Baolu wrote:
>> Hi Mathias,
>>
>> I have some comments for the implementation of xhci_abort_cmd_ring() below.
>>
>> On 12/20/2016 11:13 PM, Mathias Nyman wrote:
>>&
Hi,
On 12/21/2016 08:48 PM, Mathias Nyman wrote:
> On 21.12.2016 08:17, Lu Baolu wrote:
>> Hi Mathias,
>>
>> I have some comments for the implementation of xhci_abort_cmd_ring() below.
>>
>> On 12/20/2016 11:13 PM, Mathias Nyman wrote:
>>&
Hi,
On 12/21/2016 08:57 PM, Mathias Nyman wrote:
> On 21.12.2016 08:57, Lu Baolu wrote:
>> Hi Mathias,
>>
>> I have some comments for the implementation of
>> xhci_handle_command_timeout() as well.
>>
>> On 12/20/2016 11:13 PM, Mathias Nyman wrote:
>
Hi,
On 12/21/2016 08:57 PM, Mathias Nyman wrote:
> On 21.12.2016 08:57, Lu Baolu wrote:
>> Hi Mathias,
>>
>> I have some comments for the implementation of
>> xhci_handle_command_timeout() as well.
>>
>> On 12/20/2016 11:13 PM, Mathias Nyman wrote:
>
ved up to line 1295.
1323
1324 /* command timeout on stopped ring, ring can't be aborted */
1325 xhci_dbg(xhci, "Command timeout on stopped ring\n");
1326 xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
1327 spin_unlock_irqrestore(>lock, flags);
This part of code is tricky. I have no idea about in which case should this
code be executed? Anyway, we shouldn't call xhci_handle_stopped_cmd_ring()
here, right?
1328 return;
1329 }
Best regards,
Lu Baolu
ved up to line 1295.
1323
1324 /* command timeout on stopped ring, ring can't be aborted */
1325 xhci_dbg(xhci, "Command timeout on stopped ring\n");
1326 xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
1327 spin_unlock_irqrestore(>lock, flags);
This part of code is tricky. I have no idea about in which case should this
code be executed? Anyway, we shouldn't call xhci_handle_stopped_cmd_ring()
here, right?
1328 return;
1329 }
Best regards,
Lu Baolu
} else {
370 unsigned long flags;
371
372 spin_lock_irqsave(>lock, flags);
373 xhci_handle_stopped_cmd_ring(xhci,
xhci_next_queued_cmd(xhci));
374 spin_unlock_irqrestore(>lock, flags);
375 }
376 return 0;
377 }
Best regards,
Lu Baolu
} else {
370 unsigned long flags;
371
372 spin_lock_irqsave(>lock, flags);
373 xhci_handle_stopped_cmd_ring(xhci,
xhci_next_queued_cmd(xhci));
374 spin_unlock_irqrestore(>lock, flags);
375 }
376 return 0;
377 }
Best regards,
Lu Baolu
Hi,
On 12/20/2016 02:46 PM, Baolin Wang wrote:
> On 20 December 2016 at 14:39, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Hi,
>>
>> On 12/20/2016 02:06 PM, Baolin Wang wrote:
>>> Hi,
>>>
>>> On 20 December 2016 at 12:29, Lu B
Hi,
On 12/20/2016 02:46 PM, Baolin Wang wrote:
> On 20 December 2016 at 14:39, Lu Baolu wrote:
>> Hi,
>>
>> On 12/20/2016 02:06 PM, Baolin Wang wrote:
>>> Hi,
>>>
>>> On 20 December 2016 at 12:29, Lu Baolu wrote:
>>>> Hi Ma
Hi,
On 12/20/2016 02:06 PM, Baolin Wang wrote:
> Hi,
>
> On 20 December 2016 at 12:29, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Hi Mathias,
>>
>> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>>> On 19.12.2016 13:34, Baolin Wang wrote:
>>>&
Hi,
On 12/20/2016 02:06 PM, Baolin Wang wrote:
> Hi,
>
> On 20 December 2016 at 12:29, Lu Baolu wrote:
>> Hi Mathias,
>>
>> On 12/19/2016 08:13 PM, Mathias Nyman wrote:
>>> On 19.12.2016 13:34, Baolin Wang wrote:
>>>> Hi Mathias,
>>>>
mand queue becomes
more and more complicated and hard for maintain. I am also seeing
another case where a command may lose the chance to be tracked by
the watch dog timer.
Say,
queue_command(the only command in queue)
- completion irq fires--- timer times out at same time--
- another command enqueue--
- lock(xhci_lock ) - spin_on(xhci_lock)
- spin_on(xhci_lock)
- del_timer() fail
- free the command and
set current_cmd to NULL
- unlock(xhci_lock)
- lock(xhci_lock)
- queue_command()(timer will
not rescheduled since the timer
is pending)
- lock(xhci_lock)
- no current command
- return
As the result, the later command isn't under track of the watch dog.
If hardware fails to response to this command, kernel will hang in
the thread which is waiting for the completion of the command.
I can write a patch to fix this and cc stable kernel as well. For long
term, in order to make it simple and easy to maintain, how about
allocating a watch dog timer for each command? It could be part
of the command structure and be managed just like the life cycle
of a command structure.
I can write a patch for review and discussion, if you think this
change is possible.
Best regards,
Lu Baolu
ase
> it seems that patch 2/2 can be replaced by a single line change:
>
> if (!xhci->current_cmd || timer_pending(>cmd_timer))
>
> Right?
>
> -Mathias
>
It seems that the watch dog algorithm for command queue becomes
more and more complicated and hard for maintain. I am also seeing
another case where a command may lose the chance to be tracked by
the watch dog timer.
Say,
queue_command(the only command in queue)
- completion irq fires--- timer times out at same time--
- another command enqueue--
- lock(xhci_lock ) - spin_on(xhci_lock)
- spin_on(xhci_lock)
- del_timer() fail
- free the command and
set current_cmd to NULL
- unlock(xhci_lock)
- lock(xhci_lock)
- queue_command()(timer will
not rescheduled since the timer
is pending)
- lock(xhci_lock)
- no current command
- return
As the result, the later command isn't under track of the watch dog.
If hardware fails to response to this command, kernel will hang in
the thread which is waiting for the completion of the command.
I can write a patch to fix this and cc stable kernel as well. For long
term, in order to make it simple and easy to maintain, how about
allocating a watch dog timer for each command? It could be part
of the command structure and be managed just like the life cycle
of a command structure.
I can write a patch for review and discussion, if you think this
change is possible.
Best regards,
Lu Baolu
Hi,
On 12/02/2016 09:39 PM, Mathias Nyman wrote:
> On 02.12.2016 04:29, Lu Baolu wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed after t
Hi,
On 12/02/2016 09:39 PM, Mathias Nyman wrote:
> On 02.12.2016 04:29, Lu Baolu wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed after t
Hi,
On 12/02/2016 12:18 PM, Baolin Wang wrote:
> On 2 December 2016 at 10:29, Lu Baolu <baolu...@linux.intel.com> wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when
Hi,
On 12/02/2016 12:18 PM, Baolin Wang wrote:
> On 2 December 2016 at 10:29, Lu Baolu wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed af
_cmd.
Cc: <sta...@vger.kernel.org> # v3.16+
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bdf6b13..13e05f6 10
# v3.16+
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-ring.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bdf6b13..13e05f6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/h
Hi,
On 12/01/2016 04:03 PM, Baolin Wang wrote:
> On 1 December 2016 at 15:44, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Hi,
>>
>> On 12/01/2016 03:35 PM, Baolin Wang wrote:
>>> On 1 December 2016 at 14:35, Lu Baolu <baolu...@linux.intel.com> wrote:
Hi,
On 12/01/2016 04:03 PM, Baolin Wang wrote:
> On 1 December 2016 at 15:44, Lu Baolu wrote:
>> Hi,
>>
>> On 12/01/2016 03:35 PM, Baolin Wang wrote:
>>> On 1 December 2016 at 14:35, Lu Baolu wrote:
>>>> Hi,
>>>>
>>>> On 12/01/
Hi,
On 12/01/2016 03:35 PM, Baolin Wang wrote:
> On 1 December 2016 at 14:35, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Hi,
>>
>> On 12/01/2016 02:04 PM, Baolin Wang wrote:
>>> Hi Baolu,
>>>
>>> On 1 December 2016 at 13:45, Lu Baolu <
Hi,
On 12/01/2016 03:35 PM, Baolin Wang wrote:
> On 1 December 2016 at 14:35, Lu Baolu wrote:
>> Hi,
>>
>> On 12/01/2016 02:04 PM, Baolin Wang wrote:
>>> Hi Baolu,
>>>
>>> On 1 December 2016 at 13:45, Lu Baolu wrote:
>>>
Hi,
On 12/01/2016 02:04 PM, Baolin Wang wrote:
> Hi Baolu,
>
> On 1 December 2016 at 13:45, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Hi,
>>
>> On 11/30/2016 05:02 PM, Baolin Wang wrote:
>>> If the hardware never responds to the stop endpoint com
Hi,
On 12/01/2016 02:04 PM, Baolin Wang wrote:
> Hi Baolu,
>
> On 1 December 2016 at 13:45, Lu Baolu wrote:
>> Hi,
>>
>> On 11/30/2016 05:02 PM, Baolin Wang wrote:
>>> If the hardware never responds to the stop endpoint command, the
>>> URBs will
e timer is the tail end of the last
- * stop endpoint command, and the endpoint's command is still pending, we
assume
- * the host is dying.
Best regards,
Lu Baolu
>
> We also need to clean up the command queue before trying to halt the
> xHCI host in xhci_stop_endpoint_command_timeout() function.
>
> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
e timer is the tail end of the last
- * stop endpoint command, and the endpoint's command is still pending, we
assume
- * the host is dying.
Best regards,
Lu Baolu
>
> We also need to clean up the command queue before trying to halt the
> xHCI host in xhci_stop_endpoint_command_timeout() function.
>
> Signed-off-by: Baolin Wang
ory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/e
ory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Lu Baolu
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kern
document.
v1->v2:
- Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
- Free resources when hardware not used any more.
- Refine the user guide document.
Lu Baolu (4):
usb: dbc: early driver for xhci debug capability
x86: add support for earlypri
.ny...@linux.intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
arch/x86/Kconfig.debug| 14 +
drivers/usb/Kconfig |3 +
drivers/usb/Makefile |2 +-
drivers/usb/early/Makefile|1 +
drivers/usb/early/xhci-d
Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/usb/usb3-debug-port.rst | 95 +++
1 file changed, 95 inse
document.
v1->v2:
- Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
- Free resources when hardware not used any more.
- Refine the user guide document.
Lu Baolu (4):
usb: dbc: early driver for xhci debug capability
x86: add support for earlypri
de 100644
index 000..5ac4223
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,1068 @@
+/**
+ * xhci-dbc.c - xHCI debug capability early driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it a
Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu
---
Documentation/usb/usb3-debug-port.rst | 95 +++
1 file changed, 95 insertions(+)
create mode 100644
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Acked-by: Johan Hovold <jo...@kernel.org>
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --g
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial
Hi Peter,
On 11/11/2016 08:28 PM, Peter Zijlstra wrote:
> On Fri, Nov 11, 2016 at 12:33:29PM +0800, Lu Baolu wrote:
>
>> Things become complicated when it comes to USB debug port.
>> But it's still addressable.
>>
>> At this time, we can do it like this.
>>
Hi Peter,
On 11/11/2016 08:28 PM, Peter Zijlstra wrote:
> On Fri, Nov 11, 2016 at 12:33:29PM +0800, Lu Baolu wrote:
>
>> Things become complicated when it comes to USB debug port.
>> But it's still addressable.
>>
>> At this time, we can do it like this.
>>
Hi Peter,
On 11/10/2016 07:44 PM, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote:
>> On Thu, 10 Nov 2016, Lu Baolu wrote:
>>> This seems to be a common issue for all early printk drivers.
>> No. The other early printk drivers
Hi Peter,
On 11/10/2016 07:44 PM, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote:
>> On Thu, 10 Nov 2016, Lu Baolu wrote:
>>> This seems to be a common issue for all early printk drivers.
>> No. The other early printk drivers
Hi,
On 11/11/2016 10:24 AM, Lu Baolu wrote:
>> The only thing you can do to make this work is to prevent printing in NMI
>> > context:
>> >
>> > write()
>> > {
>> >if (in_nmi())
>> >return;
>> >
>
Hi,
On 11/11/2016 10:24 AM, Lu Baolu wrote:
>> The only thing you can do to make this work is to prevent printing in NMI
>> > context:
>> >
>> > write()
>> > {
>> >if (in_nmi())
>> >return;
>> >
>
Hi,
On 11/10/2016 04:56 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Lu Baolu wrote:
>> On 11/09/2016 05:37 PM, Thomas Gleixner wrote:
>>> On Tue, 1 Nov 2016, Lu Baolu wrote:
>>>> +static void early_xdbc_write(struct console *con, const char *str, u32 n)
Hi,
On 11/10/2016 04:56 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Lu Baolu wrote:
>> On 11/09/2016 05:37 PM, Thomas Gleixner wrote:
>>> On Tue, 1 Nov 2016, Lu Baolu wrote:
>>>> +static void early_xdbc_write(struct console *con, const char *str, u32 n)
onding USB device stays in unresponsive state.
This patch enhances xHCI driver on this by printing out
the malformed TRB and clearing the endpoint Error state.
Tested-by: Wang Wendy <wendy.w...@intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Change log:
v1->
onding USB device stays in unresponsive state.
This patch enhances xHCI driver on this by printing out
the malformed TRB and clearing the endpoint Error state.
Tested-by: Wang Wendy
Signed-off-by: Lu Baolu
---
Change log:
v1->v2:
- Correct the email of Tested-by.
drivers/usb/host/xhc
Hi,
On 11/11/2016 09:03 AM, Lu Baolu wrote:
> When xHCI host sees a malformed TRB in a transfer ring,
> it will generate a transfer event with the completion
> code set to COMP_TRB_ERR (5), and sets the endpoint
> state in output endpoint context to EP_STATE_ERROR.
> The endpoi
Hi,
On 11/11/2016 09:03 AM, Lu Baolu wrote:
> When xHCI host sees a malformed TRB in a transfer ring,
> it will generate a transfer event with the completion
> code set to COMP_TRB_ERR (5), and sets the endpoint
> state in output endpoint context to EP_STATE_ERROR.
> The endpoi
onding USB device stays in unresponsive state.
This patch enhances xHCI driver on this by printing out
the malformed TRB and clearing the endpoint Error state.
Tested-by: Wang Wendy <wendy.w...@inte.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb
onding USB device stays in unresponsive state.
This patch enhances xHCI driver on this by printing out
the malformed TRB and clearing the endpoint Error state.
Tested-by: Wang Wendy
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-ring.c | 35 +++
drivers/usb/h
Hi,
On 11/09/2016 05:37 PM, Thomas Gleixner wrote:
> On Tue, 1 Nov 2016, Lu Baolu wrote:
>> +static void early_xdbc_write(struct console *con, const char *str, u32 n)
>> +{
>> +int chunk, ret;
>> +static char buf[XDBC_MAX_PACKET];
>> +int use_cr = 0
Hi,
On 11/09/2016 05:37 PM, Thomas Gleixner wrote:
> On Tue, 1 Nov 2016, Lu Baolu wrote:
>> +static void early_xdbc_write(struct console *con, const char *str, u32 n)
>> +{
>> +int chunk, ret;
>> +static char buf[XDBC_MAX_PACKET];
>> +int use_cr = 0
Hi,
On 11/09/2016 05:23 PM, Thomas Gleixner wrote:
> On Tue, 1 Nov 2016, Lu Baolu wrote:
>> +static int __init xdbc_init(void)
>> +{
> ...
>> +base = ioremap_nocache(xdbc.xhci_start, xdbc.xhci_length);
>> +if (!base) {
>> +xdbc_tra
Hi,
On 11/09/2016 05:23 PM, Thomas Gleixner wrote:
> On Tue, 1 Nov 2016, Lu Baolu wrote:
>> +static int __init xdbc_init(void)
>> +{
> ...
>> +base = ioremap_nocache(xdbc.xhci_start, xdbc.xhci_length);
>> +if (!base) {
>> +xdbc_tra
Hi,
On 11/03/2016 07:36 PM, Mathias Nyman wrote:
> On 03.11.2016 12:22, Sergei Shtylyov wrote:
>> On 11/3/2016 9:48 AM, Lu Baolu wrote:
>>
>>> cmd_completion in struct xhci_virt_device is legacy. With command
>>> strutcture and command queue i
Hi,
On 11/03/2016 07:36 PM, Mathias Nyman wrote:
> On 03.11.2016 12:22, Sergei Shtylyov wrote:
>> On 11/3/2016 9:48 AM, Lu Baolu wrote:
>>
>>> cmd_completion in struct xhci_virt_device is legacy. With command
>>> strutcture and command queue i
cmd_completion in struct xhci_virt_device is legacy. With command
strutcture and command queue introduced in xhci, cmd_completion is
not used any more. This patch removes it.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci.h
cmd_completion in struct xhci_virt_device is legacy. With command
strutcture and command queue introduced in xhci, cmd_completion is
not used any more. This patch removes it.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci.h | 1 -
2 files changed, 2
ver. It is time to get rid of addr_dev
and use the completion in the command structure instead.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci.c | 18 ++
drivers/usb/host/xhci.h | 1 -
3 files changed, 10 i
ver. It is time to get rid of addr_dev
and use the completion in the command structure instead.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci.c | 18 ++
drivers/usb/host/xhci.h | 1 -
3 files changed, 10 insertions(+), 10 deletions(-)
d
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Acked-by: Johan Hovold <jo...@kernel.org>
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --g
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial
.ny...@linux.intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
arch/x86/Kconfig.debug| 14 +
drivers/usb/Kconfig |3 +
drivers/usb/Makefile |2 +-
drivers/usb/early/Makefile|1 +
drivers/usb/early/xhci-d
Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/usb/usb3-debug-port.rst | 95 +++
1 file changed, 95 inse
Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu
---
Documentation/usb/usb3-debug-port.rst | 95 +++
1 file changed, 95 insertions(+)
create mode 100644
de 100644
index 000..728a1a0
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,1050 @@
+/**
+ * xhci-dbc.c - xHCI debug capability early driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it a
rly_start() and
xdbc_handle_external_reset().
- Free resources when hardware not used any more.
- Refine the user guide document.
Lu Baolu (4):
usb: dbc: early driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug port
usb: serial: usb_debug: add support for dbc deb
rly_start() and
xdbc_handle_external_reset().
- Free resources when hardware not used any more.
- Refine the user guide document.
Lu Baolu (4):
usb: dbc: early driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug port
usb: serial: usb_debug: add support for dbc deb
ory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/e
ory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Lu Baolu
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kern
in xhci_handle_event(). Otherwise, those errors are just
ignored silently.
This patch cleans up this by replacing the setting of error_bitmask
with the kernel print functions, so that users can easily check and
report the errors happened in xhci_handle_event().
Signed-off-by: Lu Baolu <ba
in xhci_handle_event(). Otherwise, those errors are just
ignored silently.
This patch cleans up this by replacing the setting of error_bitmask
with the kernel print functions, so that users can easily check and
report the errors happened in xhci_handle_event().
Signed-off-by: Lu Baolu
---
Changelog
Hi,
On 10/20/2016 04:30 PM, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Hi Jani,
>>
>> On 10/19/2016 03:48 PM, Jani Nikula wrote:
>>> On Wed, 19 Oct 2016, Lu Baolu <baolu...@linux.intel.com> wrote:
>
Hi,
On 10/20/2016 04:30 PM, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Lu Baolu wrote:
>> Hi Jani,
>>
>> On 10/19/2016 03:48 PM, Jani Nikula wrote:
>>> On Wed, 19 Oct 2016, Lu Baolu wrote:
>>>> Add Documentation/usb/usb3-debug-port.txt. This document i
mostly work.
>
Thank you again.
Your comments make sense to me. I will remove the lock and work
queue usages in the new version.
Best regards,
Lu Baolu
mostly work.
>
Thank you again.
Your comments make sense to me. I will remove the lock and work
queue usages in the new version.
Best regards,
Lu Baolu
Hi Peter,
Thanks for your comments.
On 10/19/2016 09:09 PM, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 08:18:22AM +0800, Lu Baolu wrote:
>> +++ b/drivers/usb/early/xhci-dbc.c
>> +static int xdbc_bulk_write(const char *bytes, int size)
>> +{
>> +unsigned
Hi Peter,
Thanks for your comments.
On 10/19/2016 09:09 PM, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 08:18:22AM +0800, Lu Baolu wrote:
>> +++ b/drivers/usb/early/xhci-dbc.c
>> +static int xdbc_bulk_write(const char *bytes, int size)
>> +{
>> +unsigned
Hi Jani,
On 10/19/2016 03:48 PM, Jani Nikula wrote:
> On Wed, 19 Oct 2016, Lu Baolu <baolu...@linux.intel.com> wrote:
>> Add Documentation/usb/usb3-debug-port.txt. This document includes
>> the user guide for USB3 debug port.
> If you're adding completely new files,
Hi Jani,
On 10/19/2016 03:48 PM, Jani Nikula wrote:
> On Wed, 19 Oct 2016, Lu Baolu wrote:
>> Add Documentation/usb/usb3-debug-port.txt. This document includes
>> the user guide for USB3 debug port.
> If you're adding completely new files, please at least consi
Hi,
On 10/19/2016 02:52 PM, Mathias Nyman wrote:
> Hi
>
> On 19.10.2016 03:53, Lu Baolu wrote:
>> In xhci_handle_event(), when errors are detected, driver always sets
>> a bit in error_bitmask (one member of the xhci private driver data).
>> That means users have to re
Hi,
On 10/19/2016 02:52 PM, Mathias Nyman wrote:
> Hi
>
> On 19.10.2016 03:53, Lu Baolu wrote:
>> In xhci_handle_event(), when errors are detected, driver always sets
>> a bit in error_bitmask (one member of the xhci private driver data).
>> That means users have to re
in xhci_handle_event(). Otherwise, those errors are just
ignored silently.
This patch cleans up this by replacing the setting of error_bitmask
with the kernel print functions, so that users can easily check and
report the errors happened in xhci_handle_event().
Signed-off-by: Lu Baolu <ba
in xhci_handle_event(). Otherwise, those errors are just
ignored silently.
This patch cleans up this by replacing the setting of error_bitmask
with the kernel print functions, so that users can easily check and
report the errors happened in xhci_handle_event().
Signed-off-by: Lu Baolu
---
drivers/usb
Add Documentation/usb/usb3-debug-port.txt. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/usb/usb3-debug-port.txt | 87 +++
1 file changed, 87 inse
Add Documentation/usb/usb3-debug-port.txt. This document includes
the user guide for USB3 debug port.
Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu
---
Documentation/usb/usb3-debug-port.txt | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
ory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/e
ory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Lu Baolu
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kern
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Acked-by: Johan Hovold <jo...@kernel.org>
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --g
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial
.ny...@linux.intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
arch/x86/Kconfig.debug| 14 +
drivers/usb/Kconfig |3 +
drivers/usb/Makefile |2 +-
drivers/usb/early/Makefile|1 +
drivers/usb/early/xhci-d
le mode 100644
index 000..939fff2
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,1097 @@
+/**
+ * xhci-dbc.c - xHCI debug capability early driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it a
;v2:
- Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
- Free resources when hardware not used any more.
- Refine the user guide document.
Lu Baolu (4):
usb: dbc: early driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug p
;v2:
- Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
- Free resources when hardware not used any more.
- Refine the user guide document.
Lu Baolu (4):
usb: dbc: early driver for xhci debug capability
x86: add support for earlyprintk via USB3 debug p
't usb_charger_exit() a better place?
> The usb_charger_exit() will issue usb_charger_unregister() and we need
> use the usb_charger structure in usb_charger_unregister() to
> unregister the usb charger.
>
This seems not to be a strong reason. :-)
You can unregister the charger first and then free the structure.
Just do the reverse operation of what you have done in the init
function.
Best regards,
Lu Baolu
't usb_charger_exit() a better place?
> The usb_charger_exit() will issue usb_charger_unregister() and we need
> use the usb_charger structure in usb_charger_unregister() to
> unregister the usb charger.
>
This seems not to be a strong reason. :-)
You can unregister the charger first and then free the structure.
Just do the reverse operation of what you have done in the init
function.
Best regards,
Lu Baolu
1001 - 1100 of 1892 matches
Mail list logo
