Re: DWC3 question
Hi, (please, always Cc linux-usb@vger.kernel.org) Fernando writes: > Hi Felipe. > > Sorry to bother you, but your name is all over the place on the DWC3 code > and I was wondering if you could help me with something (I promise there > won't be future emails with further questions). > > > The thing is nothing happens when a USB device is plugged into the host > port (no call to "hub_irq()")... Also: > > 1) The generix xHCI "PORTSC" register does not change its value > from "0x02a0" (PP = 1, PLS = 5, RxDetect state)". > > 2) The DWC3 specific "GSTS" register is always set to "0x3e800021 > (Host mode, CRS timeout)" which platform is this? Which kernel version? > I have already verified there are no electrical problems (the D+/- lines > are correctly being pulled up when a device is inserted). > > I don't know how to proceed from here. > > My question is: do you know where I can get DWC3 specific registers > documentation? I guess I can go through the description of all of them > to find out what is going on. you need to sign agreement with Synopsys to get it. -- balbi signature.asc Description: PGP signature
Re: [PATCH v4 02/13] dt-bindings: usb: add documentation for typec port controller(TCPCI)
Hi Li Jun,
Are you working on an updated version of this patch series?
I'm pondering other changes that builds on these patches (the documentation
and the fwnode added to the tcpc_dev and tcpm primarily).
Btw, there is a semi-colon missing in your example below.
BR // Mats
On 2018-03-28 18:06, Li Jun wrote:
TCPCI stands for typec port controller interface, its implementation
has full typec port control with power delivery support, it's a
standard i2c slave with GPIO input as irq interface, detail see spec
"Universal Serial Bus Type-C Port Controller Interface Specification
Revision 1.0, Version 1.1"
Signed-off-by: Li Jun
---
.../devicetree/bindings/usb/typec-tcpci.txt| 33 ++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt
b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
new file mode 100644
index 000..7a7a8e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
@@ -0,0 +1,33 @@
+TCPCI(Typec port cotroller interface) binding
+-
+
+Required properties:
+- compatible: should be "usb-tcpci,chip-specific-string".
+- reg: the i2c slave address of typec port controller device.
+- interrupt-parent: the phandle to the interrupt controller which provides
+the interrupt.
+- interrupts: interrupt specification for tcpci alert.
+
+Required sub-node:
+- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
+ of connector node are specified in
+ Documentation/devicetree/bindings/connector/usb-connector.txt
+
+Example:
+
+ptn5110@50 {
+ compatible = "usb-tcpci,ptn5110";
+ reg = <0x50>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ port-type = "dual";
+ try-power-role = "sink"
Here!
+ source-pdos = <0x380190c8>;
+ sink-pdos = <0x380190c8 0x3802d0c8>;
+ op-sink-microwatt-hours = <900>;
+ };
+};
--
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: DWC3 question
> which platform is this? Which kernel version? This is a custom design based on an LS1046a reference board from NxP running kernel 4.4.74 with patches from the LEDE/Openwrt project. > you need to sign agreement with Synopsys to get it. I'll work on that. Thanks. But... based on what you know, is it OK to expect the PORTSC register to change when a device is plugged in? In other words: if I want to figure out whether it is a software configuration problem or hardware problem, is looking at the PORTSC register the best way? or is there a better (DWC3 specific) register to monitor? Thanks. -- 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: DWC3 question
Hi, Fernando writes: >> which platform is this? Which kernel version? > > This is a custom design based on an LS1046a reference board from NxP > running kernel 4.4.74 with patches from the LEDE/Openwrt project. in that case, you need to ask for support from NxP. Either that, or you need to switch to the mainline kernel. >> you need to sign agreement with Synopsys to get it. > > I'll work on that. Thanks. But... based on what you know, is it OK to > expect the PORTSC register to change when a device is plugged in? yes. You may wanna get a copy of xhci spec, that's publicly available. > In other words: if I want to figure out whether it is a software > configuration > problem or hardware problem, is looking at the PORTSC register the best > way? or is there a better (DWC3 specific) register to monitor? no idea about how NxP integrated the dwc3 IP. You may wanna ask them. If I were to guess, I'd say you already paid for support. Good luck -- balbi signature.asc Description: PGP signature
Re: [PATCH v4 01/13] dt-bindings: connector: add properties for typec
Hi, On Thu, Mar 29, 2018 at 12:06:06AM +0800, Li Jun wrote: > +Optional properties for usb-c-connector: > +- power-type: should be one of "source", "sink" or "dual"(DRP) if typec > + connector has power support. > +- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK > + or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC. > +- data-type: should be one of "host", "device", "dual"(DRD) if typec > + connector supports USB data. Please use "power-role" and "data-role". Thanks, -- heikki -- 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: Kernel Oops when downloading data from a 4G modem connected via USB
I've done some further testing using a different kernel (4.14.38) and enabled debug messages in the DWC2 driver. Here's the capture from dmesg when the error occurs (the full dmesg log can be found at https://paste.ee/p/YKpGn): [ 84.167126] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction Error-- [ 84.216520] dwc2 101c.usb: --Host Channel 8 Interrupt: Transaction Error-- [ 84.242636] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction Error-- [ 84.263634] dwc2 101c.usb: --Host Channel 11 Interrupt: Transaction Error-- [ 84.276001] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction Error-- [ 84.276369] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction Error-- [ 84.276547] dwc2 101c.usb: --Host Channel 4 Interrupt: Transaction Error-- [ 84.277231] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.26] dwc2 101c.usb: --Host Channel 7 Interrupt: Transaction Error-- [ 84.297704] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction Error-- [ 84.305824] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction Error-- [ 84.306066] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.320372] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction Error-- [ 84.324756] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction Error-- [ 84.325176] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction Error-- [ 84.329268] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.330228] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.338506] dwc2 101c.usb: --Host Channel 3 Interrupt: Transaction Error-- [ 84.338830] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction Error-- [ 84.343005] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction Error-- [ 84.343247] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction Error-- [ 84.343306] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.346649] dwc2 101c.usb: --Host Channel 7 Interrupt: Transaction Error-- [ 84.347051] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction Error-- [ 84.347214] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction Error-- [ 84.347654] dwc2 101c.usb: --Host Channel 3 Interrupt: Transaction Error-- [ 84.347819] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction Error-- [ 84.348021] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction Error-- [ 84.351267] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction Error-- [ 84.360017] dwc2 101c.usb: --Host Channel 11 Interrupt: Transaction Error-- [ 84.360284] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction Error-- [ 84.365016] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction Error-- [ 84.368882] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.373262] dwc2 101c.usb: --Host Channel 4 Interrupt: Transaction Error-- [ 84.373796] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction Error-- [ 84.377982] dwc2 101c.usb: --Host Channel 6 Interrupt: Transaction Error-- [ 84.378360] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.378526] dwc2 101c.usb: --Host Channel 3 Interrupt: Transaction Error-- [ 84.382005] dwc2 101c.usb: --Host Channel 5 Interrupt: Transaction Error-- [ 84.386340] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction Error-- [ 84.386520] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction Error-- [ 84.386892] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction Error-- [ 84.387044] dwc2 101c.usb: --Host Channel 7 Interrupt: Transaction Error-- [ 84.390633] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction Error-- [ 84.391048] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction Error-- [ 84.395104] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction Error-- [ 84.395280] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction Error-- [ 84.395440] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction Error-- [ 84.399121] dwc2 101c.usb: --Host Channel 11 Interrupt: Transaction Error-- [ 84.399737] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction Error-- [ 84.399898] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction Error-- [ 84.400117] dwc2 101c.usb: --Host Channel 8 Interrupt: Transaction Error-- [ 84.400231] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction Error-- [ 84.400408] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction Error-- [ 84.403278] dwc2 101c.usb: --Host Channel 4 Interrupt: Transaction Error-- [ 84.408280] dwc2 101c.usb: --Host Channel 11 Interrupt: Transaction Error-- [ 84.412077] dwc2 101c.usb: --Host Channel 5 Interrupt: Transaction Error-- [ 84.416266] dwc2 101c.usb: --Host Channel 5 Interrupt: Transac
[PATCH 4/4] usb: roles: intel_xhci: Always allow user control
Trying to determine the USB port type with this mux is very
difficult. To simplify the situation, always allowing user
control, even if the port is USB Type-C port.
Signed-off-by: Heikki Krogerus
---
drivers/usb/roles/intel-xhci-usb-role-switch.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c
b/drivers/usb/roles/intel-xhci-usb-role-switch.c
index 28102127b9d5..6482eee6fd45 100644
--- a/drivers/usb/roles/intel-xhci-usb-role-switch.c
+++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c
@@ -43,15 +43,6 @@ struct intel_xhci_acpi_match {
int hrv;
};
-/*
- * ACPI IDs for PMICs which do not support separate data and power role
- * detection (USB ACA detection for micro USB OTG), we allow userspace to
- * change the role manually on these.
- */
-static const struct intel_xhci_acpi_match allow_userspace_ctrl_ids[] = {
- { "INT33F4", 3 }, /* X-Powers AXP288 PMIC */
-};
-
static int intel_xhci_usb_set_role(struct device *dev, enum usb_role role)
{
struct intel_xhci_usb_data *data = dev_get_drvdata(dev);
@@ -137,7 +128,6 @@ static int intel_xhci_usb_probe(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
struct intel_xhci_usb_data *data;
struct resource *res;
- int i;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -150,10 +140,7 @@ static int intel_xhci_usb_probe(struct platform_device
*pdev)
if (!data->base)
return -ENOMEM;
- for (i = 0; i < ARRAY_SIZE(allow_userspace_ctrl_ids); i++)
- if (acpi_dev_present(allow_userspace_ctrl_ids[i].hid, "1",
-allow_userspace_ctrl_ids[i].hrv))
- sw_desc.allow_userspace_control = true;
+ sw_desc.allow_userspace_control = true;
platform_set_drvdata(pdev, data);
--
2.17.0
--
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 3/4] usb: typec: fusb302: Fix debugfs issue
Removing the "fusb302" debugfs directory when unloading
the driver. That allows the driver to be loaded more then
ones.
This fixes an issue where the driver, if unloaded, can't be
re-loaded, as the "fusb302" debugfs directory already
exists. While here, removing useless condition when creating
the debugfs directory.
Fixes: 76f0c53d08b9 ("usb: typec: fusb302: Move out of staging")
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/fusb302/fusb302.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index eba6bb890b17..0e5d0aa052f5 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -218,11 +218,9 @@ static struct dentry *rootdir;
static int fusb302_debugfs_init(struct fusb302_chip *chip)
{
mutex_init(&chip->logbuffer_lock);
- if (!rootdir) {
- rootdir = debugfs_create_dir("fusb302", NULL);
- if (!rootdir)
- return -ENOMEM;
- }
+ rootdir = debugfs_create_dir("fusb302", NULL);
+ if (!rootdir)
+ return -ENOMEM;
chip->dentry = debugfs_create_file(dev_name(chip->dev),
S_IFREG | 0444, rootdir,
@@ -234,6 +232,7 @@ static int fusb302_debugfs_init(struct fusb302_chip *chip)
static void fusb302_debugfs_exit(struct fusb302_chip *chip)
{
debugfs_remove(chip->dentry);
+ debugfs_remove(rootdir);
}
#else
--
2.17.0
--
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/4] platform: x86: intel_cht_int33fe: Fix dependencies
The driver will not probe unless bq24190 is loaded, so making it a dependency. Signed-off-by: Heikki Krogerus Cc: Wolfram Sang Cc: Darren Hart Cc: Andy Shevchenko --- drivers/i2c/busses/Kconfig | 3 +-- drivers/platform/x86/Kconfig | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 8d21b9825d71..fce9f2ca0570 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -202,8 +202,7 @@ config I2C_CHT_WC Note this controller is hooked up to a TI bq24292i charger-IC, combined with a FUSB302 Type-C port-controller as such it is advised - to also select CONFIG_CHARGER_BQ24190=m and CONFIG_TYPEC_FUSB302=m - (the fusb302 driver currently is in drivers/staging). + to also select CONFIG_TYPEC_FUSB302=m. config I2C_NFORCE2 tristate "Nvidia nForce2, nForce3 and nForce4" diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 39d06dd1f63a..1dbd9d547e60 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -866,6 +866,7 @@ config ACPI_CMPC config INTEL_CHT_INT33FE tristate "Intel Cherry Trail ACPI INT33FE Driver" depends on X86 && ACPI && I2C && REGULATOR + depends on CHARGER_BQ24190 ---help--- This driver add support for the INT33FE ACPI device found on some Intel Cherry Trail devices. @@ -877,8 +878,7 @@ config INTEL_CHT_INT33FE i2c drivers for these chips can bind to the them. If you enable this driver it is advised to also select - CONFIG_TYPEC_FUSB302=m, CONFIG_CHARGER_BQ24190=m and - CONFIG_BATTERY_MAX17042=m. + CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m. config INTEL_INT0002_VGPIO tristate "Intel ACPI INT0002 Virtual GPIO driver" -- 2.17.0 -- 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 2/4] usb: typec: tcpm: Release the role mux when exiting
The ref count for the USB role switch device must be
released after we are done using the switch.
Fixes: c6962c29729c ("usb: typec: tcpm: Set USB role switch to device mode when
configured as such")
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/tcpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 1ee259bc14a5..66dc0773b9bf 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -4652,6 +4652,7 @@ void tcpm_unregister_port(struct tcpm_port *port)
for (i = 0; i < ARRAY_SIZE(port->port_altmode); i++)
typec_unregister_altmode(port->port_altmode[i]);
typec_unregister_port(port->typec_port);
+ usb_role_switch_put(port->role_sw);
tcpm_debugfs_exit(port);
destroy_workqueue(port->wq);
}
--
2.17.0
--
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 0/4] usb: typec: fixes for Cherry Trails
Hi, I now have a GPD Win device - Intel Cherry Trail based board with FUSB302 USB Type-C PHY - that I started using for testing my alternate mode patches. I noticed a few dependency issues, and some other problems with the fusb302 driver. These were the most obvious ones. Hans, I included the patch for the xhci usb role mux to this series. On top of these, the driver for INT34D3 (the PMIC) needs CHT GPIO driver in order for it to work at least on GPD Win. If that is the case with all CHT based platforms, we probable should make the driver depend on the CHT GPIO, but I don't know if it is? With CHT, the driver for fusb302 also depends in practice on the extcon_intel_cht_wc extcon device. It would probable be possible to check it in Kconfig, but I'm not proposing anything for that here either. I wonder if that thing needs to be an extcon device at all? Heikki Krogerus (4): platform: x86: intel_cht_int33fe: Fix dependencies usb: typec: tcpm: Release the role mux when exiting usb: typec: fusb302: Fix debugfs issue usb: roles: intel_xhci: Always allow user control drivers/i2c/busses/Kconfig | 3 +-- drivers/platform/x86/Kconfig | 4 ++-- drivers/usb/roles/intel-xhci-usb-role-switch.c | 15 +-- drivers/usb/typec/fusb302/fusb302.c| 9 - drivers/usb/typec/tcpm.c | 1 + 5 files changed, 9 insertions(+), 23 deletions(-) -- 2.17.0 -- 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 v2 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)
This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0 hardware module for authenticating IoT devices and gateways. The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This driver configures the bridge, registers the bridge as an SPI controller, and adds the TPM 2.0 as an SPI device. The in-kernel TPM 2.0 driver is then automatically loaded to configure the TPM and expose it to userspace. Changes since v1: * Remove empty spi cleanup function * Fix __beXX/__eXX mismatches * Correct typos in comments * Add break to last case of switch * Check result of kzalloc David R. Bild (2): usb: misc: xapea00x: add driver for Xaptum ENF Access Card usb: misc: xapea00x: perform platform initialization of TPM MAINTAINERS | 6 + drivers/usb/misc/Kconfig| 2 + drivers/usb/misc/Makefile | 1 + drivers/usb/misc/xapea00x/Kconfig | 16 + drivers/usb/misc/xapea00x/Makefile | 8 + drivers/usb/misc/xapea00x/xapea00x-bridge.c | 400 drivers/usb/misc/xapea00x/xapea00x-core.c | 451 + drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++ drivers/usb/misc/xapea00x/xapea00x-tpm.c| 954 drivers/usb/misc/xapea00x/xapea00x.h| 75 +++ 10 files changed, 2122 insertions(+) create mode 100644 drivers/usb/misc/xapea00x/Kconfig create mode 100644 drivers/usb/misc/xapea00x/Makefile create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h -- 2.16.2 -- 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 v2 2/2] usb: misc: xapea00x: perform platform initialization of TPM
Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
for performing initialization of the TPM. For these modules, the host
kernel is the platform, so we perform the initialization in the driver
before registering the TPM with the kernel TPM subsystem.
The initialization consists of issuing the TPM startup command,
running the TPM self-test, and setting the TPM platform hierarchy
authorization to a random, unsaved value so that it can never be used
after the driver has loaded.
Signed-off-by: David R. Bild
---
drivers/usb/misc/xapea00x/Makefile| 3 +-
drivers/usb/misc/xapea00x/xapea00x-core.c | 25 +
drivers/usb/misc/xapea00x/xapea00x-tpm.c | 954 ++
3 files changed, 981 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c
diff --git a/drivers/usb/misc/xapea00x/Makefile
b/drivers/usb/misc/xapea00x/Makefile
index c4bcd7524c31..aa3f8803cdf5 100644
--- a/drivers/usb/misc/xapea00x/Makefile
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -4,4 +4,5 @@
#
obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
-xapea00x-y += xapea00x-core.o xapea00x-bridge.o
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o xapea00x-tpm.o
+
diff --git a/drivers/usb/misc/xapea00x/xapea00x-core.c
b/drivers/usb/misc/xapea00x/xapea00x-core.c
index 68caf3bf9be6..a1be7796295d 100644
--- a/drivers/usb/misc/xapea00x/xapea00x-core.c
+++ b/drivers/usb/misc/xapea00x/xapea00x-core.c
@@ -285,6 +285,31 @@ static void xapea00x_tpm_probe(struct work_struct *work)
struct spi_device *tpm;
int retval;
+ mutex_lock(&dev->usb_mutex);
+ if (!dev->interface) {
+ retval = -ENODEV;
+ goto out;
+ }
+ /*
+* This driver is the "platform" in TPM terminology. Before
+* passing control of the TPM to the Linux TPM subsystem, do
+* the TPM initialization normally done by the platform code
+* (e.g., BIOS).
+*/
+ retval = xapea00x_tpm_platform_initialize(dev);
+ if (retval) {
+ dev_err(&dev->interface->dev,
+ "unable to do TPM platform initialization: %d\n",
+ retval);
+ goto err;
+ }
+
+ /*
+* Now register the TPM with the Linux TPM subsystem. This
+* may call through to xapea00x_spi_transfer_one_message(), so
+* don't hold usb_mutex here.
+*/
+ mutex_unlock(&dev->usb_mutex);
tpm = spi_new_device(spi_master, &tpm_board_info);
mutex_lock(&dev->usb_mutex);
if (!dev->interface) {
diff --git a/drivers/usb/misc/xapea00x/xapea00x-tpm.c
b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
new file mode 100644
index ..d0e5c5b6d75d
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
@@ -0,0 +1,954 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ * TPM 2.0-based hardware module for authenticating IoT devices and
+ * gateways.
+ *
+ * Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define TPM_RETRY 50
+#define TPM_TIMEOUT 5// msecs
+#define TPM_TIMEOUT_RANGE_US 300 // usecs
+
+#define TIS_SHORT_TIMEOUT 750 // msecs
+#define TIS_LONG_TIMEOUT 2000 // msecs
+
+#define TIS_MAX_BUF 1024 // byte
+#define TIS_HEADER_LEN10 // byte
+
+#define TPM2_TIMEOUT_A750 // msecs
+#define TPM2_TIMEOUT_B2000 // msecs
+#define TPM2_TIMEOUT_C200 // msecs
+#define TPM2_TIMEOUT_D30 // msecs
+
+#define TPM_ACCESS_0 0x
+#define TPM_STS_0 0x0018
+#define TPM_DATA_FIFO_0 0x0024
+
+#define TPM2_ST_NO_SESSIONS 0x8001
+#define TPM2_ST_SESSIONS 0x8002
+
+#define TPM2_CC_STARTUP 0x0144
+#define TPM2_CC_SHUTDOWN 0x0145
+#define TPM2_CC_SELF_TEST 0x0143
+#define TPM2_CC_GET_RANDOM0x017B
+#define TPM2_CC_HIERARCHY_CHANGE_AUTH 0x0129
+#define TPM2_CC_DICT_ATTACK_LOCK_RST 0x0139
+
+#define TPM_RC_SUCCESS0x000
+#define TPM_RC_INITIALIZE 0x100
+
+enum tis_access {
+ TPM_ACCESS_VALID = 0x80,
+ TPM_ACCESS_ACTIVE_LOCALITY = 0x20,
+ TPM_ACCESS_REQUEST_PENDING = 0x04,
+ TPM_ACCESS_REQUEST_USE = 0x02
+};
+
+enum tis_status {
+ TPM_STS_VALID = 0x80,
+ TPM_STS_COMMAND_READY = 0x40,
+ TPM_STS_GO = 0x20,
+ TPM_STS_DATA_AVAIL = 0x10,
+ TPM_STS_DATA_EXPECT= 0x08,
+ TPM_STS_SELF_TEST_DONE = 0x04,
+ TPM_STS_RESPONSE_RETRY = 0x02
+};
+
+struct tpm_tis_command {
+ __be16 tag;
+ __be32 size;
+ __be32 code;
+ u8 body[0];
+} __attribute__((__packed__));
+
+/*
[PATCH v2 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card
This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.
The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device. The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.
Signed-off-by: David R. Bild
---
MAINTAINERS | 6 +
drivers/usb/misc/Kconfig| 2 +
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/xapea00x/Kconfig | 16 ++
drivers/usb/misc/xapea00x/Makefile | 7 +
drivers/usb/misc/xapea00x/xapea00x-bridge.c | 400 ++
drivers/usb/misc/xapea00x/xapea00x-core.c | 426
drivers/usb/misc/xapea00x/xapea00x-spi.c| 209 ++
drivers/usb/misc/xapea00x/xapea00x.h| 75 +
9 files changed, 1142 insertions(+)
create mode 100644 drivers/usb/misc/xapea00x/Kconfig
create mode 100644 drivers/usb/misc/xapea00x/Makefile
create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 79bb02ff812f..c0e34a3ef5aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14795,6 +14795,12 @@ L: linux-wirel...@vger.kernel.org
S: Maintained
F: drivers/net/wireless/rndis_wlan.c
+USB XAPEA00X DRIVER
+M: David R. Bild
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/xapea00x/
+
USB XHCI DRIVER
M: Mathias Nyman
L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 68d2f2cd17dd..747d7f03fb84 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,3 +275,5 @@ config USB_CHAOSKEY
To compile this driver as a module, choose M here: the
module will be called chaoskey.
+
+source "drivers/usb/misc/xapea00x/Kconfig"
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 109f54f5b9aa..f3583501547c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x/
obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
diff --git a/drivers/usb/misc/xapea00x/Kconfig
b/drivers/usb/misc/xapea00x/Kconfig
new file mode 100644
index ..56c11f6ee7b3
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Kconfig
@@ -0,0 +1,16 @@
+config USB_XAPEA00X
+tristate "Xaptum ENF Access card support (XAP-EA-00x)"
+depends on USB_SUPPORT
+select SPI
+select TCG_TPM
+select TCG_TIS_SPI
+help
+ Say Y here if you want to support the Xaptum ENF Access
+ modules (XAP-EA-00x) in the USB or Mini PCI-e form
+ factors. The XAP-EA-00x module exposes a TPM 2.0 as
+ /dev/tpmX to use for authenticating with the Xaptum ENF.
+
+ To compile this driver as a module, choose M here. The
+ module will be called xapea00x.
+
+ If unsure, say M.
diff --git a/drivers/usb/misc/xapea00x/Makefile
b/drivers/usb/misc/xapea00x/Makefile
new file mode 100644
index ..c4bcd7524c31
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the xapea00x driver.
+#
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
+
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o
diff --git a/drivers/usb/misc/xapea00x/xapea00x-bridge.c
b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
new file mode 100644
index ..6d78e83d96f6
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
@@ -0,0 +1,400 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ * TPM 2.0-based hardware module for authenticating IoT devices and
+ * gateways.
+ *
+ * Copyright (c) 2017 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define XAPEA00X_BR_CMD_READ 0x00
+#define XAPEA00X_BR_CMD_WRITE0x01
+#define XAPEA00X_BR_CMD_WRITEREAD0x02
+
+#define XAPEA00X_BR_BREQTYP_SET 0x40
+
+#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES 0x21
+#define XAPEA00X_BR_BREQ_SET_GPIO_CS 0x25
+#define XAPEA00X_BR_BREQ_SET_SPI_WORD0x31
+
+#define XAPEA00X_BR_USB_TIMEOUT 1000 // msecs
+
+#define XAPEA00X_BR_CS_DISABLED 0x00
+
+/***
+ * Bridge USB transfers
+ */
+
+struct xapea00x_br_bulk_command {
+ _
Re: [PATCH 3/4] usb: typec: fusb302: Fix debugfs issue
On 04/30/2018 05:41 AM, Heikki Krogerus wrote:
Removing the "fusb302" debugfs directory when unloading
the driver. That allows the driver to be loaded more then
ones.
This fixes an issue where the driver, if unloaded, can't be
re-loaded, as the "fusb302" debugfs directory already
exists. While here, removing useless condition when creating
the debugfs directory.
Fixes: 76f0c53d08b9 ("usb: typec: fusb302: Move out of staging")
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/fusb302/fusb302.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index eba6bb890b17..0e5d0aa052f5 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -218,11 +218,9 @@ static struct dentry *rootdir;
static int fusb302_debugfs_init(struct fusb302_chip *chip)
{
mutex_init(&chip->logbuffer_lock);
- if (!rootdir) {
- rootdir = debugfs_create_dir("fusb302", NULL);
- if (!rootdir)
- return -ENOMEM;
- }
I think the idea here was to permit more than one instance of the driver,
and have all debugfs file entries under the fusb302 directory. Loading the
second instance will fail after this patch is applied.
+ rootdir = debugfs_create_dir("fusb302", NULL);
+ if (!rootdir)
+ return -ENOMEM;
chip->dentry = debugfs_create_file(dev_name(chip->dev),
S_IFREG | 0444, rootdir,
@@ -234,6 +232,7 @@ static int fusb302_debugfs_init(struct fusb302_chip *chip)
static void fusb302_debugfs_exit(struct fusb302_chip *chip)
{
debugfs_remove(chip->dentry);
+ debugfs_remove(rootdir); > }
#else
--
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 2/4] usb: typec: tcpm: Release the role mux when exiting
On 04/30/2018 05:41 AM, Heikki Krogerus wrote:
The ref count for the USB role switch device must be
released after we are done using the switch.
Fixes: c6962c29729c ("usb: typec: tcpm: Set USB role switch to device mode when
configured as such")
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/tcpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 1ee259bc14a5..66dc0773b9bf 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -4652,6 +4652,7 @@ void tcpm_unregister_port(struct tcpm_port *port)
for (i = 0; i < ARRAY_SIZE(port->port_altmode); i++)
typec_unregister_altmode(port->port_altmode[i]);
typec_unregister_port(port->typec_port);
+ usb_role_switch_put(port->role_sw);
tcpm_debugfs_exit(port);
destroy_workqueue(port->wq);
}
--
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] typec: tcpm: Fix incorrect 'and' operator
Currently, logical and is being used instead of *bitwise* and.
Fix this by using a proper bitwise and operator.
Addresses-Coverity-ID: 1468455 ("Logical vs. bitwise operator")
Fixes: 64f7c494a3c0 ("typec: tcpm: Add support for sink PPS related
messages")
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/typec/tcpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 1ee259b..7ee417a 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1772,7 +1772,7 @@ static void tcpm_pd_ext_msg_request(struct tcpm_port
*port,
enum pd_ext_msg_type type = pd_header_type_le(msg->header);
unsigned int data_size =
pd_ext_header_data_size_le(msg->ext_msg.header);
- if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+ if (!(msg->ext_msg.header & PD_EXT_HDR_CHUNKED)) {
tcpm_log(port, "Unchunked extended messages unsupported");
return;
}
--
2.7.4
--
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] typec: tcpm: Fix incorrect 'and' operator
On 30 April 2018 14:23, Gustavo A. R. Silva wrote:
> Currently, logical and is being used instead of *bitwise* and.
>
> Fix this by using a proper bitwise and operator.
>
> Addresses-Coverity-ID: 1468455 ("Logical vs. bitwise operator")
> Fixes: 64f7c494a3c0 ("typec: tcpm: Add support for sink PPS related
> messages")
> Signed-off-by: Gustavo A. R. Silva
> ---
Good spot. :(
Acked-by: Adam Thomson
> drivers/usb/typec/tcpm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 1ee259b..7ee417a 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -1772,7 +1772,7 @@ static void tcpm_pd_ext_msg_request(struct tcpm_port
> *port,
> enum pd_ext_msg_type type = pd_header_type_le(msg->header);
> unsigned int data_size = pd_ext_header_data_size_le(msg-
> >ext_msg.header);
>
> - if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
> + if (!(msg->ext_msg.header & PD_EXT_HDR_CHUNKED)) {
> tcpm_log(port, "Unchunked extended messages unsupported");
> return;
> }
> --
> 2.7.4
--
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: USB mouse and PS2 Keyboard freeze all of a sudden in Ubuntu Mate 16.04.4
On Mon, Apr 30, 2018 at 03:49:19PM +0300, Kyprianos Papadimitriou wrote: > Dear Greg, > > I am still monitoring the behavior. Please let me come back to you when I am > sure about that. > > Where should I send the "patch"? As I told you it is not a 100% fix! If you run the tool, scripts/get_maintainer.pl on your patch, it will tell you who to send it to, including the needed mailing lists. thanks, greg k-h -- 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 01/20] usb: host: xhci: rename queue_bulk_tx() to queue_bulk_intr_tx()
Hi, Felipe Balbi writes: > That function is used for both Bulk and Interrupt transfer types, > let's make it clear on the function name and provide one extra helper > for queueing bulk transfers. > > Signed-off-by: Felipe Balbi gentle reminder about this series. -- balbi -- 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: smsc95xx: aligment issues
Hi Stefan,
Thanks for report. We will try to repro issue and contact you if need more
details.
Regards,
Woojung
> -Original Message-
> From: Stefan Wahren [mailto:stefan.wah...@i2se.com]
> Sent: Saturday, April 28, 2018 3:59 AM
> To: Nisar Sayed - I17970 ; Woojung Huh - C21699
>
> Cc: David S. Miller ; linux-usb
> ; netdev
> ; popcorn mix ; James Hughes
>
> Subject: net: smsc95xx: aligment issues
>
> Hi,
> after connecting a Raspberry Pi 1 B to my local network i'm seeing aligment
> issues under
> /proc/cpu/alignment:
>
> User: 0
> System: 142 (_decode_session4+0x12c/0x3c8)
> Skipped: 0
> Half: 0
> Word: 0
> DWord:127
> Multi:15
> User faults: 2 (fixup)
>
> I've also seen outputs with _csum_ipv6_magic.
>
> Kernel config: bcm2835_defconfig
> Reproducible kernel trees: current linux-next, 4.17-rc2 and 4.14.37 (i didn't
> test older versions)
>
> Please tell if you need more information to narrow down this issue.
>
> Best regards
> Stefan
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [GIT PULL] USB fixes for v4.17-rc3
On Fri, Apr 27, 2018 at 11:09:50AM +0300, Felipe Balbi wrote: > > Hi Greg, > > here's a tiny, 7 fixes only, pull request for the current -rc cycle. Let > me know if you want anything to be changed. > > cheers > > The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: > > Linux 4.17-rc2 (2018-04-22 19:20:09 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/fixes-for-v4.17-rc3 > > for you to fetch changes up to ed769520727edbf526e0f510e6c501fc6ba3824a: > > usb: gadget: composite Allow for larger configuration descriptors > (2018-04-27 10:17:10 +0300) Sorry these missed my last pull request to Linus. I've taken them now and will send them off to him with my next round in a week or so. thanks, greg k-h -- 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 v2 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card
On Mon, Apr 30, 2018 at 07:54:17AM -0500, David R. Bild wrote:
> This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
> hardware module for authenticating IoT devices and gateways.
>
> The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
> driver configures the bridge, registers the bridge as an SPI
> controller, and adds the TPM 2.0 as an SPI device. The in-kernel TPM
> 2.0 driver is then automatically loaded to configure the TPM and
> expose it to userspace.
A few random USB driver-like review comments of minor things to tweak
for your next submission. Overall it looks good to me, but you should
also get the TPM maintainers/developers to review it as I will require
their review before I can take it in the USB tree.
> --- /dev/null
> +++ b/drivers/usb/misc/xapea00x/Kconfig
> @@ -0,0 +1,16 @@
> +config USB_XAPEA00X
> +tristate "Xaptum ENF Access card support (XAP-EA-00x)"
> +depends on USB_SUPPORT
> +select SPI
> +select TCG_TPM
> +select TCG_TIS_SPI
Do you really want to 'select' these? Why not just depend on them?
> --- /dev/null
> +++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
> @@ -0,0 +1,400 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
> + * TPM 2.0-based hardware module for authenticating IoT devices and
> + * gateways.
> + *
> + * Copyright (c) 2017 Xaptum, Inc.
It's 2018 now :)
> + */
> +
> +#include "xapea00x.h"
> +
> +#define XAPEA00X_BR_CMD_READ 0x00
> +#define XAPEA00X_BR_CMD_WRITE 0x01
> +#define XAPEA00X_BR_CMD_WRITEREAD 0x02
> +
> +#define XAPEA00X_BR_BREQTYP_SET0x40
> +
> +#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES 0x21
> +#define XAPEA00X_BR_BREQ_SET_GPIO_CS 0x25
> +#define XAPEA00X_BR_BREQ_SET_SPI_WORD 0x31
> +
> +#define XAPEA00X_BR_USB_TIMEOUT1000 // msecs
> +
> +#define XAPEA00X_BR_CS_DISABLED0x00
Odd placement of spaces after the tabs, why?
> +
> +/***
> + * Bridge USB transfers
> + */
> +
> +struct xapea00x_br_bulk_command {
> + __u16 reserved1;
> + __u8 command;
> + __u8 reserved2;
> + __le32 length;
> +} __attribute__((__packed__));
> +
> +/**
> + * xapea00x_br_prep_bulk_command - Prepares the bulk command header with
> + * the supplied values.
> + * @hdr: pointer to header to prepare
> + * @command: the command id for the command
> + * @length: length in bytes of the command data
> + *
> + * Context: !in_interrupt()
> + *
> + * Return: If successful, 0. Otherwise a negative error number.
> + */
You don't need kerneldoc comments for static functions. Nice, but not a
requirement at all.
> +static int xapea00x_br_bulk_read(struct xapea00x_device *dev, void *data,
> + int len)
> +{
> + unsigned int pipe;
> + void *buf;
> + int actual_len, retval;
> +
> + buf = kzalloc(len, GFP_KERNEL);
> + if (!buf) {
> + retval = -ENOMEM;
> + goto out;
> + }
> +
> + pipe = usb_rcvbulkpipe(dev->udev, dev->bulk_in->bEndpointAddress);
> + retval = usb_bulk_msg(dev->udev, pipe, buf, len, &actual_len,
> + XAPEA00X_BR_USB_TIMEOUT);
> +
> + if (retval) {
> + dev_warn(&dev->interface->dev,
> + "%s: usb_bulk_msg() failed with %d\n",
> + __func__, retval);
> + goto free_buf;
> + }
Is this going to get noisy when the device gets removed from the system?
> +
> + memcpy(data, buf, actual_len);
> + retval = 0;
> +
> +free_buf:
> + kzfree(buf);
> +
> +out:
> + return retval;
> +}
> +
> +/**
> + * xapea00x_br_ctrl_write - Issues a send control transfer to the bridge
> + * chip.
> + * @dev: pointer to the device to write to
> + * @bRequest: the command
> + * @wValue: the command value
> + * @wIndex: the command index
> + * @data: pointer to the command data
> + * @len: length in bytes of the command data
> + *
> + * The possible bRequest, wValue, and wIndex values and data format
> + * are specified in the hardware datasheet.
> + *
> + * Context: !in_interrupt()
> + *
> + * Return: If successful, 0. Otherwise a negative error code.
> + */
> +static int xapea00x_br_ctrl_write(struct xapea00x_device *dev, u8 bRequest,
> + u16 wValue, u16 wIndex, u8 *data, u16 len)
> +{
> + unsigned int pipe;
> + void *buf;
> + int retval;
> +
> + /* control_msg buffer must be dma-capable (e.g.k kmalloc-ed,
> + * not stack). Copy data into such buffer here, so we can use
> + * simpler stack allocation in the callers - we have no
> + * performance concerns given the small buffers and low
> + * throughputs of this device.
> + */
This is well known and a requirement for all USB drivers, no need to
have to document it h
[PATCH 0/2] musb fixes for v4.17-rc4
Hi Greg, Here are musb fixes for v4.17-rc4 to fix two NULL pointer dereference cases. Please let me know if any change is needed. Regards, -Bin. Bin Liu (2): usb: musb: host: fix potential NULL pointer dereference usb: musb: trace: fix NULL pointer dereference in musb_g_tx() drivers/usb/musb/musb_gadget.c | 3 ++- drivers/usb/musb/musb_host.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) -- 1.9.1 -- 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 2/2] usb: musb: trace: fix NULL pointer dereference in musb_g_tx()
The usb_request pointer could be NULL in musb_g_tx(), where the
tracepoint call would trigger the NULL pointer dereference failure when
parsing the members of the usb_request pointer.
Move the tracepoint call to where the usb_request pointer is already
checked to solve the issue.
Fixes: fc78003e5345a("usb: musb: gadget: add usb-request tracepoints")
Cc: sta...@vger.kernel.org # v4.8+
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_gadget.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index e564695c6c8d..71c5835ea9cd 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -417,7 +417,6 @@ void musb_g_tx(struct musb *musb, u8 epnum)
req = next_request(musb_ep);
request = &req->request;
- trace_musb_req_tx(req);
csr = musb_readw(epio, MUSB_TXCSR);
musb_dbg(musb, "<== %s, txcsr %04x", musb_ep->end_point.name, csr);
@@ -456,6 +455,8 @@ void musb_g_tx(struct musb *musb, u8 epnum)
u8 is_dma = 0;
boolshort_packet = false;
+ trace_musb_req_tx(req);
+
if (dma && (csr & MUSB_TXCSR_DMAENAB)) {
is_dma = 1;
csr |= MUSB_TXCSR_P_WZC_BITS;
--
1.9.1
--
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/2] usb: musb: host: fix potential NULL pointer dereference
musb_start_urb() doesn't check the pass-in parameter if it is NULL. But
in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is
returned from first_qh(), which could be NULL.
So wrap the musb_start_urb() call here with a if condition check to
avoid the potential NULL pointer dereference.
Fixes: f283862f3b5cb("usb: musb: NAK timeout scheme on bulk TX endpoint")
Cc: sta...@vger.kernel.org # v3.7+
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_host.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 4fa372c845e1..e7f99d55922a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -990,7 +990,9 @@ static void musb_bulk_nak_timeout(struct musb *musb, struct
musb_hw_ep *ep,
/* set tx_reinit and schedule the next qh */
ep->tx_reinit = 1;
}
- musb_start_urb(musb, is_in, next_qh);
+
+ if (next_qh)
+ musb_start_urb(musb, is_in, next_qh);
}
}
--
1.9.1
--
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 1/2] usb: musb: host: fix potential NULL pointer dereference
On Mon, Apr 30, 2018 at 11:20:53AM -0500, Bin Liu wrote:
> musb_start_urb() doesn't check the pass-in parameter if it is NULL. But
> in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is
> returned from first_qh(), which could be NULL.
>
> So wrap the musb_start_urb() call here with a if condition check to
> avoid the potential NULL pointer dereference.
>
> Fixes: f283862f3b5cb("usb: musb: NAK timeout scheme on bulk TX endpoint")
Nit, you forgot a ' ', this should be:
f283862f3b5c ("usb: musb: NAK timeout scheme on bulk TX endpoint")
You also had one extra id value in there, odd. I'll edit this by
hand...
greg k-h
--
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 1/2] usb: musb: host: fix potential NULL pointer dereference
On Mon, Apr 30, 2018 at 09:42:15AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 30, 2018 at 11:20:53AM -0500, Bin Liu wrote:
> > musb_start_urb() doesn't check the pass-in parameter if it is NULL. But
> > in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is
> > returned from first_qh(), which could be NULL.
> >
> > So wrap the musb_start_urb() call here with a if condition check to
> > avoid the potential NULL pointer dereference.
> >
> > Fixes: f283862f3b5cb("usb: musb: NAK timeout scheme on bulk TX endpoint")
>
> Nit, you forgot a ' ', this should be:
> f283862f3b5c ("usb: musb: NAK timeout scheme on bulk TX endpoint")
Sorry, thanks.
> You also had one extra id value in there, odd. I'll edit this by
Not sure why 'git blame' gives that one extra on my computer. I will see
if I will figure it out...
> hand...
Thanks,
-Bin.
--
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 1/2] usb: musb: host: fix potential NULL pointer dereference
On Mon, Apr 30, 2018 at 01:11:34PM -0500, Bin Liu wrote:
> On Mon, Apr 30, 2018 at 09:42:15AM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Apr 30, 2018 at 11:20:53AM -0500, Bin Liu wrote:
> > > musb_start_urb() doesn't check the pass-in parameter if it is NULL. But
> > > in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is
> > > returned from first_qh(), which could be NULL.
> > >
> > > So wrap the musb_start_urb() call here with a if condition check to
> > > avoid the potential NULL pointer dereference.
> > >
> > > Fixes: f283862f3b5cb("usb: musb: NAK timeout scheme on bulk TX endpoint")
> >
> > Nit, you forgot a ' ', this should be:
> > f283862f3b5c ("usb: musb: NAK timeout scheme on bulk TX endpoint")
>
> Sorry, thanks.
>
> > You also had one extra id value in there, odd. I'll edit this by
>
> Not sure why 'git blame' gives that one extra on my computer. I will see
> if I will figure it out...
Why use 'git blame'? I use:
git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h (\"%s\")%n"
to generate these types of lines.
thanks,
greg k-h
--
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 1/2] usb: musb: host: fix potential NULL pointer dereference
On Mon, Apr 30, 2018 at 11:24:48AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 30, 2018 at 01:11:34PM -0500, Bin Liu wrote:
> > On Mon, Apr 30, 2018 at 09:42:15AM -0700, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 30, 2018 at 11:20:53AM -0500, Bin Liu wrote:
> > > > musb_start_urb() doesn't check the pass-in parameter if it is NULL. But
> > > > in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is
> > > > returned from first_qh(), which could be NULL.
> > > >
> > > > So wrap the musb_start_urb() call here with a if condition check to
> > > > avoid the potential NULL pointer dereference.
> > > >
> > > > Fixes: f283862f3b5cb("usb: musb: NAK timeout scheme on bulk TX
> > > > endpoint")
> > >
> > > Nit, you forgot a ' ', this should be:
> > > f283862f3b5c ("usb: musb: NAK timeout scheme on bulk TX endpoint")
> >
> > Sorry, thanks.
> >
> > > You also had one extra id value in there, odd. I'll edit this by
> >
> > Not sure why 'git blame' gives that one extra on my computer. I will see
> > if I will figure it out...
>
> Why use 'git blame'? I use:
> git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h (\"%s\")%n"
>
> to generate these types of lines.
My ~/.gitconfig already has
abbrev = 12
but I used 'git blame' to find the commit id which introduces the bug,
then just directly copied the commit id from there... only until now
know 'git blame' gives 13 chars...
I will create a shortcut for the command you gave above to avoid this 13
chars problem from now on.
Thanks,
-Bin.
--
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] usb: musb: Support gadget mode when the port is set to dual role
Hi, Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit : > Okay, this came down to an argument that whether we should require > loading a gadget driver on a dual-role port to work in host mode, > which is currently required on musb since a long long time ago. > > I understand the requirement is kinda unnecessary, but since it > already > exists on musb stack for a long time, I don't plan to change it. > Because I > cannot think of a use case in real products that doesn't automatically > load a gadget function on the dual-role port. > > If you can explain a use case in real world (not a engineering lab) > that the gadget driver will not be loaded at linux booting up, but > later based on user's input, I will reconsider my decision. To remove > this requirement from musb stack, the work is more than this patch. My use case here is to support common GNU/Linux-based distributions, not use-case-specific varieties of GNU/Linux-based rootfs. So my point here would be that most distros will (and probably should) ship g_ether as a module but without any particular reason to autoload it, or any other gadget module in particular, since the system is general-purpose. Then, imagine a user wants to plug a USB device through OTG (say, because it's the only USB port available at all on the tablet they're using), it simply won't work. It won't be obvious to that user that this is because no gadget is loaded, since what they want to do does not involve using gadget mode at any point. Do you think this is a valid use case? It surely is a common one and perfectly depicts my situation. Note that in addition to Allwinner devices, I also have omap3/4/5 devices for testing things. I don't think I have other MUSB-enabled devices in my collection though, but I would be willing to test fixes to this issue on the ones I have. Cheers, -- Paul Kocialkowski, developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part
[REBASED PATCH 1/2] usbip: usbip_host: delete device from busid_table after rebind
Device is left in the busid_table after unbind and rebind. Rebind initiates usb bus scan and the original driver claims the device. After rescan the device should be deleted from the busid_table as it no longer belongs to usbip_host. Fix it to delete the device after device_attach() succeeds. Signed-off-by: Shuah Khan (Samsung OSG) --- drivers/usb/usbip/stub_main.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c index d41d0cdeec0f..fb46bd62d538 100644 --- a/drivers/usb/usbip/stub_main.c +++ b/drivers/usb/usbip/stub_main.c @@ -186,6 +186,9 @@ static ssize_t rebind_store(struct device_driver *dev, const char *buf, if (!bid) return -ENODEV; + /* mark the device for deletion so probe ignores it during rescan */ + bid->status = STUB_BUSID_OTHER; + /* device_attach() callers should hold parent lock for USB */ if (bid->udev->dev.parent) device_lock(bid->udev->dev.parent); @@ -197,6 +200,9 @@ static ssize_t rebind_store(struct device_driver *dev, const char *buf, return ret; } + /* delete device from busid_table */ + del_match_busid((char *) buf); + return count; } -- 2.14.1 -- 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
[REBASED PATCH 2/2] usbip: usbip_host: run rebind from exit when module is removed
After removing usbip_host module, devices it releases are left without
a driver. For example, when a keyboard or a mass storage device are
bound to usbip_host when it is removed, these devices are no longer
bound to any driver.
Fix it to run device_attach() from the module exit routine to restore
the devices to their original drivers. This includes cleanup changes
and moving device_attach() code to a common routine to be called from
rebind_store() and usbip_host_exit().
Signed-off-by: Shuah Khan (Samsung OSG)
---
drivers/usb/usbip/stub_dev.c | 6 +
drivers/usb/usbip/stub_main.c | 60 ---
2 files changed, 52 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index 7813c1862941..9d0425113c4b 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -448,12 +448,8 @@ static void stub_disconnect(struct usb_device *udev)
busid_priv->sdev = NULL;
stub_device_free(sdev);
- if (busid_priv->status == STUB_BUSID_ALLOC) {
+ if (busid_priv->status == STUB_BUSID_ALLOC)
busid_priv->status = STUB_BUSID_ADDED;
- } else {
- busid_priv->status = STUB_BUSID_OTHER;
- del_match_busid((char *)udev_busid);
- }
}
#ifdef CONFIG_PM
diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index fb46bd62d538..587b9bc10042 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -14,6 +14,7 @@
#define DRIVER_DESC "USB/IP Host Driver"
struct kmem_cache *stub_priv_cache;
+
/*
* busid_tables defines matching busids that usbip can grab. A user can change
* dynamically what device is locally used and what device is exported to a
@@ -169,6 +170,51 @@ static ssize_t match_busid_store(struct device_driver
*dev, const char *buf,
}
static DRIVER_ATTR_RW(match_busid);
+static int do_rebind(char *busid, struct bus_id_priv *busid_priv)
+{
+ int ret;
+
+ /* device_attach() callers should hold parent lock for USB */
+ if (busid_priv->udev->dev.parent)
+ device_lock(busid_priv->udev->dev.parent);
+ ret = device_attach(&busid_priv->udev->dev);
+ if (busid_priv->udev->dev.parent)
+ device_unlock(busid_priv->udev->dev.parent);
+ if (ret < 0) {
+ dev_err(&busid_priv->udev->dev, "rebind failed\n");
+ return ret;
+ }
+ return 0;
+}
+
+static void stub_device_rebind(void)
+{
+#if IS_MODULE(CONFIG_USBIP_HOST)
+ struct bus_id_priv *busid_priv;
+ int i;
+
+ /* update status to STUB_BUSID_OTHER so probe ignores the device */
+ spin_lock(&busid_table_lock);
+ for (i = 0; i < MAX_BUSID; i++) {
+ if (busid_table[i].name[0] &&
+ busid_table[i].shutdown_busid) {
+ busid_priv = &(busid_table[i]);
+ busid_priv->status = STUB_BUSID_OTHER;
+ }
+ }
+ spin_unlock(&busid_table_lock);
+
+ /* now run rebind */
+ for (i = 0; i < MAX_BUSID; i++) {
+ if (busid_table[i].name[0] &&
+ busid_table[i].shutdown_busid) {
+ busid_priv = &(busid_table[i]);
+ do_rebind(busid_table[i].name, busid_priv);
+ }
+ }
+#endif
+}
+
static ssize_t rebind_store(struct device_driver *dev, const char *buf,
size_t count)
{
@@ -189,16 +235,9 @@ static ssize_t rebind_store(struct device_driver *dev,
const char *buf,
/* mark the device for deletion so probe ignores it during rescan */
bid->status = STUB_BUSID_OTHER;
- /* device_attach() callers should hold parent lock for USB */
- if (bid->udev->dev.parent)
- device_lock(bid->udev->dev.parent);
- ret = device_attach(&bid->udev->dev);
- if (bid->udev->dev.parent)
- device_unlock(bid->udev->dev.parent);
- if (ret < 0) {
- dev_err(&bid->udev->dev, "rebind failed\n");
+ ret = do_rebind((char *) buf, bid);
+ if (ret < 0)
return ret;
- }
/* delete device from busid_table */
del_match_busid((char *) buf);
@@ -323,6 +362,9 @@ static void __exit usbip_host_exit(void)
*/
usb_deregister_device_driver(&stub_driver);
+ /* initiate scan to attach devices */
+ stub_device_rebind();
+
kmem_cache_destroy(stub_priv_cache);
}
--
2.14.1
--
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: [REBASED PATCH 1/2] usbip: usbip_host: delete device from busid_table after rebind
On Mon, Apr 30, 2018 at 04:17:19PM -0600, Shuah Khan (Samsung OSG) wrote: > Device is left in the busid_table after unbind and rebind. Rebind > initiates usb bus scan and the original driver claims the device. > After rescan the device should be deleted from the busid_table as > it no longer belongs to usbip_host. > > Fix it to delete the device after device_attach() succeeds. > > Signed-off-by: Shuah Khan (Samsung OSG) > --- > drivers/usb/usbip/stub_main.c | 6 ++ > 1 file changed, 6 insertions(+) Why are these REBASED? I can't remember the first version of these patches, what are these for? confused, greg k-h -- 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: [REBASED PATCH 1/2] usbip: usbip_host: delete device from busid_table after rebind
On 04/30/2018 04:48 PM, Greg KH wrote: > On Mon, Apr 30, 2018 at 04:17:19PM -0600, Shuah Khan (Samsung OSG) wrote: >> Device is left in the busid_table after unbind and rebind. Rebind >> initiates usb bus scan and the original driver claims the device. >> After rescan the device should be deleted from the busid_table as >> it no longer belongs to usbip_host. >> >> Fix it to delete the device after device_attach() succeeds. >> >> Signed-off-by: Shuah Khan (Samsung OSG) >> --- >> drivers/usb/usbip/stub_main.c | 6 ++ >> 1 file changed, 6 insertions(+) > > Why are these REBASED? I can't remember the first version of these > patches, what are these for? > > confused, > > greg k-h > > Here is the original patches https://patchwork.kernel.org/patch/10337657/ https://patchwork.kernel.org/patch/10337661/ I sent a 3 patch series and the last two didn't apply to usb-next. You asked me to rebase them. I realized the reason they didn't apply is because these two depend on the fixes that went into 4.17-rc3 and now with usb-next at 4.17-rc3, they apply. I ended up generating patches on usb-next latest and resend the rebased patches. Hope this makes sense. thanks, -- Shuah -- 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
