[PATCH v2 0/4] usb: xhci: Add debug capability support in xhci
Hi, This series is for xHCI debug capability (spec section 7.6.8) support in the xHCI driver. xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Best regards, Lu Baolu --- Change log: v1->v2: - Add a new patch to move u_serial.c from drivers/usb/gadget/function to drivers/usb/common/ and move u_serial.h to include/linux/usb/. Lu Baolu (4): usb: xhci: Make some static functions global usb: common: Move u_serial from gadget/function to usb/common usb: xhci: Add DbC support in xHCI driver usb: doc: Update document for USB3 debug port usage .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + Documentation/driver-api/usb/usb3-debug-port.rst | 68 + drivers/usb/Kconfig|3 + drivers/usb/Makefile |3 +- drivers/usb/common/Makefile|1 + drivers/usb/common/u_serial.c | 1604 +++ drivers/usb/gadget/Kconfig |3 - drivers/usb/gadget/function/Makefile |1 - drivers/usb/gadget/function/f_acm.c|4 +- drivers/usb/gadget/function/f_obex.c |4 +- drivers/usb/gadget/function/f_serial.c |3 +- drivers/usb/gadget/function/u_serial.c | 1606 drivers/usb/gadget/function/u_serial.h | 71 - drivers/usb/gadget/legacy/acm_ms.c |3 +- drivers/usb/gadget/legacy/cdc2.c |2 +- drivers/usb/gadget/legacy/dbgp.c |3 +- drivers/usb/gadget/legacy/multi.c |2 +- drivers/usb/gadget/legacy/nokia.c |2 +- drivers/usb/gadget/legacy/serial.c |3 +- drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1100 ++ drivers/usb/host/xhci-dbgcap.h | 194 +++ drivers/usb/host/xhci-mem.c| 94 +- drivers/usb/host/xhci-ring.c |4 +- drivers/usb/host/xhci-trace.h | 65 + drivers/usb/host/xhci.c| 10 + drivers/usb/host/xhci.h| 17 +- include/linux/usb/gadget.h | 52 + include/linux/usb/u_serial.h | 71 + 30 files changed, 3290 insertions(+), 1742 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/common/u_serial.c delete mode 100644 drivers/usb/gadget/function/u_serial.c delete mode 100644 drivers/usb/gadget/function/u_serial.h create mode 100644 drivers/usb/host/xhci-dbgcap.c create mode 100644 drivers/usb/host/xhci-dbgcap.h create mode 100644 include/linux/usb/u_serial.h -- 2.7.4
[PATCH v2 3/4] usb: xhci: Add DbC support in xHCI driver
xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Signed-off-by: Lu Baolu --- .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1100 drivers/usb/host/xhci-dbgcap.h | 194 drivers/usb/host/xhci-trace.h | 65 ++ drivers/usb/host/xhci.c| 10 + drivers/usb/host/xhci.h|1 + include/linux/usb/gadget.h | 52 + 9 files changed, 1461 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c create mode 100644 drivers/usb/host/xhci-dbgcap.h diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd new file mode 100644 index 000..0088aba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -0,0 +1,25 @@ +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc +Date: June 2017 +Contact: Lu Baolu +Description: + xHCI compatible USB host controllers (i.e. super-speed + USB3 controllers) are often implemented with the Debug + Capability (DbC). It can present a debug device which + is fully compliant with the USB framework and provides + the equivalent of a very high performance full-duplex + serial link for debug purpose. + + The DbC debug device shares a root port with xHCI host. + When the DbC is enabled, the root port will be assigned + to the Debug Capability. Otherwise, it will be assigned + to xHCI. + + Writing "enable" to this attribute will enable the DbC + functionality and the shared root port will be assigned + to the DbC device. Writing "disable" to this attribute + will disable the DbC functionality and the shared root + port will roll back to the xHCI. + + Reading this attribute gives the state of the DbC. It + can be one of the following states: disabled, enabled, + initialized, connected, configured and stalled. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fa5692d..968a196 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -27,6 +27,15 @@ config USB_XHCI_HCD module will be called xhci-hcd. if USB_XHCI_HCD +config USB_XHCI_DBGCAP + bool "xHCI support for debug capability" + depends on TTY + select USB_U_SERIAL + ---help--- + Say 'Y' to enable the support for the xHCI debug capability. Make + sure that your xHCI host supports the extended debug capability and + you want a TTY serial device based on the xHCI debug capability + before enabling this option. If unsure, say 'N'. config USB_XHCI_PCI tristate diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index cf2691f..4629d20 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -13,6 +13,11 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o xhci-hcd-y := xhci.o xhci-mem.o xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o xhci-hcd-y += xhci-trace.o + +ifneq ($(CONFIG_USB_XHCI_DBGCAP), ) + xhci-hcd-y +=
[PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common
The component u_serial provides a glue layer between TTY layer
and a USB gadget device needed to provide a basic serial port
functionality. Currently, u_serial sits under gadget/function
and depends on CONFIG_USB_GADGET to be compiled and used.
Most of the serial gadget devices are based on a UDC (USB device
controller) and implemented by making use of the Linux gadget
frameworks. But we are facing other implementions as well. One
example can be found with xHCI debug capability. The xHCI debug
capability implements a serial gadget with hardware and firmware,
and provides an interface similar with xHCI host for submitting
and reaping the transfer requests.
In order to make better use of u_serial when implementing xHCI
debug capability in xHCI driver, this patch moves u_serial.c
from gadget/function to usb/common, and moves u_serial.h from
gadget/function to include/linux/usb.
Signed-off-by: Lu Baolu
---
drivers/usb/Kconfig|3 +
drivers/usb/Makefile |3 +-
drivers/usb/common/Makefile|1 +
drivers/usb/common/u_serial.c | 1604 +++
drivers/usb/gadget/Kconfig |3 -
drivers/usb/gadget/function/Makefile |1 -
drivers/usb/gadget/function/f_acm.c|4 +-
drivers/usb/gadget/function/f_obex.c |4 +-
drivers/usb/gadget/function/f_serial.c |3 +-
drivers/usb/gadget/function/u_serial.c | 1606
drivers/usb/gadget/function/u_serial.h | 71 --
drivers/usb/gadget/legacy/acm_ms.c |3 +-
drivers/usb/gadget/legacy/cdc2.c |2 +-
drivers/usb/gadget/legacy/dbgp.c |3 +-
drivers/usb/gadget/legacy/multi.c |2 +-
drivers/usb/gadget/legacy/nokia.c |2 +-
drivers/usb/gadget/legacy/serial.c |3 +-
include/linux/usb/u_serial.h | 71 ++
18 files changed, 1689 insertions(+), 1700 deletions(-)
create mode 100644 drivers/usb/common/u_serial.c
delete mode 100644 drivers/usb/gadget/function/u_serial.c
delete mode 100644 drivers/usb/gadget/function/u_serial.h
create mode 100644 include/linux/usb/u_serial.h
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 939a63b..c39aceb 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -35,6 +35,9 @@ config USB_COMMON
config USB_ARCH_HAS_HCD
def_bool y
+config USB_U_SERIAL
+ tristate
+
config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 9650b35..a3274aa 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -5,6 +5,7 @@
# Object files in subdirectories
obj-$(CONFIG_USB) += core/
+obj-$(CONFIG_USB_COMMON) += common/
obj-$(CONFIG_USB_SUPPORT) += phy/
obj-$(CONFIG_USB_DWC3) += dwc3/
@@ -59,8 +60,6 @@ obj-$(CONFIG_USB_CHIPIDEA)+= chipidea/
obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
obj-$(CONFIG_USB_GADGET) += gadget/
-obj-$(CONFIG_USB_COMMON) += common/
-
obj-$(CONFIG_USBIP_CORE) += usbip/
obj-$(CONFIG_TYPEC)+= typec/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 6bbb3ec..dff720b 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -8,3 +8,4 @@ usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
diff --git a/drivers/usb/common/u_serial.c b/drivers/usb/common/u_serial.c
new file mode 100644
index 000..da09602
--- /dev/null
+++ b/drivers/usb/common/u_serial.c
@@ -0,0 +1,1604 @@
+/*
+ * u_serial.c - utilities for USB gadget "serial port"/TTY support
+ *
+ * Copyright (C) 2003 Al Borchers (alborch...@steinerpoint.com)
+ * Copyright (C) 2008 David Brownell
+ * Copyright (C) 2008 by Nokia Corporation
+ *
+ * This code also borrows from usbserial.c, which is
+ * Copyright (C) 1999 - 2002 Greg Kroah-Hartman (g...@kroah.com)
+ * Copyright (C) 2000 Peter Berger (pber...@brimson.com)
+ * Copyright (C) 2000 Al Borchers (alborch...@steinerpoint.com)
+ *
+ * This software is distributed under the terms of the GNU General
+ * Public License ("GPL") as published by the Free Software Foundation,
+ * either version 2 of that License or (at your option) any later version.
+ */
+
+/* #define VERBOSE_DEBUG */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This component encapsulates the TTY layer glue needed to provide basic
+ * "serial port" functionality through the USB gadget stack. Each such
+ * port is exposed through a /dev/ttyGS* node.
+ *
+ * After this module has been loaded, the individual TTY port can be requested
+ * (gserial_alloc_line()) and it will stay available until they are removed
+ * (gserial
[PATCH v2 0/4] usb: xhci: Add debug capability support in xhci
Hi, This series is for xHCI debug capability (spec section 7.6.8) support in the xHCI driver. xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Best regards, Lu Baolu --- Change log: v1->v2: - Add a new patch to move u_serial.c from drivers/usb/gadget/function to drivers/usb/common/ and move u_serial.h to include/linux/usb/. Lu Baolu (4): usb: xhci: Make some static functions global usb: common: Move u_serial from gadget/function to usb/common usb: xhci: Add DbC support in xHCI driver usb: doc: Update document for USB3 debug port usage .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + Documentation/driver-api/usb/usb3-debug-port.rst | 68 + drivers/usb/Kconfig|3 + drivers/usb/Makefile |3 +- drivers/usb/common/Makefile|1 + drivers/usb/common/u_serial.c | 1604 +++ drivers/usb/gadget/Kconfig |3 - drivers/usb/gadget/function/Makefile |1 - drivers/usb/gadget/function/f_acm.c|4 +- drivers/usb/gadget/function/f_obex.c |4 +- drivers/usb/gadget/function/f_serial.c |3 +- drivers/usb/gadget/function/u_serial.c | 1606 drivers/usb/gadget/function/u_serial.h | 71 - drivers/usb/gadget/legacy/acm_ms.c |3 +- drivers/usb/gadget/legacy/cdc2.c |2 +- drivers/usb/gadget/legacy/dbgp.c |3 +- drivers/usb/gadget/legacy/multi.c |2 +- drivers/usb/gadget/legacy/nokia.c |2 +- drivers/usb/gadget/legacy/serial.c |3 +- drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1100 ++ drivers/usb/host/xhci-dbgcap.h | 194 +++ drivers/usb/host/xhci-mem.c| 94 +- drivers/usb/host/xhci-ring.c |4 +- drivers/usb/host/xhci-trace.h | 65 + drivers/usb/host/xhci.c| 10 + drivers/usb/host/xhci.h| 17 +- include/linux/usb/gadget.h | 52 + include/linux/usb/u_serial.h | 71 + 30 files changed, 3290 insertions(+), 1742 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/common/u_serial.c delete mode 100644 drivers/usb/gadget/function/u_serial.c delete mode 100644 drivers/usb/gadget/function/u_serial.h create mode 100644 drivers/usb/host/xhci-dbgcap.c create mode 100644 drivers/usb/host/xhci-dbgcap.h create mode 100644 include/linux/usb/u_serial.h -- 2.7.4
[PATCH v2 1/1] usb: xhci: Add debugfs interface for xHCI driver
This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.
The file hierarchy looks like this.
[root of debugfs]
|__usb
|[e,u,o]hci <-[root for other HCIs]
|xhci <---[root for xHCI]
|__:00:14.0 <--[xHCI host name]
|reg-cap<[capability registers]
|reg-op <---[operational registers]
|reg-runtime<---[runtime registers]
|reg-ext-#cap_name <[extended capability regs]
|command-ring <---[root for command ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|event-ring <-[root for event ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|devices<[root for devices]
|__#slot_id <---[root for a device]
|name <-[device name]
|slot-context <[slot context]
|ep-context <---[endpoint contexts]
|ep#ep_index<[root for an endpoint]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|______trbs <---[ring trbs]
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
Change log:
v1->v2:
- No need to check return valuse of debugfs interfaces.
- Remove file entries when adding endpoint failed.
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-debugfs.c | 526
drivers/usb/host/xhci-debugfs.h | 137 +++
drivers/usb/host/xhci-mem.c | 5 +-
drivers/usb/host/xhci.c | 23 +-
drivers/usb/host/xhci.h | 9 +
6 files changed, 700 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/host/xhci-debugfs.c
create mode 100644 drivers/usb/host/xhci-debugfs.h
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..b2a7f05 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -25,6 +25,10 @@ ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
endif
+ifneq ($(CONFIG_DEBUG_FS),)
+ xhci-hcd-y += xhci-debugfs.o
+endif
+
obj-$(CONFIG_USB_WHCI_HCD) += whci/
obj-$(CONFIG_USB_PCI) += pci-quirks.o
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
new file mode 100644
index 000..6772ee9
--- /dev/null
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -0,0 +1,526 @@
+/*
+ * xhci-debugfs.c - xHCI debugfs interface
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Author: Lu Baolu <baolu...@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include "xhci.h"
+#include "xhci-debugfs.h"
+
+static const struct debugfs_reg32 xhci_cap_regs[] = {
+ dump_register(CAPLENGTH),
+ dump_register(HCSPARAMS1),
+ dump_register(HCSPARAMS2),
+ dump_register(HCSPARAMS3),
+ dump_register(HCCPARAMS1),
+ dump_register(DOORBELLOFF),
+ dump_register(RUNTIMEOFF),
+ dump_register(HCCPARAMS2),
+};
+
+static const struct debugfs_reg32 xhci_op_regs[] = {
+ dump_register(USBCMD),
+ dump_register(USBSTS),
+ dump_register(PAGESIZE),
+ dump_register(DNCTRL),
+ dump_register(CRCR),
+ dump_register(DCBAAP_LOW),
+ dump_register(DCBAAP_HIGH),
+ dump_register(CONFIG),
+};
+
+static const struct debugfs_reg32 xhci_runtime_regs[] = {
+ dump_register(MFINDEX),
+ dump_register(IR0_IMAN),
+ dump_register(IR0_IMOD),
+ dump_register(IR0_ERSTSZ),
+ dump_register(IR0_ERSTBA_LOW),
+ dump_register(IR0_ERSTBA_HIGH),
+ dump_register(IR0_ERDP_LOW),
+ dump_register(IR0_ERDP_HIGH),
+};
+
+static const struct debugfs_reg32 xhci_extcap_legsup[]
[PATCH v2 1/1] usb: xhci: Add debugfs interface for xHCI driver
This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.
The file hierarchy looks like this.
[root of debugfs]
|__usb
|[e,u,o]hci <-[root for other HCIs]
|xhci <---[root for xHCI]
|__:00:14.0 <--[xHCI host name]
|reg-cap<[capability registers]
|reg-op <---[operational registers]
|reg-runtime<---[runtime registers]
|reg-ext-#cap_name <[extended capability regs]
|command-ring <---[root for command ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|event-ring <-[root for event ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|devices<[root for devices]
|__#slot_id <---[root for a device]
|name <-[device name]
|slot-context <[slot context]
|ep-context <---[endpoint contexts]
|ep#ep_index<[root for an endpoint]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|______trbs <---[ring trbs]
Signed-off-by: Lu Baolu
---
Change log:
v1->v2:
- No need to check return valuse of debugfs interfaces.
- Remove file entries when adding endpoint failed.
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-debugfs.c | 526
drivers/usb/host/xhci-debugfs.h | 137 +++
drivers/usb/host/xhci-mem.c | 5 +-
drivers/usb/host/xhci.c | 23 +-
drivers/usb/host/xhci.h | 9 +
6 files changed, 700 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/host/xhci-debugfs.c
create mode 100644 drivers/usb/host/xhci-debugfs.h
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..b2a7f05 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -25,6 +25,10 @@ ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
endif
+ifneq ($(CONFIG_DEBUG_FS),)
+ xhci-hcd-y += xhci-debugfs.o
+endif
+
obj-$(CONFIG_USB_WHCI_HCD) += whci/
obj-$(CONFIG_USB_PCI) += pci-quirks.o
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
new file mode 100644
index 000..6772ee9
--- /dev/null
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -0,0 +1,526 @@
+/*
+ * xhci-debugfs.c - xHCI debugfs interface
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include "xhci.h"
+#include "xhci-debugfs.h"
+
+static const struct debugfs_reg32 xhci_cap_regs[] = {
+ dump_register(CAPLENGTH),
+ dump_register(HCSPARAMS1),
+ dump_register(HCSPARAMS2),
+ dump_register(HCSPARAMS3),
+ dump_register(HCCPARAMS1),
+ dump_register(DOORBELLOFF),
+ dump_register(RUNTIMEOFF),
+ dump_register(HCCPARAMS2),
+};
+
+static const struct debugfs_reg32 xhci_op_regs[] = {
+ dump_register(USBCMD),
+ dump_register(USBSTS),
+ dump_register(PAGESIZE),
+ dump_register(DNCTRL),
+ dump_register(CRCR),
+ dump_register(DCBAAP_LOW),
+ dump_register(DCBAAP_HIGH),
+ dump_register(CONFIG),
+};
+
+static const struct debugfs_reg32 xhci_runtime_regs[] = {
+ dump_register(MFINDEX),
+ dump_register(IR0_IMAN),
+ dump_register(IR0_IMOD),
+ dump_register(IR0_ERSTSZ),
+ dump_register(IR0_ERSTBA_LOW),
+ dump_register(IR0_ERSTBA_HIGH),
+ dump_register(IR0_ERDP_LOW),
+ dump_register(IR0_ERDP_HIGH),
+};
+
+static const struct debugfs_reg32 xhci_extcap_legsup[] = {
+ dump_register(EXTCAP_USBLEGSUP),
+
Re: [PATCH 1/1] usb: xhci: Add debugfs interface for xHCI driver
Hi Greg,
On 07/29/2017 09:34 PM, Greg KH wrote:
> On Sat, Jul 29, 2017 at 04:18:03PM +0800, Lu Baolu wrote:
>> +static void xhci_debugfs_create_files(struct xhci_hcd *xhci,
>> + struct xhci_file_map *files,
>> + size_t nentries, void *data,
>> + struct dentry *parent,
>> + const struct file_operations *fops)
>> +{
>> +int i;
>> +struct dentry *file;
>> +
>> +for (i = 0; i < nentries; i++) {
>> +file = debugfs_create_file(files[i].name, 0444,
>> + parent, data, fops);
>> +if (IS_ERR_OR_NULL(file))
>> +break;
> There's no need to ever check the return value of a debugfs_ function,
> there's nothing you can do here, just keep calling it :)
>
> And you will not get an error, you will only get NULL if there is an
> error, as the only error you would get is if debugfs was not enabled.
>
>> +static struct dentry *xhci_debugfs_create_ring_dir(struct xhci_hcd *xhci,
>> + struct xhci_ring *ring,
>> + const char *name,
>> + struct dentry *parent)
>> +{
>> +struct dentry *dir;
>> +
>> +dir = debugfs_create_dir(name, parent);
>> +if (IS_ERR_OR_NULL(dir))
>> +return NULL;
> Same here. Just keep going, you don't care about the return value, but
> you can use it safely no matter what.
>
>
> Same for other places in this patch as well.
Thanks for review. I will correct them in a v2 patch.
Best regards,
Lu Baolu
Re: [PATCH 1/1] usb: xhci: Add debugfs interface for xHCI driver
Hi Greg,
On 07/29/2017 09:34 PM, Greg KH wrote:
> On Sat, Jul 29, 2017 at 04:18:03PM +0800, Lu Baolu wrote:
>> +static void xhci_debugfs_create_files(struct xhci_hcd *xhci,
>> + struct xhci_file_map *files,
>> + size_t nentries, void *data,
>> + struct dentry *parent,
>> + const struct file_operations *fops)
>> +{
>> +int i;
>> +struct dentry *file;
>> +
>> +for (i = 0; i < nentries; i++) {
>> +file = debugfs_create_file(files[i].name, 0444,
>> + parent, data, fops);
>> +if (IS_ERR_OR_NULL(file))
>> +break;
> There's no need to ever check the return value of a debugfs_ function,
> there's nothing you can do here, just keep calling it :)
>
> And you will not get an error, you will only get NULL if there is an
> error, as the only error you would get is if debugfs was not enabled.
>
>> +static struct dentry *xhci_debugfs_create_ring_dir(struct xhci_hcd *xhci,
>> + struct xhci_ring *ring,
>> + const char *name,
>> + struct dentry *parent)
>> +{
>> +struct dentry *dir;
>> +
>> +dir = debugfs_create_dir(name, parent);
>> +if (IS_ERR_OR_NULL(dir))
>> +return NULL;
> Same here. Just keep going, you don't care about the return value, but
> you can use it safely no matter what.
>
>
> Same for other places in this patch as well.
Thanks for review. I will correct them in a v2 patch.
Best regards,
Lu Baolu
[PATCH 1/1] usb: xhci: Add debugfs interface for xHCI driver
This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.
The file hierarchy looks like this.
[root of debugfs]
|__usb
|[e,u,o]hci <-[root for other HCIs]
|xhci <---[root for xHCI]
|__:00:14.0 <--[xHCI host name]
|reg-cap<[capability registers]
|reg-op <---[operational registers]
|reg-runtime<---[runtime registers]
|reg-ext-#cap_name <[extended capability regs]
|command-ring <---[root for command ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|event-ring <-[root for event ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|devices<[root for devices]
|__#slot_id <---[root for a device]
|name <-[device name]
|slot-context <[slot context]
|ep-context <---[endpoint contexts]
|ep#ep_index<[root for an endpoint]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|______trbs <---[ring trbs]
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-debugfs.c | 552
drivers/usb/host/xhci-debugfs.h | 137 ++
drivers/usb/host/xhci-mem.c | 4 +-
drivers/usb/host/xhci.c | 21 +-
drivers/usb/host/xhci.h | 9 +
6 files changed, 723 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/host/xhci-debugfs.c
create mode 100644 drivers/usb/host/xhci-debugfs.h
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..b2a7f05 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -25,6 +25,10 @@ ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
endif
+ifneq ($(CONFIG_DEBUG_FS),)
+ xhci-hcd-y += xhci-debugfs.o
+endif
+
obj-$(CONFIG_USB_WHCI_HCD) += whci/
obj-$(CONFIG_USB_PCI) += pci-quirks.o
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
new file mode 100644
index 000..7588ac6
--- /dev/null
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -0,0 +1,552 @@
+/*
+ * xhci-debugfs.c - xHCI debugfs interface
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Author: Lu Baolu <baolu...@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include "xhci.h"
+#include "xhci-debugfs.h"
+
+static const struct debugfs_reg32 xhci_cap_regs[] = {
+ dump_register(CAPLENGTH),
+ dump_register(HCSPARAMS1),
+ dump_register(HCSPARAMS2),
+ dump_register(HCSPARAMS3),
+ dump_register(HCCPARAMS1),
+ dump_register(DOORBELLOFF),
+ dump_register(RUNTIMEOFF),
+ dump_register(HCCPARAMS2),
+};
+
+static const struct debugfs_reg32 xhci_op_regs[] = {
+ dump_register(USBCMD),
+ dump_register(USBSTS),
+ dump_register(PAGESIZE),
+ dump_register(DNCTRL),
+ dump_register(CRCR),
+ dump_register(DCBAAP_LOW),
+ dump_register(DCBAAP_HIGH),
+ dump_register(CONFIG),
+};
+
+static const struct debugfs_reg32 xhci_runtime_regs[] = {
+ dump_register(MFINDEX),
+ dump_register(IR0_IMAN),
+ dump_register(IR0_IMOD),
+ dump_register(IR0_ERSTSZ),
+ dump_register(IR0_ERSTBA_LOW),
+ dump_register(IR0_ERSTBA_HIGH),
+ dump_register(IR0_ERDP_LOW),
+ dump_register(IR0_ERDP_HIGH),
+};
+
+static const struct debugfs_reg32 xhci_extcap_legsup[] = {
+ dump_register(EXTCAP_USBLEGSUP),
+ dump_register(EXTCAP_USBLEGCTLSTS),
+};
+
+static const struct d
[PATCH 1/1] usb: xhci: Add debugfs interface for xHCI driver
This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.
The file hierarchy looks like this.
[root of debugfs]
|__usb
|[e,u,o]hci <-[root for other HCIs]
|xhci <---[root for xHCI]
|__:00:14.0 <--[xHCI host name]
|reg-cap<[capability registers]
|reg-op <---[operational registers]
|reg-runtime<---[runtime registers]
|reg-ext-#cap_name <[extended capability regs]
|command-ring <---[root for command ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|event-ring <-[root for event ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|devices<[root for devices]
|__#slot_id <---[root for a device]
|name <-[device name]
|slot-context <[slot context]
|ep-context <---[endpoint contexts]
|ep#ep_index<[root for an endpoint]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|______trbs <---[ring trbs]
Signed-off-by: Lu Baolu
---
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-debugfs.c | 552
drivers/usb/host/xhci-debugfs.h | 137 ++
drivers/usb/host/xhci-mem.c | 4 +-
drivers/usb/host/xhci.c | 21 +-
drivers/usb/host/xhci.h | 9 +
6 files changed, 723 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/host/xhci-debugfs.c
create mode 100644 drivers/usb/host/xhci-debugfs.h
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..b2a7f05 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -25,6 +25,10 @@ ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
endif
+ifneq ($(CONFIG_DEBUG_FS),)
+ xhci-hcd-y += xhci-debugfs.o
+endif
+
obj-$(CONFIG_USB_WHCI_HCD) += whci/
obj-$(CONFIG_USB_PCI) += pci-quirks.o
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
new file mode 100644
index 000..7588ac6
--- /dev/null
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -0,0 +1,552 @@
+/*
+ * xhci-debugfs.c - xHCI debugfs interface
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include "xhci.h"
+#include "xhci-debugfs.h"
+
+static const struct debugfs_reg32 xhci_cap_regs[] = {
+ dump_register(CAPLENGTH),
+ dump_register(HCSPARAMS1),
+ dump_register(HCSPARAMS2),
+ dump_register(HCSPARAMS3),
+ dump_register(HCCPARAMS1),
+ dump_register(DOORBELLOFF),
+ dump_register(RUNTIMEOFF),
+ dump_register(HCCPARAMS2),
+};
+
+static const struct debugfs_reg32 xhci_op_regs[] = {
+ dump_register(USBCMD),
+ dump_register(USBSTS),
+ dump_register(PAGESIZE),
+ dump_register(DNCTRL),
+ dump_register(CRCR),
+ dump_register(DCBAAP_LOW),
+ dump_register(DCBAAP_HIGH),
+ dump_register(CONFIG),
+};
+
+static const struct debugfs_reg32 xhci_runtime_regs[] = {
+ dump_register(MFINDEX),
+ dump_register(IR0_IMAN),
+ dump_register(IR0_IMOD),
+ dump_register(IR0_ERSTSZ),
+ dump_register(IR0_ERSTBA_LOW),
+ dump_register(IR0_ERSTBA_HIGH),
+ dump_register(IR0_ERDP_LOW),
+ dump_register(IR0_ERDP_HIGH),
+};
+
+static const struct debugfs_reg32 xhci_extcap_legsup[] = {
+ dump_register(EXTCAP_USBLEGSUP),
+ dump_register(EXTCAP_USBLEGCTLSTS),
+};
+
+static const struct debugfs_reg32 xhci_extcap_protocol[] = {
+ dump_register(EXTCAP_REVISIO
Re: [PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command
Hi, On 07/27/2017 03:55 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu <baolu...@linux.intel.com> writes: >> Xhci driver handles USB transaction errors on transfer events, >> but transaction errors are possible on address device command >> completion events as well. >> >> The xHCI specification (section 4.6.5) says: A USB Transaction >> Error Completion Code for an Address Device Command may be due >> to a Stall response from a device. Software should issue a Disable >> Slot Command for the Device Slot then an Enable Slot Command to >> recover from this error. >> >> This patch handles USB transaction errors on address command >> completion events. The related discussion threads can be found >> through below links. >> >> http://marc.info/?l=linux-usb=149362010728921=2 >> http://marc.info/?l=linux-usb=149252752825755=2 >> >> Suggested-by: Mathias Nyman <mathias.ny...@linux.intel.com> >> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> >> --- >> drivers/usb/host/xhci.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index d6b728d..95780f8 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, >> struct usb_device *udev, >> break; >> case COMP_USB_TRANSACTION_ERROR: >> dev_warn(>dev, "Device not responding to setup %s.\n", >> act); >> + >> +ret = xhci_disable_slot(xhci, udev->slot_id); >> + if (!ret) >> +xhci_alloc_dev(hcd, udev); > aren't you leaking previously allocated virt_dev ? > When disable slot command completes, the command completion handler will release the previous allocated virt_dev. Best regards, Lu Baolu
Re: [PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command
Hi, On 07/27/2017 03:55 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu writes: >> Xhci driver handles USB transaction errors on transfer events, >> but transaction errors are possible on address device command >> completion events as well. >> >> The xHCI specification (section 4.6.5) says: A USB Transaction >> Error Completion Code for an Address Device Command may be due >> to a Stall response from a device. Software should issue a Disable >> Slot Command for the Device Slot then an Enable Slot Command to >> recover from this error. >> >> This patch handles USB transaction errors on address command >> completion events. The related discussion threads can be found >> through below links. >> >> http://marc.info/?l=linux-usb=149362010728921=2 >> http://marc.info/?l=linux-usb=149252752825755=2 >> >> Suggested-by: Mathias Nyman >> Signed-off-by: Lu Baolu >> --- >> drivers/usb/host/xhci.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index d6b728d..95780f8 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, >> struct usb_device *udev, >> break; >> case COMP_USB_TRANSACTION_ERROR: >> dev_warn(>dev, "Device not responding to setup %s.\n", >> act); >> + >> +ret = xhci_disable_slot(xhci, udev->slot_id); >> +if (!ret) >> +xhci_alloc_dev(hcd, udev); > aren't you leaking previously allocated virt_dev ? > When disable slot command completes, the command completion handler will release the previous allocated virt_dev. Best regards, Lu Baolu
[PATCH v2 4/5] usb: xhci: Return error when host is dead in xhci_disable_slot()
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead host.
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang <guoqing.zh...@intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2df601e..d6b728d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3568,10 +3568,9 @@ int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
state = readl(>op_regs->status);
if (state == 0x || (xhci->xhc_state & XHCI_STATE_DYING) ||
(xhci->xhc_state & XHCI_STATE_HALTED)) {
- xhci_free_virt_device(xhci, slot_id);
spin_unlock_irqrestore(>lock, flags);
kfree(command);
- return ret;
+ return -ENODEV;
}
ret = xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
--
2.7.4
[PATCH v2 3/5] usb: xhci: Fix memory leak when xhci_disable_slot() returns error
If xhci_disable_slot() returns success, a disable slot command trb was queued in the command ring. The command completion handler will free the virtual device data structure associated with the slot. On the other hand, when xhci_disable_slot() returns error, the invokers should take the responsibilities to free the slot related data structure. Otherwise, memory leakage happens. Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- drivers/usb/host/xhci.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index cb2461a..2df601e 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3547,11 +3547,9 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev) del_timer_sync(_dev->eps[i].stop_cmd_timer); } - xhci_disable_slot(xhci, udev->slot_id); - /* -* Event command completion handler will free any data structures -* associated with the slot. XXX Can free sleep? -*/ + ret = xhci_disable_slot(xhci, udev->slot_id); + if (ret) + xhci_free_virt_device(xhci, udev->slot_id); } int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id) @@ -3697,7 +3695,11 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev) return 1; disable_slot: - return xhci_disable_slot(xhci, udev->slot_id); + ret = xhci_disable_slot(xhci, udev->slot_id); + if (ret) + xhci_free_virt_device(xhci, udev->slot_id); + + return 0; } /* -- 2.7.4
[PATCH v2 2/5] usb: xhci: Fix potential memory leak in xhci_disable_slot()
xhci_disable_slot() allows the invoker to pass a command pointer
as paramenter. Otherwise, it will allocate one. This will cause
memory leak when a command structure was allocated inside of this
function while queuing command trb fails. Another problem comes up
when the invoker passed a command pointer, but xhci_disable_slot()
frees it when it detects a dead host.
This patch fixes these two problems by removing the command parameter
from xhci_disable_slot().
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang <guoqing.zh...@intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci.c | 30 +-
drivers/usb/host/xhci.h | 3 +--
3 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 00721e8..c862d53 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -612,7 +612,7 @@ static int xhci_enter_test_mode(struct xhci_hcd *xhci,
xhci_dbg(xhci, "Disable all slots\n");
spin_unlock_irqrestore(>lock, *flags);
for (i = 1; i <= HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
- retval = xhci_disable_slot(xhci, NULL, i);
+ retval = xhci_disable_slot(xhci, i);
if (retval)
xhci_err(xhci, "Failed to disable slot %d, %d. Enter
test mode anyway\n",
i, retval);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e69073f..cb2461a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3519,11 +3519,6 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
struct xhci_virt_device *virt_dev;
struct xhci_slot_ctx *slot_ctx;
int i, ret;
- struct xhci_command *command;
-
- command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
- if (!command)
- return;
#ifndef CONFIG_USB_DEFAULT_PERSIST
/*
@@ -3539,10 +3534,8 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
/* If the host is halted due to driver unload, we still need to free the
* device.
*/
- if (ret <= 0 && ret != -ENODEV) {
- kfree(command);
+ if (ret <= 0 && ret != -ENODEV)
return;
- }
virt_dev = xhci->devs[udev->slot_id];
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
@@ -3554,22 +3547,21 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
del_timer_sync(_dev->eps[i].stop_cmd_timer);
}
- xhci_disable_slot(xhci, command, udev->slot_id);
+ xhci_disable_slot(xhci, udev->slot_id);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
*/
}
-int xhci_disable_slot(struct xhci_hcd *xhci, struct xhci_command *command,
- u32 slot_id)
+int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
{
+ struct xhci_command *command;
unsigned long flags;
u32 state;
int ret = 0;
- if (!command)
- command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
+ command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
return -ENOMEM;
@@ -3588,7 +3580,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct
xhci_command *command,
slot_id);
if (ret) {
spin_unlock_irqrestore(>lock, flags);
- xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
+ kfree(command);
return ret;
}
xhci_ring_cmd_db(xhci);
@@ -3663,6 +3655,8 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
return 0;
}
+ xhci_free_command(xhci, command);
+
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
spin_lock_irqsave(>lock, flags);
ret = xhci_reserve_host_control_ep_resources(xhci);
@@ -3698,18 +3692,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct
usb_device *udev)
pm_runtime_get_noresume(hcd->self.controller);
#endif
-
- xhci_free_command(xhci, command);
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
disable_slot:
- /* Disable slot, if we can do it without mem alloc */
- kfree(command->completion);
- command->completion = NULL;
- command->status = 0;
- return xhci_disable_slot(xhci, command, udev->slot_id);
+ return xhci_disable_slot(xhci, udev->slot_id);
}
/*
diff --git a/drivers
[PATCH v2 4/5] usb: xhci: Return error when host is dead in xhci_disable_slot()
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead host.
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2df601e..d6b728d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3568,10 +3568,9 @@ int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
state = readl(>op_regs->status);
if (state == 0x || (xhci->xhc_state & XHCI_STATE_DYING) ||
(xhci->xhc_state & XHCI_STATE_HALTED)) {
- xhci_free_virt_device(xhci, slot_id);
spin_unlock_irqrestore(>lock, flags);
kfree(command);
- return ret;
+ return -ENODEV;
}
ret = xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
--
2.7.4
[PATCH v2 3/5] usb: xhci: Fix memory leak when xhci_disable_slot() returns error
If xhci_disable_slot() returns success, a disable slot command trb was queued in the command ring. The command completion handler will free the virtual device data structure associated with the slot. On the other hand, when xhci_disable_slot() returns error, the invokers should take the responsibilities to free the slot related data structure. Otherwise, memory leakage happens. Signed-off-by: Lu Baolu --- drivers/usb/host/xhci.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index cb2461a..2df601e 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3547,11 +3547,9 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev) del_timer_sync(_dev->eps[i].stop_cmd_timer); } - xhci_disable_slot(xhci, udev->slot_id); - /* -* Event command completion handler will free any data structures -* associated with the slot. XXX Can free sleep? -*/ + ret = xhci_disable_slot(xhci, udev->slot_id); + if (ret) + xhci_free_virt_device(xhci, udev->slot_id); } int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id) @@ -3697,7 +3695,11 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev) return 1; disable_slot: - return xhci_disable_slot(xhci, udev->slot_id); + ret = xhci_disable_slot(xhci, udev->slot_id); + if (ret) + xhci_free_virt_device(xhci, udev->slot_id); + + return 0; } /* -- 2.7.4
[PATCH v2 2/5] usb: xhci: Fix potential memory leak in xhci_disable_slot()
xhci_disable_slot() allows the invoker to pass a command pointer
as paramenter. Otherwise, it will allocate one. This will cause
memory leak when a command structure was allocated inside of this
function while queuing command trb fails. Another problem comes up
when the invoker passed a command pointer, but xhci_disable_slot()
frees it when it detects a dead host.
This patch fixes these two problems by removing the command parameter
from xhci_disable_slot().
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci.c | 30 +-
drivers/usb/host/xhci.h | 3 +--
3 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 00721e8..c862d53 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -612,7 +612,7 @@ static int xhci_enter_test_mode(struct xhci_hcd *xhci,
xhci_dbg(xhci, "Disable all slots\n");
spin_unlock_irqrestore(>lock, *flags);
for (i = 1; i <= HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
- retval = xhci_disable_slot(xhci, NULL, i);
+ retval = xhci_disable_slot(xhci, i);
if (retval)
xhci_err(xhci, "Failed to disable slot %d, %d. Enter
test mode anyway\n",
i, retval);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e69073f..cb2461a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3519,11 +3519,6 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
struct xhci_virt_device *virt_dev;
struct xhci_slot_ctx *slot_ctx;
int i, ret;
- struct xhci_command *command;
-
- command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
- if (!command)
- return;
#ifndef CONFIG_USB_DEFAULT_PERSIST
/*
@@ -3539,10 +3534,8 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
/* If the host is halted due to driver unload, we still need to free the
* device.
*/
- if (ret <= 0 && ret != -ENODEV) {
- kfree(command);
+ if (ret <= 0 && ret != -ENODEV)
return;
- }
virt_dev = xhci->devs[udev->slot_id];
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
@@ -3554,22 +3547,21 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
del_timer_sync(_dev->eps[i].stop_cmd_timer);
}
- xhci_disable_slot(xhci, command, udev->slot_id);
+ xhci_disable_slot(xhci, udev->slot_id);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
*/
}
-int xhci_disable_slot(struct xhci_hcd *xhci, struct xhci_command *command,
- u32 slot_id)
+int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
{
+ struct xhci_command *command;
unsigned long flags;
u32 state;
int ret = 0;
- if (!command)
- command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
+ command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
return -ENOMEM;
@@ -3588,7 +3580,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct
xhci_command *command,
slot_id);
if (ret) {
spin_unlock_irqrestore(>lock, flags);
- xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
+ kfree(command);
return ret;
}
xhci_ring_cmd_db(xhci);
@@ -3663,6 +3655,8 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
return 0;
}
+ xhci_free_command(xhci, command);
+
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
spin_lock_irqsave(>lock, flags);
ret = xhci_reserve_host_control_ep_resources(xhci);
@@ -3698,18 +3692,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct
usb_device *udev)
pm_runtime_get_noresume(hcd->self.controller);
#endif
-
- xhci_free_command(xhci, command);
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
disable_slot:
- /* Disable slot, if we can do it without mem alloc */
- kfree(command->completion);
- command->completion = NULL;
- command->status = 0;
- return xhci_disable_slot(xhci, command, udev->slot_id);
+ return xhci_disable_slot(xhci, udev->slot_id);
}
/*
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e3e9352..6325
[PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. This patch handles USB transaction errors on address command completion events. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb=149362010728921=2 http://marc.info/?l=linux-usb=149252752825755=2 Suggested-by: Mathias Nyman <mathias.ny...@linux.intel.com> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- drivers/usb/host/xhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index d6b728d..95780f8 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, break; case COMP_USB_TRANSACTION_ERROR: dev_warn(>dev, "Device not responding to setup %s.\n", act); + + ret = xhci_disable_slot(xhci, udev->slot_id); + if (!ret) + xhci_alloc_dev(hcd, udev); + ret = -EPROTO; break; case COMP_INCOMPATIBLE_DEVICE_ERROR: -- 2.7.4
[PATCH v2 5/5] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. This patch handles USB transaction errors on address command completion events. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb=149362010728921=2 http://marc.info/?l=linux-usb=149252752825755=2 Suggested-by: Mathias Nyman Signed-off-by: Lu Baolu --- drivers/usb/host/xhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index d6b728d..95780f8 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, break; case COMP_USB_TRANSACTION_ERROR: dev_warn(>dev, "Device not responding to setup %s.\n", act); + + ret = xhci_disable_slot(xhci, udev->slot_id); + if (!ret) + xhci_alloc_dev(hcd, udev); + ret = -EPROTO; break; case COMP_INCOMPATIBLE_DEVICE_ERROR: -- 2.7.4
[PATCH v2 1/5] usb: xhci: Disable slot even virt-dev is null
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it checks
the corespoding virt-dev pointer and returns directly (w/o issuing
disable slot command) if it's null.
This is unnecessary and will cause problems in case where virt-dev
allocation fails and xhci_disable_slot() is called to roll back the
hardware state. Refer to the implementation of xhci_alloc_dev().
This patch removes lines to check virt-dev in xhci_disable_slot().
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang <guoqing.zh...@intel.com>
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b2ff1ff..e69073f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3567,11 +3567,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct
xhci_command *command,
unsigned long flags;
u32 state;
int ret = 0;
- struct xhci_virt_device *virt_dev;
- virt_dev = xhci->devs[slot_id];
- if (!virt_dev)
- return -EINVAL;
if (!command)
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
--
2.7.4
[PATCH v2 1/5] usb: xhci: Disable slot even virt-dev is null
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it checks
the corespoding virt-dev pointer and returns directly (w/o issuing
disable slot command) if it's null.
This is unnecessary and will cause problems in case where virt-dev
allocation fails and xhci_disable_slot() is called to roll back the
hardware state. Refer to the implementation of xhci_alloc_dev().
This patch removes lines to check virt-dev in xhci_disable_slot().
Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b2ff1ff..e69073f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3567,11 +3567,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct
xhci_command *command,
unsigned long flags;
u32 state;
int ret = 0;
- struct xhci_virt_device *virt_dev;
- virt_dev = xhci->devs[slot_id];
- if (!virt_dev)
- return -EINVAL;
if (!command)
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
--
2.7.4
[PATCH v2 0/5] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb=149362010728921=2 http://marc.info/?l=linux-usb=149252752825755=2 This patch set includes some fixes in xhci_disable_slot() as well which will be used to handle USB transaction error on address command. --- Change log: v1->v2: - include 4 fixes in xhci_disable_slot which will be used to handle USB transaction error on address command. Lu Baolu (5): usb: xhci: Disable slot even virt-dev is null usb: xhci: Fix potential memory leak in xhci_disable_slot() usb: xhci: Fix memory leak when xhci_disable_slot() returns error usb: xhci: Return error when host is dead in xhci_disable_slot() usb: xhci: Handle USB transaction error on address command drivers/usb/host/xhci-hub.c | 2 +- drivers/usb/host/xhci.c | 52 ++--- drivers/usb/host/xhci.h | 3 +-- 3 files changed, 23 insertions(+), 34 deletions(-) -- 2.7.4
[PATCH v2 0/5] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb=149362010728921=2 http://marc.info/?l=linux-usb=149252752825755=2 This patch set includes some fixes in xhci_disable_slot() as well which will be used to handle USB transaction error on address command. --- Change log: v1->v2: - include 4 fixes in xhci_disable_slot which will be used to handle USB transaction error on address command. Lu Baolu (5): usb: xhci: Disable slot even virt-dev is null usb: xhci: Fix potential memory leak in xhci_disable_slot() usb: xhci: Fix memory leak when xhci_disable_slot() returns error usb: xhci: Return error when host is dead in xhci_disable_slot() usb: xhci: Handle USB transaction error on address command drivers/usb/host/xhci-hub.c | 2 +- drivers/usb/host/xhci.c | 52 ++--- drivers/usb/host/xhci.h | 3 +-- 3 files changed, 23 insertions(+), 34 deletions(-) -- 2.7.4
Re: [PATCH 1/1] usb: xhci: Handle USB transaction error on address command
Hi, On 07/26/2017 01:11 PM, Xing, Zhengjun wrote: > > > On 7/25/2017 1:09 PM, Lu Baolu wrote: >> Xhci driver handles USB transaction errors on transfer events, >> but transaction errors are possible on address device command >> completion events as well. >> >> The xHCI specification (section 4.6.5) says: A USB Transaction >> Error Completion Code for an Address Device Command may be due >> to a Stall response from a device. Software should issue a Disable >> Slot Command for the Device Slot then an Enable Slot Command to >> recover from this error. >> >> This patch handles USB transaction errors on address command >> completion events. The related discussion threads can be found >> through below links. >> >> http://marc.info/?l=linux-usb=149362010728921=2 >> http://marc.info/?l=linux-usb=149252752825755=2 >> >> Suggested-by: Mathias Nyman <mathias.ny...@linux.intel.com> >> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> >> --- >> drivers/usb/host/xhci.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index b2ff1ff..9cc56cd 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, >> struct usb_device *udev, >> ret = -EINVAL; >> break; >> case COMP_USB_TRANSACTION_ERROR: >> +xhci_free_virt_device(xhci, udev->slot_id); > > In xhci_free_virt_device xhci->devs[slot_id]will be set to NULL. > >> +ret = xhci_disable_slot(xhci, command, udev->slot_id); > > When xhci_disable_slot check xhci->devs[slot_id] is NULL, just return > -EINVAL, the slot will not be disabled. Yes, really. I don't think xhci_disable_slot() should return directly when the virtual device structure is not allocated. This function is also used to issue a disable slot command when the virtual device data allocation fails in xhci_alloc_dev(). I will develop v2 patch with a fix for xhci_disable_slot(). Best regards, Lu Baolu
Re: [PATCH 1/1] usb: xhci: Handle USB transaction error on address command
Hi, On 07/26/2017 01:11 PM, Xing, Zhengjun wrote: > > > On 7/25/2017 1:09 PM, Lu Baolu wrote: >> Xhci driver handles USB transaction errors on transfer events, >> but transaction errors are possible on address device command >> completion events as well. >> >> The xHCI specification (section 4.6.5) says: A USB Transaction >> Error Completion Code for an Address Device Command may be due >> to a Stall response from a device. Software should issue a Disable >> Slot Command for the Device Slot then an Enable Slot Command to >> recover from this error. >> >> This patch handles USB transaction errors on address command >> completion events. The related discussion threads can be found >> through below links. >> >> http://marc.info/?l=linux-usb=149362010728921=2 >> http://marc.info/?l=linux-usb=149252752825755=2 >> >> Suggested-by: Mathias Nyman >> Signed-off-by: Lu Baolu >> --- >> drivers/usb/host/xhci.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index b2ff1ff..9cc56cd 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, >> struct usb_device *udev, >> ret = -EINVAL; >> break; >> case COMP_USB_TRANSACTION_ERROR: >> +xhci_free_virt_device(xhci, udev->slot_id); > > In xhci_free_virt_device xhci->devs[slot_id]will be set to NULL. > >> +ret = xhci_disable_slot(xhci, command, udev->slot_id); > > When xhci_disable_slot check xhci->devs[slot_id] is NULL, just return > -EINVAL, the slot will not be disabled. Yes, really. I don't think xhci_disable_slot() should return directly when the virtual device structure is not allocated. This function is also used to issue a disable slot command when the virtual device data allocation fails in xhci_alloc_dev(). I will develop v2 patch with a fix for xhci_disable_slot(). Best regards, Lu Baolu
[PATCH 1/1] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. This patch handles USB transaction errors on address command completion events. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb=149362010728921=2 http://marc.info/?l=linux-usb=149252752825755=2 Suggested-by: Mathias Nyman <mathias.ny...@linux.intel.com> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- drivers/usb/host/xhci.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index b2ff1ff..9cc56cd 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, ret = -EINVAL; break; case COMP_USB_TRANSACTION_ERROR: + xhci_free_virt_device(xhci, udev->slot_id); + ret = xhci_disable_slot(xhci, command, udev->slot_id); + udev->slot_id = 0; + if (!ret) + xhci_alloc_dev(hcd, udev); + dev_warn(>dev, "Device not responding to setup %s.\n", act); ret = -EPROTO; break; -- 2.7.4
[PATCH 1/1] usb: xhci: Handle USB transaction error on address command
Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an Address Device Command may be due to a Stall response from a device. Software should issue a Disable Slot Command for the Device Slot then an Enable Slot Command to recover from this error. This patch handles USB transaction errors on address command completion events. The related discussion threads can be found through below links. http://marc.info/?l=linux-usb=149362010728921=2 http://marc.info/?l=linux-usb=149252752825755=2 Suggested-by: Mathias Nyman Signed-off-by: Lu Baolu --- drivers/usb/host/xhci.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index b2ff1ff..9cc56cd 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, ret = -EINVAL; break; case COMP_USB_TRANSACTION_ERROR: + xhci_free_virt_device(xhci, udev->slot_id); + ret = xhci_disable_slot(xhci, command, udev->slot_id); + udev->slot_id = 0; + if (!ret) + xhci_alloc_dev(hcd, udev); + dev_warn(>dev, "Device not responding to setup %s.\n", act); ret = -EPROTO; break; -- 2.7.4
Re: [PATCH 2/3] usb: xhci: Add DbC support in xHCI driver
Hi Felipe,
On 07/21/2017 06:31 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu <baolu...@linux.intel.com> writes:
>> +static void xhci_dbc_stop(struct xhci_hcd *xhci)
>> +{
>> +struct xhci_dbc *dbc = xhci->dbc;
>> +
>> +WARN_ON(!dbc);
>> +
>> +cancel_delayed_work_sync(>event_work);
>> +
>> +if (dbc->gs_port_num != GSPORT_INVAL) {
>> +gserial_disconnect(>gs_port);
>> +gserial_free_line(dbc->gs_port_num);
> why are you tying host stack to the gadget framework?
XHCI debug capability is actually a debug device gadget.
The hardware and firmware do everything of gadget work
and leave the interface to xHCI for enabling/disabling and
queuing transfer requests.
u_serial.c provides a generic layer between a USB gadget
and the TTY layer. I used it to avoid duplicating code.
>
> With this, you're forcing every single PC in the world to compile the
> gadget framework, that's a bit much don't you think?
>
Yes, you are right. Is it acceptable if I move u_serial.c from
the current place to drivers/usb/common?
Best regards,
Lu Baolu
Re: [PATCH 2/3] usb: xhci: Add DbC support in xHCI driver
Hi Felipe,
On 07/21/2017 06:31 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu writes:
>> +static void xhci_dbc_stop(struct xhci_hcd *xhci)
>> +{
>> +struct xhci_dbc *dbc = xhci->dbc;
>> +
>> +WARN_ON(!dbc);
>> +
>> +cancel_delayed_work_sync(>event_work);
>> +
>> +if (dbc->gs_port_num != GSPORT_INVAL) {
>> +gserial_disconnect(>gs_port);
>> +gserial_free_line(dbc->gs_port_num);
> why are you tying host stack to the gadget framework?
XHCI debug capability is actually a debug device gadget.
The hardware and firmware do everything of gadget work
and leave the interface to xHCI for enabling/disabling and
queuing transfer requests.
u_serial.c provides a generic layer between a USB gadget
and the TTY layer. I used it to avoid duplicating code.
>
> With this, you're forcing every single PC in the world to compile the
> gadget framework, that's a bit much don't you think?
>
Yes, you are right. Is it acceptable if I move u_serial.c from
the current place to drivers/usb/common?
Best regards,
Lu Baolu
[PATCH 3/3] usb: doc: Update document for USB3 debug port usage
Update Documentation/driver-api/usb/usb3-debug-port.rst. This update includes the guide for using xHCI debug capability based TTY serial link. Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- Documentation/driver-api/usb/usb3-debug-port.rst | 68 1 file changed, 68 insertions(+) diff --git a/Documentation/driver-api/usb/usb3-debug-port.rst b/Documentation/driver-api/usb/usb3-debug-port.rst index feb1a36..e4bb02e 100644 --- a/Documentation/driver-api/usb/usb3-debug-port.rst +++ b/Documentation/driver-api/usb/usb3-debug-port.rst @@ -98,3 +98,71 @@ you to check the sanity of the setup. cat /dev/ttyUSB0 done = end of bash scripts === + +Serial TTY +== + +DbC has also been designed for a serial TTY device at runtime. +One use of this is running a login service on the debug target. +Hence it can be remote accessed by the debug host. Another use +can probably be found in servers. It provides a peer-to-peer USB +link between two host-only machines. This provides a reasonable +out-of-band communication method between two servers. + +In order to use this, you need to make sure your kernel has been +configured to support USB_XHCI_DBGCAP. A sysfs attribute under +the xHCI device node is used to enable or disable DbC. By default, +DbC is disabled:: + + root@target:/sys/bus/pci/devices/:00:14.0# cat dbc + disabled + +Enable DbC with the following command:: + + root@target:/sys/bus/pci/devices/:00:14.0# echo enable > dbc + +You can check the DbC state at anytime:: + + root@target:/sys/bus/pci/devices/:00:14.0# cat dbc + enabled + +Connect the debug target to the debug host with a USB 3.0 super- +speed A-to-A debugging cable. You can see the /dev/ttyGSn created +on the debug target. You will see below kernel message lines:: + + root@target: tail -f /var/log/kern.log + [ 182.730103] xhci_hcd :00:14.0: DbC connected + [ 191.169420] xhci_hcd :00:14.0: DbC configured + [ 191.169597] xhci_hcd :00:14.0: DbC now attached to /dev/ttyGS0 + +Accordingly, the DbC state has been brought up to:: + + root@host:/sys/bus/pci/devices/:00:14.0# cat dbc + configured + +On the debug host, you will see the debug device has been enumerated. +You will see below kernel message lines:: + + root@host: tail -f /var/log/kern.log + [ 79.454780] usb 2-2.1: new SuperSpeed USB device number 3 using xhci_hcd + [ 79.475003] usb 2-2.1: LPM exit latency is zeroed, disabling LPM. + [ 79.475389] usb 2-2.1: New USB device found, idVendor=1d6b, idProduct=0004 + [ 79.475390] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 79.475391] usb 2-2.1: Product: Remote GDB + [ 79.475392] usb 2-2.1: Manufacturer: Linux + [ 79.475393] usb 2-2.1: SerialNumber: 0001 + [ 79.660368] usb_debug 2-2.1:1.0: xhci_dbc converter detected + [ 79.660439] usb 2-2.1: xhci_dbc converter now attached to ttyUSB0 + +You can simply verify whether it works by:: + + # On target side + root@target: echo "Hello world" > /dev/ttyGS0 + + # On host side + root@host: cat /dev/ttyUSB0 + Hello world + + # vice versa + +You have a workable serial link over USB now. -- 2.7.4
[PATCH 3/3] usb: doc: Update document for USB3 debug port usage
Update Documentation/driver-api/usb/usb3-debug-port.rst. This update includes the guide for using xHCI debug capability based TTY serial link. Signed-off-by: Lu Baolu --- Documentation/driver-api/usb/usb3-debug-port.rst | 68 1 file changed, 68 insertions(+) diff --git a/Documentation/driver-api/usb/usb3-debug-port.rst b/Documentation/driver-api/usb/usb3-debug-port.rst index feb1a36..e4bb02e 100644 --- a/Documentation/driver-api/usb/usb3-debug-port.rst +++ b/Documentation/driver-api/usb/usb3-debug-port.rst @@ -98,3 +98,71 @@ you to check the sanity of the setup. cat /dev/ttyUSB0 done = end of bash scripts === + +Serial TTY +== + +DbC has also been designed for a serial TTY device at runtime. +One use of this is running a login service on the debug target. +Hence it can be remote accessed by the debug host. Another use +can probably be found in servers. It provides a peer-to-peer USB +link between two host-only machines. This provides a reasonable +out-of-band communication method between two servers. + +In order to use this, you need to make sure your kernel has been +configured to support USB_XHCI_DBGCAP. A sysfs attribute under +the xHCI device node is used to enable or disable DbC. By default, +DbC is disabled:: + + root@target:/sys/bus/pci/devices/:00:14.0# cat dbc + disabled + +Enable DbC with the following command:: + + root@target:/sys/bus/pci/devices/:00:14.0# echo enable > dbc + +You can check the DbC state at anytime:: + + root@target:/sys/bus/pci/devices/:00:14.0# cat dbc + enabled + +Connect the debug target to the debug host with a USB 3.0 super- +speed A-to-A debugging cable. You can see the /dev/ttyGSn created +on the debug target. You will see below kernel message lines:: + + root@target: tail -f /var/log/kern.log + [ 182.730103] xhci_hcd :00:14.0: DbC connected + [ 191.169420] xhci_hcd :00:14.0: DbC configured + [ 191.169597] xhci_hcd :00:14.0: DbC now attached to /dev/ttyGS0 + +Accordingly, the DbC state has been brought up to:: + + root@host:/sys/bus/pci/devices/:00:14.0# cat dbc + configured + +On the debug host, you will see the debug device has been enumerated. +You will see below kernel message lines:: + + root@host: tail -f /var/log/kern.log + [ 79.454780] usb 2-2.1: new SuperSpeed USB device number 3 using xhci_hcd + [ 79.475003] usb 2-2.1: LPM exit latency is zeroed, disabling LPM. + [ 79.475389] usb 2-2.1: New USB device found, idVendor=1d6b, idProduct=0004 + [ 79.475390] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 79.475391] usb 2-2.1: Product: Remote GDB + [ 79.475392] usb 2-2.1: Manufacturer: Linux + [ 79.475393] usb 2-2.1: SerialNumber: 0001 + [ 79.660368] usb_debug 2-2.1:1.0: xhci_dbc converter detected + [ 79.660439] usb 2-2.1: xhci_dbc converter now attached to ttyUSB0 + +You can simply verify whether it works by:: + + # On target side + root@target: echo "Hello world" > /dev/ttyGS0 + + # On host side + root@host: cat /dev/ttyUSB0 + Hello world + + # vice versa + +You have a workable serial link over USB now. -- 2.7.4
[PATCH 1/3] usb: xhci: Make some static functions global
This patch makes some static functions global to avoid duplications
in different files. These functions can be used in the implementation
of xHCI debug capability. There is no functional change.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-mem.c | 94 ++--
drivers/usb/host/xhci-ring.c | 4 +-
drivers/usb/host/xhci.h | 16 +++-
3 files changed, 72 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 2a82c92..1ccb1c5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -368,7 +368,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd
*xhci,
* Set the end flag and the cycle toggle bit on the last segment.
* See section 4.9.1 and figures 15 and 16.
*/
-static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
+struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
unsigned int num_segs, unsigned int cycle_state,
enum xhci_ring_type type, unsigned int max_packet, gfp_t flags)
{
@@ -467,7 +467,7 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct
xhci_ring *ring,
#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
-static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd
*xhci,
+struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci,
int type, gfp_t flags)
{
struct xhci_container_ctx *ctx;
@@ -492,7 +492,7 @@ static struct xhci_container_ctx
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
return ctx;
}
-static void xhci_free_container_ctx(struct xhci_hcd *xhci,
+void xhci_free_container_ctx(struct xhci_hcd *xhci,
struct xhci_container_ctx *ctx)
{
if (!ctx)
@@ -1762,21 +1762,61 @@ void xhci_free_command(struct xhci_hcd *xhci,
kfree(command);
}
+int xhci_alloc_erst(struct xhci_hcd *xhci,
+ struct xhci_ring *evt_ring,
+ struct xhci_erst *erst,
+ gfp_t flags)
+{
+ size_t size;
+ unsigned int val;
+ struct xhci_segment *seg;
+ struct xhci_erst_entry *entry;
+
+ size = sizeof(struct xhci_erst_entry) * evt_ring->num_segs;
+ erst->entries = dma_alloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
+ size,
+ >erst_dma_addr,
+ flags);
+ if (!erst->entries)
+ return -ENOMEM;
+
+ memset(erst->entries, 0, size);
+ erst->num_entries = evt_ring->num_segs;
+
+ seg = evt_ring->first_seg;
+ for (val = 0; val < evt_ring->num_segs; val++) {
+ entry = >entries[val];
+ entry->seg_addr = cpu_to_le64(seg->dma);
+ entry->seg_size = cpu_to_le32(TRBS_PER_SEGMENT);
+ entry->rsvd = 0;
+ seg = seg->next;
+ }
+
+ return 0;
+}
+
+void xhci_free_erst(struct xhci_hcd *xhci, struct xhci_erst *erst)
+{
+ size_t size;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+
+ size = sizeof(struct xhci_erst_entry) * (erst->num_entries);
+ if (erst->entries)
+ dma_free_coherent(dev, size,
+ erst->entries,
+ erst->erst_dma_addr);
+ erst->entries = NULL;
+}
+
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
- int size;
int i, j, num_ports;
cancel_delayed_work_sync(>cmd_timer);
- /* Free the Event Ring Segment Table and the actual Event Ring */
- size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
- if (xhci->erst.entries)
- dma_free_coherent(dev, size,
- xhci->erst.entries, xhci->erst.erst_dma_addr);
- xhci->erst.entries = NULL;
- xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed ERST");
+ xhci_free_erst(xhci, >erst);
+
if (xhci->event_ring)
xhci_ring_free(xhci, xhci->event_ring);
xhci->event_ring = NULL;
@@ -2313,9 +2353,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
- struct xhci_segment *seg;
- u32 page_size, temp;
- int i;
+ u32 page_size, temp;
+ int i, ret;
INIT_LIST_HEAD(>cmd_list);
@@ -2454,32 +2493,9 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
if (xhci_check_trb_in_td_math(xhci) < 0)
goto fail;
- xhci->erst.entries = dma_alloc_coheren
[PATCH 2/3] usb: xhci: Add DbC support in xHCI driver
xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1128 drivers/usb/host/xhci-trace.h | 64 ++ drivers/usb/host/xhci.c|9 + drivers/usb/host/xhci.h| 189 +++- 7 files changed, 1429 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd new file mode 100644 index 000..0088aba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -0,0 +1,25 @@ +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc +Date: June 2017 +Contact: Lu Baolu <baolu...@linux.intel.com> +Description: + xHCI compatible USB host controllers (i.e. super-speed + USB3 controllers) are often implemented with the Debug + Capability (DbC). It can present a debug device which + is fully compliant with the USB framework and provides + the equivalent of a very high performance full-duplex + serial link for debug purpose. + + The DbC debug device shares a root port with xHCI host. + When the DbC is enabled, the root port will be assigned + to the Debug Capability. Otherwise, it will be assigned + to xHCI. + + Writing "enable" to this attribute will enable the DbC + functionality and the shared root port will be assigned + to the DbC device. Writing "disable" to this attribute + will disable the DbC functionality and the shared root + port will roll back to the xHCI. + + Reading this attribute gives the state of the DbC. It + can be one of the following states: disabled, enabled, + initialized, connected, configured and stalled. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fa5692d..cfb2450 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -27,6 +27,16 @@ config USB_XHCI_HCD module will be called xhci-hcd. if USB_XHCI_HCD +config USB_XHCI_DBGCAP + bool "xHCI support for debug capability" + depends on TTY + depends on USB_GADGET=y + select USB_U_SERIAL + ---help--- + Say 'Y' to enable the support for the xHCI debug capability. Make + sure that your xHCI host supports the extended debug capability and + you want a TTY serial device based on the xHCI debug capability + before enabling this option. If unsure, say 'N'. config USB_XHCI_PCI tristate diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index cf2691f..4629d20 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -13,6 +13,11 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o xhci-hcd-y := xhci.o xhci-mem.o xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o xhci-hcd-y += xhci-trace.o + +ifneq ($(CONFIG_USB_XHCI_DBGCAP), ) + xhci-hcd-y += xhci-dbgcap.o +endif + ifneq ($(CONFIG_USB_XHCI_MTK), ) xhci
[PATCH 1/3] usb: xhci: Make some static functions global
This patch makes some static functions global to avoid duplications
in different files. These functions can be used in the implementation
of xHCI debug capability. There is no functional change.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-mem.c | 94 ++--
drivers/usb/host/xhci-ring.c | 4 +-
drivers/usb/host/xhci.h | 16 +++-
3 files changed, 72 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 2a82c92..1ccb1c5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -368,7 +368,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd
*xhci,
* Set the end flag and the cycle toggle bit on the last segment.
* See section 4.9.1 and figures 15 and 16.
*/
-static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
+struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
unsigned int num_segs, unsigned int cycle_state,
enum xhci_ring_type type, unsigned int max_packet, gfp_t flags)
{
@@ -467,7 +467,7 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct
xhci_ring *ring,
#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
-static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd
*xhci,
+struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci,
int type, gfp_t flags)
{
struct xhci_container_ctx *ctx;
@@ -492,7 +492,7 @@ static struct xhci_container_ctx
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
return ctx;
}
-static void xhci_free_container_ctx(struct xhci_hcd *xhci,
+void xhci_free_container_ctx(struct xhci_hcd *xhci,
struct xhci_container_ctx *ctx)
{
if (!ctx)
@@ -1762,21 +1762,61 @@ void xhci_free_command(struct xhci_hcd *xhci,
kfree(command);
}
+int xhci_alloc_erst(struct xhci_hcd *xhci,
+ struct xhci_ring *evt_ring,
+ struct xhci_erst *erst,
+ gfp_t flags)
+{
+ size_t size;
+ unsigned int val;
+ struct xhci_segment *seg;
+ struct xhci_erst_entry *entry;
+
+ size = sizeof(struct xhci_erst_entry) * evt_ring->num_segs;
+ erst->entries = dma_alloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
+ size,
+ >erst_dma_addr,
+ flags);
+ if (!erst->entries)
+ return -ENOMEM;
+
+ memset(erst->entries, 0, size);
+ erst->num_entries = evt_ring->num_segs;
+
+ seg = evt_ring->first_seg;
+ for (val = 0; val < evt_ring->num_segs; val++) {
+ entry = >entries[val];
+ entry->seg_addr = cpu_to_le64(seg->dma);
+ entry->seg_size = cpu_to_le32(TRBS_PER_SEGMENT);
+ entry->rsvd = 0;
+ seg = seg->next;
+ }
+
+ return 0;
+}
+
+void xhci_free_erst(struct xhci_hcd *xhci, struct xhci_erst *erst)
+{
+ size_t size;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+
+ size = sizeof(struct xhci_erst_entry) * (erst->num_entries);
+ if (erst->entries)
+ dma_free_coherent(dev, size,
+ erst->entries,
+ erst->erst_dma_addr);
+ erst->entries = NULL;
+}
+
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
- int size;
int i, j, num_ports;
cancel_delayed_work_sync(>cmd_timer);
- /* Free the Event Ring Segment Table and the actual Event Ring */
- size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
- if (xhci->erst.entries)
- dma_free_coherent(dev, size,
- xhci->erst.entries, xhci->erst.erst_dma_addr);
- xhci->erst.entries = NULL;
- xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed ERST");
+ xhci_free_erst(xhci, >erst);
+
if (xhci->event_ring)
xhci_ring_free(xhci, xhci->event_ring);
xhci->event_ring = NULL;
@@ -2313,9 +2353,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
- struct xhci_segment *seg;
- u32 page_size, temp;
- int i;
+ u32 page_size, temp;
+ int i, ret;
INIT_LIST_HEAD(>cmd_list);
@@ -2454,32 +2493,9 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
if (xhci_check_trb_in_td_math(xhci) < 0)
goto fail;
- xhci->erst.entries = dma_alloc_coherent(dev,
- si
[PATCH 2/3] usb: xhci: Add DbC support in xHCI driver
xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Signed-off-by: Lu Baolu --- .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1128 drivers/usb/host/xhci-trace.h | 64 ++ drivers/usb/host/xhci.c|9 + drivers/usb/host/xhci.h| 189 +++- 7 files changed, 1429 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd new file mode 100644 index 000..0088aba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -0,0 +1,25 @@ +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc +Date: June 2017 +Contact: Lu Baolu +Description: + xHCI compatible USB host controllers (i.e. super-speed + USB3 controllers) are often implemented with the Debug + Capability (DbC). It can present a debug device which + is fully compliant with the USB framework and provides + the equivalent of a very high performance full-duplex + serial link for debug purpose. + + The DbC debug device shares a root port with xHCI host. + When the DbC is enabled, the root port will be assigned + to the Debug Capability. Otherwise, it will be assigned + to xHCI. + + Writing "enable" to this attribute will enable the DbC + functionality and the shared root port will be assigned + to the DbC device. Writing "disable" to this attribute + will disable the DbC functionality and the shared root + port will roll back to the xHCI. + + Reading this attribute gives the state of the DbC. It + can be one of the following states: disabled, enabled, + initialized, connected, configured and stalled. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fa5692d..cfb2450 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -27,6 +27,16 @@ config USB_XHCI_HCD module will be called xhci-hcd. if USB_XHCI_HCD +config USB_XHCI_DBGCAP + bool "xHCI support for debug capability" + depends on TTY + depends on USB_GADGET=y + select USB_U_SERIAL + ---help--- + Say 'Y' to enable the support for the xHCI debug capability. Make + sure that your xHCI host supports the extended debug capability and + you want a TTY serial device based on the xHCI debug capability + before enabling this option. If unsure, say 'N'. config USB_XHCI_PCI tristate diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index cf2691f..4629d20 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -13,6 +13,11 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o xhci-hcd-y := xhci.o xhci-mem.o xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o xhci-hcd-y += xhci-trace.o + +ifneq ($(CONFIG_USB_XHCI_DBGCAP), ) + xhci-hcd-y += xhci-dbgcap.o +endif + ifneq ($(CONFIG_USB_XHCI_MTK), ) xhci-hcd-y += xhci-mtk-sch.o endif diff --git a/drivers/usb/host/xhci-db
[PATCH 0/3] usb: xhci: Add debug capability support in xhci
Hi, This series is for xHCI debug capability (spec section 7.6.8) support in the xHCI driver. xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Best regards, Lu Baolu Lu Baolu (3): usb: xhci: Make some static functions global usb: xhci: Add DbC support in xHCI driver usb: doc: Update document for USB3 debug port usage .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + Documentation/driver-api/usb/usb3-debug-port.rst | 68 ++ drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1128 drivers/usb/host/xhci-mem.c| 94 +- drivers/usb/host/xhci-ring.c |4 +- drivers/usb/host/xhci-trace.h | 64 ++ drivers/usb/host/xhci.c|9 + drivers/usb/host/xhci.h| 205 +++- 10 files changed, 1569 insertions(+), 43 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c -- 2.7.4
[PATCH 0/3] usb: xhci: Add debug capability support in xhci
Hi, This series is for xHCI debug capability (spec section 7.6.8) support in the xHCI driver. xHCI compatible USB host controllers(i.e. super-speed USB3 controllers) can be implemented with the Debug Capability(DbC). It presents a debug device which is fully compliant with the USB framework and provides the equivalent of a very high performance full-duplex serial link. The debug capability operation model and registers interface are defined in 7.6.8 of the xHCI specification, revision 1.1. The DbC debug device shares a root port with the xHCI host. By default, the debug capability is disabled and the root port is assigned to xHCI. When the DbC is enabled, the root port will be assigned to the DbC debug device, and the xHCI sees nothing on this port. This implementation uses a sysfs node named under the xHCI device to manage the enabling and disabling of the debug capability. When the debug capability is enabled, it will present a debug device through the debug port. This debug device is fully compliant with the USB3 framework, and it can be enumerated by a debug host on the other end of the USB link. As soon as the debug device is configured, a TTY serial device named /dev/ttyGSn will be created. One use of this link is running a login service on the debug target. Hence it can be remote accessed by a debug host. Another use case can probably be found in servers. It provides a peer-to-peer USB link between two host-only machines. This provides a reasonable out-of-band communication method between two servers. Best regards, Lu Baolu Lu Baolu (3): usb: xhci: Make some static functions global usb: xhci: Add DbC support in xHCI driver usb: doc: Update document for USB3 debug port usage .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 25 + Documentation/driver-api/usb/usb3-debug-port.rst | 68 ++ drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile |5 + drivers/usb/host/xhci-dbgcap.c | 1128 drivers/usb/host/xhci-mem.c| 94 +- drivers/usb/host/xhci-ring.c |4 +- drivers/usb/host/xhci-trace.h | 64 ++ drivers/usb/host/xhci.c|9 + drivers/usb/host/xhci.h| 205 +++- 10 files changed, 1569 insertions(+), 43 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 drivers/usb/host/xhci-dbgcap.c -- 2.7.4
Re: [PATCH v8 1/5] x86: add simple udelay calibration
Hi,
On 07/13/2017 09:39 AM, Dou Liyang wrote:
> Hi, Lu
>
> At 07/13/2017 09:17 AM, Lu Baolu wrote:
>> Hi,
>>
>> On 07/12/2017 04:02 PM, Dou Liyang wrote:
>>> Hi, Lu
>>>
>>> At 05/05/2017 08:50 PM, Boris Ostrovsky wrote:
>>>> On 05/05/2017 01:41 AM, Lu Baolu wrote:
>>>>> Hi,
>>>>>
>>>>> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
>>>>>> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>>>>>>> Add a simple udelay calibration in x86 architecture-specific
>>>>>>> boot-time initializations. This will get a workable estimate
>>>>>>> for loops_per_jiffy. Hence, udelay() could be used after this
>>>>>>> initialization.
>>>>>> This breaks Xen PV guests since at this point, and until
>>>>>> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
>>>>>> mapped, they cannot access pvclock.
>>>>>>
>>>>>> Is it reasonable to do this before tsc_init() is called? (The failure
>>>>>> has nothing to do with tsc_init(), really --- it's just that it is
>>>>>> called late enough that Xen PV guests get properly initialized.) If it
>>>>>> is, would it be possible to move simple_udelay_calibration() after
>>>>>> x86_init.paging.pagetable_init()?
>>>>> This is currently only used for bare metal. How about by-pass it
>>>>> for Xen PV guests?
>>>>
>>>> It is fixed this for Xen PV guests now (in the sense that we don't crash
>>>> anymore) but my question is still whether this is not too early. Besides
>>>> tsc_init() (which might not be important here), at the time when
>>>> simple_udelay_calibration() is invoked we haven't yet called:
>>>> * kvmclock_init(), which sets calibration routines for KVM
>>>> * init_hypervisor_platform(), which sets calibration routines for vmware
>>>> and Xen HVM
>>>> * x86_init.paging.pagetable_init(), which sets calibration routines for
>>>> Xen PV
>>>>
>>>
>>> I guess these may have been missed.
>>>
>>> Do you have any comments about these?
>>>
>>
>> The patch will be available in 4.13-rc1.
>
> Yes, I have seen it in the upstream.
>
> Firstly, I also met this problem want to call udelay() earlier than
> *loops_per_jiffy* setup like you[1]. So I am very interesting in this
> patch. ;)
>
> I am also confused about the questions which Boris asked:
>
> whether do the CPU and TSC calibration too early just for using
> udelay()?
>
> this design broke our interface of x86_paltform.calibrate_cpu/tsc.
>
> And I also have a question below.
>
> [...]
>
>>>>>>>
>>>>>>> +static void __init simple_udelay_calibration(void)
>>>>>>> +{
>>>>>>> +unsigned int tsc_khz, cpu_khz;
>>>>>>> +unsigned long lpj;
>>>>>>> +
>>>>>>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>>>>>>> +return;
>
> if we don't have the TSC feature in booting CPU and
> it returns here, can we use udelay() correctly like before?
>
If we have TSC feature, we calculate a preciser loops_per_jiffy here.
Otherwise, we just keep it as before. This function doesn't broke the
use of udelay().
Best regards,
Lu Baolu
>
> [1] https://lkml.org/lkml/2017/7/3/276
>
> Thanks,
>
> dou.
>
>>> Thanks,
>>>
>>> dou.
>>>
>>>>>>> +
>>>>>>> +cpu_khz = x86_platform.calibrate_cpu();
>>>>>>> +tsc_khz = x86_platform.calibrate_tsc();
>>>>>>> +
>>>>>>> +tsc_khz = tsc_khz ? : cpu_khz;
>>>>>>> +if (!tsc_khz)
>>>>>>> +return;
>>>>>>> +
>>>>>>> +lpj = tsc_khz * 1000;
>>>>>>> +do_div(lpj, HZ);
>>>>>>> +loops_per_jiffy = lpj;
>>>>>>> +}
>>>>>>> +
>>>>>>> /*
>>>>>>> * Determine if we were loaded by an EFI loader. If so, then we have
>>>>>>> also been
>>>>>>> * passed the efi memmap, systab, etc., so we should use these data
>>>>>>> structures
>>>>>>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>>>>>>> */
>>>>>>> x86_configure_nx();
>>>>>>>
>>>>>>> +simple_udelay_calibration();
>>>>>>> +
>>>>>>> parse_early_param();
>>>>>>>
>>>>>>> #ifdef CONFIG_MEMORY_HOTPLUG
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>>
>
>
> --
> 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
>
Re: [PATCH v8 1/5] x86: add simple udelay calibration
Hi,
On 07/13/2017 09:39 AM, Dou Liyang wrote:
> Hi, Lu
>
> At 07/13/2017 09:17 AM, Lu Baolu wrote:
>> Hi,
>>
>> On 07/12/2017 04:02 PM, Dou Liyang wrote:
>>> Hi, Lu
>>>
>>> At 05/05/2017 08:50 PM, Boris Ostrovsky wrote:
>>>> On 05/05/2017 01:41 AM, Lu Baolu wrote:
>>>>> Hi,
>>>>>
>>>>> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
>>>>>> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>>>>>>> Add a simple udelay calibration in x86 architecture-specific
>>>>>>> boot-time initializations. This will get a workable estimate
>>>>>>> for loops_per_jiffy. Hence, udelay() could be used after this
>>>>>>> initialization.
>>>>>> This breaks Xen PV guests since at this point, and until
>>>>>> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
>>>>>> mapped, they cannot access pvclock.
>>>>>>
>>>>>> Is it reasonable to do this before tsc_init() is called? (The failure
>>>>>> has nothing to do with tsc_init(), really --- it's just that it is
>>>>>> called late enough that Xen PV guests get properly initialized.) If it
>>>>>> is, would it be possible to move simple_udelay_calibration() after
>>>>>> x86_init.paging.pagetable_init()?
>>>>> This is currently only used for bare metal. How about by-pass it
>>>>> for Xen PV guests?
>>>>
>>>> It is fixed this for Xen PV guests now (in the sense that we don't crash
>>>> anymore) but my question is still whether this is not too early. Besides
>>>> tsc_init() (which might not be important here), at the time when
>>>> simple_udelay_calibration() is invoked we haven't yet called:
>>>> * kvmclock_init(), which sets calibration routines for KVM
>>>> * init_hypervisor_platform(), which sets calibration routines for vmware
>>>> and Xen HVM
>>>> * x86_init.paging.pagetable_init(), which sets calibration routines for
>>>> Xen PV
>>>>
>>>
>>> I guess these may have been missed.
>>>
>>> Do you have any comments about these?
>>>
>>
>> The patch will be available in 4.13-rc1.
>
> Yes, I have seen it in the upstream.
>
> Firstly, I also met this problem want to call udelay() earlier than
> *loops_per_jiffy* setup like you[1]. So I am very interesting in this
> patch. ;)
>
> I am also confused about the questions which Boris asked:
>
> whether do the CPU and TSC calibration too early just for using
> udelay()?
>
> this design broke our interface of x86_paltform.calibrate_cpu/tsc.
>
> And I also have a question below.
>
> [...]
>
>>>>>>>
>>>>>>> +static void __init simple_udelay_calibration(void)
>>>>>>> +{
>>>>>>> +unsigned int tsc_khz, cpu_khz;
>>>>>>> +unsigned long lpj;
>>>>>>> +
>>>>>>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>>>>>>> +return;
>
> if we don't have the TSC feature in booting CPU and
> it returns here, can we use udelay() correctly like before?
>
If we have TSC feature, we calculate a preciser loops_per_jiffy here.
Otherwise, we just keep it as before. This function doesn't broke the
use of udelay().
Best regards,
Lu Baolu
>
> [1] https://lkml.org/lkml/2017/7/3/276
>
> Thanks,
>
> dou.
>
>>> Thanks,
>>>
>>> dou.
>>>
>>>>>>> +
>>>>>>> +cpu_khz = x86_platform.calibrate_cpu();
>>>>>>> +tsc_khz = x86_platform.calibrate_tsc();
>>>>>>> +
>>>>>>> +tsc_khz = tsc_khz ? : cpu_khz;
>>>>>>> +if (!tsc_khz)
>>>>>>> +return;
>>>>>>> +
>>>>>>> +lpj = tsc_khz * 1000;
>>>>>>> +do_div(lpj, HZ);
>>>>>>> +loops_per_jiffy = lpj;
>>>>>>> +}
>>>>>>> +
>>>>>>> /*
>>>>>>> * Determine if we were loaded by an EFI loader. If so, then we have
>>>>>>> also been
>>>>>>> * passed the efi memmap, systab, etc., so we should use these data
>>>>>>> structures
>>>>>>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>>>>>>> */
>>>>>>> x86_configure_nx();
>>>>>>>
>>>>>>> +simple_udelay_calibration();
>>>>>>> +
>>>>>>> parse_early_param();
>>>>>>>
>>>>>>> #ifdef CONFIG_MEMORY_HOTPLUG
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>>
>
>
> --
> 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
>
Re: [PATCH v8 1/5] x86: add simple udelay calibration
Hi,
On 07/12/2017 04:02 PM, Dou Liyang wrote:
> Hi, Lu
>
> At 05/05/2017 08:50 PM, Boris Ostrovsky wrote:
>> On 05/05/2017 01:41 AM, Lu Baolu wrote:
>>> Hi,
>>>
>>> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
>>>> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>>>>> Add a simple udelay calibration in x86 architecture-specific
>>>>> boot-time initializations. This will get a workable estimate
>>>>> for loops_per_jiffy. Hence, udelay() could be used after this
>>>>> initialization.
>>>> This breaks Xen PV guests since at this point, and until
>>>> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
>>>> mapped, they cannot access pvclock.
>>>>
>>>> Is it reasonable to do this before tsc_init() is called? (The failure
>>>> has nothing to do with tsc_init(), really --- it's just that it is
>>>> called late enough that Xen PV guests get properly initialized.) If it
>>>> is, would it be possible to move simple_udelay_calibration() after
>>>> x86_init.paging.pagetable_init()?
>>> This is currently only used for bare metal. How about by-pass it
>>> for Xen PV guests?
>>
>> It is fixed this for Xen PV guests now (in the sense that we don't crash
>> anymore) but my question is still whether this is not too early. Besides
>> tsc_init() (which might not be important here), at the time when
>> simple_udelay_calibration() is invoked we haven't yet called:
>> * kvmclock_init(), which sets calibration routines for KVM
>> * init_hypervisor_platform(), which sets calibration routines for vmware
>> and Xen HVM
>> * x86_init.paging.pagetable_init(), which sets calibration routines for
>> Xen PV
>>
>
> I guess these may have been missed.
>
> Do you have any comments about these?
>
The patch will be available in 4.13-rc1.
Best regards,
Lu Baolu
>> -boris
>>
>>
>>>
>>> Best regards,
>>> Lu Baolu
>>>
>>>> -boris
>>>>
>>>>
>>>>> Cc: Ingo Molnar <mi...@redhat.com>
>>>>> Cc: x...@kernel.org
>>>>> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
>>>>> ---
>>>>> arch/x86/kernel/setup.c | 22 ++
>>>>> 1 file changed, 22 insertions(+)
>>>>>
>>>>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>>>>> index 4bf0c89..e70204e 100644
>>>>> --- a/arch/x86/kernel/setup.c
>>>>> +++ b/arch/x86/kernel/setup.c
>>>>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self,
>>>>> unsigned long v, void *p)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +static void __init simple_udelay_calibration(void)
>>>>> +{
>>>>> +unsigned int tsc_khz, cpu_khz;
>>>>> +unsigned long lpj;
>>>>> +
>>>>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>>>>> +return;
>
>
> if it returns here, can we use udelay() correctly like before?
>
> Thanks,
>
> dou.
>
>>>>> +
>>>>> +cpu_khz = x86_platform.calibrate_cpu();
>>>>> +tsc_khz = x86_platform.calibrate_tsc();
>>>>> +
>>>>> +tsc_khz = tsc_khz ? : cpu_khz;
>>>>> +if (!tsc_khz)
>>>>> +return;
>>>>> +
>>>>> +lpj = tsc_khz * 1000;
>>>>> +do_div(lpj, HZ);
>>>>> +loops_per_jiffy = lpj;
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Determine if we were loaded by an EFI loader. If so, then we have
>>>>> also been
>>>>> * passed the efi memmap, systab, etc., so we should use these data
>>>>> structures
>>>>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>>>>> */
>>>>> x86_configure_nx();
>>>>>
>>>>> +simple_udelay_calibration();
>>>>> +
>>>>> parse_early_param();
>>>>>
>>>>> #ifdef CONFIG_MEMORY_HOTPLUG
>>
>>
>>
>>
>
>
> --
> 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
>
Re: [PATCH v8 1/5] x86: add simple udelay calibration
Hi,
On 07/12/2017 04:02 PM, Dou Liyang wrote:
> Hi, Lu
>
> At 05/05/2017 08:50 PM, Boris Ostrovsky wrote:
>> On 05/05/2017 01:41 AM, Lu Baolu wrote:
>>> Hi,
>>>
>>> On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
>>>> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>>>>> Add a simple udelay calibration in x86 architecture-specific
>>>>> boot-time initializations. This will get a workable estimate
>>>>> for loops_per_jiffy. Hence, udelay() could be used after this
>>>>> initialization.
>>>> This breaks Xen PV guests since at this point, and until
>>>> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
>>>> mapped, they cannot access pvclock.
>>>>
>>>> Is it reasonable to do this before tsc_init() is called? (The failure
>>>> has nothing to do with tsc_init(), really --- it's just that it is
>>>> called late enough that Xen PV guests get properly initialized.) If it
>>>> is, would it be possible to move simple_udelay_calibration() after
>>>> x86_init.paging.pagetable_init()?
>>> This is currently only used for bare metal. How about by-pass it
>>> for Xen PV guests?
>>
>> It is fixed this for Xen PV guests now (in the sense that we don't crash
>> anymore) but my question is still whether this is not too early. Besides
>> tsc_init() (which might not be important here), at the time when
>> simple_udelay_calibration() is invoked we haven't yet called:
>> * kvmclock_init(), which sets calibration routines for KVM
>> * init_hypervisor_platform(), which sets calibration routines for vmware
>> and Xen HVM
>> * x86_init.paging.pagetable_init(), which sets calibration routines for
>> Xen PV
>>
>
> I guess these may have been missed.
>
> Do you have any comments about these?
>
The patch will be available in 4.13-rc1.
Best regards,
Lu Baolu
>> -boris
>>
>>
>>>
>>> Best regards,
>>> Lu Baolu
>>>
>>>> -boris
>>>>
>>>>
>>>>> Cc: Ingo Molnar
>>>>> Cc: x...@kernel.org
>>>>> Signed-off-by: Lu Baolu
>>>>> ---
>>>>> arch/x86/kernel/setup.c | 22 ++
>>>>> 1 file changed, 22 insertions(+)
>>>>>
>>>>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>>>>> index 4bf0c89..e70204e 100644
>>>>> --- a/arch/x86/kernel/setup.c
>>>>> +++ b/arch/x86/kernel/setup.c
>>>>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self,
>>>>> unsigned long v, void *p)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +static void __init simple_udelay_calibration(void)
>>>>> +{
>>>>> +unsigned int tsc_khz, cpu_khz;
>>>>> +unsigned long lpj;
>>>>> +
>>>>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>>>>> +return;
>
>
> if it returns here, can we use udelay() correctly like before?
>
> Thanks,
>
> dou.
>
>>>>> +
>>>>> +cpu_khz = x86_platform.calibrate_cpu();
>>>>> +tsc_khz = x86_platform.calibrate_tsc();
>>>>> +
>>>>> +tsc_khz = tsc_khz ? : cpu_khz;
>>>>> +if (!tsc_khz)
>>>>> +return;
>>>>> +
>>>>> +lpj = tsc_khz * 1000;
>>>>> +do_div(lpj, HZ);
>>>>> +loops_per_jiffy = lpj;
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Determine if we were loaded by an EFI loader. If so, then we have
>>>>> also been
>>>>> * passed the efi memmap, systab, etc., so we should use these data
>>>>> structures
>>>>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>>>>> */
>>>>> x86_configure_nx();
>>>>>
>>>>> +simple_udelay_calibration();
>>>>> +
>>>>> parse_early_param();
>>>>>
>>>>> #ifdef CONFIG_MEMORY_HOTPLUG
>>
>>
>>
>>
>
>
> --
> 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
>
[PATCH 1/1] usb/early: Remove trace_printk() callers in xhci-dbc
Trace_printk() was used to log debug messages in xhci-dbc.c where printk() isn't feasible. As there should not be a single caller to trace_printk() in normal kernels, replace them with empty functions. Cc: Vlastimil Babka <vbabka.l...@gmail.com> Cc: Steven Rostedt <rost...@goodmis.org> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- drivers/usb/early/xhci-dbc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c index 1268818..12fe70b 100644 --- a/drivers/usb/early/xhci-dbc.c +++ b/drivers/usb/early/xhci-dbc.c @@ -32,7 +32,6 @@ static struct xdbc_state xdbc; static bool early_console_keep; -#define XDBC_TRACE #ifdef XDBC_TRACE #definexdbc_trace trace_printk #else -- 2.7.4
[PATCH 1/1] usb/early: Remove trace_printk() callers in xhci-dbc
Trace_printk() was used to log debug messages in xhci-dbc.c where printk() isn't feasible. As there should not be a single caller to trace_printk() in normal kernels, replace them with empty functions. Cc: Vlastimil Babka Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Greg Kroah-Hartman Signed-off-by: Lu Baolu --- drivers/usb/early/xhci-dbc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c index 1268818..12fe70b 100644 --- a/drivers/usb/early/xhci-dbc.c +++ b/drivers/usb/early/xhci-dbc.c @@ -32,7 +32,6 @@ static struct xdbc_state xdbc; static bool early_console_keep; -#define XDBC_TRACE #ifdef XDBC_TRACE #definexdbc_trace trace_printk #else -- 2.7.4
Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability
Hi, On 05/31/2017 05:38 PM, Vlastimil Babka wrote: > On 05/31/2017 05:27 AM, Lu Baolu wrote: >> Hi, >> >> On 05/30/2017 09:46 PM, Vlastimil Babka wrote: >>> On 03/21/2017 09:01 AM, Lu Baolu wrote: >>>> XHCI debug capability (DbC) is an optional but standalone >>>> functionality provided by an xHCI host controller. Software >>>> learns this capability by walking through the extended >>>> capability list of the host. XHCI specification describes >>>> DbC in the section 7.6. >>>> >>>> This patch introduces the code to probe and initialize the >>>> debug capability hardware during early boot. With hardware >>>> initialized, the debug target (system on which this code is >>>> running) will present a debug device through the debug port >>>> (normally the first USB3 port). The debug device is fully >>>> compliant with the USB framework and provides the equivalent >>>> of a very high performance (USB3) full-duplex serial link >>>> between the debug host and target. The DbC functionality is >>>> independent of the xHCI host. There isn't any precondition >>>> from the xHCI host side for the DbC to work. >>>> >>>> One use for this feature is kernel debugging, for example >>>> when your machine crashes very early before the regular >>>> console code is initialized. Other uses include simpler, >>>> lockless logging instead of a full-blown printk console >>>> driver and klogd. >>>> >>>> Cc: Ingo Molnar <mi...@redhat.com> >>>> Cc: Mathias Nyman <mathias.ny...@linux.intel.com> >>>> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> >>> ... >>> >>>> + >>>> +#define XDBC_TRACE >>>> +#ifdef XDBC_TRACE >>>> +#define xdbc_trace trace_printk >>> Did you forget to remove the #define XDBC_TRACE? >>> >>> Enabling this driver brings the "trace_printk() being used. Allocating >>> extra memory. This means that this is a DEBUG kernel and it is unsafe >>> for production use." message in 4.12-rcX dmesg. >> This feature is only for a DEBUG kernel, should not be enabled for >> any production kernel. This was the reason I enabled trace_printk() >> by default. > Hmm, but it seems we generally enable all these early printk > features/drivers in our distro kernels. They are not active without a > early_printk=X bootparam anyway, right? It's much more convenient to > e.g. just tell customer to change a param when debugging something than > to install a debug kernel. So I wouldn't agree that only a DEBUG kernel > should have this compiled in. Okay, I will try to find a fix. Best regards, Lu Baolu > > Thanks, > Vlastimil > >> Best regards, >> Lu Baolu >> >>> Thanks, >>> Vlastimil >>> > -- > 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 >
Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability
Hi, On 05/31/2017 05:38 PM, Vlastimil Babka wrote: > On 05/31/2017 05:27 AM, Lu Baolu wrote: >> Hi, >> >> On 05/30/2017 09:46 PM, Vlastimil Babka wrote: >>> On 03/21/2017 09:01 AM, Lu Baolu wrote: >>>> XHCI debug capability (DbC) is an optional but standalone >>>> functionality provided by an xHCI host controller. Software >>>> learns this capability by walking through the extended >>>> capability list of the host. XHCI specification describes >>>> DbC in the section 7.6. >>>> >>>> This patch introduces the code to probe and initialize the >>>> debug capability hardware during early boot. With hardware >>>> initialized, the debug target (system on which this code is >>>> running) will present a debug device through the debug port >>>> (normally the first USB3 port). The debug device is fully >>>> compliant with the USB framework and provides the equivalent >>>> of a very high performance (USB3) full-duplex serial link >>>> between the debug host and target. The DbC functionality is >>>> independent of the xHCI host. There isn't any precondition >>>> from the xHCI host side for the DbC to work. >>>> >>>> One use for this feature is kernel debugging, for example >>>> when your machine crashes very early before the regular >>>> console code is initialized. Other uses include simpler, >>>> lockless logging instead of a full-blown printk console >>>> driver and klogd. >>>> >>>> Cc: Ingo Molnar >>>> Cc: Mathias Nyman >>>> Signed-off-by: Lu Baolu >>> ... >>> >>>> + >>>> +#define XDBC_TRACE >>>> +#ifdef XDBC_TRACE >>>> +#define xdbc_trace trace_printk >>> Did you forget to remove the #define XDBC_TRACE? >>> >>> Enabling this driver brings the "trace_printk() being used. Allocating >>> extra memory. This means that this is a DEBUG kernel and it is unsafe >>> for production use." message in 4.12-rcX dmesg. >> This feature is only for a DEBUG kernel, should not be enabled for >> any production kernel. This was the reason I enabled trace_printk() >> by default. > Hmm, but it seems we generally enable all these early printk > features/drivers in our distro kernels. They are not active without a > early_printk=X bootparam anyway, right? It's much more convenient to > e.g. just tell customer to change a param when debugging something than > to install a debug kernel. So I wouldn't agree that only a DEBUG kernel > should have this compiled in. Okay, I will try to find a fix. Best regards, Lu Baolu > > Thanks, > Vlastimil > >> Best regards, >> Lu Baolu >> >>> Thanks, >>> Vlastimil >>> > -- > 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 >
Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability
Hi, On 05/31/2017 02:24 PM, Steven Rostedt wrote: > On Wed, 31 May 2017 11:27:19 +0800 > Lu Baolu <baolu...@linux.intel.com> wrote: > > >>>> + >>>> +#define XDBC_TRACE >>>> +#ifdef XDBC_TRACE >>>> +#define xdbc_trace trace_printk >>> Did you forget to remove the #define XDBC_TRACE? >>> >>> Enabling this driver brings the "trace_printk() being used. >>> Allocating extra memory. This means that this is a DEBUG kernel and >>> it is unsafe for production use." message in 4.12-rcX dmesg. >> This feature is only for a DEBUG kernel, should not be enabled for >> any production kernel. This was the reason I enabled trace_printk() >> by default. > Yes, it is perfectly fine to use trace_printk() for debug only configs. > But if if you have it there and it is helpful to debug something that > happens in a production system, you may want to look into creating a > real tracepoint for the locations. Yes. Good suggestion. I will try this. Thank you! Best regards, Lu Baolu > > -- Steve > -- > 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 >
Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability
Hi, On 05/31/2017 02:24 PM, Steven Rostedt wrote: > On Wed, 31 May 2017 11:27:19 +0800 > Lu Baolu wrote: > > >>>> + >>>> +#define XDBC_TRACE >>>> +#ifdef XDBC_TRACE >>>> +#define xdbc_trace trace_printk >>> Did you forget to remove the #define XDBC_TRACE? >>> >>> Enabling this driver brings the "trace_printk() being used. >>> Allocating extra memory. This means that this is a DEBUG kernel and >>> it is unsafe for production use." message in 4.12-rcX dmesg. >> This feature is only for a DEBUG kernel, should not be enabled for >> any production kernel. This was the reason I enabled trace_printk() >> by default. > Yes, it is perfectly fine to use trace_printk() for debug only configs. > But if if you have it there and it is helpful to debug something that > happens in a production system, you may want to look into creating a > real tracepoint for the locations. Yes. Good suggestion. I will try this. Thank you! Best regards, Lu Baolu > > -- Steve > -- > 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 >
Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability
Hi, On 05/30/2017 09:46 PM, Vlastimil Babka wrote: > On 03/21/2017 09:01 AM, Lu Baolu wrote: >> XHCI debug capability (DbC) is an optional but standalone >> functionality provided by an xHCI host controller. Software >> learns this capability by walking through the extended >> capability list of the host. XHCI specification describes >> DbC in the section 7.6. >> >> This patch introduces the code to probe and initialize the >> debug capability hardware during early boot. With hardware >> initialized, the debug target (system on which this code is >> running) will present a debug device through the debug port >> (normally the first USB3 port). The debug device is fully >> compliant with the USB framework and provides the equivalent >> of a very high performance (USB3) full-duplex serial link >> between the debug host and target. The DbC functionality is >> independent of the xHCI host. There isn't any precondition >> from the xHCI host side for the DbC to work. >> >> One use for this feature is kernel debugging, for example >> when your machine crashes very early before the regular >> console code is initialized. Other uses include simpler, >> lockless logging instead of a full-blown printk console >> driver and klogd. >> >> Cc: Ingo Molnar <mi...@redhat.com> >> Cc: Mathias Nyman <mathias.ny...@linux.intel.com> >> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> > ... > >> + >> +#define XDBC_TRACE >> +#ifdef XDBC_TRACE >> +#define xdbc_trace trace_printk > Did you forget to remove the #define XDBC_TRACE? > > Enabling this driver brings the "trace_printk() being used. Allocating > extra memory. This means that this is a DEBUG kernel and it is unsafe > for production use." message in 4.12-rcX dmesg. This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default. Best regards, Lu Baolu > Thanks, > Vlastimil >
Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability
Hi, On 05/30/2017 09:46 PM, Vlastimil Babka wrote: > On 03/21/2017 09:01 AM, Lu Baolu wrote: >> XHCI debug capability (DbC) is an optional but standalone >> functionality provided by an xHCI host controller. Software >> learns this capability by walking through the extended >> capability list of the host. XHCI specification describes >> DbC in the section 7.6. >> >> This patch introduces the code to probe and initialize the >> debug capability hardware during early boot. With hardware >> initialized, the debug target (system on which this code is >> running) will present a debug device through the debug port >> (normally the first USB3 port). The debug device is fully >> compliant with the USB framework and provides the equivalent >> of a very high performance (USB3) full-duplex serial link >> between the debug host and target. The DbC functionality is >> independent of the xHCI host. There isn't any precondition >> from the xHCI host side for the DbC to work. >> >> One use for this feature is kernel debugging, for example >> when your machine crashes very early before the regular >> console code is initialized. Other uses include simpler, >> lockless logging instead of a full-blown printk console >> driver and klogd. >> >> Cc: Ingo Molnar >> Cc: Mathias Nyman >> Signed-off-by: Lu Baolu > ... > >> + >> +#define XDBC_TRACE >> +#ifdef XDBC_TRACE >> +#define xdbc_trace trace_printk > Did you forget to remove the #define XDBC_TRACE? > > Enabling this driver brings the "trace_printk() being used. Allocating > extra memory. This means that this is a DEBUG kernel and it is unsafe > for production use." message in 4.12-rcX dmesg. This feature is only for a DEBUG kernel, should not be enabled for any production kernel. This was the reason I enabled trace_printk() by default. Best regards, Lu Baolu > Thanks, > Vlastimil >
Re: [PATCH] x86/timers: Move simple_udelay_calibration past init_hypervisor_platform
On 05/25/2017 02:04 AM, Jan Kiszka wrote:
> This ensures that adjustments to x86_platform done by the hypervisor
> setup is already respected by this simple calibration.
>
> The current user of this, introduced by 1b5aeebf3a92 ("x86/earlyprintk:
> Add support for earlyprintk via USB3 debug port"), comes much later
> into play.
Acked-by: Lu Baolu <baolu...@linux.intel.com>
>
> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
> ---
> arch/x86/kernel/setup.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 0b4d3c686b1e..f81823695014 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -980,8 +980,6 @@ void __init setup_arch(char **cmdline_p)
>*/
> x86_configure_nx();
>
> - simple_udelay_calibration();
> -
> parse_early_param();
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> @@ -1041,6 +1039,8 @@ void __init setup_arch(char **cmdline_p)
>*/
> init_hypervisor_platform();
>
> + simple_udelay_calibration();
> +
> x86_init.resources.probe_roms();
>
> /* after parse_early_param, so could debug it */
>
Re: [PATCH] x86/timers: Move simple_udelay_calibration past init_hypervisor_platform
On 05/25/2017 02:04 AM, Jan Kiszka wrote:
> This ensures that adjustments to x86_platform done by the hypervisor
> setup is already respected by this simple calibration.
>
> The current user of this, introduced by 1b5aeebf3a92 ("x86/earlyprintk:
> Add support for earlyprintk via USB3 debug port"), comes much later
> into play.
Acked-by: Lu Baolu
>
> Signed-off-by: Jan Kiszka
> ---
> arch/x86/kernel/setup.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 0b4d3c686b1e..f81823695014 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -980,8 +980,6 @@ void __init setup_arch(char **cmdline_p)
>*/
> x86_configure_nx();
>
> - simple_udelay_calibration();
> -
> parse_early_param();
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> @@ -1041,6 +1039,8 @@ void __init setup_arch(char **cmdline_p)
>*/
> init_hypervisor_platform();
>
> + simple_udelay_calibration();
> +
> x86_init.resources.probe_roms();
>
> /* after parse_early_param, so could debug it */
>
Re: [tip:x86/debug] x86/timers: Add simple udelay calibration
Hi,
On 05/25/2017 12:56 AM, Jan Kiszka wrote:
> On 2017-03-21 13:19, tip-bot for Lu Baolu wrote:
>> Commit-ID: dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
>> Gitweb:
>> http://git.kernel.org/tip/dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
>> Author: Lu Baolu <baolu...@linux.intel.com>
>> AuthorDate: Tue, 21 Mar 2017 16:01:29 +0800
>> Committer: Ingo Molnar <mi...@kernel.org>
>> CommitDate: Tue, 21 Mar 2017 12:28:45 +0100
>>
>> x86/timers: Add simple udelay calibration
>>
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initialization.
>>
>> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
>> Acked-by: Thomas Gleixner <t...@linutronix.de>
>> Cc: Andy Lutomirski <l...@kernel.org>
>> Cc: Borislav Petkov <b...@alien8.de>
>> Cc: Brian Gerst <brge...@gmail.com>
>> Cc: Denys Vlasenko <dvlas...@redhat.com>
>> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> Cc: H. Peter Anvin <h...@zytor.com>
>> Cc: Josh Poimboeuf <jpoim...@redhat.com>
>> Cc: Linus Torvalds <torva...@linux-foundation.org>
>> Cc: Mathias Nyman <mathias.ny...@linux.intel.com>
>> Cc: Peter Zijlstra <pet...@infradead.org>
>> Cc: linux-...@vger.kernel.org
>> Link:
>> http://lkml.kernel.org/r/1490083293-3792-2-git-send-email-baolu...@linux.intel.com
>> Signed-off-by: Ingo Molnar <mi...@kernel.org>
>> ---
>> arch/x86/kernel/setup.c | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4bf0c89..e70204e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self,
>> unsigned long v, void *p)
>> return 0;
>> }
>>
>> +static void __init simple_udelay_calibration(void)
>> +{
>> +unsigned int tsc_khz, cpu_khz;
>> +unsigned long lpj;
>> +
>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>> +return;
>> +
>> +cpu_khz = x86_platform.calibrate_cpu();
>> +tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +tsc_khz = tsc_khz ? : cpu_khz;
>> +if (!tsc_khz)
>> +return;
>> +
>> +lpj = tsc_khz * 1000;
>> +do_div(lpj, HZ);
>> +loops_per_jiffy = lpj;
>> +}
>> +
>> /*
>> * Determine if we were loaded by an EFI loader. If so, then we have also
>> been
>> * passed the efi memmap, systab, etc., so we should use these data
>> structures
>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>> */
>> x86_configure_nx();
>>
>> +simple_udelay_calibration();
>> +
>> parse_early_param();
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>>
> Can we move this past init_hypervisor_platform()?
Yes, we can as far as I can see.
Best regards,
Lu Baolu
> Otherwise, the
> x86_platform hooks aren't fully initialized yet, and we may use the
> wrong functions.
>
> Jan
>
Re: [tip:x86/debug] x86/timers: Add simple udelay calibration
Hi,
On 05/25/2017 12:56 AM, Jan Kiszka wrote:
> On 2017-03-21 13:19, tip-bot for Lu Baolu wrote:
>> Commit-ID: dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
>> Gitweb:
>> http://git.kernel.org/tip/dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
>> Author: Lu Baolu
>> AuthorDate: Tue, 21 Mar 2017 16:01:29 +0800
>> Committer: Ingo Molnar
>> CommitDate: Tue, 21 Mar 2017 12:28:45 +0100
>>
>> x86/timers: Add simple udelay calibration
>>
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initialization.
>>
>> Signed-off-by: Lu Baolu
>> Acked-by: Thomas Gleixner
>> Cc: Andy Lutomirski
>> Cc: Borislav Petkov
>> Cc: Brian Gerst
>> Cc: Denys Vlasenko
>> Cc: Greg Kroah-Hartman
>> Cc: H. Peter Anvin
>> Cc: Josh Poimboeuf
>> Cc: Linus Torvalds
>> Cc: Mathias Nyman
>> Cc: Peter Zijlstra
>> Cc: linux-...@vger.kernel.org
>> Link:
>> http://lkml.kernel.org/r/1490083293-3792-2-git-send-email-baolu...@linux.intel.com
>> Signed-off-by: Ingo Molnar
>> ---
>> arch/x86/kernel/setup.c | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4bf0c89..e70204e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self,
>> unsigned long v, void *p)
>> return 0;
>> }
>>
>> +static void __init simple_udelay_calibration(void)
>> +{
>> +unsigned int tsc_khz, cpu_khz;
>> +unsigned long lpj;
>> +
>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>> +return;
>> +
>> +cpu_khz = x86_platform.calibrate_cpu();
>> +tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +tsc_khz = tsc_khz ? : cpu_khz;
>> +if (!tsc_khz)
>> +return;
>> +
>> +lpj = tsc_khz * 1000;
>> +do_div(lpj, HZ);
>> +loops_per_jiffy = lpj;
>> +}
>> +
>> /*
>> * Determine if we were loaded by an EFI loader. If so, then we have also
>> been
>> * passed the efi memmap, systab, etc., so we should use these data
>> structures
>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>> */
>> x86_configure_nx();
>>
>> +simple_udelay_calibration();
>> +
>> parse_early_param();
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>>
> Can we move this past init_hypervisor_platform()?
Yes, we can as far as I can see.
Best regards,
Lu Baolu
> Otherwise, the
> x86_platform hooks aren't fully initialized yet, and we may use the
> wrong functions.
>
> Jan
>
Re: [PATCH v8 1/5] x86: add simple udelay calibration
Hi,
On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initialization.
> This breaks Xen PV guests since at this point, and until
> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
> mapped, they cannot access pvclock.
>
> Is it reasonable to do this before tsc_init() is called? (The failure
> has nothing to do with tsc_init(), really --- it's just that it is
> called late enough that Xen PV guests get properly initialized.) If it
> is, would it be possible to move simple_udelay_calibration() after
> x86_init.paging.pagetable_init()?
This is currently only used for bare metal. How about by-pass it
for Xen PV guests?
Best regards,
Lu Baolu
>
> -boris
>
>
>> Cc: Ingo Molnar <mi...@redhat.com>
>> Cc: x...@kernel.org
>> Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
>> ---
>> arch/x86/kernel/setup.c | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4bf0c89..e70204e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self,
>> unsigned long v, void *p)
>> return 0;
>> }
>>
>> +static void __init simple_udelay_calibration(void)
>> +{
>> +unsigned int tsc_khz, cpu_khz;
>> +unsigned long lpj;
>> +
>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>> +return;
>> +
>> +cpu_khz = x86_platform.calibrate_cpu();
>> +tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +tsc_khz = tsc_khz ? : cpu_khz;
>> +if (!tsc_khz)
>> +return;
>> +
>> +lpj = tsc_khz * 1000;
>> +do_div(lpj, HZ);
>> +loops_per_jiffy = lpj;
>> +}
>> +
>> /*
>> * Determine if we were loaded by an EFI loader. If so, then we have also
>> been
>> * passed the efi memmap, systab, etc., so we should use these data
>> structures
>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>> */
>> x86_configure_nx();
>>
>> +simple_udelay_calibration();
>> +
>> parse_early_param();
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>
Re: [PATCH v8 1/5] x86: add simple udelay calibration
Hi,
On 05/03/2017 06:38 AM, Boris Ostrovsky wrote:
> On 03/21/2017 04:01 AM, Lu Baolu wrote:
>> Add a simple udelay calibration in x86 architecture-specific
>> boot-time initializations. This will get a workable estimate
>> for loops_per_jiffy. Hence, udelay() could be used after this
>> initialization.
> This breaks Xen PV guests since at this point, and until
> x86_init.paging.pagetable_init() which is when pvclock_vcpu_time_info is
> mapped, they cannot access pvclock.
>
> Is it reasonable to do this before tsc_init() is called? (The failure
> has nothing to do with tsc_init(), really --- it's just that it is
> called late enough that Xen PV guests get properly initialized.) If it
> is, would it be possible to move simple_udelay_calibration() after
> x86_init.paging.pagetable_init()?
This is currently only used for bare metal. How about by-pass it
for Xen PV guests?
Best regards,
Lu Baolu
>
> -boris
>
>
>> Cc: Ingo Molnar
>> Cc: x...@kernel.org
>> Signed-off-by: Lu Baolu
>> ---
>> arch/x86/kernel/setup.c | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4bf0c89..e70204e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self,
>> unsigned long v, void *p)
>> return 0;
>> }
>>
>> +static void __init simple_udelay_calibration(void)
>> +{
>> +unsigned int tsc_khz, cpu_khz;
>> +unsigned long lpj;
>> +
>> +if (!boot_cpu_has(X86_FEATURE_TSC))
>> +return;
>> +
>> +cpu_khz = x86_platform.calibrate_cpu();
>> +tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +tsc_khz = tsc_khz ? : cpu_khz;
>> +if (!tsc_khz)
>> +return;
>> +
>> +lpj = tsc_khz * 1000;
>> +do_div(lpj, HZ);
>> +loops_per_jiffy = lpj;
>> +}
>> +
>> /*
>> * Determine if we were loaded by an EFI loader. If so, then we have also
>> been
>> * passed the efi memmap, systab, etc., so we should use these data
>> structures
>> @@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
>> */
>> x86_configure_nx();
>>
>> +simple_udelay_calibration();
>> +
>> parse_early_param();
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>
Re: [PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface"
Hi, On 03/24/2017 07:47 PM, Chanwoo Choi wrote: > Hi Lu Baolu, > > On 2017년 03월 24일 20:24, Andy Shevchenko wrote: >> On Fri, 2017-03-24 at 20:03 +0900, Chanwoo Choi wrote: >>> On 2017년 03월 22일 22:09, Andy Shevchenko wrote: >>>> On Wed, 2017-03-22 at 10:14 +0900, Chanwoo Choi wrote: >>>>> On 2017년 03월 22일 03:37, Andy Shevchenko wrote: >>>>>> The commit 942c7924a51e introduced a check for ACPI handle for >>>>>> the >>>>>> device that never appears on any ACPI-enabled platform so far. >>>>>> It >>>>>> seems >>>>>> a confusion with extcon-intel-int3496 which does support ACPI- >>>>>> enabled >>>>>> platforms. >>>>> Only for the reason that there is no any usecase until now, >>>>> and remove the confusion between extcon-usb-gpio and extcon-intel- >>>>> int3496. >>>>> Should we revert it? >>>> >>>>> I think that both extcon-usb-gpio and extcon-intel-int3496 >>>>> driver are not same operation perfectly. Also, the filename >>>>> of extcon-intel-int3496 has specific name. Instead, extcon-usb- >>>>> gpio.c >>>>> is more common device driver. >>>>> >>>>> Can the extcon-intel-int3496.c support the everything on acpi >>>>> side? >>>> For my understanding we have the only driver for now for USB mux in >>>> the >>>> kernel for ACPI-enabled platforms. >>>> >>>> Besides confusion, it makes harder to fix a real bugs in at least >>>> GPIO >>>> ACPI library since we need to amend any user of it first. While >>>> confusion is here, I can't do anything to not possible break the >>>> functionality of the driver in a real use case if any (I doubt there >>>> is >>>> any in this particular case). >>>> >>>> So, my opinion here is "yes, we should revert it until we have a >>>> confirmation that there is a product which is using this among with >>>> ACPI" (which I doubt ever exists). >>> Because you told me there was not any use case of extcon-usb-gpioc.c >>> on acpi side. But, I think that it is not enough as the reason. >>> >>> Because I already mentioned, >>> 1. >>> "The both extcon-usb-gpio and extcon-intel-int3496 driver >>> are not same operation perfectly." It two driver are same operation >>> and there is no use case on acpi side, I may agree your suggestion. >>> But, in this case, they are different between two drivers. >>> >>> 2. >>> Also, extcon-intel-int3496 has the specific name 'int3496'. >>> I think that it only depends on the specific device driver on acpi >>> side. >>> I don't think it cover all of use case on acpi side. >> Just one question: is there *real* existing device where ACPI table >> contains something related to extcon-usb-gpio? >> >> I'm pretty sure the answer is no. Moreover, Lu pointed me out to the >> series which tried to update the driver in question to support int3496. >> Though it comes as a separate driver, thus that series was abandoned >> IIUC. >> >> I really don't care if some dead confusing code will be left in some >> poor driver, at the end it's not my call. >> >> P.S. We already spent enough time making a mountain out of a molehill. I >> rest my case. >> > OK. Just I want to receive the reply from Lu Baolu. > > In the "extcon-usb-gpio ACPI support" mail thread, > I understood that Lu Baolu said that the related patches were abandoned. > > To Lu Baolu, > Don't you ever use the extcon-usb-gpio.c in the future on acpi side? > If you agree it, I'll revert it. > I will not use extcon-usb-gpio.c in the future on acpi side AFAICS. Best regards, Lu Baolu
Re: [PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface"
Hi, On 03/24/2017 07:47 PM, Chanwoo Choi wrote: > Hi Lu Baolu, > > On 2017년 03월 24일 20:24, Andy Shevchenko wrote: >> On Fri, 2017-03-24 at 20:03 +0900, Chanwoo Choi wrote: >>> On 2017년 03월 22일 22:09, Andy Shevchenko wrote: >>>> On Wed, 2017-03-22 at 10:14 +0900, Chanwoo Choi wrote: >>>>> On 2017년 03월 22일 03:37, Andy Shevchenko wrote: >>>>>> The commit 942c7924a51e introduced a check for ACPI handle for >>>>>> the >>>>>> device that never appears on any ACPI-enabled platform so far. >>>>>> It >>>>>> seems >>>>>> a confusion with extcon-intel-int3496 which does support ACPI- >>>>>> enabled >>>>>> platforms. >>>>> Only for the reason that there is no any usecase until now, >>>>> and remove the confusion between extcon-usb-gpio and extcon-intel- >>>>> int3496. >>>>> Should we revert it? >>>> >>>>> I think that both extcon-usb-gpio and extcon-intel-int3496 >>>>> driver are not same operation perfectly. Also, the filename >>>>> of extcon-intel-int3496 has specific name. Instead, extcon-usb- >>>>> gpio.c >>>>> is more common device driver. >>>>> >>>>> Can the extcon-intel-int3496.c support the everything on acpi >>>>> side? >>>> For my understanding we have the only driver for now for USB mux in >>>> the >>>> kernel for ACPI-enabled platforms. >>>> >>>> Besides confusion, it makes harder to fix a real bugs in at least >>>> GPIO >>>> ACPI library since we need to amend any user of it first. While >>>> confusion is here, I can't do anything to not possible break the >>>> functionality of the driver in a real use case if any (I doubt there >>>> is >>>> any in this particular case). >>>> >>>> So, my opinion here is "yes, we should revert it until we have a >>>> confirmation that there is a product which is using this among with >>>> ACPI" (which I doubt ever exists). >>> Because you told me there was not any use case of extcon-usb-gpioc.c >>> on acpi side. But, I think that it is not enough as the reason. >>> >>> Because I already mentioned, >>> 1. >>> "The both extcon-usb-gpio and extcon-intel-int3496 driver >>> are not same operation perfectly." It two driver are same operation >>> and there is no use case on acpi side, I may agree your suggestion. >>> But, in this case, they are different between two drivers. >>> >>> 2. >>> Also, extcon-intel-int3496 has the specific name 'int3496'. >>> I think that it only depends on the specific device driver on acpi >>> side. >>> I don't think it cover all of use case on acpi side. >> Just one question: is there *real* existing device where ACPI table >> contains something related to extcon-usb-gpio? >> >> I'm pretty sure the answer is no. Moreover, Lu pointed me out to the >> series which tried to update the driver in question to support int3496. >> Though it comes as a separate driver, thus that series was abandoned >> IIUC. >> >> I really don't care if some dead confusing code will be left in some >> poor driver, at the end it's not my call. >> >> P.S. We already spent enough time making a mountain out of a molehill. I >> rest my case. >> > OK. Just I want to receive the reply from Lu Baolu. > > In the "extcon-usb-gpio ACPI support" mail thread, > I understood that Lu Baolu said that the related patches were abandoned. > > To Lu Baolu, > Don't you ever use the extcon-usb-gpio.c in the future on acpi side? > If you agree it, I'll revert it. > I will not use extcon-usb-gpio.c in the future on acpi side AFAICS. Best regards, Lu Baolu
Re: [PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
Hi, On 03/21/2017 07:33 PM, Ingo Molnar wrote: >> Lu Baolu (5): >> > x86: add simple udelay calibration >> > usb: early: add driver for xhci debug capability >> > x86: add support for earlyprintk via USB3 debug port >> > usb: serial: add dbc debug device support to usb_debug >> > usb: doc: add document for USB3 debug port usage >> > >> > Documentation/admin-guide/kernel-parameters.txt |1 + >> > Documentation/usb/usb3-debug-port.rst | 100 +++ >> > arch/x86/Kconfig.debug | 23 + >> > arch/x86/kernel/early_printk.c |5 + >> > arch/x86/kernel/setup.c | 26 + >> > drivers/usb/Makefile|2 +- >> > drivers/usb/early/Makefile |1 + >> > drivers/usb/early/xhci-dbc.c| 1014 >> > +++ >> > drivers/usb/early/xhci-dbc.h| 211 + >> > drivers/usb/serial/usb_debug.c | 28 +- >> > include/linux/usb/xhci-dbgp.h | 29 + >> > 11 files changed, 1436 insertions(+), 4 deletions(-) >> > create mode 100644 Documentation/usb/usb3-debug-port.rst >> > create mode 100644 drivers/usb/early/xhci-dbc.c >> > create mode 100644 drivers/usb/early/xhci-dbc.h >> > create mode 100644 include/linux/usb/xhci-dbgp.h > Ok, this has now become a high quality series with picture-perfect patches > AFAICS. > > Thomas also gave his Acked-by to all the patches. > > I've applied them locally to -tip (it appears the USB maintainers are still > fine > with this being carried in tip:x86/debug for a v4.12 merge, right?), and will > push > them out and will propagate them to linux-next as well if they pass testing. > > Thanks for the great work! Thank you! Best regards, Lu Baolu
Re: [PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
Hi, On 03/21/2017 07:33 PM, Ingo Molnar wrote: >> Lu Baolu (5): >> > x86: add simple udelay calibration >> > usb: early: add driver for xhci debug capability >> > x86: add support for earlyprintk via USB3 debug port >> > usb: serial: add dbc debug device support to usb_debug >> > usb: doc: add document for USB3 debug port usage >> > >> > Documentation/admin-guide/kernel-parameters.txt |1 + >> > Documentation/usb/usb3-debug-port.rst | 100 +++ >> > arch/x86/Kconfig.debug | 23 + >> > arch/x86/kernel/early_printk.c |5 + >> > arch/x86/kernel/setup.c | 26 + >> > drivers/usb/Makefile|2 +- >> > drivers/usb/early/Makefile |1 + >> > drivers/usb/early/xhci-dbc.c| 1014 >> > +++ >> > drivers/usb/early/xhci-dbc.h| 211 + >> > drivers/usb/serial/usb_debug.c | 28 +- >> > include/linux/usb/xhci-dbgp.h | 29 + >> > 11 files changed, 1436 insertions(+), 4 deletions(-) >> > create mode 100644 Documentation/usb/usb3-debug-port.rst >> > create mode 100644 drivers/usb/early/xhci-dbc.c >> > create mode 100644 drivers/usb/early/xhci-dbc.h >> > create mode 100644 include/linux/usb/xhci-dbgp.h > Ok, this has now become a high quality series with picture-perfect patches > AFAICS. > > Thomas also gave his Acked-by to all the patches. > > I've applied them locally to -tip (it appears the USB maintainers are still > fine > with this being carried in tip:x86/debug for a v4.12 merge, right?), and will > push > them out and will propagate them to linux-next as well if they pass testing. > > Thanks for the great work! Thank you! Best regards, Lu Baolu
[tip:x86/debug] usb/serial: Add DBC debug device support to usb_debug
Commit-ID: 57fb47279a04cd53641dc5ae55a6d47e4f32a2fd
Gitweb: http://git.kernel.org/tip/57fb47279a04cd53641dc5ae55a6d47e4f32a2fd
Author: Lu Baolu <baolu...@linux.intel.com>
AuthorDate: Tue, 21 Mar 2017 16:01:32 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 21 Mar 2017 12:30:17 +0100
usb/serial: Add DBC debug device support to usb_debug
This patch adds DBC debug device support to the usb_debug driver.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Acked-by: Thomas Gleixner <t...@linutronix.de>
Acked-by: Johan Hovold <jo...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Mathias Nyman <mathias.ny...@linux.intel.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1490083293-3792-5-git-send-email-baolu...@linux.intel.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
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/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
};
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+ { USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
/* This HW really does not support a serial break, so one will be
* emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
};
+static struct usb_serial_driver dbc_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = "xhci_dbc",
+ },
+ .id_table = dbc_id_table,
+ .num_ports =1,
+ .break_ctl =usb_debug_break_ctl,
+ .process_read_urb = usb_debug_process_read_urb,
+};
+
static struct usb_serial_driver * const serial_drivers[] = {
- _device, NULL
+ _device, _device, NULL
};
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_LICENSE("GPL");
[tip:x86/debug] usb/serial: Add DBC debug device support to usb_debug
Commit-ID: 57fb47279a04cd53641dc5ae55a6d47e4f32a2fd
Gitweb: http://git.kernel.org/tip/57fb47279a04cd53641dc5ae55a6d47e4f32a2fd
Author: Lu Baolu
AuthorDate: Tue, 21 Mar 2017 16:01:32 +0800
Committer: Ingo Molnar
CommitDate: Tue, 21 Mar 2017 12:30:17 +0100
usb/serial: Add DBC debug device support to usb_debug
This patch adds DBC debug device support to the usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Thomas Gleixner
Acked-by: Johan Hovold
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Mathias Nyman
Cc: Peter Zijlstra
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1490083293-3792-5-git-send-email-baolu...@linux.intel.com
Signed-off-by: Ingo Molnar
---
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/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
};
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+ { USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
/* This HW really does not support a serial break, so one will be
* emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
};
+static struct usb_serial_driver dbc_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = "xhci_dbc",
+ },
+ .id_table = dbc_id_table,
+ .num_ports =1,
+ .break_ctl =usb_debug_break_ctl,
+ .process_read_urb = usb_debug_process_read_urb,
+};
+
static struct usb_serial_driver * const serial_drivers[] = {
- _device, NULL
+ _device, _device, NULL
};
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_LICENSE("GPL");
[tip:x86/debug] usb/doc: Add document for USB3 debug port usage
Commit-ID: 1b326277798aa820c1043617786609b9bb4bee78 Gitweb: http://git.kernel.org/tip/1b326277798aa820c1043617786609b9bb4bee78 Author: Lu Baolu <baolu...@linux.intel.com> AuthorDate: Tue, 21 Mar 2017 16:01:33 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 21 Mar 2017 12:30:17 +0100 usb/doc: Add document for USB3 debug port usage Add Documentation/usb/usb3-debug-port.rst. This document includes the guide for using USB3 debug port. Signed-off-by: Lu Baolu <baolu...@linux.intel.com> Acked-by: Thomas Gleixner <t...@linutronix.de> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Mathias Nyman <mathias.ny...@linux.intel.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1490083293-3792-6-git-send-email-baolu...@linux.intel.com Signed-off-by: Ingo Molnar <mi...@kernel.org> --- Documentation/usb/usb3-debug-port.rst | 100 ++ 1 file changed, 100 insertions(+) diff --git a/Documentation/usb/usb3-debug-port.rst b/Documentation/usb/usb3-debug-port.rst new file mode 100644 index 000..feb1a36 --- /dev/null +++ b/Documentation/usb/usb3-debug-port.rst @@ -0,0 +1,100 @@ +=== +USB3 debug port +=== + +:Author: Lu Baolu <baolu...@linux.intel.com> +:Date: March 2017 + +GENERAL +=== + +This is a HOWTO for using the USB3 debug port on x86 systems. + +Before using any kernel debugging functionality based on USB3 +debug port, you need to:: + + 1) check whether any USB3 debug port is available in + your system; + 2) check which port is used for debugging purposes; + 3) have a USB 3.0 super-speed A-to-A debugging cable. + +INTRODUCTION + + +The xHCI debug capability (DbC) is an optional but standalone +functionality provided by the xHCI host controller. The xHCI +specification describes DbC in the section 7.6. + +When DbC is initialized and enabled, it will present a debug +device through the debug port (normally the first USB3 +super-speed port). The debug device is fully compliant with +the USB framework and provides the equivalent of a very high +performance full-duplex serial link between the debug target +(the system under debugging) and a debug host. + +EARLY PRINTK + + +DbC has been designed to log early printk messages. One use for +this feature is kernel debugging. For example, when your machine +crashes very early before the regular console code is initialized. +Other uses include simpler, lockless logging instead of a full- +blown printk console driver and klogd. + +On the debug target system, you need to customize a debugging +kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add below +kernel boot parameter:: + + "earlyprintk=xdbc" + +If there are multiple xHCI controllers in your system, you can +append a host contoller index to this kernel parameter. This +index starts from 0. + +Current design doesn't support DbC runtime suspend/resume. As +the result, you'd better disable runtime power management for +USB subsystem by adding below kernel boot parameter:: + + "usbcore.autosuspend=-1" + +Before starting the debug target, you should connect the debug +port to a USB port (root port or port of any external hub) on +the debug host. The cable used to connect these two ports +should be a USB 3.0 super-speed A-to-A debugging cable. + +During early boot of the debug target, DbC will be detected and +initialized. After initialization, the debug host should be able +to enumerate the debug device in debug target. The debug host +will then bind the debug device with the usb_debug driver module +and create the /dev/ttyUSB device. + +If the debug device enumeration goes smoothly, you should be able +to see below kernel messages on the debug host:: + + # tail -f /var/log/kern.log + [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd + [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM. + [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, idProduct=0004 + [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 1815.03] usb 4-3: Product: Remote GDB + [ 1815.04] usb 4-3: Manufacturer: Linux + [ 1815.05] usb 4-3: SerialNumber: 0001 + [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected + [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0 + +You can use any communication program, for example minicom, to +read and view the messages. Below simple bash scripts can help +you to check the sanity of the setup. + +.. code-block:: sh + + = start of bash scripts = + #!/bin/bash + + while true ; do + while [ ! -d /sys/class/tty/ttyUSB
[tip:x86/debug] usb/doc: Add document for USB3 debug port usage
Commit-ID: 1b326277798aa820c1043617786609b9bb4bee78 Gitweb: http://git.kernel.org/tip/1b326277798aa820c1043617786609b9bb4bee78 Author: Lu Baolu AuthorDate: Tue, 21 Mar 2017 16:01:33 +0800 Committer: Ingo Molnar CommitDate: Tue, 21 Mar 2017 12:30:17 +0100 usb/doc: Add document for USB3 debug port usage Add Documentation/usb/usb3-debug-port.rst. This document includes the guide for using USB3 debug port. Signed-off-by: Lu Baolu Acked-by: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Linus Torvalds Cc: Mathias Nyman Cc: Peter Zijlstra Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1490083293-3792-6-git-send-email-baolu...@linux.intel.com Signed-off-by: Ingo Molnar --- Documentation/usb/usb3-debug-port.rst | 100 ++ 1 file changed, 100 insertions(+) diff --git a/Documentation/usb/usb3-debug-port.rst b/Documentation/usb/usb3-debug-port.rst new file mode 100644 index 000..feb1a36 --- /dev/null +++ b/Documentation/usb/usb3-debug-port.rst @@ -0,0 +1,100 @@ +=== +USB3 debug port +=== + +:Author: Lu Baolu +:Date: March 2017 + +GENERAL +=== + +This is a HOWTO for using the USB3 debug port on x86 systems. + +Before using any kernel debugging functionality based on USB3 +debug port, you need to:: + + 1) check whether any USB3 debug port is available in + your system; + 2) check which port is used for debugging purposes; + 3) have a USB 3.0 super-speed A-to-A debugging cable. + +INTRODUCTION + + +The xHCI debug capability (DbC) is an optional but standalone +functionality provided by the xHCI host controller. The xHCI +specification describes DbC in the section 7.6. + +When DbC is initialized and enabled, it will present a debug +device through the debug port (normally the first USB3 +super-speed port). The debug device is fully compliant with +the USB framework and provides the equivalent of a very high +performance full-duplex serial link between the debug target +(the system under debugging) and a debug host. + +EARLY PRINTK + + +DbC has been designed to log early printk messages. One use for +this feature is kernel debugging. For example, when your machine +crashes very early before the regular console code is initialized. +Other uses include simpler, lockless logging instead of a full- +blown printk console driver and klogd. + +On the debug target system, you need to customize a debugging +kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add below +kernel boot parameter:: + + "earlyprintk=xdbc" + +If there are multiple xHCI controllers in your system, you can +append a host contoller index to this kernel parameter. This +index starts from 0. + +Current design doesn't support DbC runtime suspend/resume. As +the result, you'd better disable runtime power management for +USB subsystem by adding below kernel boot parameter:: + + "usbcore.autosuspend=-1" + +Before starting the debug target, you should connect the debug +port to a USB port (root port or port of any external hub) on +the debug host. The cable used to connect these two ports +should be a USB 3.0 super-speed A-to-A debugging cable. + +During early boot of the debug target, DbC will be detected and +initialized. After initialization, the debug host should be able +to enumerate the debug device in debug target. The debug host +will then bind the debug device with the usb_debug driver module +and create the /dev/ttyUSB device. + +If the debug device enumeration goes smoothly, you should be able +to see below kernel messages on the debug host:: + + # tail -f /var/log/kern.log + [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd + [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM. + [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, idProduct=0004 + [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 1815.03] usb 4-3: Product: Remote GDB + [ 1815.04] usb 4-3: Manufacturer: Linux + [ 1815.05] usb 4-3: SerialNumber: 0001 + [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected + [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0 + +You can use any communication program, for example minicom, to +read and view the messages. Below simple bash scripts can help +you to check the sanity of the setup. + +.. code-block:: sh + + = start of bash scripts = + #!/bin/bash + + while true ; do + while [ ! -d /sys/class/tty/ttyUSB0 ] ; do + : + done + cat /dev/ttyUSB0 + done + = end of bash scripts ===
[tip:x86/debug] x86/earlyprintk: Add support for earlyprintk via USB3 debug port
Commit-ID: 1b5aeebf3a92273b4d85aeff37a16037bc3c3abf
Gitweb: http://git.kernel.org/tip/1b5aeebf3a92273b4d85aeff37a16037bc3c3abf
Author: Lu Baolu <baolu...@linux.intel.com>
AuthorDate: Tue, 21 Mar 2017 16:01:31 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 21 Mar 2017 12:30:16 +0100
x86/earlyprintk: Add support for earlyprintk via USB3 debug port
Add support for earlyprintk by writing debug messages to the
USB3 debug port. Users can use this type of early printk by
specifying the kernel parameter of "earlyprintk=xdbc". This
gives users a chance of providing debugging output.
The hardware for USB3 debug port requires DMA memory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Acked-by: Thomas Gleixner <t...@linutronix.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Mathias Nyman <mathias.ny...@linux.intel.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1490083293-3792-4-git-send-email-baolu...@linux.intel.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
Documentation/admin-guide/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kernel/setup.c | 4
3 files changed, 10 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..ea1293d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -989,6 +989,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+ earlyprintk=xdbc[xhciController#]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
#endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+ if (!strncmp(buf, "xdbc", 4))
+ early_xdbc_parse_parameter(buf + 4);
+#endif
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e70204e..2600b1d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
@@ -1144,6 +1145,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
+ if (!early_xdbc_setup_hardware())
+ early_xdbc_register_console();
+
reserve_bios_regions();
if (efi_enabled(EFI_MEMMAP)) {
[tip:x86/debug] x86/earlyprintk: Add support for earlyprintk via USB3 debug port
Commit-ID: 1b5aeebf3a92273b4d85aeff37a16037bc3c3abf
Gitweb: http://git.kernel.org/tip/1b5aeebf3a92273b4d85aeff37a16037bc3c3abf
Author: Lu Baolu
AuthorDate: Tue, 21 Mar 2017 16:01:31 +0800
Committer: Ingo Molnar
CommitDate: Tue, 21 Mar 2017 12:30:16 +0100
x86/earlyprintk: Add support for earlyprintk via USB3 debug port
Add support for earlyprintk by writing debug messages to the
USB3 debug port. Users can use this type of early printk by
specifying the kernel parameter of "earlyprintk=xdbc". This
gives users a chance of providing debugging output.
The hardware for USB3 debug port requires DMA memory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Signed-off-by: Lu Baolu
Acked-by: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Mathias Nyman
Cc: Peter Zijlstra
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1490083293-3792-4-git-send-email-baolu...@linux.intel.com
Signed-off-by: Ingo Molnar
---
Documentation/admin-guide/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kernel/setup.c | 4
3 files changed, 10 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..ea1293d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -989,6 +989,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+ earlyprintk=xdbc[xhciController#]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
#endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+ if (!strncmp(buf, "xdbc", 4))
+ early_xdbc_parse_parameter(buf + 4);
+#endif
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e70204e..2600b1d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
@@ -1144,6 +1145,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
+ if (!early_xdbc_setup_hardware())
+ early_xdbc_register_console();
+
reserve_bios_regions();
if (efi_enabled(EFI_MEMMAP)) {
[tip:x86/debug] usb/early: Add driver for xhci debug capability
Commit-ID: aeb9dd1de98c1a5f2007ea5d2a154c1244caf8a0 Gitweb: http://git.kernel.org/tip/aeb9dd1de98c1a5f2007ea5d2a154c1244caf8a0 Author: Lu Baolu <baolu...@linux.intel.com> AuthorDate: Tue, 21 Mar 2017 16:01:30 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 21 Mar 2017 12:30:05 +0100 usb/early: Add driver for xhci debug capability XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in section 7.6. This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work. One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd. Signed-off-by: Lu Baolu <baolu...@linux.intel.com> Acked-by: Thomas Gleixner <t...@linutronix.de> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Mathias Nyman <mathias.ny...@linux.intel.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1490083293-3792-3-git-send-email-baolu...@linux.intel.com [ Small fix to the Kconfig help text. ] Signed-off-by: Ingo Molnar <mi...@kernel.org> --- arch/x86/Kconfig.debug| 27 +- drivers/usb/Makefile |2 +- drivers/usb/early/Makefile|1 + drivers/usb/early/xhci-dbc.c | 1014 + drivers/usb/early/xhci-dbc.h | 211 + include/linux/usb/xhci-dbgp.h | 29 ++ 6 files changed, 1281 insertions(+), 3 deletions(-) diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 63c1d13..fcb7604 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT source "lib/Kconfig.debug" +config EARLY_PRINTK_USB + bool + config X86_VERBOSE_BOOTUP bool "Enable verbose x86 bootup info messages" default y @@ -23,19 +26,20 @@ config EARLY_PRINTK This is useful for kernel debugging when your machine crashes very early before the console code is initialized. For normal operation it is not recommended because it looks ugly and doesn't cooperate - with klogd/syslogd or the X server. You should normally N here, + with klogd/syslogd or the X server. You should normally say N here, unless you want to debug such a crash. config EARLY_PRINTK_DBGP bool "Early printk via EHCI debug port" depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB ---help--- Write kernel log output directly into the EHCI debug port. This is useful for kernel debugging when your machine crashes very early before the console code is initialized. For normal operation it is not recommended because it looks ugly and doesn't cooperate - with klogd/syslogd or the X server. You should normally N here, + with klogd/syslogd or the X server. You should normally say N here, unless you want to debug such a crash. You need usb debug device. config EARLY_PRINTK_EFI @@ -48,6 +52,25 @@ config EARLY_PRINTK_EFI This is useful for kernel debugging when your machine crashes very early before the console code is initialized. +config EARLY_PRINTK_USB_XDBC + bool "Early printk via the xHCI debug port" + depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB + ---help--- + Write kernel log output directly into the xHCI debug port. + + One use for this feature is kernel debugging, for example when your + machine crashes very early before the regular console code is + initialized. Other uses include simpler, lockless logging instead of + a full-blown printk console driver + klogd. + + For normal production environments this is normally not recommended, + because it doesn't feed events into klogd/syslogd and doesn't try to + print anything on the screen. + + You should normally say N here, unless you want to debug early + crashes or need a very simple printk logging fac
[tip:x86/debug] usb/early: Add driver for xhci debug capability
Commit-ID: aeb9dd1de98c1a5f2007ea5d2a154c1244caf8a0 Gitweb: http://git.kernel.org/tip/aeb9dd1de98c1a5f2007ea5d2a154c1244caf8a0 Author: Lu Baolu AuthorDate: Tue, 21 Mar 2017 16:01:30 +0800 Committer: Ingo Molnar CommitDate: Tue, 21 Mar 2017 12:30:05 +0100 usb/early: Add driver for xhci debug capability XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in section 7.6. This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work. One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd. Signed-off-by: Lu Baolu Acked-by: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Linus Torvalds Cc: Mathias Nyman Cc: Peter Zijlstra Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1490083293-3792-3-git-send-email-baolu...@linux.intel.com [ Small fix to the Kconfig help text. ] Signed-off-by: Ingo Molnar --- arch/x86/Kconfig.debug| 27 +- drivers/usb/Makefile |2 +- drivers/usb/early/Makefile|1 + drivers/usb/early/xhci-dbc.c | 1014 + drivers/usb/early/xhci-dbc.h | 211 + include/linux/usb/xhci-dbgp.h | 29 ++ 6 files changed, 1281 insertions(+), 3 deletions(-) diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 63c1d13..fcb7604 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT source "lib/Kconfig.debug" +config EARLY_PRINTK_USB + bool + config X86_VERBOSE_BOOTUP bool "Enable verbose x86 bootup info messages" default y @@ -23,19 +26,20 @@ config EARLY_PRINTK This is useful for kernel debugging when your machine crashes very early before the console code is initialized. For normal operation it is not recommended because it looks ugly and doesn't cooperate - with klogd/syslogd or the X server. You should normally N here, + with klogd/syslogd or the X server. You should normally say N here, unless you want to debug such a crash. config EARLY_PRINTK_DBGP bool "Early printk via EHCI debug port" depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB ---help--- Write kernel log output directly into the EHCI debug port. This is useful for kernel debugging when your machine crashes very early before the console code is initialized. For normal operation it is not recommended because it looks ugly and doesn't cooperate - with klogd/syslogd or the X server. You should normally N here, + with klogd/syslogd or the X server. You should normally say N here, unless you want to debug such a crash. You need usb debug device. config EARLY_PRINTK_EFI @@ -48,6 +52,25 @@ config EARLY_PRINTK_EFI This is useful for kernel debugging when your machine crashes very early before the console code is initialized. +config EARLY_PRINTK_USB_XDBC + bool "Early printk via the xHCI debug port" + depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB + ---help--- + Write kernel log output directly into the xHCI debug port. + + One use for this feature is kernel debugging, for example when your + machine crashes very early before the regular console code is + initialized. Other uses include simpler, lockless logging instead of + a full-blown printk console driver + klogd. + + For normal production environments this is normally not recommended, + because it doesn't feed events into klogd/syslogd and doesn't try to + print anything on the screen. + + You should normally say N here, unless you want to debug early + crashes or need a very simple printk logging facility. + config X86_PTDUMP_CORE def_bool n diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 7791af6..53d1356 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/ obj-$
[tip:x86/debug] x86/timers: Add simple udelay calibration
Commit-ID: dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Gitweb: http://git.kernel.org/tip/dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Author: Lu Baolu <baolu...@linux.intel.com>
AuthorDate: Tue, 21 Mar 2017 16:01:29 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 21 Mar 2017 12:28:45 +0100
x86/timers: Add simple udelay calibration
Add a simple udelay calibration in x86 architecture-specific
boot-time initializations. This will get a workable estimate
for loops_per_jiffy. Hence, udelay() could be used after this
initialization.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
Acked-by: Thomas Gleixner <t...@linutronix.de>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Mathias Nyman <mathias.ny...@linux.intel.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1490083293-3792-2-git-send-email-baolu...@linux.intel.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
arch/x86/kernel/setup.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..e70204e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+static void __init simple_udelay_calibration(void)
+{
+ unsigned int tsc_khz, cpu_khz;
+ unsigned long lpj;
+
+ if (!boot_cpu_has(X86_FEATURE_TSC))
+ return;
+
+ cpu_khz = x86_platform.calibrate_cpu();
+ tsc_khz = x86_platform.calibrate_tsc();
+
+ tsc_khz = tsc_khz ? : cpu_khz;
+ if (!tsc_khz)
+ return;
+
+ lpj = tsc_khz * 1000;
+ do_div(lpj, HZ);
+ loops_per_jiffy = lpj;
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
*/
x86_configure_nx();
+ simple_udelay_calibration();
+
parse_early_param();
#ifdef CONFIG_MEMORY_HOTPLUG
[tip:x86/debug] x86/timers: Add simple udelay calibration
Commit-ID: dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Gitweb: http://git.kernel.org/tip/dd759d93f4dd4fd2f345a78ad1223bb3edf3ee7b
Author: Lu Baolu
AuthorDate: Tue, 21 Mar 2017 16:01:29 +0800
Committer: Ingo Molnar
CommitDate: Tue, 21 Mar 2017 12:28:45 +0100
x86/timers: Add simple udelay calibration
Add a simple udelay calibration in x86 architecture-specific
boot-time initializations. This will get a workable estimate
for loops_per_jiffy. Hence, udelay() could be used after this
initialization.
Signed-off-by: Lu Baolu
Acked-by: Thomas Gleixner
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Greg Kroah-Hartman
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Mathias Nyman
Cc: Peter Zijlstra
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1490083293-3792-2-git-send-email-baolu...@linux.intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/setup.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..e70204e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+static void __init simple_udelay_calibration(void)
+{
+ unsigned int tsc_khz, cpu_khz;
+ unsigned long lpj;
+
+ if (!boot_cpu_has(X86_FEATURE_TSC))
+ return;
+
+ cpu_khz = x86_platform.calibrate_cpu();
+ tsc_khz = x86_platform.calibrate_tsc();
+
+ tsc_khz = tsc_khz ? : cpu_khz;
+ if (!tsc_khz)
+ return;
+
+ lpj = tsc_khz * 1000;
+ do_div(lpj, HZ);
+ loops_per_jiffy = lpj;
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
*/
x86_configure_nx();
+ simple_udelay_calibration();
+
parse_early_param();
#ifdef CONFIG_MEMORY_HOTPLUG
[PATCH v8 3/5] x86: add support for earlyprintk via USB3 debug port
Add support for earlyprintk by writing debug messages to the
USB3 debug port. Users can use this type of early printk by
specifying the kernel parameter of "earlyprintk=xdbc". This
gives users a chance of providing debugging output.
The hardware for USB3 debug port requires DMA memory 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/admin-guide/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kernel/setup.c | 4
3 files changed, 10 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..ea1293d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -989,6 +989,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+ earlyprintk=xdbc[xhciController#]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
#endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+ if (!strncmp(buf, "xdbc", 4))
+ early_xdbc_parse_parameter(buf + 4);
+#endif
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e70204e..2600b1d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
@@ -1144,6 +1145,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
+ if (!early_xdbc_setup_hardware())
+ early_xdbc_register_console();
+
reserve_bios_regions();
if (efi_enabled(EFI_MEMMAP)) {
--
2.1.4
[PATCH v8 3/5] x86: add support for earlyprintk via USB3 debug port
Add support for earlyprintk by writing debug messages to the
USB3 debug port. Users can use this type of early printk by
specifying the kernel parameter of "earlyprintk=xdbc". This
gives users a chance of providing debugging output.
The hardware for USB3 debug port requires DMA memory 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/admin-guide/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kernel/setup.c | 4
3 files changed, 10 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..ea1293d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -989,6 +989,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+ earlyprintk=xdbc[xhciController#]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
#endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+ if (!strncmp(buf, "xdbc", 4))
+ early_xdbc_parse_parameter(buf + 4);
+#endif
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e70204e..2600b1d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
@@ -1144,6 +1145,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
+ if (!early_xdbc_setup_hardware())
+ early_xdbc_register_console();
+
reserve_bios_regions();
if (efi_enabled(EFI_MEMMAP)) {
--
2.1.4
[PATCH v8 5/5] usb: doc: add document for USB3 debug port usage
Add Documentation/usb/usb3-debug-port.rst. This document includes the guide for using USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- Documentation/usb/usb3-debug-port.rst | 100 ++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/usb/usb3-debug-port.rst diff --git a/Documentation/usb/usb3-debug-port.rst b/Documentation/usb/usb3-debug-port.rst new file mode 100644 index 000..feb1a36 --- /dev/null +++ b/Documentation/usb/usb3-debug-port.rst @@ -0,0 +1,100 @@ +=== +USB3 debug port +=== + +:Author: Lu Baolu <baolu...@linux.intel.com> +:Date: March 2017 + +GENERAL +=== + +This is a HOWTO for using the USB3 debug port on x86 systems. + +Before using any kernel debugging functionality based on USB3 +debug port, you need to:: + + 1) check whether any USB3 debug port is available in + your system; + 2) check which port is used for debugging purposes; + 3) have a USB 3.0 super-speed A-to-A debugging cable. + +INTRODUCTION + + +The xHCI debug capability (DbC) is an optional but standalone +functionality provided by the xHCI host controller. The xHCI +specification describes DbC in the section 7.6. + +When DbC is initialized and enabled, it will present a debug +device through the debug port (normally the first USB3 +super-speed port). The debug device is fully compliant with +the USB framework and provides the equivalent of a very high +performance full-duplex serial link between the debug target +(the system under debugging) and a debug host. + +EARLY PRINTK + + +DbC has been designed to log early printk messages. One use for +this feature is kernel debugging. For example, when your machine +crashes very early before the regular console code is initialized. +Other uses include simpler, lockless logging instead of a full- +blown printk console driver and klogd. + +On the debug target system, you need to customize a debugging +kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add below +kernel boot parameter:: + + "earlyprintk=xdbc" + +If there are multiple xHCI controllers in your system, you can +append a host contoller index to this kernel parameter. This +index starts from 0. + +Current design doesn't support DbC runtime suspend/resume. As +the result, you'd better disable runtime power management for +USB subsystem by adding below kernel boot parameter:: + + "usbcore.autosuspend=-1" + +Before starting the debug target, you should connect the debug +port to a USB port (root port or port of any external hub) on +the debug host. The cable used to connect these two ports +should be a USB 3.0 super-speed A-to-A debugging cable. + +During early boot of the debug target, DbC will be detected and +initialized. After initialization, the debug host should be able +to enumerate the debug device in debug target. The debug host +will then bind the debug device with the usb_debug driver module +and create the /dev/ttyUSB device. + +If the debug device enumeration goes smoothly, you should be able +to see below kernel messages on the debug host:: + + # tail -f /var/log/kern.log + [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd + [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM. + [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, idProduct=0004 + [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 1815.03] usb 4-3: Product: Remote GDB + [ 1815.04] usb 4-3: Manufacturer: Linux + [ 1815.05] usb 4-3: SerialNumber: 0001 + [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected + [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0 + +You can use any communication program, for example minicom, to +read and view the messages. Below simple bash scripts can help +you to check the sanity of the setup. + +.. code-block:: sh + + = start of bash scripts = + #!/bin/bash + + while true ; do + while [ ! -d /sys/class/tty/ttyUSB0 ] ; do + : + done + cat /dev/ttyUSB0 + done + = end of bash scripts === -- 2.1.4
[PATCH v8 5/5] usb: doc: add document for USB3 debug port usage
Add Documentation/usb/usb3-debug-port.rst. This document includes the guide for using USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu --- Documentation/usb/usb3-debug-port.rst | 100 ++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/usb/usb3-debug-port.rst diff --git a/Documentation/usb/usb3-debug-port.rst b/Documentation/usb/usb3-debug-port.rst new file mode 100644 index 000..feb1a36 --- /dev/null +++ b/Documentation/usb/usb3-debug-port.rst @@ -0,0 +1,100 @@ +=== +USB3 debug port +=== + +:Author: Lu Baolu +:Date: March 2017 + +GENERAL +=== + +This is a HOWTO for using the USB3 debug port on x86 systems. + +Before using any kernel debugging functionality based on USB3 +debug port, you need to:: + + 1) check whether any USB3 debug port is available in + your system; + 2) check which port is used for debugging purposes; + 3) have a USB 3.0 super-speed A-to-A debugging cable. + +INTRODUCTION + + +The xHCI debug capability (DbC) is an optional but standalone +functionality provided by the xHCI host controller. The xHCI +specification describes DbC in the section 7.6. + +When DbC is initialized and enabled, it will present a debug +device through the debug port (normally the first USB3 +super-speed port). The debug device is fully compliant with +the USB framework and provides the equivalent of a very high +performance full-duplex serial link between the debug target +(the system under debugging) and a debug host. + +EARLY PRINTK + + +DbC has been designed to log early printk messages. One use for +this feature is kernel debugging. For example, when your machine +crashes very early before the regular console code is initialized. +Other uses include simpler, lockless logging instead of a full- +blown printk console driver and klogd. + +On the debug target system, you need to customize a debugging +kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add below +kernel boot parameter:: + + "earlyprintk=xdbc" + +If there are multiple xHCI controllers in your system, you can +append a host contoller index to this kernel parameter. This +index starts from 0. + +Current design doesn't support DbC runtime suspend/resume. As +the result, you'd better disable runtime power management for +USB subsystem by adding below kernel boot parameter:: + + "usbcore.autosuspend=-1" + +Before starting the debug target, you should connect the debug +port to a USB port (root port or port of any external hub) on +the debug host. The cable used to connect these two ports +should be a USB 3.0 super-speed A-to-A debugging cable. + +During early boot of the debug target, DbC will be detected and +initialized. After initialization, the debug host should be able +to enumerate the debug device in debug target. The debug host +will then bind the debug device with the usb_debug driver module +and create the /dev/ttyUSB device. + +If the debug device enumeration goes smoothly, you should be able +to see below kernel messages on the debug host:: + + # tail -f /var/log/kern.log + [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd + [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM. + [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, idProduct=0004 + [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 1815.03] usb 4-3: Product: Remote GDB + [ 1815.04] usb 4-3: Manufacturer: Linux + [ 1815.05] usb 4-3: SerialNumber: 0001 + [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected + [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0 + +You can use any communication program, for example minicom, to +read and view the messages. Below simple bash scripts can help +you to check the sanity of the setup. + +.. code-block:: sh + + = start of bash scripts = + #!/bin/bash + + while true ; do + while [ ! -d /sys/class/tty/ttyUSB0 ] ; do + : + done + cat /dev/ttyUSB0 + done + = end of bash scripts === -- 2.1.4
[PATCH v8 2/5] usb: early: add driver for xhci debug capability
XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6. This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work. One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd. Cc: Ingo Molnar <mi...@redhat.com> Cc: Mathias Nyman <mathias.ny...@linux.intel.com> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> --- arch/x86/Kconfig.debug| 23 + drivers/usb/Makefile |2 +- drivers/usb/early/Makefile|1 + drivers/usb/early/xhci-dbc.c | 1014 + drivers/usb/early/xhci-dbc.h | 211 + include/linux/usb/xhci-dbgp.h | 29 ++ 6 files changed, 1279 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/early/xhci-dbc.h create mode 100644 include/linux/usb/xhci-dbgp.h diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 63c1d13..f586462 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT source "lib/Kconfig.debug" +config EARLY_PRINTK_USB + bool + config X86_VERBOSE_BOOTUP bool "Enable verbose x86 bootup info messages" default y @@ -29,6 +32,7 @@ config EARLY_PRINTK config EARLY_PRINTK_DBGP bool "Early printk via EHCI debug port" depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB ---help--- Write kernel log output directly into the EHCI debug port. @@ -48,6 +52,25 @@ config EARLY_PRINTK_EFI This is useful for kernel debugging when your machine crashes very early before the console code is initialized. +config EARLY_PRINTK_USB_XDBC + bool "Early printk via the xHCI debug port" + depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB + ---help--- + Write kernel log output directly into the xHCI debug port. + + One use for this feature is kernel debugging, for example when your + machine crashes very early before the regular console code is + initialized. Other uses include simpler, lockless logging instead of + a full-blown printk console driver + klogd. + + For normal production environments this is normally not recommended, + because it doesn't feed events into klogd/syslogd and doesn't try to + print anything on the screen. + + You should normally N here, unless you want to debug early crashes or + need a very simple printk logging facility. + config X86_PTDUMP_CORE def_bool n diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 7791af6..53d1356 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/ obj-$(CONFIG_USB_SERIAL) += serial/ obj-$(CONFIG_USB) += misc/ -obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/ +obj-$(CONFIG_EARLY_PRINTK_USB) += early/ obj-$(CONFIG_USB_ATM) += atm/ obj-$(CONFIG_USB_SPEEDTOUCH) += atm/ diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile index 24bbe51..fcde228 100644 --- a/drivers/usb/early/Makefile +++ b/drivers/usb/early/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o +obj-$(CONFIG_EARLY_PRINTK_USB_XDBC) += xhci-dbc.o diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c new file mode 100644 index 000..1268818 --- /dev/null +++ b/drivers/usb/early/xhci-dbc.c @@ -0,0 +1,1014 @@ +/** + * xhci-dbc.c - xHCI debug capability early driver + * + * Copyright (C) 2016 Intel Corporation + * + * Author: Lu Baolu <baolu...@linux.intel.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#define pr_fmt(fmt)KBUILD_MODNAME ":%s: " fmt, __func__ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include
[PATCH v8 2/5] usb: early: add driver for xhci debug capability
XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6. This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work. One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd. Cc: Ingo Molnar Cc: Mathias Nyman Signed-off-by: Lu Baolu --- arch/x86/Kconfig.debug| 23 + drivers/usb/Makefile |2 +- drivers/usb/early/Makefile|1 + drivers/usb/early/xhci-dbc.c | 1014 + drivers/usb/early/xhci-dbc.h | 211 + include/linux/usb/xhci-dbgp.h | 29 ++ 6 files changed, 1279 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/early/xhci-dbc.h create mode 100644 include/linux/usb/xhci-dbgp.h diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 63c1d13..f586462 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT source "lib/Kconfig.debug" +config EARLY_PRINTK_USB + bool + config X86_VERBOSE_BOOTUP bool "Enable verbose x86 bootup info messages" default y @@ -29,6 +32,7 @@ config EARLY_PRINTK config EARLY_PRINTK_DBGP bool "Early printk via EHCI debug port" depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB ---help--- Write kernel log output directly into the EHCI debug port. @@ -48,6 +52,25 @@ config EARLY_PRINTK_EFI This is useful for kernel debugging when your machine crashes very early before the console code is initialized. +config EARLY_PRINTK_USB_XDBC + bool "Early printk via the xHCI debug port" + depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB + ---help--- + Write kernel log output directly into the xHCI debug port. + + One use for this feature is kernel debugging, for example when your + machine crashes very early before the regular console code is + initialized. Other uses include simpler, lockless logging instead of + a full-blown printk console driver + klogd. + + For normal production environments this is normally not recommended, + because it doesn't feed events into klogd/syslogd and doesn't try to + print anything on the screen. + + You should normally N here, unless you want to debug early crashes or + need a very simple printk logging facility. + config X86_PTDUMP_CORE def_bool n diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 7791af6..53d1356 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/ obj-$(CONFIG_USB_SERIAL) += serial/ obj-$(CONFIG_USB) += misc/ -obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/ +obj-$(CONFIG_EARLY_PRINTK_USB) += early/ obj-$(CONFIG_USB_ATM) += atm/ obj-$(CONFIG_USB_SPEEDTOUCH) += atm/ diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile index 24bbe51..fcde228 100644 --- a/drivers/usb/early/Makefile +++ b/drivers/usb/early/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o +obj-$(CONFIG_EARLY_PRINTK_USB_XDBC) += xhci-dbc.o diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c new file mode 100644 index 000..1268818 --- /dev/null +++ b/drivers/usb/early/xhci-dbc.c @@ -0,0 +1,1014 @@ +/** + * 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 and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#define pr_fmt(fmt)KBUILD_MODNAME ":%s: " fmt, __func__ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../host/xhci.h" +#include "xhci-dbc.h" + +static struct xdbc_state xd
[PATCH v8 4/5] usb: serial: add dbc debug device support to usb_debug
This patch adds dbc debug device support to the 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 --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
};
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+ { USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
/* This HW really does not support a serial break, so one will be
* emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
};
+static struct usb_serial_driver dbc_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = "xhci_dbc",
+ },
+ .id_table = dbc_id_table,
+ .num_ports =1,
+ .break_ctl =usb_debug_break_ctl,
+ .process_read_urb = usb_debug_process_read_urb,
+};
+
static struct usb_serial_driver * const serial_drivers[] = {
- _device, NULL
+ _device, _device, NULL
};
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_LICENSE("GPL");
--
2.1.4
[PATCH v8 4/5] usb: serial: add dbc debug device support to usb_debug
This patch adds dbc debug device support to the 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/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
};
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+ { USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
/* This HW really does not support a serial break, so one will be
* emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
};
+static struct usb_serial_driver dbc_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = "xhci_dbc",
+ },
+ .id_table = dbc_id_table,
+ .num_ports =1,
+ .break_ctl =usb_debug_break_ctl,
+ .process_read_urb = usb_debug_process_read_urb,
+};
+
static struct usb_serial_driver * const serial_drivers[] = {
- _device, NULL
+ _device, _device, NULL
};
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_LICENSE("GPL");
--
2.1.4
[PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of xHCI host. This patch set adds support for early printk functionality through a USB3 debug port by 1) initializing and enabling the DbC hardware during early boot; 2) registering a boot console to the system so that early printk messages can go through the USB3 debug port. It also includes some lines of changes in usb_debug driver so that it can be bound when a USB3 debug device is enumerated. --- Change log: v7->v8: - refine the Kconfig help text. - cleanup the unnecessary USB_EARLY_PRINTK bool. - refine comments and trace messages in the driver. - update usb3-debug-port.rst after internal reivew. v6->v7: - add a new patch "[PATCH 1/5] x86: add simple udelay calibration" to make udelay() work for early drivers. - [PATCH 2/5] usb: dbc: early driver for xhci debug capability - add a kernel thread to handle error cases, such as cable unplugging. - Fixed several code styles pointed out by Ingo. v5->v6: - rebase the patches on top of the latest 4.10-rc4 - run successfully in a 32-bit kernel - [PATCH 1/4] - remove ugly linebreaks to make code more readable - rename config names to make them consistency - move sleep-able ioremap() out of the lock area - rename reserved fields of register structures - make the vertical tabulation of struct fields consistent - [PATCH 2/4] - remove "#ifdef" in the generic code by creating proper wrappers in header file - [PATCH 3/4] - refine the title and commit message - [PATCH 4/4] - fix several typos and grammar errors in the document v4->v5: - add raw_spin_lock to make xdbc_bulk_write() reentrant. v3->v4: - Rename the document with .dst suffix. - Add the list of hardware that has been succesfuly tested on in the document. v2->v3: - Removed spinlock usage. - Removed work queue usage. - Refined the user guide 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 (5): x86: add simple udelay calibration usb: early: add driver for xhci debug capability x86: add support for earlyprintk via USB3 debug port usb: serial: add dbc debug device support to usb_debug usb: doc: add document for USB3 debug port usage Documentation/admin-guide/kernel-parameters.txt |1 + Documentation/usb/usb3-debug-port.rst | 100 +++ arch/x86/Kconfig.debug | 23 + arch/x86/kernel/early_printk.c |5 + arch/x86/kernel/setup.c | 26 + drivers/usb/Makefile|2 +- drivers/usb/early/Makefile |1 + drivers/usb/early/xhci-dbc.c| 1014 +++ drivers/usb/early/xhci-dbc.h| 211 + drivers/usb/serial/usb_debug.c | 28 +- include/linux/usb/xhci-dbgp.h | 29 + 11 files changed, 1436 insertions(+), 4 deletions(-) create mode 100644 Documentation/usb/usb3-debug-port.rst create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/early/xhci-dbc.h create mode 100644 include/linux/usb/xhci-dbgp.h -- 2.1.4
[PATCH v8 1/5] x86: add simple udelay calibration
Add a simple udelay calibration in x86 architecture-specific
boot-time initializations. This will get a workable estimate
for loops_per_jiffy. Hence, udelay() could be used after this
initialization.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: x...@kernel.org
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
arch/x86/kernel/setup.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..e70204e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+static void __init simple_udelay_calibration(void)
+{
+ unsigned int tsc_khz, cpu_khz;
+ unsigned long lpj;
+
+ if (!boot_cpu_has(X86_FEATURE_TSC))
+ return;
+
+ cpu_khz = x86_platform.calibrate_cpu();
+ tsc_khz = x86_platform.calibrate_tsc();
+
+ tsc_khz = tsc_khz ? : cpu_khz;
+ if (!tsc_khz)
+ return;
+
+ lpj = tsc_khz * 1000;
+ do_div(lpj, HZ);
+ loops_per_jiffy = lpj;
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
*/
x86_configure_nx();
+ simple_udelay_calibration();
+
parse_early_param();
#ifdef CONFIG_MEMORY_HOTPLUG
--
2.1.4
[PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of xHCI host. This patch set adds support for early printk functionality through a USB3 debug port by 1) initializing and enabling the DbC hardware during early boot; 2) registering a boot console to the system so that early printk messages can go through the USB3 debug port. It also includes some lines of changes in usb_debug driver so that it can be bound when a USB3 debug device is enumerated. --- Change log: v7->v8: - refine the Kconfig help text. - cleanup the unnecessary USB_EARLY_PRINTK bool. - refine comments and trace messages in the driver. - update usb3-debug-port.rst after internal reivew. v6->v7: - add a new patch "[PATCH 1/5] x86: add simple udelay calibration" to make udelay() work for early drivers. - [PATCH 2/5] usb: dbc: early driver for xhci debug capability - add a kernel thread to handle error cases, such as cable unplugging. - Fixed several code styles pointed out by Ingo. v5->v6: - rebase the patches on top of the latest 4.10-rc4 - run successfully in a 32-bit kernel - [PATCH 1/4] - remove ugly linebreaks to make code more readable - rename config names to make them consistency - move sleep-able ioremap() out of the lock area - rename reserved fields of register structures - make the vertical tabulation of struct fields consistent - [PATCH 2/4] - remove "#ifdef" in the generic code by creating proper wrappers in header file - [PATCH 3/4] - refine the title and commit message - [PATCH 4/4] - fix several typos and grammar errors in the document v4->v5: - add raw_spin_lock to make xdbc_bulk_write() reentrant. v3->v4: - Rename the document with .dst suffix. - Add the list of hardware that has been succesfuly tested on in the document. v2->v3: - Removed spinlock usage. - Removed work queue usage. - Refined the user guide 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 (5): x86: add simple udelay calibration usb: early: add driver for xhci debug capability x86: add support for earlyprintk via USB3 debug port usb: serial: add dbc debug device support to usb_debug usb: doc: add document for USB3 debug port usage Documentation/admin-guide/kernel-parameters.txt |1 + Documentation/usb/usb3-debug-port.rst | 100 +++ arch/x86/Kconfig.debug | 23 + arch/x86/kernel/early_printk.c |5 + arch/x86/kernel/setup.c | 26 + drivers/usb/Makefile|2 +- drivers/usb/early/Makefile |1 + drivers/usb/early/xhci-dbc.c| 1014 +++ drivers/usb/early/xhci-dbc.h| 211 + drivers/usb/serial/usb_debug.c | 28 +- include/linux/usb/xhci-dbgp.h | 29 + 11 files changed, 1436 insertions(+), 4 deletions(-) create mode 100644 Documentation/usb/usb3-debug-port.rst create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/early/xhci-dbc.h create mode 100644 include/linux/usb/xhci-dbgp.h -- 2.1.4
[PATCH v8 1/5] x86: add simple udelay calibration
Add a simple udelay calibration in x86 architecture-specific
boot-time initializations. This will get a workable estimate
for loops_per_jiffy. Hence, udelay() could be used after this
initialization.
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Lu Baolu
---
arch/x86/kernel/setup.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..e70204e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+static void __init simple_udelay_calibration(void)
+{
+ unsigned int tsc_khz, cpu_khz;
+ unsigned long lpj;
+
+ if (!boot_cpu_has(X86_FEATURE_TSC))
+ return;
+
+ cpu_khz = x86_platform.calibrate_cpu();
+ tsc_khz = x86_platform.calibrate_tsc();
+
+ tsc_khz = tsc_khz ? : cpu_khz;
+ if (!tsc_khz)
+ return;
+
+ lpj = tsc_khz * 1000;
+ do_div(lpj, HZ);
+ loops_per_jiffy = lpj;
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
*/
x86_configure_nx();
+ simple_udelay_calibration();
+
parse_early_param();
#ifdef CONFIG_MEMORY_HOTPLUG
--
2.1.4
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo, On 03/16/2017 03:17 PM, Ingo Molnar wrote: > * Lu Baolu <baolu...@linux.intel.com> wrote: > >> Hi Ingo, >> >> On 03/02/2017 02:40 PM, Ingo Molnar wrote: >>> * Lu Baolu <baolu...@linux.intel.com> wrote: >>> >>>> Hi Ingo, >>>> >>>> How about this version? Any further comments? >>> So I have re-read the review feedback I gave on Jan 19 and found at least >>> one >>> thing I pointed out that you didn't address in the latest patches ... >> Do you mind telling me which one is not addressed? Is it one of below >> feedbacks? > So one piece of feedback I gave was: > > | BTW., just a side note, some kernel developers (like PeterZ - and I do it > | sometimes too) remap early_printk to printk permanently and use it as their > main > | printk facility - because printk() reliability has suffered over the last > couple > | of years. > | > | So it's more than just early boot debugging - it's a very simple state-less > | logging facility to an external computer. > > But the latest Kconfig help text still says this: > > +config EARLY_PRINTK_USB_XDBC > + bool "Early printk via the xHCI debug port" > + depends on EARLY_PRINTK && PCI > + select EARLY_PRINTK_USB > + ---help--- > + Write kernel log output directly into the xHCI debug port. > + > + This is useful for kernel debugging when your machine crashes very > + early before the console code is initialized. For normal operation > + it is not recommended because it looks ugly and doesn't cooperate > + with klogd/syslogd or the X server. You should normally N here, > + unless you want to debug such a crash. > > ... while in reality it's an alternative lockless logging facility that goes > way > beyond debugging early boot crashes! > > Granted, I qualified that with 'just a side note'. I guess something like > this > would work: > > + One use for this feature is kernel debugging, for example when your > + machine crashes very early before the regular console code is > + initialized. Other uses include simpler, lockless logging instead of > a > + full-blown printk console driver + klogd. > + > + For normal production environments this is normally not recommended, > + because it doesn't feed events into klogd/syslogd and doesn't try to > + print anything on the screen. > + > + You should normally N here, unless you want to debug early crashes or > + need a very simple printk logging facility. Very appreciated for pointing this out. I will replace it. > > Another piece of feedback I gave was: > >>> +config USB_EARLY_PRINTK >>> + bool >> Also, could we standardize the nomencalture to not be a mixture of prefixes >> and >> postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig >> space) and rename this one to EARLY_PRINTK_USB or so? > yet your latest submission still includes the very same postfixed config > switch > name that collides with the prefixed names such as EARLY_PRINTK_USB: > > --- a/drivers/usb/Kconfig > +++ b/drivers/usb/Kconfig > @@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO > config USB_EHCI_BIG_ENDIAN_DESC > bool > > +config USB_EARLY_PRINTK > + bool > + > menuconfig USB_SUPPORT > bool "USB support" > depends on HAS_IOMEM > > The problem I tried to point out with my review feedback is that we thus have > both: > > CONFIG_EARLY_PRINTK_USB=y > CONFIG_USB_EARLY_PRINTK=y > > ... which is confusing at the very least. > > On a second look, this config switch appears to be unused - is it a leftover > from > earlier patches? Yes, it is a leftover from the earlier patches. I should remove it. Sorry about it. > > The patches don't look too bad otherwise, so we are not far from having > something > acceptable, IMHO. > Thanks. For the typo and grammar issues, I will recheck the patches and ask some English speakers for review. Best regards, Lu Baolu
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo, On 03/16/2017 03:17 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Hi Ingo, >> >> On 03/02/2017 02:40 PM, Ingo Molnar wrote: >>> * Lu Baolu wrote: >>> >>>> Hi Ingo, >>>> >>>> How about this version? Any further comments? >>> So I have re-read the review feedback I gave on Jan 19 and found at least >>> one >>> thing I pointed out that you didn't address in the latest patches ... >> Do you mind telling me which one is not addressed? Is it one of below >> feedbacks? > So one piece of feedback I gave was: > > | BTW., just a side note, some kernel developers (like PeterZ - and I do it > | sometimes too) remap early_printk to printk permanently and use it as their > main > | printk facility - because printk() reliability has suffered over the last > couple > | of years. > | > | So it's more than just early boot debugging - it's a very simple state-less > | logging facility to an external computer. > > But the latest Kconfig help text still says this: > > +config EARLY_PRINTK_USB_XDBC > + bool "Early printk via the xHCI debug port" > + depends on EARLY_PRINTK && PCI > + select EARLY_PRINTK_USB > + ---help--- > + Write kernel log output directly into the xHCI debug port. > + > + This is useful for kernel debugging when your machine crashes very > + early before the console code is initialized. For normal operation > + it is not recommended because it looks ugly and doesn't cooperate > + with klogd/syslogd or the X server. You should normally N here, > + unless you want to debug such a crash. > > ... while in reality it's an alternative lockless logging facility that goes > way > beyond debugging early boot crashes! > > Granted, I qualified that with 'just a side note'. I guess something like > this > would work: > > + One use for this feature is kernel debugging, for example when your > + machine crashes very early before the regular console code is > + initialized. Other uses include simpler, lockless logging instead of > a > + full-blown printk console driver + klogd. > + > + For normal production environments this is normally not recommended, > + because it doesn't feed events into klogd/syslogd and doesn't try to > + print anything on the screen. > + > + You should normally N here, unless you want to debug early crashes or > + need a very simple printk logging facility. Very appreciated for pointing this out. I will replace it. > > Another piece of feedback I gave was: > >>> +config USB_EARLY_PRINTK >>> + bool >> Also, could we standardize the nomencalture to not be a mixture of prefixes >> and >> postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig >> space) and rename this one to EARLY_PRINTK_USB or so? > yet your latest submission still includes the very same postfixed config > switch > name that collides with the prefixed names such as EARLY_PRINTK_USB: > > --- a/drivers/usb/Kconfig > +++ b/drivers/usb/Kconfig > @@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO > config USB_EHCI_BIG_ENDIAN_DESC > bool > > +config USB_EARLY_PRINTK > + bool > + > menuconfig USB_SUPPORT > bool "USB support" > depends on HAS_IOMEM > > The problem I tried to point out with my review feedback is that we thus have > both: > > CONFIG_EARLY_PRINTK_USB=y > CONFIG_USB_EARLY_PRINTK=y > > ... which is confusing at the very least. > > On a second look, this config switch appears to be unused - is it a leftover > from > earlier patches? Yes, it is a leftover from the earlier patches. I should remove it. Sorry about it. > > The patches don't look too bad otherwise, so we are not far from having > something > acceptable, IMHO. > Thanks. For the typo and grammar issues, I will recheck the patches and ask some English speakers for review. Best regards, Lu Baolu
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo,
On 03/02/2017 02:40 PM, Ingo Molnar wrote:
> * Lu Baolu <baolu...@linux.intel.com> wrote:
>
>> Hi Ingo,
>>
>> How about this version? Any further comments?
> So I have re-read the review feedback I gave on Jan 19 and found at least one
> thing I pointed out that you didn't address in the latest patches ...
Do you mind telling me which one is not addressed? Is it one of below
feedbacks?
==
>
> USB connection is stable enough, unless the user unplugs the
> USB cable during debugging.
What does the hardware do in this case? The XHCI registers are in the host
hardware, so they won't disappear, right? Is there some cable connection status
bit we can extract without interrupts?
I.e. if there's any polling component then it would be reasonable to add an
error
component: poll the status and if it goes 'disconnected' then disable
early-printk
altogether in this case and trigger an emergency printk() so that there's chance
that the user notices [if the system does not misbehave otherwise].
I.e. try to be as robust and informative as lockdep - yet don't lock up the host
kernel: lockdep too is called from very deep internals, there are various
conditions where it sees corrupt data structures (i.e. a 'disconnect' - a system
environment outside the normal bounds of operation), yet of the kernel and over
the last 10+ years of lockdep's existence we had very, very few cases of lockdep
itself locking up and behaving unpredictably.
-
>> Put it in simple:
>>
>> The driver sets the RUN bit in control register and polls READY
>> bit in status register for the successful USB device enumeration.
>> As the USB device enumeration might fail and the READY bit will
>> never be set, the driver must have a timeout logic to avoid
>> endless loop.
> Is there any error status available in the host registers anywhere that tells
> us
> that enumeration did not succeed?
No, there isn't. The xhci spec requires software to impose a timeout.
Page 425, xhci specification:
"
Software shall impose a timeout between the detection
of the Debug Host connection and the DbC Run transition
to ‘1’.
"
-
> +
> +val64 = val & PCI_BASE_ADDRESS_MEM_MASK;
> +sz64 = sz & PCI_BASE_ADDRESS_MEM_MASK;
> +mask64 = (u32)PCI_BASE_ADDRESS_MEM_MASK;
Is this cast necessary?
-
> +if ((val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> PCI_BASE_ADDRESS_MEM_TYPE_64) {
> +val = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4);
> +write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4, ~0);
> +sz = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4);
> +write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4, val);
> +
> +val64 |= (u64)val << 32;
> +sz64 |= (u64)sz << 32;
Could these type casts be avoided by declaring 'val' and 'sz' as u64 to begin
with?
==
I posted all feedbacks I received by now at the tail of this email to
make sure all feedbacks were communicated and addressed.
>
> Plus please go beyond the feedback given - for example the Kconfig text
> contains
> at least one typo.
>
>
I am sorry about this.
I will try my best to make typos and code style clean.
Best regards,
Lu Baolu
[Below are all feedbacks.]
=
[PATCH v5 1/4] usb: dbc: early driver for xhci debug capability
=
Could we please do this rename:
s/EARLY_PRINTK_XDBC
EARLY_PRINTK_USB_XDBC
?
As many people will not realize what 'xdbc' means, standalone - while "it's an
USB serial logging variant" is a lot more natural.
-
Also, could we standardize the nomencalture to not be a mixture of prefixes and
postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig
space)
and rename this one to EARLY_PRINTK_USB or so?
-
> +if ((val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> +PCI_BASE_ADDRESS_MEM_TYPE_64) {
Please don't break the line here.
-
> +val64 |= ((u64)val << 32);
> +sz64 |= ((u64)sz << 32);
> +mask64 |= ((u64)~0 << 32);
Unnecessary parentheses.
-
> +if (sizeof(dma_addr_t) < 8 || !sz64) {
> +pr_notice("invalid mmio address\n");
> +return NULL;
> +}
S
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo,
On 03/02/2017 02:40 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>> Hi Ingo,
>>
>> How about this version? Any further comments?
> So I have re-read the review feedback I gave on Jan 19 and found at least one
> thing I pointed out that you didn't address in the latest patches ...
Do you mind telling me which one is not addressed? Is it one of below
feedbacks?
==
>
> USB connection is stable enough, unless the user unplugs the
> USB cable during debugging.
What does the hardware do in this case? The XHCI registers are in the host
hardware, so they won't disappear, right? Is there some cable connection status
bit we can extract without interrupts?
I.e. if there's any polling component then it would be reasonable to add an
error
component: poll the status and if it goes 'disconnected' then disable
early-printk
altogether in this case and trigger an emergency printk() so that there's chance
that the user notices [if the system does not misbehave otherwise].
I.e. try to be as robust and informative as lockdep - yet don't lock up the host
kernel: lockdep too is called from very deep internals, there are various
conditions where it sees corrupt data structures (i.e. a 'disconnect' - a system
environment outside the normal bounds of operation), yet of the kernel and over
the last 10+ years of lockdep's existence we had very, very few cases of lockdep
itself locking up and behaving unpredictably.
-
>> Put it in simple:
>>
>> The driver sets the RUN bit in control register and polls READY
>> bit in status register for the successful USB device enumeration.
>> As the USB device enumeration might fail and the READY bit will
>> never be set, the driver must have a timeout logic to avoid
>> endless loop.
> Is there any error status available in the host registers anywhere that tells
> us
> that enumeration did not succeed?
No, there isn't. The xhci spec requires software to impose a timeout.
Page 425, xhci specification:
"
Software shall impose a timeout between the detection
of the Debug Host connection and the DbC Run transition
to ‘1’.
"
-
> +
> +val64 = val & PCI_BASE_ADDRESS_MEM_MASK;
> +sz64 = sz & PCI_BASE_ADDRESS_MEM_MASK;
> +mask64 = (u32)PCI_BASE_ADDRESS_MEM_MASK;
Is this cast necessary?
-
> +if ((val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> PCI_BASE_ADDRESS_MEM_TYPE_64) {
> +val = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4);
> +write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4, ~0);
> +sz = read_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4);
> +write_pci_config(bus, dev, func, PCI_BASE_ADDRESS_0 + 4, val);
> +
> +val64 |= (u64)val << 32;
> +sz64 |= (u64)sz << 32;
Could these type casts be avoided by declaring 'val' and 'sz' as u64 to begin
with?
==
I posted all feedbacks I received by now at the tail of this email to
make sure all feedbacks were communicated and addressed.
>
> Plus please go beyond the feedback given - for example the Kconfig text
> contains
> at least one typo.
>
>
I am sorry about this.
I will try my best to make typos and code style clean.
Best regards,
Lu Baolu
[Below are all feedbacks.]
=
[PATCH v5 1/4] usb: dbc: early driver for xhci debug capability
=
Could we please do this rename:
s/EARLY_PRINTK_XDBC
EARLY_PRINTK_USB_XDBC
?
As many people will not realize what 'xdbc' means, standalone - while "it's an
USB serial logging variant" is a lot more natural.
-
Also, could we standardize the nomencalture to not be a mixture of prefixes and
postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig
space)
and rename this one to EARLY_PRINTK_USB or so?
-
> +if ((val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> +PCI_BASE_ADDRESS_MEM_TYPE_64) {
Please don't break the line here.
-
> +val64 |= ((u64)val << 32);
> +sz64 |= ((u64)sz << 32);
> +mask64 |= ((u64)~0 << 32);
Unnecessary parentheses.
-
> +if (sizeof(dma_addr_t) < 8 || !sz64) {
> +pr_notice("invalid mmio address\n");
> +return NULL;
> +}
So this doesn
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo, How about this version? Any further comments? Best regards, Lu Baolu On 02/14/2017 10:27 AM, Lu Baolu wrote: > xHCI debug capability (DbC) is an optional but standalone > functionality provided by an xHCI host controller. With DbC > hardware initialized, the system will present a debug device > through the USB3 debug port (normally the first USB3 port). > The debug device is fully compliant with the USB framework > and provides the equivalent of a very high performance (USB3) > full-duplex serial link between the debug host and target. > The DbC functionality is independent of xHCI host. There > isn't any precondition from xHCI host side for DbC to work. > > This patch set adds support for early printk functionality > through a USB3 debug port by 1) initializing and enabling > the DbC hardware during early boot; 2) registering a boot > console to the system so that early printk messages can go > through the USB3 debug port. It also includes some lines > of changes in usb_debug driver so that it can be bound when > a USB3 debug device is enumerated. > > --- > Change log: > v6->v7: > - add a new patch "[PATCH 1/5] x86: add simple udelay > calibration" to make udelay() work for early drivers. > - [PATCH 2/5] usb: dbc: early driver for xhci debug capability > - add a kernel thread to handle error cases, such as cable > unplugging. > - Fixed several code styles pointed out by Ingo. > > v5->v6: > - rebase the patches on top of the latest 4.10-rc4 > - run successfully in a 32-bit kernel > - [PATCH 1/4] > - remove ugly linebreaks to make code more readable > - rename config names to make them consistency > - move sleep-able ioremap() out of the lock area > - rename reserved fields of register structures > - make the vertical tabulation of struct fields consistent > - [PATCH 2/4] > - remove "#ifdef" in the generic code by creating proper > wrappers in header file > - [PATCH 3/4] > - refine the title and commit message > - [PATCH 4/4] > - fix several typos and grammar errors in the document > > v4->v5: > - add raw_spin_lock to make xdbc_bulk_write() reentrant. > > v3->v4: > - Rename the document with .dst suffix. > - Add the list of hardware that has been succesfuly > tested on in the document. > > v2->v3: > - Removed spinlock usage. > - Removed work queue usage. > - Refined the user guide 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 (5): > x86: add simple udelay calibration > usb: dbc: early driver for xhci debug capability > x86: add support for earlyprintk via USB3 debug port > usb: serial: add dbc debug device support to usb_debug > usb: doc: add document for USB3 debug port usage > > Documentation/admin-guide/kernel-parameters.txt |1 + > Documentation/usb/usb3-debug-port.rst | 98 +++ > arch/x86/Kconfig.debug | 17 + > arch/x86/kernel/early_printk.c |5 + > arch/x86/kernel/setup.c | 26 + > drivers/usb/Kconfig |3 + > drivers/usb/Makefile|2 +- > drivers/usb/early/Makefile |1 + > drivers/usb/early/xhci-dbc.c| 1026 > +++ > drivers/usb/early/xhci-dbc.h| 210 + > drivers/usb/serial/usb_debug.c | 28 +- > include/linux/usb/xhci-dbgp.h | 29 + > 12 files changed, 1442 insertions(+), 4 deletions(-) > create mode 100644 Documentation/usb/usb3-debug-port.rst > create mode 100644 drivers/usb/early/xhci-dbc.c > create mode 100644 drivers/usb/early/xhci-dbc.h > create mode 100644 include/linux/usb/xhci-dbgp.h >
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo, How about this version? Any further comments? Best regards, Lu Baolu On 02/14/2017 10:27 AM, Lu Baolu wrote: > xHCI debug capability (DbC) is an optional but standalone > functionality provided by an xHCI host controller. With DbC > hardware initialized, the system will present a debug device > through the USB3 debug port (normally the first USB3 port). > The debug device is fully compliant with the USB framework > and provides the equivalent of a very high performance (USB3) > full-duplex serial link between the debug host and target. > The DbC functionality is independent of xHCI host. There > isn't any precondition from xHCI host side for DbC to work. > > This patch set adds support for early printk functionality > through a USB3 debug port by 1) initializing and enabling > the DbC hardware during early boot; 2) registering a boot > console to the system so that early printk messages can go > through the USB3 debug port. It also includes some lines > of changes in usb_debug driver so that it can be bound when > a USB3 debug device is enumerated. > > --- > Change log: > v6->v7: > - add a new patch "[PATCH 1/5] x86: add simple udelay > calibration" to make udelay() work for early drivers. > - [PATCH 2/5] usb: dbc: early driver for xhci debug capability > - add a kernel thread to handle error cases, such as cable > unplugging. > - Fixed several code styles pointed out by Ingo. > > v5->v6: > - rebase the patches on top of the latest 4.10-rc4 > - run successfully in a 32-bit kernel > - [PATCH 1/4] > - remove ugly linebreaks to make code more readable > - rename config names to make them consistency > - move sleep-able ioremap() out of the lock area > - rename reserved fields of register structures > - make the vertical tabulation of struct fields consistent > - [PATCH 2/4] > - remove "#ifdef" in the generic code by creating proper > wrappers in header file > - [PATCH 3/4] > - refine the title and commit message > - [PATCH 4/4] > - fix several typos and grammar errors in the document > > v4->v5: > - add raw_spin_lock to make xdbc_bulk_write() reentrant. > > v3->v4: > - Rename the document with .dst suffix. > - Add the list of hardware that has been succesfuly > tested on in the document. > > v2->v3: > - Removed spinlock usage. > - Removed work queue usage. > - Refined the user guide 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 (5): > x86: add simple udelay calibration > usb: dbc: early driver for xhci debug capability > x86: add support for earlyprintk via USB3 debug port > usb: serial: add dbc debug device support to usb_debug > usb: doc: add document for USB3 debug port usage > > Documentation/admin-guide/kernel-parameters.txt |1 + > Documentation/usb/usb3-debug-port.rst | 98 +++ > arch/x86/Kconfig.debug | 17 + > arch/x86/kernel/early_printk.c |5 + > arch/x86/kernel/setup.c | 26 + > drivers/usb/Kconfig |3 + > drivers/usb/Makefile|2 +- > drivers/usb/early/Makefile |1 + > drivers/usb/early/xhci-dbc.c| 1026 > +++ > drivers/usb/early/xhci-dbc.h| 210 + > drivers/usb/serial/usb_debug.c | 28 +- > include/linux/usb/xhci-dbgp.h | 29 + > 12 files changed, 1442 insertions(+), 4 deletions(-) > create mode 100644 Documentation/usb/usb3-debug-port.rst > create mode 100644 drivers/usb/early/xhci-dbc.c > create mode 100644 drivers/usb/early/xhci-dbc.h > create mode 100644 include/linux/usb/xhci-dbgp.h >
Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events
Hi,
On 02/15/2017 04:56 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu <baolu...@linux.intel.com> writes:
>>> Lu Baolu <baolu...@linux.intel.com> writes:
>>>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>>>> index 1ac2cdf..c31eeaf 100644
>>>> --- a/drivers/usb/host/xhci-trace.h
>>>> +++ b/drivers/usb/host/xhci-trace.h
>>>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>>>>TP_ARGS(urb)
>>>> );
>>>>
>>>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>>>> + TP_PROTO(struct xhci_command *cmd),
>>>> + TP_ARGS(cmd),
>>>> + TP_STRUCT__entry(
>>>> + __field(struct xhci_command *, cmd)
>>>> + __field(struct xhci_container_ctx *, in_ctx)
>>>> + __field(union xhci_trb *, cmd_trb)
>>>> + __field(int, slot_id)
>>>> + __field(int, status)
>>>> + __field(int, type)
>>>> + ),
>>>> + TP_fast_assign(
>>>> + __entry->cmd = cmd;
>>>> + __entry->in_ctx = cmd->in_ctx;
>>>> + __entry->cmd_trb = cmd->command_trb;
>>>> + __entry->slot_id = cmd->slot_id;
>>>> + __entry->status = cmd->status;
>>>> + __entry->type =
>>>> TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>>>> + ),
>>>> + TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>>>> + __entry->cmd, xhci_trb_type_string(__entry->type),
>>>> + __entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>>>> + __entry->status
>>>> + )
>>>> +);
>>> we already have a generic TRB tracer that decodes every single TRB. What
>>> is this bringing that the previous doesn't provide?
>> This tracer traces the life cycle of a command. It gives,
>>
>> 1) Which function started an xhci command?
>> 2) What was name of that command?
>> 3) Did hardware respond to it, or timed out?
>> 4) If hardware responded, what was the execution result?
>> 5) If timed out, did 'abort command ring operation' abort it successfully?
>> 6) Was the command structure freed at last?
> We already have all that, AFAICT. Command is enqueued, then an event
> triggers for command completion, then we look at results.
The TRB tracer can directly tell us above 2 and 4 by tracing the enqueue
and dequeue of command trbs. It doesn't tell us 1 and 6. For 3 and 5, we
might be able to get to know, but it needs deep understand of the driver
code and many efforts to look through the trace log.
This command tracer will make the life easier when we are debugging
command related issues in xhci driver.
> The only thing
> missing for completeness is slot/EP context tracers (which I've pointed
> you to) so we can see what changes each command cause to the different
> contexts.
>
> Frankly, I don't think printing out context pointers brings
> anything. What can you do with that address? :-p Same goes for cmd
> pointer, it brings nothing; gives no insight into the problem
> whatsoever.
>
> We certainly need to know which command was enqueued, the slot, etc. But
> addresses... not so sure.
My thought was 'if we find a command failed, we might want to
know what parameters did we feed hardware'. The trb and ctx
pointers will let us go through the trb and context trace log.
For the command pointer, it can help us to grep the trace log
of a single command, so we are able to know how did the
command go.
Best regards,
Lu Baolu
>
>>> BTW, I also have
>>> ready Slot and EP context tracers, I didn't send before because I
>>> already had quite a large series pending for Mathias :-p
>> Sorry for the duplication.
> no need to apologize, you didn't know :-)
>
Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events
Hi,
On 02/15/2017 04:56 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu writes:
>>> Lu Baolu writes:
>>>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>>>> index 1ac2cdf..c31eeaf 100644
>>>> --- a/drivers/usb/host/xhci-trace.h
>>>> +++ b/drivers/usb/host/xhci-trace.h
>>>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>>>>TP_ARGS(urb)
>>>> );
>>>>
>>>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>>>> + TP_PROTO(struct xhci_command *cmd),
>>>> + TP_ARGS(cmd),
>>>> + TP_STRUCT__entry(
>>>> + __field(struct xhci_command *, cmd)
>>>> + __field(struct xhci_container_ctx *, in_ctx)
>>>> + __field(union xhci_trb *, cmd_trb)
>>>> + __field(int, slot_id)
>>>> + __field(int, status)
>>>> + __field(int, type)
>>>> + ),
>>>> + TP_fast_assign(
>>>> + __entry->cmd = cmd;
>>>> + __entry->in_ctx = cmd->in_ctx;
>>>> + __entry->cmd_trb = cmd->command_trb;
>>>> + __entry->slot_id = cmd->slot_id;
>>>> + __entry->status = cmd->status;
>>>> + __entry->type =
>>>> TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>>>> + ),
>>>> + TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>>>> + __entry->cmd, xhci_trb_type_string(__entry->type),
>>>> + __entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>>>> + __entry->status
>>>> + )
>>>> +);
>>> we already have a generic TRB tracer that decodes every single TRB. What
>>> is this bringing that the previous doesn't provide?
>> This tracer traces the life cycle of a command. It gives,
>>
>> 1) Which function started an xhci command?
>> 2) What was name of that command?
>> 3) Did hardware respond to it, or timed out?
>> 4) If hardware responded, what was the execution result?
>> 5) If timed out, did 'abort command ring operation' abort it successfully?
>> 6) Was the command structure freed at last?
> We already have all that, AFAICT. Command is enqueued, then an event
> triggers for command completion, then we look at results.
The TRB tracer can directly tell us above 2 and 4 by tracing the enqueue
and dequeue of command trbs. It doesn't tell us 1 and 6. For 3 and 5, we
might be able to get to know, but it needs deep understand of the driver
code and many efforts to look through the trace log.
This command tracer will make the life easier when we are debugging
command related issues in xhci driver.
> The only thing
> missing for completeness is slot/EP context tracers (which I've pointed
> you to) so we can see what changes each command cause to the different
> contexts.
>
> Frankly, I don't think printing out context pointers brings
> anything. What can you do with that address? :-p Same goes for cmd
> pointer, it brings nothing; gives no insight into the problem
> whatsoever.
>
> We certainly need to know which command was enqueued, the slot, etc. But
> addresses... not so sure.
My thought was 'if we find a command failed, we might want to
know what parameters did we feed hardware'. The trb and ctx
pointers will let us go through the trb and context trace log.
For the command pointer, it can help us to grep the trace log
of a single command, so we are able to know how did the
command go.
Best regards,
Lu Baolu
>
>>> BTW, I also have
>>> ready Slot and EP context tracers, I didn't send before because I
>>> already had quite a large series pending for Mathias :-p
>> Sorry for the duplication.
> no need to apologize, you didn't know :-)
>
Re: [PATCH 2/6] usb: xhci: enhance xhci_log_ctx trace events
Hi, On 02/15/2017 04:00 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu <baolu...@linux.intel.com> writes: >> XHCI driver has defined xhci_log_ctx trace events to trace >> the change of an xhci input or output context. This patch >> extends the trace class of xhci_log_ctx to print out the >> contents of a context block in a human readable way. >> >> This patch also adds some other xhci_log_ctx based events >> where the xhci input or output context changes. >> >> Signed-off-by: Lu Baolu <baolu...@linux.intel.com> > how about? > > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=xhci-cleanup=4c45cec9f399fb3a53b77c4bb63d5e8fbe382171 > Great. I will look into this. Best regards, Lu Baolu
Re: [PATCH 2/6] usb: xhci: enhance xhci_log_ctx trace events
Hi, On 02/15/2017 04:00 PM, Felipe Balbi wrote: > Hi, > > Lu Baolu writes: >> XHCI driver has defined xhci_log_ctx trace events to trace >> the change of an xhci input or output context. This patch >> extends the trace class of xhci_log_ctx to print out the >> contents of a context block in a human readable way. >> >> This patch also adds some other xhci_log_ctx based events >> where the xhci input or output context changes. >> >> Signed-off-by: Lu Baolu > how about? > > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=xhci-cleanup=4c45cec9f399fb3a53b77c4bb63d5e8fbe382171 > Great. I will look into this. Best regards, Lu Baolu
Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events
Hi,
On 02/15/2017 03:58 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu <baolu...@linux.intel.com> writes:
>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>> index 1ac2cdf..c31eeaf 100644
>> --- a/drivers/usb/host/xhci-trace.h
>> +++ b/drivers/usb/host/xhci-trace.h
>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>> TP_ARGS(urb)
>> );
>>
>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>> +TP_PROTO(struct xhci_command *cmd),
>> +TP_ARGS(cmd),
>> +TP_STRUCT__entry(
>> +__field(struct xhci_command *, cmd)
>> +__field(struct xhci_container_ctx *, in_ctx)
>> +__field(union xhci_trb *, cmd_trb)
>> +__field(int, slot_id)
>> +__field(int, status)
>> +__field(int, type)
>> +),
>> +TP_fast_assign(
>> +__entry->cmd = cmd;
>> +__entry->in_ctx = cmd->in_ctx;
>> +__entry->cmd_trb = cmd->command_trb;
>> +__entry->slot_id = cmd->slot_id;
>> +__entry->status = cmd->status;
>> +__entry->type =
>> TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>> +),
>> +TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>> +__entry->cmd, xhci_trb_type_string(__entry->type),
>> +__entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>> +__entry->status
>> +)
>> +);
> we already have a generic TRB tracer that decodes every single TRB. What
> is this bringing that the previous doesn't provide?
This tracer traces the life cycle of a command. It gives,
1) Which function started an xhci command?
2) What was name of that command?
3) Did hardware respond to it, or timed out?
4) If hardware responded, what was the execution result?
5) If timed out, did 'abort command ring operation' abort it successfully?
6) Was the command structure freed at last?
> BTW, I also have
> ready Slot and EP context tracers, I didn't send before because I
> already had quite a large series pending for Mathias :-p
>
Sorry for the duplication.
Best regards,
Lu Baolu
Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events
Hi,
On 02/15/2017 03:58 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu writes:
>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>> index 1ac2cdf..c31eeaf 100644
>> --- a/drivers/usb/host/xhci-trace.h
>> +++ b/drivers/usb/host/xhci-trace.h
>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>> TP_ARGS(urb)
>> );
>>
>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>> +TP_PROTO(struct xhci_command *cmd),
>> +TP_ARGS(cmd),
>> +TP_STRUCT__entry(
>> +__field(struct xhci_command *, cmd)
>> +__field(struct xhci_container_ctx *, in_ctx)
>> +__field(union xhci_trb *, cmd_trb)
>> +__field(int, slot_id)
>> +__field(int, status)
>> +__field(int, type)
>> +),
>> +TP_fast_assign(
>> +__entry->cmd = cmd;
>> +__entry->in_ctx = cmd->in_ctx;
>> +__entry->cmd_trb = cmd->command_trb;
>> +__entry->slot_id = cmd->slot_id;
>> +__entry->status = cmd->status;
>> +__entry->type =
>> TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>> +),
>> +TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>> +__entry->cmd, xhci_trb_type_string(__entry->type),
>> +__entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>> +__entry->status
>> +)
>> +);
> we already have a generic TRB tracer that decodes every single TRB. What
> is this bringing that the previous doesn't provide?
This tracer traces the life cycle of a command. It gives,
1) Which function started an xhci command?
2) What was name of that command?
3) Did hardware respond to it, or timed out?
4) If hardware responded, what was the execution result?
5) If timed out, did 'abort command ring operation' abort it successfully?
6) Was the command structure freed at last?
> BTW, I also have
> ready Slot and EP context tracers, I didn't send before because I
> already had quite a large series pending for Mathias :-p
>
Sorry for the duplication.
Best regards,
Lu Baolu
[PATCH 5/6] usb: xhci: fix link trb decoding
xhci_decode_trb() treats a link trb in the same way as that for
an event trb. This patch fixes this by decoding the link trb
according to the spec.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci.h | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index ef4a342..ff12c8a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2159,14 +2159,12 @@ static inline const char *xhci_decode_trb(u32 field0,
u32 field1, u32 field2,
switch (type) {
case TRB_LINK:
sprintf(str,
- "TRB %08x%08x status '%s' len %d slot %d ep %d type
'%s' flags %c:%c",
- field1, field0,
- xhci_trb_comp_code_string(GET_COMP_CODE(field2)),
- EVENT_TRB_LEN(field2), TRB_TO_SLOT_ID(field3),
- /* Macro decrements 1, maybe it shouldn't?!? */
- TRB_TO_EP_INDEX(field3) + 1,
+ "LINK %08x%08x intr %d type '%s' flags %c:%c:%c:%c",
+ field1, field0, GET_INTR_TARGET(field2),
xhci_trb_type_string(TRB_FIELD_TO_TYPE(field3)),
- field3 & EVENT_DATA ? 'E' : 'e',
+ field3 & TRB_IOC ? 'I' : 'i',
+ field3 & TRB_CHAIN ? 'C' : 'c',
+ field3 & TRB_TC ? 'T' : 't',
field3 & TRB_CYCLE ? 'C' : 'c');
break;
case TRB_TRANSFER:
--
2.1.4
[PATCH 1/6] usb: xhci: add xhci_log_cmd trace events
This patch creates a new event class called xhci_log_cmd, and
defines the events used for tracing the life cycle of commands
issued for various purposes.
This info can be used, later, to print, in a human readable way,
the life cycle of an xHCI command using the trace-cmd tool and
the appropriate plugin.
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-hub.c | 2 +
drivers/usb/host/xhci-ring.c | 13 +--
drivers/usb/host/xhci-trace.h | 90 +++
drivers/usb/host/xhci.c | 7
4 files changed, 108 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 3bddeaa..2c3f77f 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -411,9 +411,11 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
}
xhci_queue_stop_endpoint(xhci, command, slot_id, i,
suspend);
+ trace_cmd_xhci_stop_device(command);
}
}
xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
+ trace_cmd_xhci_stop_device(cmd);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d9936c7..4cdcd71 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1124,6 +1124,7 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
xhci_queue_configure_endpoint(xhci, command,
xhci->devs[slot_id]->in_ctx->dma, slot_id,
false);
+ trace_cmd_xhci_handle_cmd_reset_ep(command);
xhci_ring_cmd_db(xhci);
} else {
/* Clear our internal halted state */
@@ -1231,13 +1232,13 @@ static void xhci_handle_cmd_nec_get_fw(struct xhci_hcd
*xhci,
static void xhci_complete_del_and_free_cmd(struct xhci_command *cmd, u32
status)
{
list_del(>cmd_list);
+ cmd->status = status;
+ trace_cmd_xhci_complete_del_and_free_cmd(cmd);
- if (cmd->completion) {
- cmd->status = status;
+ if (cmd->completion)
complete(cmd->completion);
- } else {
+ else
kfree(cmd);
- }
}
void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
@@ -1268,6 +1269,7 @@ void xhci_handle_command_timeout(struct work_struct *work)
}
/* mark this command to be cancelled */
xhci->current_cmd->status = COMP_COMMAND_ABORTED;
+ trace_cmd_xhci_handle_command_timeout(xhci->current_cmd);
/* Make sure command ring is running before aborting it */
hw_ring_state = xhci_read_64(xhci, >op_regs->cmd_ring);
@@ -1432,6 +1434,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
}
event_handled:
+ trace_cmd_handle_cmd_completion(cmd);
xhci_complete_del_and_free_cmd(cmd, cmd_comp_code);
inc_deq(xhci, xhci->cmd_ring);
@@ -1773,6 +1776,7 @@ static void xhci_cleanup_halted_endpoint(struct xhci_hcd
*xhci,
ep->stopped_stream = stream_id;
xhci_queue_reset_ep(xhci, command, slot_id, ep_index);
+ trace_cmd_xhci_cleanup_halted_endpoint(command);
xhci_cleanup_stalled_ring(xhci, ep_index, td);
ep->stopped_stream = 0;
@@ -3956,6 +3960,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
xhci_free_command(xhci, cmd);
return;
}
+ trace_cmd_xhci_queue_new_dequeue_state(cmd);
/* Stop the TD queueing code from ringing the doorbell until
* this command completes. The HC won't set the dequeue pointer
diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
index 1ac2cdf..c31eeaf 100644
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
TP_ARGS(urb)
);
+DECLARE_EVENT_CLASS(xhci_log_cmd,
+ TP_PROTO(struct xhci_command *cmd),
+ TP_ARGS(cmd),
+ TP_STRUCT__entry(
+ __field(struct xhci_command *, cmd)
+ __field(struct xhci_container_ctx *, in_ctx)
+ __field(union xhci_trb *, cmd_trb)
+ __field(int, slot_id)
+ __field(int, status)
+ __field(int, type)
+ ),
+ TP_fast_assign(
+ __entry->cmd = cmd;
+ __entry->in_ctx = cmd->in_ctx;
+ __entry->cmd_trb = cmd->command_trb;
+ __entry->slot_id = cmd->slot_id;
+ __entry->status = cmd->status;
+ __entry->type =
TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
+ ),
+
[PATCH 5/6] usb: xhci: fix link trb decoding
xhci_decode_trb() treats a link trb in the same way as that for
an event trb. This patch fixes this by decoding the link trb
according to the spec.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.h | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index ef4a342..ff12c8a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2159,14 +2159,12 @@ static inline const char *xhci_decode_trb(u32 field0,
u32 field1, u32 field2,
switch (type) {
case TRB_LINK:
sprintf(str,
- "TRB %08x%08x status '%s' len %d slot %d ep %d type
'%s' flags %c:%c",
- field1, field0,
- xhci_trb_comp_code_string(GET_COMP_CODE(field2)),
- EVENT_TRB_LEN(field2), TRB_TO_SLOT_ID(field3),
- /* Macro decrements 1, maybe it shouldn't?!? */
- TRB_TO_EP_INDEX(field3) + 1,
+ "LINK %08x%08x intr %d type '%s' flags %c:%c:%c:%c",
+ field1, field0, GET_INTR_TARGET(field2),
xhci_trb_type_string(TRB_FIELD_TO_TYPE(field3)),
- field3 & EVENT_DATA ? 'E' : 'e',
+ field3 & TRB_IOC ? 'I' : 'i',
+ field3 & TRB_CHAIN ? 'C' : 'c',
+ field3 & TRB_TC ? 'T' : 't',
field3 & TRB_CYCLE ? 'C' : 'c');
break;
case TRB_TRANSFER:
--
2.1.4
[PATCH 1/6] usb: xhci: add xhci_log_cmd trace events
This patch creates a new event class called xhci_log_cmd, and
defines the events used for tracing the life cycle of commands
issued for various purposes.
This info can be used, later, to print, in a human readable way,
the life cycle of an xHCI command using the trace-cmd tool and
the appropriate plugin.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-hub.c | 2 +
drivers/usb/host/xhci-ring.c | 13 +--
drivers/usb/host/xhci-trace.h | 90 +++
drivers/usb/host/xhci.c | 7
4 files changed, 108 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 3bddeaa..2c3f77f 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -411,9 +411,11 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
}
xhci_queue_stop_endpoint(xhci, command, slot_id, i,
suspend);
+ trace_cmd_xhci_stop_device(command);
}
}
xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
+ trace_cmd_xhci_stop_device(cmd);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d9936c7..4cdcd71 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1124,6 +1124,7 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
xhci_queue_configure_endpoint(xhci, command,
xhci->devs[slot_id]->in_ctx->dma, slot_id,
false);
+ trace_cmd_xhci_handle_cmd_reset_ep(command);
xhci_ring_cmd_db(xhci);
} else {
/* Clear our internal halted state */
@@ -1231,13 +1232,13 @@ static void xhci_handle_cmd_nec_get_fw(struct xhci_hcd
*xhci,
static void xhci_complete_del_and_free_cmd(struct xhci_command *cmd, u32
status)
{
list_del(>cmd_list);
+ cmd->status = status;
+ trace_cmd_xhci_complete_del_and_free_cmd(cmd);
- if (cmd->completion) {
- cmd->status = status;
+ if (cmd->completion)
complete(cmd->completion);
- } else {
+ else
kfree(cmd);
- }
}
void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
@@ -1268,6 +1269,7 @@ void xhci_handle_command_timeout(struct work_struct *work)
}
/* mark this command to be cancelled */
xhci->current_cmd->status = COMP_COMMAND_ABORTED;
+ trace_cmd_xhci_handle_command_timeout(xhci->current_cmd);
/* Make sure command ring is running before aborting it */
hw_ring_state = xhci_read_64(xhci, >op_regs->cmd_ring);
@@ -1432,6 +1434,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
}
event_handled:
+ trace_cmd_handle_cmd_completion(cmd);
xhci_complete_del_and_free_cmd(cmd, cmd_comp_code);
inc_deq(xhci, xhci->cmd_ring);
@@ -1773,6 +1776,7 @@ static void xhci_cleanup_halted_endpoint(struct xhci_hcd
*xhci,
ep->stopped_stream = stream_id;
xhci_queue_reset_ep(xhci, command, slot_id, ep_index);
+ trace_cmd_xhci_cleanup_halted_endpoint(command);
xhci_cleanup_stalled_ring(xhci, ep_index, td);
ep->stopped_stream = 0;
@@ -3956,6 +3960,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
xhci_free_command(xhci, cmd);
return;
}
+ trace_cmd_xhci_queue_new_dequeue_state(cmd);
/* Stop the TD queueing code from ringing the doorbell until
* this command completes. The HC won't set the dequeue pointer
diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
index 1ac2cdf..c31eeaf 100644
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
TP_ARGS(urb)
);
+DECLARE_EVENT_CLASS(xhci_log_cmd,
+ TP_PROTO(struct xhci_command *cmd),
+ TP_ARGS(cmd),
+ TP_STRUCT__entry(
+ __field(struct xhci_command *, cmd)
+ __field(struct xhci_container_ctx *, in_ctx)
+ __field(union xhci_trb *, cmd_trb)
+ __field(int, slot_id)
+ __field(int, status)
+ __field(int, type)
+ ),
+ TP_fast_assign(
+ __entry->cmd = cmd;
+ __entry->in_ctx = cmd->in_ctx;
+ __entry->cmd_trb = cmd->command_trb;
+ __entry->slot_id = cmd->slot_id;
+ __entry->status = cmd->status;
+ __entry->type =
TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
+ ),
+ TP_printk("cmd @%p: %s: in_c
[PATCH 3/6] usb: xhci: remove xhci_debug_trb()
Every XHCI TRB has already been traced by the trb trace events.
It is unnecessary to put the same message in kernel log. This
patch removes xhci_debug_trb().
Signed-off-by: Lu Baolu <baolu...@linux.intel.com>
---
drivers/usb/host/xhci-dbg.c | 57
drivers/usb/host/xhci-ring.c | 4
drivers/usb/host/xhci.h | 2 --
3 files changed, 63 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 363d125..269089c 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -254,63 +254,6 @@ void xhci_print_registers(struct xhci_hcd *xhci)
xhci_print_ports(xhci);
}
-void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb)
-{
- int i;
- for (i = 0; i < 4; i++)
- xhci_dbg(xhci, "Offset 0x%x = 0x%x\n",
- i*4, trb->generic.field[i]);
-}
-
-/**
- * Debug a transfer request block (TRB).
- */
-void xhci_debug_trb(struct xhci_hcd *xhci, union xhci_trb *trb)
-{
- u64 address;
- u32 type = le32_to_cpu(trb->link.control) & TRB_TYPE_BITMASK;
-
- switch (type) {
- case TRB_TYPE(TRB_LINK):
- xhci_dbg(xhci, "Link TRB:\n");
- xhci_print_trb_offsets(xhci, trb);
-
- address = le64_to_cpu(trb->link.segment_ptr);
- xhci_dbg(xhci, "Next ring segment DMA address = 0x%llx\n",
address);
-
- xhci_dbg(xhci, "Interrupter target = 0x%x\n",
-GET_INTR_TARGET(le32_to_cpu(trb->link.intr_target)));
- xhci_dbg(xhci, "Cycle bit = %u\n",
-le32_to_cpu(trb->link.control) & TRB_CYCLE);
- xhci_dbg(xhci, "Toggle cycle bit = %u\n",
-le32_to_cpu(trb->link.control) & LINK_TOGGLE);
- xhci_dbg(xhci, "No Snoop bit = %u\n",
-le32_to_cpu(trb->link.control) & TRB_NO_SNOOP);
- break;
- case TRB_TYPE(TRB_TRANSFER):
- address = le64_to_cpu(trb->trans_event.buffer);
- /*
-* FIXME: look at flags to figure out if it's an address or if
-* the data is directly in the buffer field.
-*/
- xhci_dbg(xhci, "DMA address or buffer contents= %llu\n",
address);
- break;
- case TRB_TYPE(TRB_COMPLETION):
- address = le64_to_cpu(trb->event_cmd.cmd_trb);
- xhci_dbg(xhci, "Command TRB pointer = %llu\n", address);
- xhci_dbg(xhci, "Completion status = %u\n",
-GET_COMP_CODE(le32_to_cpu(trb->event_cmd.status)));
- xhci_dbg(xhci, "Flags = 0x%x\n",
-le32_to_cpu(trb->event_cmd.flags));
- break;
- default:
- xhci_dbg(xhci, "Unknown TRB with TRB type ID %u\n",
- (unsigned int) type>>10);
- xhci_print_trb_offsets(xhci, trb);
- break;
- }
-}
-
/**
* Debug a segment with an xHCI ring.
*
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 4cdcd71..80cdb55 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2403,10 +2403,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
xhci_warn(xhci, "WARN Event TRB for slot %d ep
%d with no TDs queued?\n",
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
ep_index);
- xhci_dbg(xhci, "Event TRB with TRB type ID
%u\n",
- (le32_to_cpu(event->flags) &
-TRB_TYPE_BITMASK)>>10);
- xhci_print_trb_offsets(xhci, (union xhci_trb *)
event);
}
if (ep->skip) {
ep->skip = false;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index d6c4038..13ae2ba 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1918,8 +1918,6 @@ void xhci_print_ir_set(struct xhci_hcd *xhci, int
set_num);
void xhci_print_registers(struct xhci_hcd *xhci);
void xhci_dbg_regs(struct xhci_hcd *xhci);
void xhci_print_run_regs(struct xhci_hcd *xhci);
-void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb);
-void xhci_debug_trb(struct xhci_hcd *xhci, union xhci_trb *trb);
void xhci_debug_segment(struct xhci_hcd *xhci, struct xhci_segment *seg);
void xhci_debug_ring(struct xhci_hcd *xhci, struct xhci_ring *ring);
void xhci_dbg_erst(struct xhci_hcd *xhci, struct xhci_erst *erst);
--
2.1.4
[PATCH 3/6] usb: xhci: remove xhci_debug_trb()
Every XHCI TRB has already been traced by the trb trace events.
It is unnecessary to put the same message in kernel log. This
patch removes xhci_debug_trb().
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-dbg.c | 57
drivers/usb/host/xhci-ring.c | 4
drivers/usb/host/xhci.h | 2 --
3 files changed, 63 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 363d125..269089c 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -254,63 +254,6 @@ void xhci_print_registers(struct xhci_hcd *xhci)
xhci_print_ports(xhci);
}
-void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb)
-{
- int i;
- for (i = 0; i < 4; i++)
- xhci_dbg(xhci, "Offset 0x%x = 0x%x\n",
- i*4, trb->generic.field[i]);
-}
-
-/**
- * Debug a transfer request block (TRB).
- */
-void xhci_debug_trb(struct xhci_hcd *xhci, union xhci_trb *trb)
-{
- u64 address;
- u32 type = le32_to_cpu(trb->link.control) & TRB_TYPE_BITMASK;
-
- switch (type) {
- case TRB_TYPE(TRB_LINK):
- xhci_dbg(xhci, "Link TRB:\n");
- xhci_print_trb_offsets(xhci, trb);
-
- address = le64_to_cpu(trb->link.segment_ptr);
- xhci_dbg(xhci, "Next ring segment DMA address = 0x%llx\n",
address);
-
- xhci_dbg(xhci, "Interrupter target = 0x%x\n",
-GET_INTR_TARGET(le32_to_cpu(trb->link.intr_target)));
- xhci_dbg(xhci, "Cycle bit = %u\n",
-le32_to_cpu(trb->link.control) & TRB_CYCLE);
- xhci_dbg(xhci, "Toggle cycle bit = %u\n",
-le32_to_cpu(trb->link.control) & LINK_TOGGLE);
- xhci_dbg(xhci, "No Snoop bit = %u\n",
-le32_to_cpu(trb->link.control) & TRB_NO_SNOOP);
- break;
- case TRB_TYPE(TRB_TRANSFER):
- address = le64_to_cpu(trb->trans_event.buffer);
- /*
-* FIXME: look at flags to figure out if it's an address or if
-* the data is directly in the buffer field.
-*/
- xhci_dbg(xhci, "DMA address or buffer contents= %llu\n",
address);
- break;
- case TRB_TYPE(TRB_COMPLETION):
- address = le64_to_cpu(trb->event_cmd.cmd_trb);
- xhci_dbg(xhci, "Command TRB pointer = %llu\n", address);
- xhci_dbg(xhci, "Completion status = %u\n",
-GET_COMP_CODE(le32_to_cpu(trb->event_cmd.status)));
- xhci_dbg(xhci, "Flags = 0x%x\n",
-le32_to_cpu(trb->event_cmd.flags));
- break;
- default:
- xhci_dbg(xhci, "Unknown TRB with TRB type ID %u\n",
- (unsigned int) type>>10);
- xhci_print_trb_offsets(xhci, trb);
- break;
- }
-}
-
/**
* Debug a segment with an xHCI ring.
*
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 4cdcd71..80cdb55 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2403,10 +2403,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
xhci_warn(xhci, "WARN Event TRB for slot %d ep
%d with no TDs queued?\n",
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
ep_index);
- xhci_dbg(xhci, "Event TRB with TRB type ID
%u\n",
- (le32_to_cpu(event->flags) &
-TRB_TYPE_BITMASK)>>10);
- xhci_print_trb_offsets(xhci, (union xhci_trb *)
event);
}
if (ep->skip) {
ep->skip = false;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index d6c4038..13ae2ba 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1918,8 +1918,6 @@ void xhci_print_ir_set(struct xhci_hcd *xhci, int
set_num);
void xhci_print_registers(struct xhci_hcd *xhci);
void xhci_dbg_regs(struct xhci_hcd *xhci);
void xhci_print_run_regs(struct xhci_hcd *xhci);
-void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb);
-void xhci_debug_trb(struct xhci_hcd *xhci, union xhci_trb *trb);
void xhci_debug_segment(struct xhci_hcd *xhci, struct xhci_segment *seg);
void xhci_debug_ring(struct xhci_hcd *xhci, struct xhci_ring *ring);
void xhci_dbg_erst(struct xhci_hcd *xhci, struct xhci_erst *erst);
--
2.1.4
