Re: [PATCH v4 1/3] usb: chipidea: imx: Change switch order
On Mon, Sep 19, 2016 at 01:45:38PM +0200, Fabien Lahoudere wrote:
> Each USB controller have different behaviour, so in order to avoid to have
> several "swicth(data->index)" and lock/unlock, we prefer to get the index
> switch and then test for features if they exist for this index.
> This patch also remove useless test of reg and val. Those two values cannot
> be NULL.
Sorry, I can't see the benefits of this change.
Considering certain controller doesn't have oc feature, with current
code it only needs one comparison (flag disable_oc), but with your
changes, it needs two comparisons.
Peter
>
> Signed-off-by: Fabien Lahoudere
> ---
> drivers/usb/chipidea/usbmisc_imx.c | 38
> --
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/usb/chipidea/usbmisc_imx.c
> b/drivers/usb/chipidea/usbmisc_imx.c
> index 20d02a5..9549821 100644
> --- a/drivers/usb/chipidea/usbmisc_imx.c
> +++ b/drivers/usb/chipidea/usbmisc_imx.c
> @@ -199,31 +199,41 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data
> *data)
> val |= MX53_USB_PLL_DIV_24_MHZ;
> writel(val, usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
>
> - if (data->disable_oc) {
> - spin_lock_irqsave(&usbmisc->lock, flags);
> - switch (data->index) {
> - case 0:
> + spin_lock_irqsave(&usbmisc->lock, flags);
> +
> + switch (data->index) {
> + case 0:
> + if (data->disable_oc) {
> reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
> val = readl(reg) | MX53_BM_OVER_CUR_DIS_OTG;
> - break;
> - case 1:
> + writel(val, reg);
> + }
> + break;
> + case 1:
> + if (data->disable_oc) {
> reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
> val = readl(reg) | MX53_BM_OVER_CUR_DIS_H1;
> - break;
> - case 2:
> + writel(val, reg);
> + }
> + break;
> + case 2:
> + if (data->disable_oc) {
> reg = usbmisc->base + MX53_USB_UH2_CTRL_OFFSET;
> val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
> - break;
> - case 3:
> + writel(val, reg);
> + }
> + break;
> + case 3:
> + if (data->disable_oc) {
> reg = usbmisc->base + MX53_USB_UH3_CTRL_OFFSET;
> val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
> - break;
> - }
> - if (reg && val)
> writel(val, reg);
> - spin_unlock_irqrestore(&usbmisc->lock, flags);
> + }
> + break;
> }
>
> + spin_unlock_irqrestore(&usbmisc->lock, flags);
> +
> return 0;
> }
>
> --
> 2.1.4
>
--
Best Regards,
Peter Chen
--
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/2] usb: chipidea: otg: fix reading otgsc register
On Mon, Sep 19, 2016 at 01:44:36PM +0200, Sascha Hauer wrote:
> When switching from gadget to host the driver waits for VBUS
It should be switching from host to gadget
> to disappear before doing the actual switch. This waiting is
> done by letting hw_wait_reg() poll the OTGSC register. This is
> buggy. hw_wait_reg() directly reads the register, but for
> reading the OTGSC register hw_read_otgsc() must be used since
> this function eventually patches the VBUS status read from extcon
> into the raw register value.
> To fix this inline the hw_wait_reg() code into its only user and
> use the correct function to read the OTGSC register. Since
> hw_wait_reg() is unused now remove it.
>
Stephen Boyd has already posted a similar fix at below:
http://www.spinics.net/lists/linux-usb/msg146304.html
For patch 1, if there is a separate API to wait vbus to be low,
it seems not so necessary.
Peter
> Signed-off-by: Sascha Hauer
> ---
> drivers/usb/chipidea/ci.h | 3 ---
> drivers/usb/chipidea/core.c | 32
> drivers/usb/chipidea/otg.c | 16
> 3 files changed, 12 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index cd41455..05bc4d6 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -428,9 +428,6 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
>
> u8 hw_port_test_get(struct ci_hdrc *ci);
>
> -int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
> - u32 value, unsigned int timeout_ms);
> -
> void ci_platform_configure(struct ci_hdrc *ci);
>
> int dbg_create_files(struct ci_hdrc *ci);
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 69426e6..01390e0 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -516,38 +516,6 @@ int hw_device_reset(struct ci_hdrc *ci)
> return 0;
> }
>
> -/**
> - * hw_wait_reg: wait the register value
> - *
> - * Sometimes, it needs to wait register value before going on.
> - * Eg, when switch to device mode, the vbus value should be lower
> - * than OTGSC_BSV before connects to host.
> - *
> - * @ci: the controller
> - * @reg: register index
> - * @mask: mast bit
> - * @value: the bit value to wait
> - * @timeout_ms: timeout in millisecond
> - *
> - * This function returns an error code if timeout
> - */
> -int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
> - u32 value, unsigned int timeout_ms)
> -{
> - unsigned long elapse = jiffies + msecs_to_jiffies(timeout_ms);
> -
> - while (hw_read(ci, reg, mask) != value) {
> - if (time_after(jiffies, elapse)) {
> - dev_err(ci->dev, "timeout waiting for %08x in %d\n",
> - mask, reg);
> - return -ETIMEDOUT;
> - }
> - msleep(20);
> - }
> -
> - return 0;
> -}
> -
> static irqreturn_t ci_irq(int irq, void *data)
> {
> struct ci_hdrc *ci = data;
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> index 91989be..d1c4cdf 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -104,7 +104,6 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
> usb_gadget_vbus_disconnect(&ci->gadget);
> }
>
> -#define CI_VBUS_STABLE_TIMEOUT_MS 5000
> static void ci_handle_id_switch(struct ci_hdrc *ci)
> {
> enum ci_role role = ci_otg_role(ci);
> @@ -117,10 +116,19 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
>
> ci_role_stop(ci);
>
> - if (role == CI_ROLE_GADGET)
> + if (role == CI_ROLE_GADGET) {
> + unsigned long elapse = jiffies + msecs_to_jiffies(5000);
> +
> /* wait vbus lower than OTGSC_BSV */
> - hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> - CI_VBUS_STABLE_TIMEOUT_MS);
> + while (hw_read_otgsc(ci, OTGSC_BSV)) {
> + if (time_after(jiffies, elapse)) {
> + dev_err(ci->dev,
> + "timeout waiting for VBUS disappear\n");
> + break;
> + }
> + msleep(20);
> + }
> + }
>
> ci_role_start(ci, role);
> }
> --
> 2.8.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
--
Best Regards,
Peter Chen
--
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: [RESEND PATCH 0/4] usb: early: add support for early printk through USB3 debug port
Hi, On 09/20/2016 10:06 PM, Mathias Nyman wrote: > On 29.08.2016 08:26, 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. >> >> This is the resend version. Original patch set was submitted >> several months ago. This resend version addresses the review >> comment here [1]. >> >> [1] https://lkml.org/lkml/2016/2/16/444 >> > > So other than making sure memory is freed, > (and maybe cleanup the duplicate code) I don't really have any objections. > Thanks for your time. I will refresh my patch according to your review comments. Thinking that the merge window will be closed soon. I won't send out the refreshed patch until the next rc1 is out. I'm willing to hear more comments during this time. > As you state in PATCH 1/4, this could be useful in the specific case of > kernel debugging when machine crashes very early before the console code is > initialized. For normal operation it is not recommended. > > And as it's not recommended or used for normal operations it shouldn't do any > harm either > > -Mathias > Best regards, Lu Baolu -- 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: [RESEND PATCH 1/4] usb: dbc: early driver for xhci debug capability
Hi,
On 09/20/2016 09:54 PM, Mathias Nyman wrote:
> On 29.08.2016 08:26, 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 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 xHCI host. There isn't any precondition from
>> xHCI host side for DbC to work.
>>
>> This patch also includes bulk out and bulk in interfaces.
>> These interfaces could be used to implement early printk
>> bootconsole or hook to various system debuggers.
>>
>> This code is designed to be only used for kernel debugging
>> when machine crashes very early before the console code is
>> initialized. For normal operation it is not recommended.
>>
>> Cc: Mathias Nyman
>> Signed-off-by: Lu Baolu
>> ---
>
> Some comments inline
Thank you for reviewing my patch.
>
>> +
>> +#ifdef XDBC_TRACE
>> +#definexdbc_tracetrace_printk
>> +#else
>> +static inline void xdbc_trace(const char *fmt, ...) { }
>> +#endif /* XDBC_TRACE */
>
> I guess there's probably no better way to enable/disable debug messages for
> this
> driver this early, and ehci-dbgp does the same.
>
> So I guess It's ok, but it still looks weird
>
>> +
>> +static void xdbc_early_delay(unsigned long count)
>> +{
>> +u8 val;
>> +
>> +val = inb(0x80);
>> +while (count-- > 0)
>> +outb(val, 0x80);
>> +}
>> +
>> +static void xdbc_runtime_delay(unsigned long count)
>> +{
>> +udelay(count);
>> +}
>> +
>
> Glad to see the addition of this runtime_delay in addition
> to the hack of reading port 0x80 for a 1us delay.
>
> And that the early_delay is only used for as long as it must.
>
>
>> +static int xdbc_handle_external_reset(void)
>> +{
>> +u32 ctrl;
>> +int ret;
>> +
>> +writel(0, &xdbc.xdbc_reg->control);
>> +ret = handshake(&xdbc.xdbc_reg->control, CTRL_DCE, 0, 10, 10);
>> +if (ret)
>> +return ret;
>> +
>> +xdbc_mem_init();
>> +mmiowb();
>> +
>> +ctrl = readl(&xdbc.xdbc_reg->control);
>> +writel(ctrl | CTRL_DCE | CTRL_PED, &xdbc.xdbc_reg->control);
>> +ret = handshake(&xdbc.xdbc_reg->control,
>> +CTRL_DCE, CTRL_DCE, 10, 10);
>> +if (ret)
>> +return ret;
>> +
>> +if (xdbc.vendor == PCI_VENDOR_ID_INTEL)
>> +xdbc_do_reset_debug_port(xdbc.port_number, 1);
>> +
>> +/* wait for port connection */
>> +ret = handshake(&xdbc.xdbc_reg->portsc,
>> +PORTSC_CCS, PORTSC_CCS, 500, 10);
>> +if (ret)
>> +return ret;
>> +
>> +/* wait for debug device to be configured */
>> +ret = handshake(&xdbc.xdbc_reg->control,
>> +CTRL_DCR, CTRL_DCR, 500, 10);
>> +if (ret)
>> +return ret;
>> +
>> +xdbc.flags |= XDBC_FLAGS_INITIALIZED | XDBC_FLAGS_CONFIGURED;
>> +
>> +xdbc_bulk_transfer(NULL, XDBC_MAX_PACKET, true);
>> +
>> +return 0;
>> +}
>> +
> ...
>
>> +static int __init xdbc_early_start(void)
>> +{
>> +u32 ctrl, status;
>> +int ret;
>> +
>> +ctrl = readl(&xdbc.xdbc_reg->control);
>> +writel(ctrl | CTRL_DCE | CTRL_PED, &xdbc.xdbc_reg->control);
>> +ret = handshake(&xdbc.xdbc_reg->control,
>> +CTRL_DCE, CTRL_DCE, 10, 100);
>> +if (ret) {
>> +pr_notice("falied to initialize hardware\n");
>> +return ret;
>> +}
>> +
>> +/* reset port to avoid bus hang */
>> +if (xdbc.vendor == PCI_VENDOR_ID_INTEL)
>> +xdbc_reset_debug_port();
>> +
>> +/* wait for port connection */
>> +ret = handshake(&xdbc.xdbc_reg->portsc,
>> +PORTSC_CCS, PORTSC_CCS, 500, 100);
>> +if (ret) {
>> +pr_notice("waiting for connection timed out\n");
>> +return ret;
>> +}
>> +
>> +/* wait for debug device to be configured */
>> +ret = handshake(&xdbc.xdbc_reg->control,
>> +CTRL_DCR, CTRL_DCR, 500, 100);
>> +if (ret) {
>> +pr_notice("waiting for device configuration timed out\n");
>> +return ret;
>> +}
>> +
>> +/* port should have a valid port# */
>> +status = readl(&xdbc.xdbc_reg->status);
>> +if (!DCST_DPN(status)) {
>> +pr_notice("invalid root hub port number\n");
>> +return -ENODEV;
>> +}
>> +
>> +xdbc.port_number = DCST_DPN(status);
>> +
>> +pr_notice("DbC is running now, control 0x%08x port ID %d\n",
>> + readl(&xdbc.xdbc_reg->control), xdbc.po
[RESEND PATCH v6, 1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode
Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.
Additionally add optional properties of pinctrl for host only mode
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 54 +++-
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..2a930bd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,10 +2,18 @@ MT8173 xHCI
The device node for Mediatek SOC USB3.0 host controller
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
Required properties:
- compatible : should contain "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers,
- the first one for MAC, the second for IPPC
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
- interrupts : interrupt used by the controller
- power-domains : a phandle to USB power domain node to control USB's
mtcmos
@@ -27,12 +35,16 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
- vbus-supply : reference to the VBUS regulator;
- usb3-lpm-capable : supports USB3.0 LPM
+ - pinctrl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+ See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
Example:
usb30: usb@1127 {
compatible = "mediatek,mt8173-xhci";
reg = <0 0x1127 0 0x1000>,
<0 0x11280700 0 0x0100>;
+ reg-names = "mac", "ippc";
interrupts = ;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
@@ -49,3 +61,41 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <&pericfg>;
mediatek,wakeup-src = <1>;
};
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+ mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must be
+ "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>;
+ reg-names = "mac";
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>;
+ clock-names = "sys_ck";
+ vusb33-supply = <&mt6397_vusb_reg>;
+ usb3-lpm-capable;
+};
--
1.7.9.5
--
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
[RESEND PATCH v6, 5/5] arm64: dts: mediatek: add USB3 DRD driver
USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 46 +--
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 29 +
2 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
chosen { };
+ extcon_usb: extcon_iddig {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pio 16 GPIO_ACTIVE_HIGH>;
+ };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ usb_p0_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&pio 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
};
&i2c1 {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+ usb_id_pins_float: usb_iddig_pull_up {
+ pins_iddig {
+ pinmux = ;
+ bias-pull-up;
+ };
+ };
+
+ usb_id_pins_ground: usb_iddig_pull_down {
+ pins_iddig {
+ pinmux = ;
+ bias-pull-down;
+ };
+ };
};
&pwm0 {
@@ -431,12 +460,25 @@
status = "okay";
};
+&ssusb {
+ vusb33-supply = <&mt6397_vusb_reg>;
+ vbus-supply = <&usb_p0_vbus>;
+ extcon = <&extcon_usb>;
+ dr_mode = "otg";
+ mediatek,enable-wakeup;
+ pinctrl-names = "default", "id_float", "id_ground";
+ pinctrl-0 = <&usb_id_pins_float>;
+ pinctrl-1 = <&usb_id_pins_float>;
+ pinctrl-2 = <&usb_id_pins_ground>;
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
-&usb30 {
+&usb_host {
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p1_vbus>;
- mediatek,wakeup-src = <1>;
+ status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..925948a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -668,11 +668,14 @@
status = "disabled";
};
- usb30: usb@1127 {
- compatible = "mediatek,mt8173-xhci";
- reg = <0 0x1127 0 0x1000>,
+ ssusb: usb@11271000 {
+ compatible = "mediatek,mt8173-mtu3";
+ reg = <0 0x11271000 0 0x3000>,
<0 0x11280700 0 0x0100>;
- interrupts = ;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
<&pericfg CLK_PERI_USB0>,
@@ -680,10 +683,22 @@
clock-names = "sys_ck",
"wakeup_deb_p0",
"wakeup_deb_p1";
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <&pericfg>;
- status = "okay";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usb_host: xhci@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>;
+ reg-names = "mac";
+ interrupts = ;
+ power-domains = <&scpsys
MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>;
+ clock-names = "sys_ck";
+ status = "disabled";
+ };
};
u3phy: usb-phy@1129 {
--
1.7.9.5
--
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.h
[RESEND PATCH v6, 4/5] usb: Add MediaTek USB3 DRD Driver
This patch adds support for the MediaTek USB3 controller integrated into MT8173. It can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only (xHCI) modes. Signed-off-by: Chunfeng Yun --- drivers/usb/Kconfig|2 + drivers/usb/Makefile |1 + drivers/usb/mtu3/Kconfig | 54 +++ drivers/usb/mtu3/Makefile | 19 + drivers/usb/mtu3/mtu3.h| 422 + drivers/usb/mtu3/mtu3_core.c | 871 +++ drivers/usb/mtu3/mtu3_dr.c | 379 drivers/usb/mtu3/mtu3_dr.h | 108 + drivers/usb/mtu3/mtu3_gadget.c | 731 + drivers/usb/mtu3/mtu3_gadget_ep0.c | 883 drivers/usb/mtu3/mtu3_host.c | 294 drivers/usb/mtu3/mtu3_hw_regs.h| 473 +++ drivers/usb/mtu3/mtu3_plat.c | 490 drivers/usb/mtu3/mtu3_qmu.c| 599 drivers/usb/mtu3/mtu3_qmu.h| 43 ++ 15 files changed, 5369 insertions(+) create mode 100644 drivers/usb/mtu3/Kconfig create mode 100644 drivers/usb/mtu3/Makefile create mode 100644 drivers/usb/mtu3/mtu3.h create mode 100644 drivers/usb/mtu3/mtu3_core.c create mode 100644 drivers/usb/mtu3/mtu3_dr.c create mode 100644 drivers/usb/mtu3/mtu3_dr.h create mode 100644 drivers/usb/mtu3/mtu3_gadget.c create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c create mode 100644 drivers/usb/mtu3/mtu3_host.c create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h create mode 100644 drivers/usb/mtu3/mtu3_plat.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.h diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 8689dcb..9ca0bf0 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig" endif +source "drivers/usb/mtu3/Kconfig" + source "drivers/usb/musb/Kconfig" source "drivers/usb/dwc3/Kconfig" diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index dca7856..7791af6 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/ obj-$(CONFIG_USB_ISP1760) += isp1760/ obj-$(CONFIG_USB_MON) += mon/ +obj-$(CONFIG_USB_MTU3) += mtu3/ obj-$(CONFIG_PCI) += host/ obj-$(CONFIG_USB_EHCI_HCD) += host/ diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig new file mode 100644 index 000..25cd619 --- /dev/null +++ b/drivers/usb/mtu3/Kconfig @@ -0,0 +1,54 @@ +# For MTK USB3.0 IP + +config USB_MTU3 + tristate "MediaTek USB3 Dual Role controller" + depends on EXTCON && (USB || USB_GADGET) && HAS_DMA + depends on ARCH_MEDIATEK || COMPILE_TEST + select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD + help + Say Y or M here if your system runs on MediaTek SoCs with + Dual Role SuperSpeed USB controller. You can select usb + mode as peripheral role or host role, or both. + + If you don't know what this is, please say N. + + Choose M here to compile this driver as a module, and it + will be called mtu3.ko. + + +if USB_MTU3 +choice + bool "MTU3 Mode Selection" + default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET) + default USB_MTU3_HOST if (USB && !USB_GADGET) + default USB_MTU3_GADGET if (!USB && USB_GADGET) + +config USB_MTU3_HOST + bool "Host only mode" + depends on USB=y || USB=USB_MTU3 + help + Select this when you want to use MTU3 in host mode only, + thereby the gadget feature will be regressed. + +config USB_MTU3_GADGET + bool "Gadget only mode" + depends on USB_GADGET=y || USB_GADGET=USB_MTU3 + help + Select this when you want to use MTU3 in gadget mode only, + thereby the host feature will be regressed. + +config USB_MTU3_DUAL_ROLE + bool "Dual Role mode" + depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || USB_GADGET=USB_MTU3)) + help + This is the default mode of working of MTU3 controller where + both host and gadget features are enabled. + +endchoice + +config USB_MTU3_DEBUG + bool "Enable Debugging Messages" + help + Say Y here to enable debugging messages in the MTU3 Driver. + +endif diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile new file mode 100644 index 000..3e17ff7 --- /dev/null +++ b/drivers/usb/mtu3/Makefile @@ -0,0 +1,19 @@ + +ccflags-$(CONFIG_USB_MTU3_DEBUG) += -DDEBUG + +obj-$(CONFIG_USB_MTU3) += mtu3.o + +mtu3-y := mtu3_plat.o + +ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),) + mtu3-y += mtu3_host.o +endif + +ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),) + mtu3-y += mtu3_core.o mtu3_gadget_ep0.o mtu3_gadget.o mtu3_qmu.o
[RESEND PATCH v6, 0/5] Add MediaTek USB3 DRD Driver
>From 99e428a1808c8ca91ff473d487b52ca5d355d875 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Mon, 5 Sep 2016 10:27:07 +0800 Subject: [PATCH v6, 0/5] Add MediaTek USB3 DRD Driver These patches introduce the MediaTek USB3 dual-role controller driver. The driver can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only (xHCI) modes. It works well with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is tested on MT8173 platform which only contains USB2.0 device IP, and on MT6290 platform which contains USB3.0 device IP. Change in v6: 1. handle endianness of GPD and SETUP data 2. remove dummy error log and return suitable error number 3. cancel delay work when deregiseter driver Change in v5: 1. modify some comments 2. rename some unsuitable variables 3. add reg-names property for host node 4. add USB_MTU3_DEBUG to control debug messages Change in v4: 1. fix build errors on non-mediatek platforms 2. provide manual dual-role switch via debugfs instead of sysfs Change in v3: 1. fix some typo error 2. rename mtu3.txt to mt8173-mtu3.txt Change in v2: 1. modify binding docs according to suggestions 2. modify some comments and remove some dummy blank lines 3. fix memory leakage Chunfeng Yun (5): dt-bindings: mt8173-xhci: support host side of dual-role mode dt-bindings: mt8173-mtu3: add devicetree bindings usb: xhci-mtk: make IPPC register optional usb: Add MediaTek USB3 DRD Driver arm64: dts: mediatek: add USB3 DRD driver .../devicetree/bindings/usb/mt8173-mtu3.txt| 87 ++ .../devicetree/bindings/usb/mt8173-xhci.txt| 54 +- arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 46 +- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 29 +- drivers/usb/Kconfig|2 + drivers/usb/Makefile |1 + drivers/usb/host/xhci-mtk.c| 36 +- drivers/usb/mtu3/Kconfig | 54 ++ drivers/usb/mtu3/Makefile | 19 + drivers/usb/mtu3/mtu3.h| 422 ++ drivers/usb/mtu3/mtu3_core.c | 871 +++ drivers/usb/mtu3/mtu3_dr.c | 379 + drivers/usb/mtu3/mtu3_dr.h | 108 +++ drivers/usb/mtu3/mtu3_gadget.c | 731 drivers/usb/mtu3/mtu3_gadget_ep0.c | 883 drivers/usb/mtu3/mtu3_host.c | 294 +++ drivers/usb/mtu3/mtu3_hw_regs.h| 473 +++ drivers/usb/mtu3/mtu3_plat.c | 490 +++ drivers/usb/mtu3/mtu3_qmu.c| 599 + drivers/usb/mtu3/mtu3_qmu.h| 43 + 20 files changed, 5603 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt create mode 100644 drivers/usb/mtu3/Kconfig create mode 100644 drivers/usb/mtu3/Makefile create mode 100644 drivers/usb/mtu3/mtu3.h create mode 100644 drivers/usb/mtu3/mtu3_core.c create mode 100644 drivers/usb/mtu3/mtu3_dr.c create mode 100644 drivers/usb/mtu3/mtu3_dr.h create mode 100644 drivers/usb/mtu3/mtu3_gadget.c create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c create mode 100644 drivers/usb/mtu3/mtu3_host.c create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h create mode 100644 drivers/usb/mtu3/mtu3_plat.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.h -- 1.7.9.5 -- 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
[RESEND PATCH v6, 2/5] dt-bindings: mt8173-mtu3: add devicetree bindings
add a DT binding doc for MediaTek USB3 DRD driver
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/mt8173-mtu3.txt| 87
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
new file mode 100644
index 000..e049d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -0,0 +1,87 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+ mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+ "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+ depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+ refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+ with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+ when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+ dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+ "id_float" and "id_ground" are optinal which depends on
+ "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+ See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+ "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via debugfs; usually
+ used when receptacle is TYPE-A and also wants to support dual-role
+ mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+ control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+ compatible = "mediatek,mt8173-mtu3";
+ reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+ clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+ vusb33-supply = <&mt6397_vusb_reg>;
+ vbus-supply = <&usb_p0_vbus>;
+ extcon = <&extcon_usb>;
+ dr_mode = "otg";
+ mediatek,enable-wakeup;
+ mediatek,syscon-wakeup = <&pericfg>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usb_host: xhci@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>;
+ reg-names = "mac";
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>;
+ clock-names = "sys_ck";
+ vusb33-supply = <&mt6397_vusb_reg>;
+ status = "disabled";
+ };
+};
--
1.7.9.5
--
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
[RESEND PATCH v6, 3/5] usb: xhci-mtk: make IPPC register optional
Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..4bf99b9 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
+ if (ippc == NULL)
+ return 0;
+
/* power on host ip */
value = readl(&ippc->ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
+ if (ippc == NULL)
+ return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(&ippc->u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
+ if (ippc == NULL)
+ return 0;
+
/* reset whole ip */
value = readl(&ippc->ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct
xhci_hcd *xhci)
/* called during probe() after chip reset completes */
static int xhci_mtk_setup(struct usb_hcd *hcd)
{
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+ }
+
+ ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+ if (ret)
+ return ret;
+
+ if (usb_hcd_is_primary_hcd(hcd)) {
+ mtk->num_u3_ports = xhci->num_usb3_ports;
+ mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
- return xhci_gen_setup(hcd, xhci_mtk_quirks);
+ return ret;
}
static int xhci_mtk_probe(struct platform_device *pdev)
@@ -586,7 +605,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
mtk->hcd = platform_get_drvdata(pdev);
platform_set_drvdata(pdev, mtk);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mac");
hcd->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(hcd->regs)) {
ret = PTR_ERR(hcd->regs);
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- mtk->ippc_regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(mtk->ippc_regs)) {
- ret = PTR_ERR(mtk->ippc_regs);
- goto put_usb2_hcd;
+ mtk->ippc_regs = NULL;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ippc");
+ if (res) { /* ippc register is optional */
+ mtk->ippc_regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mtk->ippc_regs)) {
+ ret = PTR_ERR(mtk->ippc_regs);
+ goto put_usb2_hcd;
+ }
}
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
--
1.7.9.5
--
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 net 0/5] r8152: correct the flow of PHY
From: Hayes Wang Date: Tue, 20 Sep 2016 16:22:04 +0800 > First, to enable the PHY as early as possible. Some settings may fail if the > PHY is power down. > > Move the other PHY settings to hw_phy_cfg() to make sure the order is correct. > > Finally, disable ALDPS and EEE before updating the PHY for RTL8153. Series applied, 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: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi guys, On Di, 2016-08-30 at 10:32 +0530, Anand Moon wrote: > Hi All > > Adding Vivek Gautam. > > On 29 August 2016 at 16:35, Michael Niewöhner > wrote: > > > > Hi Mathias, > > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: > > > > > > On 29.08.2016 10:28, Felipe Balbi wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > Michael Niewöhner writes: > > > > > > > > > > > > > > > [1.] One line summary of the problem: > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > [2.] Full description of the problem/report: > > > > > No usb 3.0 devices are being detected when attached while USB > > > > > 2.0 > > > > > devices work on the same port. > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but > > > > > seems > > > > > to be > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > attached. > > > > > > > > dwc3 is host, which means it's actually XHCI :-) > > > > > > > > Adding Mathias > > > > > > > > > > > > > > > > > > > dmesg: > > > > > [ 192.287080] usb 3-1.2: USB disconnect, device number 7 > > > > > [ 210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = > > > > > -71) > > > > > > Looks like the hub GetPortStatus request fails with protocol > > > error. > > > > > > Reading xhci root hub port status is mostly just register reads > > > and > > > writes. It > > > shouldn't include any actual transfers that could return -EPROTO > > > > > > So this is not the root hub? but a external or integrated on your > > > board, right? > > > > > > The protocol error -71 is returned at transfer errors or if > > > device > > > stalled. > > > > > > Adding more xhci debugging options could show something: > > > echo -n 'module xhci_hcd =p' > > > > /sys/kernel/debug/dynamic_debug/control > > > > > > > > > > > > > > > > > > > > > > > > > > [9.] Other notes, patches, fixes, workarounds: > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 > > > > > > The additional patches that makes things somehow work involve > > > tuning > > > the PHY, > > > this is an area I'm not familiar with > > > > > > -Mathias > > > > > > > > > I'm sorry, I should have said that this is the dmesg output with > > the > > patches applied. Without them there is no output at all when I > > attach > > an usb 3.0 device. > > > > Michael > > There are two dwc3 ports in the SoC : one for Gbit Ethernet another > one for on-board GL3521 USB 3.0 hub controller. > > 3.10.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, > Driver=r8152, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M > > 4.x kernel > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, > Driver=r8152, 480M > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb- > storage, 5000M > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb- > storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M > > I fell that Ethernet driver r8152 is not getting registered to > xhci-hcd to bus port 06 > which lead to other ports to miss configure, some time the Ethernet > port get register to bus port 04 > > Their is also a possibility that all the port are not getting proper > power from the S2MPS11 PMIC > and possible some reset of the phy is needed to reconfigure the > exynos > USB HSIC controller. > > Best Regards > -Anand Moon > -- > To unsubscribe from this list: send the line "unsubscribe linux- > samsung-soc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Today I've tested v4.8-rc7 (without the patches above). The USB 3.0 ports have stopped working completely for me. Neither USB 2.0 nor USB 3.0 are being detected. The Ethernet port does not work, too. The USB- 2.0-only Port works. There also a new problem: my XU4 does not reboot or poweroff anymore. When I force-remove
Re: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, Sep 20, 2016 at 9:49 PM, Alan Stern wrote:
> On Tue, 20 Sep 2016, Carsten Mattner wrote:
>
> > On Tue, Sep 20, 2016 at 5:41 PM, Alan Stern
> > wrote:
> >
> > > I suspect the problem has been there all along, but it simply wasn't
> > > reported until commit 71723f95463d ("PM / runtime: print error when
> > > activating a child to unactive parent") was merged in 4.8-rc1.
> >
> > Is this just a false positive or a real error that had been silently
> > ignored all this time?
>
> It's a real error, albeit one that is quite unlikely to cause any real
> harm. That's why nobody noticed it until the warning message was
> added.
Just to be clear, your patch doesn't hide the error but merely silences
the safe-to-ignore condition after trying a little harder, right?
--
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: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, 20 Sep 2016, Carsten Mattner wrote:
> On Tue, Sep 20, 2016 at 5:41 PM, Alan Stern wrote:
>
> > I suspect the problem has been there all along, but it simply wasn't
> > reported until commit 71723f95463d ("PM / runtime: print error when
> > activating a child to unactive parent") was merged in 4.8-rc1.
>
> Is this just a false positive or a real error that had been silently
> ignored all this time?
It's a real error, albeit one that is quite unlikely to cause any real
harm. That's why nobody noticed it until the warning message was
added.
> > Does this patch get rid of the error message?
>
> Thanks. Yes it does. Will it be in rc8 next Sunday?
I don't know.
Alan Stern
--
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: serial: update CH34x driver in drivers/usb/serial
On 2016-09-15 01:03, Aidan Thornton wrote: thanks, greg k-h It looks like someone by the name of Grigori Goronzy (CCed) had a patch series or four attempting to do this that just never went anywhere like all the other attempts. Might be worth someone talking to him or looking at his patches. Seriously, this is... I was considering trying to get parity support merged so I don't have to keep patching it in, but it feels like a total waste of effort at this point after seeing all the other attempts. Hi everyone, sorry for not following up on the patches. There were some odd compatibility issues reported by one user and then I got busy with other things, so this got sidetracked. But just a few days ago the lack of working parity annoyed me again. STM32 bootloaders need parity. I'll take a look at your revised patches, Aidan. Maybe we can finally get this done. About the compatibility issues, I never managed to reproduce them and I concluded in the end that it might be something unrelated. The person that reported compatibility issues with the patch series was Eddi De Pieri . Best regards Grigori -- 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: UAS and f_tcm -- is anyone using it?
On 9/20/2016 11:35 AM, John Youn wrote: > On 9/20/2016 1:29 AM, Felipe Balbi wrote: >> >> Hi, >> >> John Youn writes: >>> There's also a TCM python tool somewhere which helps with this. I >>> haven't used f_tcm in a long while, but Sebastian and I used it long >>> back to test streams with dwc3. >> >> Have you tried it recently? Or do you know of anyone who has? > > Sebastian is the only one I know who has used this in the past. > Just from the code it seems there will be some fundamental issues with it, such as the value of maxpacket size and some alt-interface stuff. At least when used with DWC3. >>> >>> such as? >> >> I'll see if I can write up the exact issues later. I have to go back >> to my notes to remind myself. >>> >>> Ok, coming back to this uas gadget stuff. >>> >>> I've finally had a chance to go back to my notes. Here are some of the >>> concrete issues that I found, that I was able to workaround in some >>> way. >>> >>> * EP's for UAS alt-interface cannot be configured correctly because >>> the config_ep_for_speed() in composite.c does not take into account >>> alt-interfaces. This results in incorrectly configured EP in the >>> controller (no streaming enabled, wrong direction, etc). >> >> cool, that's a bug in composite.c which needs to be fixed. >> >>> * START_XFER command needs to enable streams >> >> bug in dwc3 which needs to be fixed. >> >>> * XFER_NOT_READY event needs to be enabled for streams >> >> bug in dwc3 which needs to be fixed :-) In any case, can you point me to >> section in documention which states Streams *requires* XFER_NOT_READY? > > It should be the same as used for BULK. Maybe it's not needed with > your recent enhancements? Not sure. I have to rebase and test. > >> >>> * For OUT EPs, the TCM/target framework sets receive buffers size as >>> 512 bytes. This cannot work in SUPERSPEED as you must always provide >>> at least MPS-sized buffers. This causes all writes to fail. I'm not >> >> that's a good point. TCM gadget should be checking for ep out aligned >> quirk flag. > > Is this an existing quirk? It's not just about alignment, but the size > of the rx buffer, which it should know based on the MPS for the speed. > >> >>> sure how to properly fix this as it should be fixed at the function >>> driver level, and this size comes from the target framework. I put a >>> workaround at the controller-level. >>> >>> After addressing these issues, UAS read/write works to some extent. >>> But it is still unstable in ways that point to issues in the target >>> framework, things to do with locking/race conditions there. >> >> Alright, those are all bugs which need to be fixed. Certainly we don't >> need an entire new gadget just because you've found some bugs, right? >> > > Sure. I was just curious if there was any interest in it since we have > an existing driver we could port. > >> We'd be much better off fixing these problems because then more folks >> would benefit from them. > > Agree if it was working and being used in the first place. > > But anyways I'll focus on TCM. > Hi Sebastian, Andrzej, If possible, could you share how you are using it? Such as in what speed, mode, and with what controllers/platforms and hosts? If you have any other tips on usage I would appreciate it. I'm looking into getting it working with our dwc3 controller, maybe also dwc2. Regards, John -- 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: [PATCHv2] usb: musb: Fix unbalanced platform_disable
* Tony Lindgren [160920 10:11]: > * Laurent Pinchart [160919 23:36]: > > No, I perform the following steps: > > > > - Connect the panda board to the USB through USB (which powers the board on) > > - Let the board boot over NFS > > - Log in as root, run 'reboot' > > > > The second boot produces the warning. > > Oh I was looking at the errors while shutting down things.. OK yeah I get > that too along with a bunch of DSS related warnings with your .config. > Probably I did not notice it earlier because of the DSS warnings. Will > take a look. The patch below fixes the issue for me, care to give it a try? If that works for you I'll repost with a proper patch description. Regards, Tony 8< diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1255,6 +1255,7 @@ static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req, map_dma_buffer(request, musb, musb_ep); + pm_runtime_get_sync(musb->controller); spin_lock_irqsave(&musb->lock, lockflags); /* don't queue if the ep is down */ @@ -1275,6 +1276,9 @@ static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req, unlock: spin_unlock_irqrestore(&musb->lock, lockflags); + pm_runtime_mark_last_busy(musb->controller); + pm_runtime_put_autosuspend(musb->controller); + return status; } -- 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: UAS and f_tcm -- is anyone using it?
On 9/20/2016 1:29 AM, Felipe Balbi wrote: > > Hi, > > John Youn writes: >> There's also a TCM python tool somewhere which helps with this. I >> haven't used f_tcm in a long while, but Sebastian and I used it long >> back to test streams with dwc3. > > Have you tried it recently? Or do you know of anyone who has? Sebastian is the only one I know who has used this in the past. >>> Just from the code it seems there will be some fundamental issues with >>> it, such as the value of maxpacket size and some alt-interface >>> stuff. At least when used with DWC3. >> >> such as? > > I'll see if I can write up the exact issues later. I have to go back > to my notes to remind myself. >> >> Ok, coming back to this uas gadget stuff. >> >> I've finally had a chance to go back to my notes. Here are some of the >> concrete issues that I found, that I was able to workaround in some >> way. >> >> * EP's for UAS alt-interface cannot be configured correctly because >> the config_ep_for_speed() in composite.c does not take into account >> alt-interfaces. This results in incorrectly configured EP in the >> controller (no streaming enabled, wrong direction, etc). > > cool, that's a bug in composite.c which needs to be fixed. > >> * START_XFER command needs to enable streams > > bug in dwc3 which needs to be fixed. > >> * XFER_NOT_READY event needs to be enabled for streams > > bug in dwc3 which needs to be fixed :-) In any case, can you point me to > section in documention which states Streams *requires* XFER_NOT_READY? It should be the same as used for BULK. Maybe it's not needed with your recent enhancements? Not sure. I have to rebase and test. > >> * For OUT EPs, the TCM/target framework sets receive buffers size as >> 512 bytes. This cannot work in SUPERSPEED as you must always provide >> at least MPS-sized buffers. This causes all writes to fail. I'm not > > that's a good point. TCM gadget should be checking for ep out aligned > quirk flag. Is this an existing quirk? It's not just about alignment, but the size of the rx buffer, which it should know based on the MPS for the speed. > >> sure how to properly fix this as it should be fixed at the function >> driver level, and this size comes from the target framework. I put a >> workaround at the controller-level. >> >> After addressing these issues, UAS read/write works to some extent. >> But it is still unstable in ways that point to issues in the target >> framework, things to do with locking/race conditions there. > > Alright, those are all bugs which need to be fixed. Certainly we don't > need an entire new gadget just because you've found some bugs, right? > Sure. I was just curious if there was any interest in it since we have an existing driver we could port. > We'd be much better off fixing these problems because then more folks > would benefit from them. Agree if it was working and being used in the first place. But anyways I'll focus on TCM. Regards, John -- 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: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, Sep 20, 2016 at 5:41 PM, Alan Stern wrote:
> I suspect the problem has been there all along, but it simply wasn't
> reported until commit 71723f95463d ("PM / runtime: print error when
> activating a child to unactive parent") was merged in 4.8-rc1.
Is this just a false positive or a real error that had been silently
ignored all this time?
> Does this patch get rid of the error message?
Thanks. Yes it does. Will it be in rc8 next Sunday?
--
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: [PATCHv2] usb: musb: Fix unbalanced platform_disable
* Laurent Pinchart [160919 23:36]: > Hi Tony, > > On Monday 19 Sep 2016 15:41:50 Tony Lindgren wrote: > > * Laurent Pinchart [160919 13:35]: > > > On Sunday 18 Sep 2016 08:19:02 Tony Lindgren wrote: > > >>> [5.711303] [] (_raw_spin_unlock_irqrestore) from > > >>> [] > > >>> (musb_gadget_queue+0x128/0x4ac) > > >>> [5.711303] [] (musb_gadget_queue) from [] > > >>> (usb_ep_queue+0x38/0x1d4) > > >>> [5.729766] [] (usb_ep_queue) from [] > > >>> (rx_submit+0xc8/0x19c) > > >>> [5.737548] [] (rx_submit) from [] > > >>> (rx_fill+0x7c/0xa0) [5.737548] [] (rx_fill) from > > >>> [] (eth_start+0x28/0x48) [5.751983] [] > > >>> (eth_start) from [] (eth_open+0x6c/0x7c) [5.751983] > > >>> [] (eth_open) from [] > > >>> (__dev_open+0x9c/0x104) > > >> > > >> This could be something else though. Care to email me your .config, > > >> maybe this is related to legacy g_ether being built in? > > > > > > Sure, please find it attached. The legacy g_ether is indeed built-in, > > > that's what I use to boot over nfsroot. > > > > OK, I think g_ether may have issues in general.. > > > > I mostly test with configfs based gadgets and shell script as then I can > > test load/configure/connect/disconnect/unconfigure/unload easily :) > > g_ether is very convenient when using nfsroot, as it allows booting the > system > without an initramfs. Yeah no doubt about that. > > >> Anyways, please also give the following patch a try. > > > > > > I've tested the patch and if fixes the original problem. Warm reboots are > > > still broken though. > > > > No luck here with your .config a try with my pandaboard es against v4.8-rc7 > > plus the patch I posted on Sunday. It reboots with no errors for me with > > NFSroot. Do you do something other than just reboot? > > No, I perform the following steps: > > - Connect the panda board to the USB through USB (which powers the board on) > - Let the board boot over NFS > - Log in as root, run 'reboot' > > The second boot produces the warning. Oh I was looking at the errors while shutting down things.. OK yeah I get that too along with a bunch of DSS related warnings with your .config. Probably I did not notice it earlier because of the DSS warnings. Will take a look. Thanks, Tony -- 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
g_webcam Isoch high bandwidth transfer
Hi,
I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
high-speed connection.
First I hacked webcam.c as follows to enable 640x480@30fps mode.
diff --git a/drivers/usb/gadget/legacy/webcam.c
b/drivers/usb/gadget/legacy/webcam.c
index 72c976b..9eb315f 100644
--- a/drivers/usb/gadget/legacy/webcam.c
+++ b/drivers/usb/gadget/legacy/webcam.c
@@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3)
uvc_frame_yuv_360p = {
.bFrameIndex= 1,
.bmCapabilities = 0,
.wWidth = cpu_to_le16(640),
- .wHeight= cpu_to_le16(360),
+ .wHeight= cpu_to_le16(480),
.dwMinBitRate = cpu_to_le32(18432000),
.dwMaxBitRate = cpu_to_le32(55296000),
- .dwMaxVideoFrameBufferSize = cpu_to_le32(460800),
- .dwDefaultFrameInterval = cpu_to_le32(66),
+ .dwMaxVideoFrameBufferSize = cpu_to_le32(614400),
+ .dwDefaultFrameInterval = cpu_to_le32(33),
.bFrameIntervalType = 3,
- .dwFrameInterval[0] = cpu_to_le32(66),
- .dwFrameInterval[1] = cpu_to_le32(100),
- .dwFrameInterval[2] = cpu_to_le32(500),
+ .dwFrameInterval[0] = cpu_to_le32(33),
+ .dwFrameInterval[1] = cpu_to_le32(66),
+ .dwFrameInterval[2] = cpu_to_le32(100),
};
then loaded g_webcam.ko as
# modprobe g_webcam streaming_maxpacket=3072
The endpoint descriptor showing on the host is
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8d EP 13 IN
bmAttributes5
Transfer TypeIsochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1400 3x 1024 bytes
bInterval 1
However the usb bus trace shows only one transaction with 1024-bytes packet in
every SOF. The host only sends one IN packet in every SOF, I am expecting 2~3
1024-bytes transactions, since this would be required to transfer 640x480@30fps
YUV frames in high-speed.
DId I miss anything in the setup?
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: xHCI problem? [was Re: Erratic USB device behavior and device loss]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2016-09-20 at 11:43 -0400, Alan Stern wrote: > > Yes. But that'd also mean to write that value upon every suspend/resume > cycle > > because the rtsx usb driver still declares support for autosuspend. > > Should that be dropped ? > > No, the value doesn't change across a suspend/resume cycle. > I just verified, and yes, you are right. The value doesn't change. > > > I'm afraid that this won't prevent the device from disconnecting > > > itself, though. This appears to be some sort of hardware bug that > > > can't be fixed in software. > > > > And that'd mean that upon every reset, the driver will again enable > autosuspend > > for that driver. > > Yes, that's true. I'm curious to see if preventing autosuspends will > get rid of the resets. My guess is that it won't. No. We tried it in the beginning. And the resets were still seen. Thanks. - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX4Vr/AAoJEKY6WKPy4XVpqSoP/jimRbblWfR56HM3RuK6jLTp XHm2lJj6LopxC7BDPVF+SIMULlTyPh2hjbF2MVw9yNwsv1nruGQspzZ5VrBWlTsK 8Fs2sJif7Y8tWVFEMZczghrEoHN0KLe5vW4W6rX8xjjH5nL6ljtUeBDT6DyvD7yT WymQWfObwp6VnjoR3nZ1SzB4DN/oGH10NaMjkk234mTkhU9Pl+UXFmesDdWn8Y64 3l5SpemMbNQaCaa/jyFQBJXu3+OTYVQafHjcl0bb3aRt4sHq5neS5zc/EIjz+Cpo kqQwpQ6FslvSvamlwwB8mqDalPQZHeIvUNFMjlldpiAs8iCVeMHpolWI/CXCfo+1 BwVv8Kc1VnoMsjZ7uEUQJY9F1Q7YJ+4gFK6WSAhz7B9Na/0ztPJgq0tFYnVQgrwx zUnLL7jPZZ4Wt8if9UayPtCUCdqHBSIfeoJ7+HMkC6FPt5GGCsrhtZX0u0Onop7F Ka/VNgpMUNccgPvdqq3zYKyNIaAIUPf0jSyFbwxVXGbCLSZi8f4QmSw7k3BvkqNN lR+pyqjKbImTpzqk0QT22SGT+4MeQgclbEUkpfA8PaPyb+9uLjgtZgp1ucTlMzOV c3mXaTzRtSihagSW4hNyqYOINtBnvZp3n2fWDPgjJu+LWGOhpqY7P8mq8gFj77Fp G49mKNuDiOkPWH3qHJgA =bGWs -END PGP SIGNATURE- -- 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: crash by cdc_acm driver in kernels 4.8-rc1/5
On Tue, Sep 20, 2016 at 03:05:14PM +0200, Oliver Neukum wrote: > > I cannot replicate it. Could you please provide "lsusb -v"? > > Regards > Oliver It concerns these type of modems: http://www.ebay.nl/itm/191933738340 http://www.ebay.nl/itm/121590899044 lsusb: Bus 002 Device 002: ID 0bda:0111 Realtek Semiconductor Corp. RTS5111 Card Reader Controller Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Since the output is quite lengthy, I've cut out everything but Bus 007 Device 002 lsusb -v: Bus 007 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0572 Conexant Systems (Rockwell), Inc. idProduct 0x1340 bcdDevice1.00 iManufacturer 1 Conexant iProduct2 USB Modem iSerial 3 12345678 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 73 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 128 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 CDC ACM: bmCapabilities 0x07 sends break line coding and serial state get/set/clear comm features CDC Union: bMasterInterface0 bSlaveInterface 1 Country Selection: iCountryCodeRelDate4 04052004 wCountryCode 0x4803 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 96 bNumInterfaces 3 bConfigurationValue 2 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25
Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
On Tue, 20 Sep 2016, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello Alan, > > On Tue, 2016-09-20 at 10:16 -0400, Alan Stern wrote: > > This is a lot better. No more I/O errors. > > > > We still have irregular suspends and resumes, but that's to be > > expected. More worrying are the spontaneous disconnects. They don't > > seem to be related to the suspend/resume activity. > > > > You can disable suspend for this device entirely by doing: > > > > echo on >/sys/bus/usb/devices/2-4/power/control > > > > Yes. But that'd also mean to write that value upon every suspend/resume cycle > because the rtsx usb driver still declares support for autosuspend. > Should that be dropped ? No, the value doesn't change across a suspend/resume cycle. > > I'm afraid that this won't prevent the device from disconnecting > > itself, though. This appears to be some sort of hardware bug that > > can't be fixed in software. > > And that'd mean that upon every reset, the driver will again enable > autosuspend > for that driver. Yes, that's true. I'm curious to see if preventing autosuspends will get rid of the resets. My guess is that it won't. Alan Stern -- 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: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, 20 Sep 2016, Carsten Mattner wrote:
> On Tue, Sep 20, 2016 at 2:36 PM, Oliver Neukum wrote:
> > On Tue, 2016-09-20 at 14:11 +0200, Carsten Mattner wrote:
> >> 4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report
> >> this
> >> warning or error (cannot tell) anytime a USB mass storage device is
> >> inserted
> >> into a usb port (2.0 or 3.0):
> >>
> >> runtime PM trying to activate child device host6 but parent
> >> (2-1.2:1.0) is not active
> >
> > I see no obvious culprit. Could you bisect?
>
> I need the machine for so cannot do too many compile and reboot
> cycles, but I've confirmed that the error message is triggered back
> in 4.8-rc2.
>
> No such thing in 4.7.4 and I'm now back in lts-4.7.4 to get work done.
I suspect the problem has been there all along, but it simply wasn't
reported until commit 71723f95463d ("PM / runtime: print error when
activating a child to unactive parent") was merged in 4.8-rc1.
Does this patch get rid of the error message?
Alan Stern
Index: usb-4.x/drivers/usb/storage/usb.c
===
--- usb-4.x.orig/drivers/usb/storage/usb.c
+++ usb-4.x/drivers/usb/storage/usb.c
@@ -1070,17 +1070,18 @@ int usb_stor_probe2(struct us_data *us)
result = usb_stor_acquire_resources(us);
if (result)
goto BadDevice;
+
+ usb_autopm_get_interface_no_resume(us->pusb_intf);
snprintf(us->scsi_name, sizeof(us->scsi_name), "usb-storage %s",
dev_name(&us->pusb_intf->dev));
result = scsi_add_host(us_to_host(us), dev);
if (result) {
dev_warn(dev,
"Unable to add the scsi host\n");
- goto BadDevice;
+ goto AddHostFailed;
}
/* Submit the delayed_work for SCSI-device scanning */
- usb_autopm_get_interface_no_resume(us->pusb_intf);
set_bit(US_FLIDX_SCAN_PENDING, &us->dflags);
if (delay_use > 0)
@@ -1090,7 +1091,9 @@ int usb_stor_probe2(struct us_data *us)
return 0;
/* We come here if there are any problems */
-BadDevice:
+ AddHostFailed:
+ usb_autopm_put_interface_no_suspend(us->pusb_intf);
+ BadDevice:
usb_stor_dbg(us, "storage_probe() failed\n");
release_everything(us);
return result;
--
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: xHCI problem? [was Re: Erratic USB device behavior and device loss]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Alan, On Tue, 2016-09-20 at 10:16 -0400, Alan Stern wrote: > This is a lot better. No more I/O errors. > > We still have irregular suspends and resumes, but that's to be > expected. More worrying are the spontaneous disconnects. They don't > seem to be related to the suspend/resume activity. > > You can disable suspend for this device entirely by doing: > > echo on >/sys/bus/usb/devices/2-4/power/control > Yes. But that'd also mean to write that value upon every suspend/resume cycle because the rtsx usb driver still declares support for autosuspend. Should that be dropped ? > I'm afraid that this won't prevent the device from disconnecting > itself, though. This appears to be some sort of hardware bug that > can't be fixed in software. And that'd mean that upon every reset, the driver will again enable autosuspend for that driver. It is an upsetting state for this device but thank you, to all of you, for helping debug this problem. - -- RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX4VLyAAoJEKY6WKPy4XVprEgQAKdYcFIF1ICNGHkF+oyDe1VY DqyxTa0vLPbXWsG6GaV4Jdwld+gVKiWIVNKxbLpboBHj/vj0bkzoPJ0z4xI+Oc8p bu6T5Io6nAaegdGa6XvYIAXk1fIlXEehBFVM6OyzC1EUJAjgYhIDVlG8mqZKxqVp GGsX1e5UFdS0vCqjYqSxI5IHrqsm1M4lXuwr8ia66qyuSfpg8trizLiWrdiEa7hv hRtI81XxITvVJ4+2ernO6Y+RO/z6WQLs1SAhXvDEH3RlYh/RoEBpolqMIO8LVWMK jd4GSsYmMKiG1eJJq3UYM+iPDANIIi4gdO0hf/24vNcsVa8eF5kcKT+bxufRaiB/ 5TzZS0RARBdq1+N6bK/wF8lDL4bWy4Sl1mts/dXJaCOlOoLeQ/u/J55K58mDJb2O gdvEvzD/S9NNeawL2ow4sxaM8EBpeyJtBTyVIbLJVFmetauVs+ClI0uLoNMW/N+u qMDE8yhiey4ClXa0WmVZHN4qjfNAnW4OSMtrq8+TLa1yhVj/ONNBo8QkfjuKBHwE ELDrX3/N9JsZo6ZX0CPNVhodvck8ZVKrk8w3jAlcqQ0FlJy5MMFoqGEvqJ1EIfNv IQ5FKrI08RIA7yw6keTy3nybzyY3MhepLJWxiEVyKRCopiHk96DmEGJmOmor7VIQ hjgbpCikJ7sXPcn0n97u =DBja -END PGP SIGNATURE- -- 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] extcon: usb-gpio: Add VBUS detection support
Driver can now work with both ID and VBUS pins or either one of
them.
There can be the following 3 cases
1) Both ID and VBUS GPIOs are available:
ID = LOW -> USB_HOST active, USB inactive
ID = HIGH -> USB_HOST inactive, USB state is same as VBUS.
2) Only ID GPIO is available:
ID = LOW -> USB_HOST active, USB inactive
ID = HIGH -> USB_HOST inactive, USB active
3) Only VBUS GPIO is available:
VBUS = LOW -> USB_HOST inactive, USB inactive
VBUS = HIGH -> USB_HOST inactive, USB active
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +
drivers/extcon/extcon-usb-gpio.c | 169 -
2 files changed, 132 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
index af0b903..dfc14f7 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -5,7 +5,10 @@ connected to a GPIO pin.
Required properties:
- compatible: Should be "linux,extcon-usb-gpio"
+
+Either one of id-gpio or vbus-gpio must be present. Both can be present as
well.
- id-gpio: gpio for USB ID pin. See gpio binding.
+- vbus-gpio: gpio for USB VBUS pin.
Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
extcon_usb1 {
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index a27d350..d589c5f 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -36,7 +35,9 @@ struct usb_extcon_info {
struct extcon_dev *edev;
struct gpio_desc *id_gpiod;
+ struct gpio_desc *vbus_gpiod;
int id_irq;
+ int vbus_irq;
unsigned long debounce_jiffies;
struct delayed_work wq_detcable;
@@ -48,31 +49,47 @@ static const unsigned int usb_extcon_cable[] = {
EXTCON_NONE,
};
+/*
+ * "USB" = VBUS and "USB-HOST" = !ID, so we have:
+ * Both "USB" and "USB-HOST" can't be set as active at the
+ * same time so if "USB-HOST" is active (i.e. ID is 0) we keep "USB" inactive
+ * even if VBUS is on.
+ *
+ * State |ID | VBUS
+ *
+ * [1] USB|H|H
+ * [2] none |H|L
+ * [3] USB-HOST |L|H
+ * [4] USB-HOST |L|L
+ *
+ * In case we have only one of these signals:
+ * - VBUS only - we want to distinguish between [1] and [2], so ID is always 1.
+ * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
+*/
static void usb_extcon_detect_cable(struct work_struct *work)
{
- int id;
+ int id, vbus;
struct usb_extcon_info *info = container_of(to_delayed_work(work),
struct usb_extcon_info,
wq_detcable);
- /* check ID and update cable state */
- id = gpiod_get_value_cansleep(info->id_gpiod);
- if (id) {
- /*
-* ID = 1 means USB HOST cable detached.
-* As we don't have event for USB peripheral cable attached,
-* we simulate USB peripheral attach here.
-*/
+ /* check ID and VBUS and update cable state */
+ id = info->id_gpiod ?
+ gpiod_get_value_cansleep(info->id_gpiod) : 1;
+ vbus = info->vbus_gpiod ?
+ gpiod_get_value_cansleep(info->vbus_gpiod) : id;
+
+ /* at first we clean states which are no longer active */
+ if (id)
extcon_set_state_sync(info->edev, EXTCON_USB_HOST, false);
- extcon_set_state_sync(info->edev, EXTCON_USB, true);
- } else {
- /*
-* ID = 0 means USB HOST cable attached.
-* As we don't have event for USB peripheral cable detached,
-* we simulate USB peripheral detach here.
-*/
+ if (!vbus)
extcon_set_state_sync(info->edev, EXTCON_USB, false);
+
+ if (!id) {
extcon_set_state_sync(info->edev, EXTCON_USB_HOST, true);
+ } else {
+ if (vbus)
+ extcon_set_state_sync(info->edev, EXTCON_USB, true);
}
}
@@ -101,12 +118,21 @@ static int usb_extcon_probe(struct platform_device *pdev)
return -ENOMEM;
info->dev = dev;
- info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
- if (IS_ERR(info->id_gpiod)) {
- dev_err(dev, "failed to get ID GPIO\n");
- return PTR_ERR(info->id_gpiod);
+ info->id_gpiod = devm_gpiod_get_optional(&pdev->dev, "id", GPIOD_IN);
+ info->vbus_gpiod = devm_gpiod_get_optional(&pdev->dev, "vbus",
+
Re: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, Sep 20, 2016 at 3:45 PM, Carsten Mattner wrote: > On Tue, Sep 20, 2016 at 2:36 PM, Oliver Neukum wrote: >> On Tue, 2016-09-20 at 14:11 +0200, Carsten Mattner wrote: >>> 4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report >>> this >>> warning or error (cannot tell) anytime a USB mass storage device is inserted >>> into a usb port (2.0 or 3.0): >>> >>> runtime PM trying to activate child device host6 but parent >>> (2-1.2:1.0) is not active >> >> I see no obvious culprit. Could you bisect? > > I need the machine for so cannot do too many compile and reboot > cycles, but I've confirmed that the error message is triggered back > in 4.8-rc2. > > No such thing in 4.7.4 and I'm now back in lts-4.7.4 to get work done. I meant 4.7.4 and lts-4.4.21. -- 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: Memory barrier needed with wake_up_process()?
On Tue, 20 Sep 2016, Felipe Balbi wrote:
> And here's trace output (complete, scroll to bottom). It seems to me
> like the thread didn't wake up at all. It didn't even try to
> execute. I'll add some more traces and try to get better information
> about what's going on.
>
>
>
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 2865/2865 #P:4
> #
> # _-=> irqs-off
> # / _=> need-resched
> #| / _---=> hardirq/softirq
> #|| / _--=> preempt-depth
> #||| / delay
> # TASK-PID CPU# TIMESTAMP FUNCTION
> # | | | | |
Skipping to the end...
> irq/17-dwc3-2522 [002] d...43.504199: bulk_out_complete: 0, 31/31
> file-storage-2521 [001] 43.504202: fsg_main_thread:
> get_next_command -> 0
> file-storage-2521 [001] 43.504288: fsg_main_thread:
> do_scsi_command -> 0
> file-storage-2521 [001] 43.504295: fsg_main_thread: finish_reply
> -> 0
> file-storage-2521 [001] 43.504298: fsg_main_thread: send_status
> -> 0
> irq/17-dwc3-2522 [002] d...43.504347: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504351: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504434: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504438: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504535: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504539: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504618: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504703: bulk_in_complete: 0,
> 16384/16384
> irq/17-dwc3-2522 [002] d...43.504794: bulk_in_complete: 0, 13/13
> irq/17-dwc3-2522 [002] d...43.504797: bulk_out_complete: 0, 31/31
Like you say, it appears that the thread didn't get woken up at all.
But this is inconsistent with your earlier results. On Sep. 9, you
posted a message that ended with these lines:
> irq/17-dwc3-3579 [003] d..1 21167.729666: bulk_out_complete: compl: bh
> 880111e6aac0 state 1
> file-storage-3578 [002] 21167.729670: fsg_main_thread: next: bh
> 880111e6aac0 state 1
This indicates that in the earlier test, the thread did start running
and get_next_command should have returned.
The trace you posted after this one doesn't seem to show anything new,
as far as I can tell.
So I still can't tell what's happening. Maybe the patch below will
help. It concentrates on the critical area.
Alan Stern
Index: usb-4.x/drivers/usb/gadget/function/f_mass_storage.c
===
--- usb-4.x.orig/drivers/usb/gadget/function/f_mass_storage.c
+++ usb-4.x/drivers/usb/gadget/function/f_mass_storage.c
@@ -402,8 +402,12 @@ static void wakeup_thread(struct fsg_com
smp_wmb(); /* ensure the write of bh->state is complete */
/* Tell the main thread that something has happened */
common->thread_wakeup_needed = 1;
- if (common->thread_task)
- wake_up_process(common->thread_task);
+ if (common->thread_task) {
+ if (wake_up_process(common->thread_task))
+ trace_printk("wakeup_thread 1\n");
+ else
+ trace_printk("wakeup_thread 0\n");
+ }
}
static void raise_exception(struct fsg_common *common, enum fsg_state
new_state)
@@ -479,6 +483,8 @@ static void bulk_out_complete(struct usb
req->status, req->actual, bh->bulk_out_intended_length);
if (req->status == -ECONNRESET) /* Request was cancelled */
usb_ep_fifo_flush(ep);
+ trace_printk("bulk_out: %d, %u/%u\n", req->status, req->actual,
+ bh->bulk_out_intended_length);
/* Hold the lock while we update the request and buffer states */
smp_wmb();
@@ -2204,13 +2210,17 @@ static int get_next_command(struct fsg_c
/* Wait for the CBW to arrive */
while (bh->state != BUF_STATE_FULL) {
+ trace_printk("get_next: sleep\n");
rc = sleep_thread(common, true);
+ trace_printk("get_next: sleep -> %d loop %d\n",
+ rc, bh->state != BUF_STATE_FULL);
if (rc)
return rc;
}
smp_rmb();
rc = fsg_is_set(common) ? received_cbw(common->fsg, bh) : -EIO;
bh->state = BUF_STATE_EMPTY;
+ trace_printk("get_next: return %d\n", rc);
return rc;
}
--
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
Re: [PATCHv2] usb: musb: Fix unbalanced platform_disable
* Andreas Kemnade [160919 22:05]: > On Mon, 19 Sep 2016 09:02:50 -0700 > Tony Lindgren wrote: > > > * Andreas Kemnade [160918 23:00]: > > > On Sun, 18 Sep 2016 08:19:02 -0700 > > > Tony Lindgren wrote: > > > > > > > * Laurent Pinchart [160918 > > > > 05:13]: > > > > > > > > > > FYI, while this patch allows me to boot my Panda board with NFS > > > > > over usbnet, it only works with cold boots. A warm reboot > > > > > results in the following warning, and no ethernet traffic going > > > > > through. The USB device is detected by the host though. > > > > > > > > Yeah I noticed too that we still have issues. For example doing > > > > rmmod of omap2430 with gadget configured and connected will > > > > produce a hardirq-safe hardirq-unsafe lock order error. That also > > > > happens with reboot with gadget configured and connected. > > > > > > > hmm, well, there is a musb_platform_disable() in musb_remove() > > > which is simply superfluous... > > > Some days ago we had a locking problem with musb_start() and moved > > > it out of the locked area. Maybe we could do also something similar > > > here. > > > > Well I don't think we can do that safely at this point because we > > have unpaired calls to musb_start() and musb_stop(). So trying to > > make musb_platform_enable/disable() paired right now will just lead > > into mystery breakage in various use cases. > > > I am primarily talking about > doing things like the patch > usb: musb: Fix locking errors for host only mode > 2c5575401e34de3d2f > > did for musb_start(), for musb_stop() also. Yeah I know, but that is really just trying to plug holes. The real long term fix seems to to be something like: 1. Add musb_try_start_session/stop_session() that can be called multiple times unpaired and only tinker with the devctl register 2. Make musb_start/stop() paired for the hardware specific init 3. This allows making musb_platform_enable/disable() paired too But for now, we still have issues in v4.8-rc cycle, so let's get that fixed first. Regards, Tony -- 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 2/6] Documentation: dt-bindings: Add documentation for the Meson USB2 PHYs
On Sun, Sep 11, 2016 at 03:41:07PM +0200, Martin Blumenstingl wrote:
> Add the documentation for the bindings for the Meson8b and GXBB USB2
> PHYs.
>
> Signed-off-by: Martin Blumenstingl
> ---
> .../devicetree/bindings/phy/meson-usb2-phy.txt | 27
> ++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> new file mode 100644
> index 000..9da5ea2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/meson-usb2-phy.txt
> @@ -0,0 +1,27 @@
> +* Amlogic USB2 PHY
> +
> +Required properties:
> +- compatible:Depending on the platform this should be one of:
> + "amlogic,meson8b-usb2-phy"
> + "amlogic,meson-gxbb-usb2-phy"
> +- reg: The base address and length of the registers
> +- #phys-cells: should be 0 (see phy-bindings.txt in this directory)
> +- clocks:phandle and clock identifier for the phy clocks
> +- clock-names: "usb_general" and "usb"
> +
> +Optional properties:
> +- resets:reference to the reset controller
> +- phy-supply:see phy-bindings.txt in this directory
> +
> +
> +Example:
> +
> +usb0_phy: usb_phy@0 {
usb-phy@0
With that,
Acked-by: Rob Herring
> + compatible = "amlogic,meson-gxbb-usb2-phy";
> + #phy-cells = <0>;
> + reg = <0x0 0x0 0x0 0x20>;
> + resets = <&reset RESET_USB_OTG>;
> + clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>;
> + clock-names = "usb_general", "usb";
> + phy-supply = <&usb_vbus>;
> +};
> --
> 2.9.3
>
--
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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
On Tue, 20 Sep 2016, Oliver Neukum wrote: > On Mon, 2016-09-19 at 14:02 -0400, Alan Stern wrote: > > > We can for sure enable autosuspend for the sdmmc device, although as > > > soon as an SD card will be detected the rtsx driver will increase > > the > > > runtime PM usage count. The count is decreased when the card is > > > removed (or failed to be initialized), thus runtime suspend is > > > prevented as long as there is a functional card inserted. > > Testing autosuspend with card readers on usb_storage I saw a uniform > response of reporting a medium change event upon resume. > I am afraid other kinds of readers are not better in that regard. That shouldn't be an issue in this case, at least, not with the current code. The sdmmc and memstick drivers block autosuspend if media is present. > > Which means that autosuspend matters only when a card isn't present, > > and the host is polled every second or so to see whether a card has > > been inserted. > > > > Under those circumstances you probably don't want to use > > autosuspend. > > That is, resuming before each poll and suspending afterward may use > > less energy than staying at full power all the time. > > Is that based on concrete figures about power consumption? No. > And it seems to me that we need a way to indicate that the heuristics > should not be used, but a device immediately suspended. The timer > is sensible only if the next wakeup is unknown. The driver can always turn off autosuspend if it wants to. Alan Stern -- 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/6] usb: dwc2: add support for Meson8b and GXBB SoCs
On Sun, Sep 11, 2016 at 03:41:06PM +0200, Martin Blumenstingl wrote: > From: Jerome Brunet > > Add compatible strings for amlogic Meson8b and GXBB SoCs with the > corresponding configuration parameters. > > Signed-off-by: Jerome Brunet > Signed-off-by: Martin Blumenstingl > --- > Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++ Acked-by: Rob Herring > drivers/usb/dwc2/platform.c| 34 > ++ > 2 files changed, 36 insertions(+) -- 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: xHCI problem? [was Re: Erratic USB device behavior and device loss]
On Tue, 20 Sep 2016, Ritesh Raj Sarraf wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Mon, 2016-09-19 at 13:48 -0400, Alan Stern wrote: > > > > This ought to help. Ritesh, please apply this patch on top of the > > two earlier ones and let's see what happens. > > > > Alan Stern > > > > > > Please find the logs at the following links. On this boot, I did not see any > kernel stack being printed. > > https://people.debian.org/~rrs/tmp/4.8.0-rc7ulf1alan2+.kern.log > https://people.debian.org/~rrs/tmp/usb-4.8.0-rc7ulf1alan2+.log This is a lot better. No more I/O errors. We still have irregular suspends and resumes, but that's to be expected. More worrying are the spontaneous disconnects. They don't seem to be related to the suspend/resume activity. You can disable suspend for this device entirely by doing: echo on >/sys/bus/usb/devices/2-4/power/control I'm afraid that this won't prevent the device from disconnecting itself, though. This appears to be some sort of hardware bug that can't be fixed in software. Alan Stern -- 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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
On Tue, 20 Sep 2016, Ulf Hansson wrote: > >> I am wondering what you think would be a good autosuspend timeout in > >> this case? It seems to me that the only thing the rtsx driver really > >> care about is to tell the parent device that it needs to be runtime > >> resumed during a certain timeframe, more or less it would like to > >> inherit the parents settings. > >> > >> Other mmc hosts, not being usb-mmc devices, are using an autosuspend > >> timeout of ~50-100ms but that doesn't seem like good value here, > >> right? > > > > Well, if you decide to let the device go into runtime suspend between > > polls then there's no reason to use autosuspend at all. Once a poll > > has ended, you know there won't be any more activity until the next > > poll. > > We could change that, as currently the approach in the mmc core isn't > that sophisticated. I even think this has been discussed earlier for > the very similar reasons regards polling card detect mode. > > I guess the main reason to why we yet have changed this, is because > mmc host drivers are using an autosuspend timeout of ~50-100 ms, so in > the end it haven't been such a big deal. No, it isn't. Although at a polling interval of 1 second, it means reducing the low-power time by as much as 10%. > > On the other hand, if you decide to keep the device at full power all > > the time during polling, then any autosuspend timeout larger than 1000 > > ms would do what you want. > > > > Mostly I'm concerned about how this will interact with the USB runtime > > PM. The thing is, suspending the sdmmc device doesn't save any energy, > > whereas suspending the USB device does. > > Yes, I agree. > > My concern is also 2s autosuspend timeout which is set for the usb > device. Somehow I feel we need to be able "share" more information > between a parent-child relationship, in this case between the sdmmc > device and the usb device. I agree, but it's not clear how this should be done. One easy solution would be to turn off USB autosuspend and do all the runtime-PM management in the sdmmc and memstick drivers. > An observation I made, is when the sdmmc device gets runtime resumed > (pm_runtime_get_sync()), the parent device (the usb device) may also > become runtime resumed (unless it's already). In this sequence, but > *only* when actually runtime resuming the usb device, the runtime PM > core decides to update the last busy mark for the usb device. Should > it really do that? Yes, that's deliberate. The whole idea of autosuspend is to prevent the device from being runtime-suspended too soon after it was used, and the PM core considers runtime-resume to be a form of usage. > Moreover, I am curious about the 2s usb timeout. Why isn't that chosen > to something like ~100ms instead? Is there is a long latency to > runtime resume the usb device or because we fear to wear out the HW, > which may be powered on/off too frequently? When I first implemented runtime PM for the USB stack, I had to choose a autosuspend timeout. Not having any basis for such a choice, and figuring that a suspend-resume cycle takes around 100 ms, I decided that 2 seconds would be a reasonable value. But it's just a default; drivers and userspace can change it whenever they want. > If we assume that the usb device shouldn't be used with a timeout less > than 2s, then I think we have two options: > > *) As the mmc polling timeout is 1s, there is really no point in > trying to runtime suspend the usb device, it may just be left runtime > resumed all the time. Wasting power, of course! Or we can decrease the USB autosuspend delay to 100 ms. > **) Add an interface to allow dynamically changes of the mmc polling > timeout to better suit the current user. Note that the block layer does its own polling for removable media, and it already has a sysfs interface to control the polling interval (or disable it entirely). But I don't know how the MMC stack interacts with the block layer. One awkward point is that the sdmmc and memstick drivers each do their own polling. This is a waste. You can see it in the usbmon trace; every second there are two query-response interactions. Even if there's no good way to reduce the number, we should at least try to synchronize the polls so that the device doesn't need to be resumed twice every second. Alan Stern -- 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: [RESEND PATCH 0/4] usb: early: add support for early printk through USB3 debug port
On 29.08.2016 08:26, 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. This is the resend version. Original patch set was submitted several months ago. This resend version addresses the review comment here [1]. [1] https://lkml.org/lkml/2016/2/16/444 So other than making sure memory is freed, (and maybe cleanup the duplicate code) I don't really have any objections. As you state in PATCH 1/4, this could be useful in the specific case of kernel debugging when machine crashes very early before the console code is initialized. For normal operation it is not recommended. And as it's not recommended or used for normal operations it shouldn't do any harm either -Mathias -- 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: [RESEND PATCH 1/4] usb: dbc: early driver for xhci debug capability
On 29.08.2016 08:26, 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 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 xHCI host. There isn't any precondition from
xHCI host side for DbC to work.
This patch also includes bulk out and bulk in interfaces.
These interfaces could be used to implement early printk
bootconsole or hook to various system debuggers.
This code is designed to be only used for kernel debugging
when machine crashes very early before the console code is
initialized. For normal operation it is not recommended.
Cc: Mathias Nyman
Signed-off-by: Lu Baolu
---
Some comments inline
+
+#ifdef XDBC_TRACE
+#definexdbc_trace trace_printk
+#else
+static inline void xdbc_trace(const char *fmt, ...) { }
+#endif /* XDBC_TRACE */
I guess there's probably no better way to enable/disable debug messages for this
driver this early, and ehci-dbgp does the same.
So I guess It's ok, but it still looks weird
+
+static void xdbc_early_delay(unsigned long count)
+{
+ u8 val;
+
+ val = inb(0x80);
+ while (count-- > 0)
+ outb(val, 0x80);
+}
+
+static void xdbc_runtime_delay(unsigned long count)
+{
+ udelay(count);
+}
+
Glad to see the addition of this runtime_delay in addition
to the hack of reading port 0x80 for a 1us delay.
And that the early_delay is only used for as long as it must.
+static int xdbc_handle_external_reset(void)
+{
+ u32 ctrl;
+ int ret;
+
+ writel(0, &xdbc.xdbc_reg->control);
+ ret = handshake(&xdbc.xdbc_reg->control, CTRL_DCE, 0, 10, 10);
+ if (ret)
+ return ret;
+
+ xdbc_mem_init();
+ mmiowb();
+
+ ctrl = readl(&xdbc.xdbc_reg->control);
+ writel(ctrl | CTRL_DCE | CTRL_PED, &xdbc.xdbc_reg->control);
+ ret = handshake(&xdbc.xdbc_reg->control,
+ CTRL_DCE, CTRL_DCE, 10, 10);
+ if (ret)
+ return ret;
+
+ if (xdbc.vendor == PCI_VENDOR_ID_INTEL)
+ xdbc_do_reset_debug_port(xdbc.port_number, 1);
+
+ /* wait for port connection */
+ ret = handshake(&xdbc.xdbc_reg->portsc,
+ PORTSC_CCS, PORTSC_CCS, 500, 10);
+ if (ret)
+ return ret;
+
+ /* wait for debug device to be configured */
+ ret = handshake(&xdbc.xdbc_reg->control,
+ CTRL_DCR, CTRL_DCR, 500, 10);
+ if (ret)
+ return ret;
+
+ xdbc.flags |= XDBC_FLAGS_INITIALIZED | XDBC_FLAGS_CONFIGURED;
+
+ xdbc_bulk_transfer(NULL, XDBC_MAX_PACKET, true);
+
+ return 0;
+}
+
...
+static int __init xdbc_early_start(void)
+{
+ u32 ctrl, status;
+ int ret;
+
+ ctrl = readl(&xdbc.xdbc_reg->control);
+ writel(ctrl | CTRL_DCE | CTRL_PED, &xdbc.xdbc_reg->control);
+ ret = handshake(&xdbc.xdbc_reg->control,
+ CTRL_DCE, CTRL_DCE, 10, 100);
+ if (ret) {
+ pr_notice("falied to initialize hardware\n");
+ return ret;
+ }
+
+ /* reset port to avoid bus hang */
+ if (xdbc.vendor == PCI_VENDOR_ID_INTEL)
+ xdbc_reset_debug_port();
+
+ /* wait for port connection */
+ ret = handshake(&xdbc.xdbc_reg->portsc,
+ PORTSC_CCS, PORTSC_CCS, 500, 100);
+ if (ret) {
+ pr_notice("waiting for connection timed out\n");
+ return ret;
+ }
+
+ /* wait for debug device to be configured */
+ ret = handshake(&xdbc.xdbc_reg->control,
+ CTRL_DCR, CTRL_DCR, 500, 100);
+ if (ret) {
+ pr_notice("waiting for device configuration timed out\n");
+ return ret;
+ }
+
+ /* port should have a valid port# */
+ status = readl(&xdbc.xdbc_reg->status);
+ if (!DCST_DPN(status)) {
+ pr_notice("invalid root hub port number\n");
+ return -ENODEV;
+ }
+
+ xdbc.port_number = DCST_DPN(status);
+
+ pr_notice("DbC is running now, control 0x%08x port ID %d\n",
+ readl(&xdbc.xdbc_reg->control), xdbc.port_number);
+
+ return 0;
+}
xdbc_early_start() and xdbc_handle_external_reset() have a lot of duplicate code
, checking DCE, resetting the port, wait for CCE and wait for DC
[PATCH] cdc-acm: hardening against malicious devices
This should fix the last holes against malicious devices
still open in cdc-acm. It cannot go into stable due to
the introduction of the common parser.
The fix for stable already merged also covers the problems this patch
fixes.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 15ffe38..78f0f85 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1179,6 +1179,9 @@ static int acm_probe(struct usb_interface *intf,
return -EINVAL;
}
+ if (!intf->cur_altsetting)
+ return -EINVAL;
+
if (!buflen) {
if (intf->cur_altsetting->endpoint &&
intf->cur_altsetting->endpoint->extralen &&
@@ -1232,6 +1235,8 @@ static int acm_probe(struct usb_interface *intf,
dev_dbg(&intf->dev, "no interfaces\n");
return -ENODEV;
}
+ if (!data_interface->cur_altsetting ||
!control_interface->cur_altsetting)
+ return -ENODEV;
if (data_intf_num != call_intf_num)
dev_dbg(&intf->dev, "Separate call control interface. That is
not fully supported.\n");
--
2.6.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
Re: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, Sep 20, 2016 at 2:36 PM, Oliver Neukum wrote: > On Tue, 2016-09-20 at 14:11 +0200, Carsten Mattner wrote: >> 4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report >> this >> warning or error (cannot tell) anytime a USB mass storage device is inserted >> into a usb port (2.0 or 3.0): >> >> runtime PM trying to activate child device host6 but parent >> (2-1.2:1.0) is not active > > I see no obvious culprit. Could you bisect? I need the machine for so cannot do too many compile and reboot cycles, but I've confirmed that the error message is triggered back in 4.8-rc2. No such thing in 4.7.4 and I'm now back in lts-4.7.4 to get work done. -- 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: crash by cdc_acm driver in kernels 4.8-rc1/5
On Mon, 2016-09-12 at 04:43 +0200, Wim Osterholt wrote: > > A laptop, more broken than the rest, does not output anything after > inserting. Later on it crashes. No system.map file in /boot. > After booting with the dongle inserted it spits out: I cannot replicate it. Could you please provide "lsusb -v"? Regards Oliver -- 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: Memory barrier needed with wake_up_process()?
Hi,
Felipe Balbi writes:
> [ Unknown signature status ]
>
> Hi,
>
> Alan Stern writes:
>
> [...]
>
>>> $ grep -RnH "raise_exception\|fsg_main_thread" /tmp/trace.txt
>>> /tmp/trace.txt:111743: irq/17-dwc3-3527 [003] d..164.833078:
>>> raise_exception: raise_exception 4
>>> /tmp/trace.txt:111745:file-storage-3526 [002] 64.833139:
>>> fsg_main_thread: get_next_command -> -4
>>> /tmp/trace.txt:111746:file-storage-3526 [002] 64.833140:
>>> fsg_main_thread: handling exception
>>> /tmp/trace.txt:112950: irq/17-dwc3-3527 [003] d..164.951349:
>>> raise_exception: raise_exception 4
>>> /tmp/trace.txt:112956:file-storage-3526 [002] 64.951401:
>>> fsg_main_thread: handling exception
>>>
>>> Any ideas?
>>
>> I'm afraid not. The only thing I can think of to try next is complete
>> tracing of fsg_main_thread, as in the patch below. It will generate
>> continuous output as long as the gadget is doing something, but there
>> doesn't seem to be any way to avoid this. At least when everything
>> stops, it should be able to tell us exactly where and why.
>
> tried with your changes plus a trace_printk() added to both
> bulk_out_complete and bulk_in_complete. Here's the diff:
another version of diff and logs. Any ideas of what could be going on?
(full trace compressed and attached)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 8f3659b65f53..de0a9ebe7f61 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -395,11 +395,24 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct
usb_ep *ep)
/* Caller must hold fsg->lock */
static void wakeup_thread(struct fsg_common *common)
{
+ struct task_struct *p = common->thread_task;
+
smp_wmb(); /* ensure the write of bh->state is complete */
/* Tell the main thread that something has happened */
common->thread_wakeup_needed = 1;
- if (common->thread_task)
- wake_up_process(common->thread_task);
+
+ trace_printk("wkup needed %d task %p [comm=%s pid=%d prio=%d
target_cpu=%03d on_rq %d state %lx]\n",
+ common->thread_wakeup_needed, p, p->comm, p->pid,
+ p->prio, task_cpu(p), p->on_rq, p->state);
+
+ if (common->thread_task) {
+ int rc;
+ rc = wake_up_process(common->thread_task);
+ if (rc)
+ trace_printk("thread_task woken up\n");
+ else
+ trace_printk("NOT woken up\n");
+ }
}
static void raise_exception(struct fsg_common *common, enum fsg_state
new_state)
@@ -411,6 +424,7 @@ static void raise_exception(struct fsg_common *common, enum
fsg_state new_state)
* If a lower-or-equal priority exception is in progress, preempt it
* and notify the main thread by sending it a signal.
*/
+ trace_printk("raise_exception %d\n", new_state);
spin_lock_irqsave(&common->lock, flags);
if (common->state <= new_state) {
common->exception_req_tag = common->ep0_req_tag;
@@ -449,6 +463,8 @@ static void bulk_in_complete(struct usb_ep *ep, struct
usb_request *req)
struct fsg_common *common = ep->driver_data;
struct fsg_buffhd *bh = req->context;
+ trace_printk("%d, %u/%u\n", req->status, req->actual, req->length);
+
if (req->status || req->actual != req->length)
DBG(common, "%s --> %d, %u/%u\n", __func__,
req->status, req->actual, req->length);
@@ -470,6 +486,8 @@ static void bulk_out_complete(struct usb_ep *ep, struct
usb_request *req)
struct fsg_buffhd *bh = req->context;
dump_msg(common, "bulk-out", req->buf, req->actual);
+
+ trace_printk("%d, %u/%u\n", req->status, req->actual,
bh->bulk_out_intended_length);
if (req->status || req->actual != bh->bulk_out_intended_length)
DBG(common, "%s --> %d, %u/%u\n", __func__,
req->status, req->actual, bh->bulk_out_intended_length);
@@ -573,6 +591,10 @@ static void start_transfer(struct fsg_dev *fsg, struct
usb_ep *ep,
spin_unlock_irq(&fsg->common->lock);
rc = usb_ep_queue(ep, req, GFP_KERNEL);
+
+ trace_printk("%d: %s: req %u bytes state %d ---> %d\n", __LINE__,
ep->name,
+ req->length, *state, rc);
+
if (rc == 0)
return; /* All good, we're done */
@@ -2496,6 +2518,7 @@ static void handle_exception(struct fsg_common *common)
static int fsg_main_thread(void *common_)
{
struct fsg_common *common = common_;
+ int rc;
/*
* Allow the thread to be killed by a signal, but set the signal mask
@@ -2519,6 +2542,7 @@ static int fsg_main_thread(void *common_)
/* The main loop */
while (common->sta
Re: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, 2016-09-20 at 14:11 +0200, Carsten Mattner wrote: > 4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report > this > warning or error (cannot tell) anytime a USB mass storage device is inserted > into a usb port (2.0 or 3.0): > > runtime PM trying to activate child device host6 but parent > (2-1.2:1.0) is not active I see no obvious culprit. Could you bisect? Regards Oliver -- 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: xHCI problem? [was Re: Erratic USB device behavior and device loss]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2016-09-19 at 13:48 -0400, Alan Stern wrote:
>
> This ought to help. Ritesh, please apply this patch on top of the
> two earlier ones and let's see what happens.
>
> Alan Stern
>
>
Please find the logs at the following links. On this boot, I did not see any
kernel stack being printed.
https://people.debian.org/~rrs/tmp/4.8.0-rc7ulf1alan2+.kern.log
https://people.debian.org/~rrs/tmp/usb-4.8.0-rc7ulf1alan2+.log
>
> Index: usb-4.x/drivers/memstick/host/rtsx_usb_ms.c
> ===
> --- usb-4.x.orig/drivers/memstick/host/rtsx_usb_ms.c
> +++ usb-4.x/drivers/memstick/host/rtsx_usb_ms.c
> @@ -681,6 +681,7 @@ static int rtsx_usb_detect_ms_card(void
> int err;
>
> for (;;) {
> + pm_runtime_get_sync(ms_dev(host));
> mutex_lock(&ucr->dev_mutex);
>
> /* Check pending MS card changes */
> @@ -703,6 +704,7 @@ static int rtsx_usb_detect_ms_card(void
> }
>
> poll_again:
> + pm_runtime_put(ms_dev(host));
> if (host->eject)
> break;
>
- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJX4S1BAAoJEKY6WKPy4XVprAUP/jPnuxUAZ+6qKiCVx6qB69d+
wHQDkFOxmlTwTh5GyMa+oxEqvi0shvOKZ/ef7Oz0NA9DSiLonFw4aqSzF7jBRbee
UTKIgnNxHmJC6pdMPXWo5HVLBn6qYtX4pJFX6g1MwmjEDa9pjYWK9p7QzHkrx1GB
Z3X7TcWYk3DJS04GbFO9pMDl0P1phLR2VtnfzQwqtgF/g2fy7USpft1bYIQLQzxb
oOSAEDnTCtpurdAfLWq8OVQbL3rrf+HD3InVtdCZa+lwNSNwNfUZWnKKkS1S1tq+
hgKxvGOTEGunhm6Px6iQUCE9yxsvfmDK2GBxc/a3Tqpcy5ndZv/5laKFhXTt27pa
OuGksYgHCf2vWGHFuYHJH6cQKxgdsnnE7yGwbC8zYnrCT9O3hcLPxbVbzJorWFU0
YMNKt7RYZXrNQss9J4ufkTSLvzbUqsiYJwWH27LbQ5zHC7b9/ebgnMW6JIb1x+2p
iuz6MERvyxVxorG3R260GWSz/5SM/VVnTqzlRUnMHcVAyUHNGPGoqLu5LkrmI2VT
Zwcikip9G3fE79786eKF50X7dp2kU2p+W2bBmcJEWpWV9Vz5PiQdibsiu3CQilKc
QGxrKLp0OSsUvtwb4ceD/RWu7F99F7VCu3f/ohYYS2iciux5sFky+27GfY0fEJ2u
ikPpuK6xNWWSDgaNVVHD
=Nq4a
-END PGP SIGNATURE-
--
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: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, Sep 20, 2016 at 02:15:02PM +0200, Carsten Mattner wrote: > On Tue, Sep 20, 2016 at 2:11 PM, Carsten Mattner > wrote: > > 4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report > > this > > In hindsight, I'm not entirely certain if rc5 was fine, so please don't take > that as a fact. Can you try it out? Using 'git bisect' to track down the offending patch would be great if possible. 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: 4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
On Tue, Sep 20, 2016 at 2:11 PM, Carsten Mattner wrote: > 4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report > this In hindsight, I'm not entirely certain if rc5 was fine, so please don't take that as a fact. > warning or error (cannot tell) anytime a USB mass storage device is inserted > into a usb port (2.0 or 3.0): > > runtime PM trying to activate child device host6 but parent > (2-1.2:1.0) is not active > > The device appears to be working regardless. -- 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
4.8-rc: runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active
4.8-rc5 was fine, but 4.8-rc6 and 4.8-rc7 on a Lenovo Thinkpad x220 report this warning or error (cannot tell) anytime a USB mass storage device is inserted into a usb port (2.0 or 3.0): runtime PM trying to activate child device host6 but parent (2-1.2:1.0) is not active The device appears to be working regardless. -- 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: misc: legousbtower: Fix NULL pointer deference
On Tue, Sep 20, 2016 at 10:09:56AM +0100, James wrote: > Hi greg, > > Many appologies, I did not see your patch attached/forgot it existed > when I > fixed this yesterday. I created this patch based on your > feedback from my original email on September 2nd. I have tested this patch > with an emulated device and it fixes the vulnerability. > Again, applogies for the long delay and patch confusion. Heh, my feedback contained the patch itself, so it might have been hard to miss it :) Anyway, I'll queue this up later today, thanks for the report, and testing, much appreciated. 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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
On Mon, 2016-09-19 at 14:02 -0400, Alan Stern wrote: > > We can for sure enable autosuspend for the sdmmc device, although as > > soon as an SD card will be detected the rtsx driver will increase > the > > runtime PM usage count. The count is decreased when the card is > > removed (or failed to be initialized), thus runtime suspend is > > prevented as long as there is a functional card inserted. Testing autosuspend with card readers on usb_storage I saw a uniform response of reporting a medium change event upon resume. I am afraid other kinds of readers are not better in that regard. > > Which means that autosuspend matters only when a card isn't present, > and the host is polled every second or so to see whether a card has > been inserted. > > Under those circumstances you probably don't want to use > autosuspend. > That is, resuming before each poll and suspending afterward may use > less energy than staying at full power all the time. Is that based on concrete figures about power consumption? And it seems to me that we need a way to indicate that the heuristics should not be used, but a device immediately suspended. The timer is sensible only if the next wakeup is unknown. Regards Oliver -- 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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
On 19 September 2016 at 20:02, Alan Stern wrote: > On Mon, 19 Sep 2016, Ulf Hansson wrote: > >> On 18 September 2016 at 04:30, Alan Stern wrote: >> > On Sat, 17 Sep 2016, Ulf Hansson wrote: >> > >> >> Each access of the parent device (usb device) needs to be done in runtime >> >> resumed state. Currently this isn't case while changing the leds, so let's >> >> add pm_runtime_get_sync() and pm_runtime_put() around these calls. >> >> >> >> Signed-off-by: Ulf Hansson >> >> --- >> >> >> >> While discussing an issue[1] related to runtime PM, I found out that this >> >> minor change at least improves the behavior that has been observed. >> >> >> >> [1] >> >> http://www.spinics.net/lists/linux-usb/msg144634.html >> >> >> >> --- >> >> drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++ >> >> 1 file changed, 2 insertions(+) >> >> >> >> diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c >> >> b/drivers/mmc/host/rtsx_usb_sdmmc.c >> >> index 6c71fc9..a59c7fa 100644 >> >> --- a/drivers/mmc/host/rtsx_usb_sdmmc.c >> >> +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c >> >> @@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct >> >> *work) >> >> container_of(work, struct rtsx_usb_sdmmc, led_work); >> >> struct rtsx_ucr *ucr = host->ucr; >> >> >> >> + pm_runtime_get_sync(sdmmc_dev(host)); >> >> mutex_lock(&ucr->dev_mutex); >> >> >> >> if (host->led.brightness == LED_OFF) >> >> @@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct >> >> *work) >> >> rtsx_usb_turn_on_led(ucr); >> >> >> >> mutex_unlock(&ucr->dev_mutex); >> >> + pm_runtime_put(sdmmc_dev(host)); >> >> } >> >> #endif >> > >> > The missing aspect here is that this won't stop the parent USB device >> > from going into autosuspend every 2 seconds and then resuming shortly >> > afterward. There are two ways of preventing this: >> > >> > Call usb_mark_last_busy() at appropriate places. >> > >> > Enable autosuspend for the sdmmc device. >> > >> > The second approach would also prevent the sdmmc device from going into >> > autosuspend as soon as the LED update is finished. Maybe that's okay, >> > but if going into suspend is a lightweight procedure then you may want >> > to prevent it. >> > >> >> We can for sure enable autosuspend for the sdmmc device, although as >> soon as an SD card will be detected the rtsx driver will increase the >> runtime PM usage count. The count is decreased when the card is >> removed (or failed to be initialized), thus runtime suspend is >> prevented as long as there is a functional card inserted. > > Which means that autosuspend matters only when a card isn't present, > and the host is polled every second or so to see whether a card has > been inserted. > > Under those circumstances you probably don't want to use autosuspend. > That is, resuming before each poll and suspending afterward may use > less energy than staying at full power all the time. > >> I am wondering what you think would be a good autosuspend timeout in >> this case? It seems to me that the only thing the rtsx driver really >> care about is to tell the parent device that it needs to be runtime >> resumed during a certain timeframe, more or less it would like to >> inherit the parents settings. >> >> Other mmc hosts, not being usb-mmc devices, are using an autosuspend >> timeout of ~50-100ms but that doesn't seem like good value here, >> right? > > Well, if you decide to let the device go into runtime suspend between > polls then there's no reason to use autosuspend at all. Once a poll > has ended, you know there won't be any more activity until the next > poll. We could change that, as currently the approach in the mmc core isn't that sophisticated. I even think this has been discussed earlier for the very similar reasons regards polling card detect mode. I guess the main reason to why we yet have changed this, is because mmc host drivers are using an autosuspend timeout of ~50-100 ms, so in the end it haven't been such a big deal. > > On the other hand, if you decide to keep the device at full power all > the time during polling, then any autosuspend timeout larger than 1000 > ms would do what you want. > > Mostly I'm concerned about how this will interact with the USB runtime > PM. The thing is, suspending the sdmmc device doesn't save any energy, > whereas suspending the USB device does. Yes, I agree. My concern is also 2s autosuspend timeout which is set for the usb device. Somehow I feel we need to be able "share" more information between a parent-child relationship, in this case between the sdmmc device and the usb device. An observation I made, is when the sdmmc device gets runtime resumed (pm_runtime_get_sync()), the parent device (the usb device) may also become runtime resumed (unless it's already). In this sequence, but *only* when actually runtime resuming the usb device, the runtime PM core decides to update the last busy mark for the usb device. Shoul
Re: USB hot-plug not working (ASUS TP301UA-C4028T)
On Tue, 2016-09-20 at 20:58 +1200, Pierre de Villemereuil wrote: > Hi Oliver! > > Here you are. > > dmesg signals when plugging AC in: > http://paste.opensuse.org/57485b34 > > dmesg signals when unplugging AC: > http://paste.opensuse.org/5a8e9910 > > And just in case, dmesg signals when plugging a USB device when AC is plugged > in: > http://paste.opensuse.org/45faee84 > > Hope this helps! This looks like your XHCI is suspended when you unplug AC but remote wakeup is not operational. The problem looks specific to XHCI not USB in general. Time to add the XHCI maintainer. Mathias, hotplug on battery fails. The XHCI seems to fail to wake up if something is plugged into the root hub. Regards Oliver -- 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: misc: legousbtower: Fix NULL pointer deference
Hi greg, Many appologies, I did not see your patch attached/forgot it existed when I fixed this yesterday. I created this patch based on your feedback from my original email on September 2nd. I have tested this patch with an emulated device and it fixes the vulnerability. Again, applogies for the long delay and patch confusion. Best regards, James On Tue, Sep 20, 2016 at 10:32:56AM +0200, Greg KH wrote: On Tue, Sep 20, 2016 at 10:18:21AM +0200, Oliver Neukum wrote: On Tue, 2016-09-20 at 08:22 +0200, Greg KH wrote: > When you sent this the last time (back on Sept 2), I sent you a > "simpler" patch, the same one below, and asked you if that worked > instead. I never heard back, could you test this patch and see if it > resolves the issue for you? As far as I can tell, your patches are identical. Hah, so they are. James's original patch was not this one, sorry for not looking at it closer. James, any reason why you are passing off my patch as yours here? Did you test mine and see that this did solve the problem? You did change your changelog text a bit, to reflect the change between mine and yours, so I'm guessing that you did? thanks, greg k-h signature.asc Description: Digital signature
Re: USB hot-plug not working (ASUS TP301UA-C4028T)
Hi Oliver! Here you are. dmesg signals when plugging AC in: http://paste.opensuse.org/57485b34 dmesg signals when unplugging AC: http://paste.opensuse.org/5a8e9910 And just in case, dmesg signals when plugging a USB device when AC is plugged in: http://paste.opensuse.org/45faee84 Hope this helps! Cheers, Pierre. Le mardi 20 septembre 2016, 10:38:09 NZST Oliver Neukum a écrit : > On Tue, 2016-09-20 at 11:11 +1200, Pierre de Villemereuil wrote: > > Dear Oliver, > > > > Sorry about my last message, the bug is actually still going on. I found > > something interesting though: when AC is plugged, USB is working totally > > OK, but when on battery, then here comes trouble... Could this be power > > management? > > Yes, absolutely. > > > Below is my TLP config (mostly default) if it's any help: > > http://paste.opensuse.org/8168b819 > > > > I tried to disable USB-suspend: doesn't change anything. > > > > I cannot unload xhci_hcd module: > > # modprobe -r xhci_hcd > > modprobe: FATAL: Module xhci_hcd is in use. > > > > Something specific I should use? > > > > Also, after entering your command below to enhance debug, dmesg is still > > not showing anything when USB is plugged. Still, below is the output of > > dmesg when "udevadm trigger" is entered with a USB mouse plugged: > > http://paste.opensuse.org/325663de > > > > Hope this helps and sorry for the confusion with my last e-mail. > > OK, please make logs of connecting and disconnecting your system > from AC with XHCI debugging enabled and post them to this list. > > Regards > Oliver -- 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: cdc_acm bug? read buffer bytes shifted
On Fri, 2016-09-16 at 18:24 +0200, Julio Guerra wrote: > > On Sat, 2016-08-20 at 14:14 +0200, Julio Guerra wrote: > Another example: > > 00 00 00 00 00 00 00 01 > ... > > 01 00 00 00 00 00 00 00 > ... > > 00 01 00 00 00 00 00 00 > ... > > 00 00 01 00 00 00 00 00 > after a random number of times, while usbmon shows the usb payload > "00 00 00 00 00 00 00 01". > >>> > >>> Hi, how many bytes does read() return? > >>> > >> > >> Exactly 8 bytes, always. I set the tty in raw non-canonical mode with > >> vmin = 8 and vtime = 0. I also tried with vmin = 1 and did the copy of > >> exactly 8 bytes by looping in userspace, without any improvement. > >> > >> I wrote a small workaround for now that detects this problem (because I > >> exactly know what the buffer is supposed to look like) to close() and > >> re-open() the device. The next read buffer is then correct. > >> > > > > Please activate dynamic debugging for the tty and cdc_acm driver. > > We need to know where the corruption happens. > > > > I didn't find anything helpful in /sys/kernel/debug/dynamic_debug > regarging the tty module (I enabled tty_io debugs and it doesn't appear > in the logs), but I enabled cdc_acm debugs. Nothing is observable in the > logs when the bug appears. I logged everything as a comment of the gist: > https://gist.github.com/Julio-Guerra/b6529994f814771c825649bdb8d927c2#gistcomment-1875985 > > Note that re-running the script restarts the underlying kernel buffer > correctly, it does not restart from its previous bugged state. > > Let me know if you want other debug traces enabled. > Can you modify the tty layer to print out the buffer? It is unclear from the logs where the shift happens. Regards Oliver -- 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 hot-plug not working (ASUS TP301UA-C4028T)
On Tue, 2016-09-20 at 11:11 +1200, Pierre de Villemereuil wrote: > Dear Oliver, > > Sorry about my last message, the bug is actually still going on. I found > something interesting though: when AC is plugged, USB is working totally OK, > but when on battery, then here comes trouble... Could this be power > management? Yes, absolutely. > Below is my TLP config (mostly default) if it's any help: > http://paste.opensuse.org/8168b819 > > I tried to disable USB-suspend: doesn't change anything. > > I cannot unload xhci_hcd module: > # modprobe -r xhci_hcd > modprobe: FATAL: Module xhci_hcd is in use. > > Something specific I should use? > > Also, after entering your command below to enhance debug, dmesg is still not > showing anything when USB is plugged. Still, below is the output of dmesg > when > "udevadm trigger" is entered with a USB mouse plugged: > http://paste.opensuse.org/325663de > > Hope this helps and sorry for the confusion with my last e-mail. OK, please make logs of connecting and disconnecting your system from AC with XHCI debugging enabled and post them to this list. Regards Oliver -- 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: misc: legousbtower: Fix NULL pointer deference
On Tue, Sep 20, 2016 at 10:18:21AM +0200, Oliver Neukum wrote: > On Tue, 2016-09-20 at 08:22 +0200, Greg KH wrote: > > When you sent this the last time (back on Sept 2), I sent you a > > "simpler" patch, the same one below, and asked you if that worked > > instead. I never heard back, could you test this patch and see if it > > resolves the issue for you? > > As far as I can tell, your patches are identical. Hah, so they are. James's original patch was not this one, sorry for not looking at it closer. James, any reason why you are passing off my patch as yours here? Did you test mine and see that this did solve the problem? You did change your changelog text a bit, to reflect the change between mine and yours, so I'm guessing that you did? 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: UAS and f_tcm -- is anyone using it?
Hi, John Youn writes: > There's also a TCM python tool somewhere which helps with this. I > haven't used f_tcm in a long while, but Sebastian and I used it long > back to test streams with dwc3. Have you tried it recently? Or do you know of anyone who has? >>> >>> Sebastian is the only one I know who has used this in the past. >>> >> Just from the code it seems there will be some fundamental issues with >> it, such as the value of maxpacket size and some alt-interface >> stuff. At least when used with DWC3. > > such as? I'll see if I can write up the exact issues later. I have to go back to my notes to remind myself. > > Ok, coming back to this uas gadget stuff. > > I've finally had a chance to go back to my notes. Here are some of the > concrete issues that I found, that I was able to workaround in some > way. > > * EP's for UAS alt-interface cannot be configured correctly because > the config_ep_for_speed() in composite.c does not take into account > alt-interfaces. This results in incorrectly configured EP in the > controller (no streaming enabled, wrong direction, etc). cool, that's a bug in composite.c which needs to be fixed. > * START_XFER command needs to enable streams bug in dwc3 which needs to be fixed. > * XFER_NOT_READY event needs to be enabled for streams bug in dwc3 which needs to be fixed :-) In any case, can you point me to section in documention which states Streams *requires* XFER_NOT_READY? > * For OUT EPs, the TCM/target framework sets receive buffers size as > 512 bytes. This cannot work in SUPERSPEED as you must always provide > at least MPS-sized buffers. This causes all writes to fail. I'm not that's a good point. TCM gadget should be checking for ep out aligned quirk flag. > sure how to properly fix this as it should be fixed at the function > driver level, and this size comes from the target framework. I put a > workaround at the controller-level. > > After addressing these issues, UAS read/write works to some extent. > But it is still unstable in ways that point to issues in the target > framework, things to do with locking/race conditions there. Alright, those are all bugs which need to be fixed. Certainly we don't need an entire new gadget just because you've found some bugs, right? We'd be much better off fixing these problems because then more folks would benefit from them. > Even the BOT interface does not work reliably. > > When I get a chance, I'll try to get everything running again rebased > on latest, then submit patches and bug reports. cool, thanks a lot. That'll help But just in trying to get it to work, these issues make me suspect no one is using this driver in superspeed, or at least regularly testing it, let alone using it in production. >>> >>> that's probably true, but it's not enough argument to have a duplicate >>> implementation of it :-) Rather, we should be figuring out what's broken >>> and fixing it. I have a ton of other stuff to be done, but I'll add this >>> to my queue, no issues. >>> > > Let me know if you make any progress on this. sure thing :-) If you got some notes on how, exactly, you got TCM running, I'd be happy to re-use them and try things out here. -- balbi signature.asc Description: PGP signature
Re: [RFC PATCH] xhci: do not halt the secondary HCD
On 19.09.2016 11:23, Joel Stanley wrote: Hi Mathias, On Mon, Sep 19, 2016 at 4:33 PM, Greg KH wrote: On Mon, Sep 19, 2016 at 04:05:45PM +0930, Joel Stanley wrote: We can't halt the secondary HCD, because it's also the primary HCD, which will cause problems if we have devices attached to the primary HCD, like a keyboard. We've been carrying this in our Linux-as-a-bootloader environment for a little while now. The machines all have the same TI TUSB73x0 part, and when we kexec the devices don't come back until a system power cycle. I'd like some advice on an acceptable way to upstream the fix, so that the xhci device survives kexec. Any reason you didn't cc: Mathias? Fat fingers - I missed him when grabbing names from get_maintainers. Thanks for adding him in. On Mon, Sep 19, 2016 at 5:11 PM, Mathias Nyman wrote: What kernel version is this? This patch is against 4.4.21. I've tested newer releases but haven't seen any improvement. As Greg said there are fixes in this area in the 4.8 latest rc kernel. If that doesn't work then we need to figure out what the real issue is. No dice on 4.8-rc7 (without any patches). Here's 4.8-rc7 loading: [3.699524] xhci_hcd 0021:09:00.0: xHCI Host Controller [3.699556] xhci_hcd 0021:09:00.0: new USB bus registered, assigned bus number 1 [3.699640] xhci_hcd 0021:09:00.0: Using 64-bit DMA iommu bypass [3.699697] xhci_hcd 0021:09:00.0: hcc params 0x0270f06d hci version 0x96 quirks 0x [3.700286] hub 1-0:1.0: USB hub found [3.700299] hub 1-0:1.0: 4 ports detected [3.700493] xhci_hcd 0021:09:00.0: xHCI Host Controller [3.700522] xhci_hcd 0021:09:00.0: new USB bus registered, assigned bus number 2 [3.700552] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [3.700733] hub 2-0:1.0: USB hub found [3.700748] hub 2-0:1.0: 4 ports detected Then we kexec into the second kernel. Here's what the second kernel prints when trying to bring the controller up: [1.588272] xhci_hcd 0021:09:00.0: xHCI Host Controller [1.588282] xhci_hcd 0021:09:00.0: new USB bus registered, assigned bus number 1 [1.619279] xhci_hcd 0021:09:00.0: Host not halted after 16000 microseconds. [1.619281] xhci_hcd 0021:09:00.0: can't setup: -110 [1.619447] xhci_hcd 0021:09:00.0: USB bus 1 deregistered [1.619457] xhci_hcd 0021:09:00.0: init 0021:09:00.0 fail, -110 [1.619571] xhci_hcd: probe of 0021:09:00.0 failed with error -110 Quick Googling shows that that TI TUSB 73x0 USB3.0 xHCI host has an issue with halting. Errata says host needs 125us to 1ms between the last control transfer and clearing the run/stop bit. (halting the host) Suggested workaround is to wait at least 2ms before halting the host. See issue #10 in: http://www.ti.com/lit/er/sllz076/sllz076.pdf It might just be that the patch works because it forces halting the host to be done later (secondary hcd -> primary hcd), giving it enough time after the last control transfer. a first step. load primary load secondary (starts the xhci controller ... unload secondary (halts the controller) unload primary (free memory) Now thinking about it, it doesn't really make sense to halt the host controller hardware before removing the primary hcd. It will just cause devices under the primary (USB2) to be removed uncleanly. So basically the idea of the workaround makes sense, it just needs to be cleaned up from a workaround to intended behavior. We might also need an additional quirk for TI TUSB 73x0 that adds a msleep() before the xhci_halt, even if it's moved to the last hcd removed. -Mathias -- 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 net 3/5] r8152: move PHY settings to hw_phy_cfg
Move the PHY relative settings together to hw_phy_cfg().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index dbf11ba..9ce5bd5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2632,6 +2632,10 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
+ r8152b_enable_eee(tp);
+ r8152_aldps_en(tp, true);
+ r8152b_enable_fc(tp);
+
set_bit(PHY_RESET, &tp->flags);
}
@@ -2839,6 +2843,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
+ r8153_enable_eee(tp);
+ r8153_aldps_en(tp, true);
+ r8152b_enable_fc(tp);
+
set_bit(PHY_RESET, &tp->flags);
}
@@ -3369,9 +3377,6 @@ static void r8152b_init(struct r8152 *tp)
SPDWN_RXDV_MSK | SPDWN_LINKCHG_MSK;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_GPHY_INTR_IMR, ocp_data);
- r8152b_enable_eee(tp);
- r8152_aldps_en(tp, true);
- r8152b_enable_fc(tp);
rtl_tally_reset(tp);
/* enable rx aggregation */
@@ -3490,9 +3495,6 @@ static void r8153_init(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
- r8153_enable_eee(tp);
- r8153_aldps_en(tp, true);
- r8152b_enable_fc(tp);
rtl_tally_reset(tp);
r8153_u2p3en(tp, true);
}
--
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
[PATCH net 1/5] r8152: move some functions
Move the following functions forward.
r8152_mmd_indirect()
r8152_mmd_read()
r8152_mmd_write()
r8152_eee_en()
r8152b_enable_eee()
r8153_eee_en()
r8153_enable_eee()
r8152b_enable_fc()
r8153_aldps_en()
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 224
1 file changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f41a8ad..ae7db46 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2552,6 +2552,77 @@ static void r8152_aldps_en(struct r8152 *tp, bool enable)
}
}
+static inline void r8152_mmd_indirect(struct r8152 *tp, u16 dev, u16 reg)
+{
+ ocp_reg_write(tp, OCP_EEE_AR, FUN_ADDR | dev);
+ ocp_reg_write(tp, OCP_EEE_DATA, reg);
+ ocp_reg_write(tp, OCP_EEE_AR, FUN_DATA | dev);
+}
+
+static u16 r8152_mmd_read(struct r8152 *tp, u16 dev, u16 reg)
+{
+ u16 data;
+
+ r8152_mmd_indirect(tp, dev, reg);
+ data = ocp_reg_read(tp, OCP_EEE_DATA);
+ ocp_reg_write(tp, OCP_EEE_AR, 0x);
+
+ return data;
+}
+
+static void r8152_mmd_write(struct r8152 *tp, u16 dev, u16 reg, u16 data)
+{
+ r8152_mmd_indirect(tp, dev, reg);
+ ocp_reg_write(tp, OCP_EEE_DATA, data);
+ ocp_reg_write(tp, OCP_EEE_AR, 0x);
+}
+
+static void r8152_eee_en(struct r8152 *tp, bool enable)
+{
+ u16 config1, config2, config3;
+ u32 ocp_data;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config1 = ocp_reg_read(tp, OCP_EEE_CONFIG1) & ~sd_rise_time_mask;
+ config2 = ocp_reg_read(tp, OCP_EEE_CONFIG2);
+ config3 = ocp_reg_read(tp, OCP_EEE_CONFIG3) & ~fast_snr_mask;
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config1 |= EEE_10_CAP | EEE_NWAY_EN | TX_QUIET_EN | RX_QUIET_EN;
+ config1 |= sd_rise_time(1);
+ config2 |= RG_DACQUIET_EN | RG_LDVQUIET_EN;
+ config3 |= fast_snr(42);
+ } else {
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config1 &= ~(EEE_10_CAP | EEE_NWAY_EN | TX_QUIET_EN |
+RX_QUIET_EN);
+ config1 |= sd_rise_time(7);
+ config2 &= ~(RG_DACQUIET_EN | RG_LDVQUIET_EN);
+ config3 |= fast_snr(511);
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CONFIG1, config1);
+ ocp_reg_write(tp, OCP_EEE_CONFIG2, config2);
+ ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
+}
+
+static void r8152b_enable_eee(struct r8152 *tp)
+{
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+}
+
+static void r8152b_enable_fc(struct r8152 *tp)
+{
+ u16 anar;
+
+ anar = r8152_mdio_read(tp, MII_ADVERTISE);
+ anar |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
+ r8152_mdio_write(tp, MII_ADVERTISE, anar);
+}
+
static void rtl8152_disable(struct r8152 *tp)
{
r8152_aldps_en(tp, false);
@@ -2701,6 +2772,47 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
}
+static void r8153_aldps_en(struct r8152 *tp, bool enable)
+{
+ u16 data;
+
+ data = ocp_reg_read(tp, OCP_POWER_CFG);
+ if (enable) {
+ data |= EN_ALDPS;
+ ocp_reg_write(tp, OCP_POWER_CFG, data);
+ } else {
+ data &= ~EN_ALDPS;
+ ocp_reg_write(tp, OCP_POWER_CFG, data);
+ msleep(20);
+ }
+}
+
+static void r8153_eee_en(struct r8152 *tp, bool enable)
+{
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
+ } else {
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153_enable_eee(struct r8152 *tp)
+{
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+}
+
static void r8153_hw_phy_cfg(struct r8152 *tp)
{
u32 ocp_data;
@@ -2866,21 +2978,6 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
}
-static void r8153_aldps_en(struct r8152 *tp, bool enable)
-{
- u16 data;
-
- data = ocp_reg_read(tp, OCP_POWER_CFG);
- if (enable) {
- data |= EN_ALDPS;
- ocp_reg_write(tp, OCP_POWER_CFG, data);
- } else {
- data &= ~EN_ALDPS;
- ocp_reg_write(tp, OCP_POWER_CFG, data);
- msleep(20);
- }
-}
-
s
[PATCH net 0/5] r8152: correct the flow of PHY
First, to enable the PHY as early as possible. Some settings may fail if the PHY is power down. Move the other PHY settings to hw_phy_cfg() to make sure the order is correct. Finally, disable ALDPS and EEE before updating the PHY for RTL8153. Hayes Wang (5): r8152: move some functions r8152: move enabling PHY r8152: move PHY settings to hw_phy_cfg r8152: remove r8153_enable_eee r8152: disable ALDPS and EEE before setting PHY drivers/net/usb/r8152.c | 281 +--- 1 file changed, 146 insertions(+), 135 deletions(-) -- 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
[PATCH net 4/5] r8152: remove r8153_enable_eee
Remove r8153_enable_eee().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 9ce5bd5..e7a05dd 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2803,12 +2803,6 @@ static void r8153_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CFG, config);
}
-static void r8153_enable_eee(struct r8152 *tp)
-{
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
-}
-
static void r8153_hw_phy_cfg(struct r8152 *tp)
{
u32 ocp_data;
@@ -2843,7 +2837,9 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_enable_eee(tp);
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
--
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
[PATCH net 5/5] r8152: disable ALDPS and EEE before setting PHY
Disable ALDPS and EEE to avoid the possible failure when setting the PHY.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e7a05dd..3c3cdb4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
#define NETNEXT_VERSION"08"
/* Information for net */
-#define NET_VERSION"5"
+#define NET_VERSION"6"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -2808,6 +2808,13 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
u32 ocp_data;
u16 data;
+ /* disable ALDPS before updating the PHY parameters */
+ r8153_aldps_en(tp, false);
+
+ /* disable EEE before updating the PHY parameters */
+ r8153_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data &= ~CTAP_SHORT_EN;
@@ -3390,7 +3397,6 @@ static void r8153_init(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return;
- r8153_aldps_en(tp, false);
r8153_u1u2en(tp, false);
for (i = 0; i < 500; i++) {
--
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] usb: misc: legousbtower: Fix NULL pointer deference
On Tue, 2016-09-20 at 08:22 +0200, Greg KH wrote: > When you sent this the last time (back on Sept 2), I sent you a > "simpler" patch, the same one below, and asked you if that worked > instead. I never heard back, could you test this patch and see if it > resolves the issue for you? As far as I can tell, your patches are identical. Regards Oliver -- 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 net 2/5] r8152: move enabling PHY
Move enabling PHY to init(), otherwise some other settings may fail.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 43 +--
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ae7db46..dbf11ba 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2632,14 +2632,6 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- u16 data;
-
- data = r8152_mdio_read(tp, MII_BMCR);
- if (data & BMCR_PDOWN) {
- data &= ~BMCR_PDOWN;
- r8152_mdio_write(tp, MII_BMCR, data);
- }
-
set_bit(PHY_RESET, &tp->flags);
}
@@ -2818,16 +2810,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
u32 ocp_data;
u16 data;
- if (tp->version == RTL_VER_03 || tp->version == RTL_VER_04 ||
- tp->version == RTL_VER_05)
- ocp_reg_write(tp, OCP_ADC_CFG, CKADSEL_L | ADC_EN | EN_EMI_L);
-
- data = r8152_mdio_read(tp, MII_BMCR);
- if (data & BMCR_PDOWN) {
- data &= ~BMCR_PDOWN;
- r8152_mdio_write(tp, MII_BMCR, data);
- }
-
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data &= ~CTAP_SHORT_EN;
@@ -3355,10 +3337,17 @@ static void rtl_tally_reset(struct r8152 *tp)
static void r8152b_init(struct r8152 *tp)
{
u32 ocp_data;
+ u16 data;
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return;
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data & BMCR_PDOWN) {
+ data &= ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
+
r8152_aldps_en(tp, false);
if (tp->version == RTL_VER_01) {
@@ -3394,6 +3383,7 @@ static void r8152b_init(struct r8152 *tp)
static void r8153_init(struct r8152 *tp)
{
u32 ocp_data;
+ u16 data;
int i;
if (test_bit(RTL8152_UNPLUG, &tp->flags))
@@ -3416,6 +3406,23 @@ static void r8153_init(struct r8152 *tp)
msleep(20);
}
+ if (tp->version == RTL_VER_03 || tp->version == RTL_VER_04 ||
+ tp->version == RTL_VER_05)
+ ocp_reg_write(tp, OCP_ADC_CFG, CKADSEL_L | ADC_EN | EN_EMI_L);
+
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data & BMCR_PDOWN) {
+ data &= ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
+
+ for (i = 0; i < 500; i++) {
+ ocp_data = ocp_reg_read(tp, OCP_PHY_STATUS) & PHY_STAT_MASK;
+ if (ocp_data == PHY_STAT_LAN_ON)
+ break;
+ msleep(20);
+ }
+
usb_disable_lpm(tp->udev);
r8153_u2p3en(tp, false);
--
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
