Re: Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
On 09/20/2012 11:44 PM, Sarah Sharp wrote: > On Wed, Sep 12, 2012 at 04:36:53PM -0700, Sarah Sharp wrote: >> Would you be willing to run some tests for me? In particular, I need >> the dmesg with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned >> on, along with a usbmon trace of the scanner running twice under one of >> your EHCI-only systems, and a trace of two scans under xHCI. The >> documentation for how to capture a usbmon trace is in the kernel source >> directory in Documentation/usb/usbmon.txt. > > Hi Michal, any chance of you sending me these logs and usbmon traces? > If you have any questions about how to capture them, let me know. > > Thanks, > Sarah Sharp > Hi Sarah, I thought I sent them on 2012-09-13 11:02:51 GMT, I can see them in the m-l via Gmane: http://article.gmane.org/gmane.linux.usb.general/71002 Let me know if they are OK. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: phy: add a new driver for usb3 phy
Hi,
On Wed, Sep 19, 2012 at 8:11 PM, Marc Kleine-Budde wrote:
> On 09/19/2012 01:30 PM, Kishon Vijay Abraham I wrote:
>> Added a driver for usb3 phy that handles the interaction between usb phy
>> device and dwc3 controller.
>>
>> This also includes device tree support for usb3 phy driver and
>> the documentation with device tree binding information is updated.
>>
>> Currently writing to control module register is taken care in this
>> driver which will be removed once the control module driver is in place.
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> Signed-off-by: Felipe Balbi
>> Signed-off-by: Moiz Sonasath
>> ---
>> Documentation/devicetree/bindings/usb/usb-phy.txt | 18 +
>> drivers/usb/phy/Kconfig |9 +
>> drivers/usb/phy/Makefile |1 +
>> drivers/usb/phy/omap-usb3.c | 369
>> +
>> include/linux/usb/omap_usb.h | 72
>> 5 files changed, 469 insertions(+)
>> create mode 100644 drivers/usb/phy/omap-usb3.c
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
>> b/Documentation/devicetree/bindings/usb/usb-phy.txt
>> index 80d4148..7c5fd89 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
>> @@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
>> reg = <0x4a0ad080 0x58>,
>> <0x4a002300 0x4>;
>> };
>> +
>> +OMAP USB3 PHY
>> +
>> +Required properties:
>> + - compatible: Should be "ti,omap-usb3"
>> + - reg : Address and length of the register set for the device. Also
>> +add the address of control module phy power register until a driver for
>> +control module is added
>> +
>> +This is usually a subnode of ocp2scp to which it is connected.
>> +
>> +usb3phy@4a084400 {
>> + compatible = "ti,omap-usb3";
>> + reg = <0x0x4a084400 0x80>,
>> + <0x4a084800 0x64>,
>> + <0x4a084c00 0x40>,
>> + <0x4a002370 0x4>;
>> +};
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index 63c339b..353dc0c 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -13,6 +13,15 @@ config OMAP_USB2
>> The USB OTG controller communicates with the comparator using this
>> driver.
>>
>> +config OMAP_USB3
>> + tristate "OMAP USB3 PHY Driver"
>> + select USB_OTG_UTILS
>> + help
>> + Enable this to support the USB3 PHY that is part of SOC. This
>> + driver takes care of all the PHY functionality apart from comparator.
>> + The USB OTG controller communicates with the comparator using this
>> + driver.
>> +
>> config USB_ISP1301
>> tristate "NXP ISP1301 USB transceiver support"
>> depends on USB || USB_GADGET
>> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
>> index b069f29..973b1e6 100644
>> --- a/drivers/usb/phy/Makefile
>> +++ b/drivers/usb/phy/Makefile
>> @@ -5,6 +5,7 @@
>> ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
>>
>> obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
>> +obj-$(CONFIG_OMAP_USB3) += omap-usb3.o
>> obj-$(CONFIG_USB_ISP1301)+= isp1301.o
>> obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
>> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
>> diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
>> new file mode 100644
>> index 000..4dc84ca
>> --- /dev/null
>> +++ b/drivers/usb/phy/omap-usb3.c
>> @@ -0,0 +1,369 @@
>> +/*
>> + * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
>> + *
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * Author: Kishon Vijay Abraham I
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static struct usb_dpll_params omap_usb3_dpll_params[NUM_SYS_CLKS] = {
>> + {1250, 5, 4, 20, 0},/* 12 MHz */
>> + {3125, 20, 4, 20, 0}, /* 16.8 MHz */
>> + {1172, 8, 4, 20, 65537},/* 19.2 MHz */
>> + {1250, 12, 4, 20, 0}, /* 26 MHz */
>> + {3125, 47, 4, 20, 92843}, /* 38.4 MHz */
>> +};
>> +
>> +/**
>> + * omap5_usb_phy_power - power on/off the serializer using control module
>> + * @phy: struct omap_usb *
>> + * @on: 0 to off and 1 to on based on powering on or off the PHY
>> + *
>> + * omap_usb3 can call this API to
Re: [PATCH 1/2] USB: check port changes before hub runtime suspend
On Fri, Sep 21, 2012 at 10:06 AM, Ming Lei wrote: > On Fri, Sep 21, 2012 at 1:04 AM, Alan Stern wrote: >> What happens if you put the msleep(1) after the new >> check_ports_change() call? > > If a new device is connected into the '05e3:0608 Genesys Logic, Inc. > USB-2.0 4-Port HUB' during this 10sec, the new connection can't > trigger a remote wakeup interrupt from ehci. The problem also exists on the device below: 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub Looks the hub devices made of Genesys Logic, Inc. chip are very popular and can be found easily in electronics market, the problem should be fixed. Thanks, -- Ming Lei -- 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 port power off discussion
On 2012年09月21日 09:52, Peter Chen wrote: >> >> Where I would like to see this work go is to have a certain set of >> "safe" internal USB devices be powered off by default when they are >> suspended. I think fingerprint readers and webcams would be a good >> start, but we probably can't do bluetooth, 3G modems, BMCs, etc. We >> would need a new USB driver flag to allow drivers to opt-in to the >> automatic port power off on suspend. We should probably turn that on by >> default and see if anyone has issues. >> > > If I understand correctly, only below ports can be power off compared > current's. > > - The internal port which is not connected any devices > - The internal port which is connected non remote-wakeup featured > device, and the port power can be off through user space application > - any other ports? > > For fingerprint, how can we let it re-use? Unless there is another > interrupt to indicate > when we touch it or other things? If the device needed outside event, the remote-wakeup would not be disabled and so the device would not be power off. > > >> Sarah Sharp >> -- >> 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 Tianyu Lan -- 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] ACPI: Allow acpi binding with usb3.0 hub
On 2012年09月21日 08:25, Sarah Sharp wrote: > Hi Tianyu, > > You're correct that the USB core and the xHCI driver has a slightly > different architecture than the ACPI representation. We have one PCI > device that has two USB buses/roothubs underneath it. That's because > external USB 3.0 hubs show up as two USB devices: a USB 3.0 only > portion, and a USB 2.0 portion. We wanted roothubs to act the same way. > > The architecture looks something like this: > > struct pci_dev > | > struct usb_hcd *primary_hcd -- struct usb_hcd *secondary_hcd > | | > struct usb_bus struct usb_bus > | | > struct usb_device *root_hub struct usb_device *root_hub > | | >struct device struct device > > Where the primary_hcd is for the USB 2.0 roothub, and the secondary_hcd > is for the USB 3.0 roothub. > > So you're trying to bind one ACPI node (RHUB) to the struct device > contained in those two root_hubs, correct? That goal seems sane to me. > Yes, that is my patch's purpose. > Sarah Sharp -- Best regards Tianyu Lan -- 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] USB: g_mass_storage: Hide caching mode page to improve write speed for Windows
If connect an UMS device (for example, an Android phone) to Linux PC and
Windows PC, then copy a big file (~500MB) to the device, you will find that
Linux PC's write speed is much faster than Windows PC. This issue can be fixed
by hiding the "caching mode page" on UMS device.
Previously in f_mass_storage.c: do_mode_sense(), caching mode page was the
only mode page, and it was configured as:
Write cache enabled (WCE=1)
Read cache not disabled
No cache retention priorities
The "Write cache enable"(WCE) bit has different influence for Linux PC and
Windows PC.
For Linux PC, whether WCE is 0 or 1, the write speed from Linux PC to UMS
device has no difference. Linux PC just ignores this flag.
For Windows PC, if
1. the UMS devices has a valid "caching mode page"
2. the WCE bit in "caching mode page" is set to 1
3. the "write-cache buffer flushing" on Windows PC is not turned off
With these three conditions together, Windows PC will send SCSI WRITE COMMAND
with FUA=1 (FUA, force unit access), and FUA=1 will cause UMS device to wait
until the blocks have been written onto the medium, which will drag down write
speed a lot. Unluckily, this is Windows PC's default behavior.
On Windows, the FUA=1 flag can be changed by turning off "write-cache buffer
flushing" under UMS device's properties, but if we do so, Windows will pop up
error message as following:
Windows could not change the write-caching setting for the device.
Your device might not support this feature or changing the setting.
[ OK ]
Windows need to change UMS device's caching mode page, but this page is hard
coded and can't be changed, so there will be error pop up.
To fix this issue, we can just hide the "caching mode page". With this patch,
there will be no influence for Linux PC, because Linux PC does not handle UMS
device's caching mode page; for Windows PC, if it does see the "caching mode
page", it will not send SCSI WRITE COMMAND with FUA=1, and write speed will
become as fast as Linux PC.
Signed-off-by: Leo Song
---
drivers/usb/gadget/f_mass_storage.c | 27 +++
1 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 4f1142e..70f3047 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -1296,30 +1296,9 @@ static int do_mode_sense(struct fsg_common *common,
struct fsg_buffhd *bh)
/* No block descriptors */
- /*
-* The mode pages, in numerical order. The only page we support
-* is the Caching page.
-*/
- if (page_code == 0x08 || all_pages) {
- valid_page = 1;
- buf[0] = 0x08; /* Page code */
- buf[1] = 10;/* Page length */
- memset(buf+2, 0, 10); /* None of the fields are changeable */
-
- if (!changeable_values) {
- buf[2] = 0x04; /* Write cache enable, */
- /* Read cache not disabled */
- /* No cache retention priorities */
- put_unaligned_be16(0x, &buf[4]);
- /* Don't disable prefetch */
- /* Minimum prefetch = 0 */
- put_unaligned_be16(0x, &buf[8]);
- /* Maximum prefetch */
- put_unaligned_be16(0x, &buf[10]);
- /* Maximum prefetch ceiling */
- }
- buf += 12;
- }
+ /* No mode pages */
+
+ valid_page = 1;
/*
* Check that a valid page was requested and the mode data length
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] Convert MSM to common clock framework
This patchset moves the existing MSM clock code and affected drivers to the
common clock framework. A prerequisite of moving to the common clock
framework is to use clk_prepare() and clk_enable() so the first
few patches migrate drivers to that call (clk_prepare() is a no-op on MSM
right now). It also removes some custom clock APIs that MSM provides
and finally moves the proc_comm clock code to the common struct clock.
This patch series will be used as the foundation of the MSM 8660/8960
clock code that I plan to send out soon.
These patches have one dependency on the devm_clk_register() function
which I already posted to the list[1]. They're based on linux-next-20120917.
Stephen Boyd (10):
usb: otg: msm: Convert to clk_prepare/unprepare
msm_sdcc: Convert to clk_prepare/unprepare
msm: iommu: Convert to clk_prepare/unprepare
msm: iommu: Use clk_set_rate() instead of clk_set_min_rate()
ARM: msm: Remove custom clk_set_flags() API
ARM: msm: Remove custom clk_set_{max,min}_rate() API
ARM: msm: Remove clock-7x30.h include file
ARM: msm: Prepare clk_get() users in mach-msm for clock-pcom driver
ARM: msm: Make proc_comm clock control into a platform driver
ARM: msm: Migrate to common clock framework
arch/arm/Kconfig | 1 +
arch/arm/mach-msm/Makefile | 10 +-
arch/arm/mach-msm/board-halibut.c | 2 +-
arch/arm/mach-msm/board-msm7x30.c | 2 +-
arch/arm/mach-msm/board-qsd8x50.c | 2 +-
arch/arm/mach-msm/board-trout-panel.c | 19 ++--
arch/arm/mach-msm/board-trout.c| 3 +-
arch/arm/mach-msm/clock-7x30.h | 155 --
arch/arm/mach-msm/clock-debug.c| 130 --
arch/arm/mach-msm/clock-pcom.c | 149 ++---
arch/arm/mach-msm/clock-pcom.h | 31 +++---
arch/arm/mach-msm/clock.c | 166 +
arch/arm/mach-msm/clock.h | 51 +++---
arch/arm/mach-msm/devices-msm7x00.c| 12 ++-
arch/arm/mach-msm/devices-msm7x30.c| 13 ++-
arch/arm/mach-msm/devices-qsd8x50.c| 11 ++-
arch/arm/mach-msm/devices.h| 15 +--
arch/arm/mach-msm/dma.c| 5 +-
arch/arm/mach-msm/include/mach/board.h | 5 -
arch/arm/mach-msm/include/mach/clk.h | 9 --
drivers/iommu/msm_iommu_dev.c | 20 ++--
drivers/mmc/host/msm_sdcc.c| 14 ++-
drivers/usb/otg/msm_otg.c | 38
23 files changed, 222 insertions(+), 641 deletions(-)
delete mode 100644 arch/arm/mach-msm/clock-7x30.h
delete mode 100644 arch/arm/mach-msm/clock-debug.c
[1] https://lkml.org/lkml/2012/9/19/28
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 01/10] usb: otg: msm: Convert to clk_prepare/unprepare
Add calls to clk_prepare and unprepare so that MSM can migrate to
the common clock framework.
Cc: Felipe Balbi
Signed-off-by: Stephen Boyd
---
drivers/usb/otg/msm_otg.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
index 9f5fc90..2ae0639 100644
--- a/drivers/usb/otg/msm_otg.c
+++ b/drivers/usb/otg/msm_otg.c
@@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
motg->pdata->otg_control == OTG_PMIC_CONTROL)
writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
- clk_disable(motg->pclk);
- clk_disable(motg->clk);
+ clk_disable_unprepare(motg->pclk);
+ clk_disable_unprepare(motg->clk);
if (motg->core_clk)
- clk_disable(motg->core_clk);
+ clk_disable_unprepare(motg->core_clk);
if (!IS_ERR(motg->pclk_src))
- clk_disable(motg->pclk_src);
+ clk_disable_unprepare(motg->pclk_src);
if (motg->pdata->phy_type == SNPS_28NM_INTEGRATED_PHY &&
motg->pdata->otg_control == OTG_PMIC_CONTROL) {
@@ -552,12 +552,12 @@ static int msm_otg_resume(struct msm_otg *motg)
return 0;
if (!IS_ERR(motg->pclk_src))
- clk_enable(motg->pclk_src);
+ clk_prepare_enable(motg->pclk_src);
- clk_enable(motg->pclk);
- clk_enable(motg->clk);
+ clk_prepare_enable(motg->pclk);
+ clk_prepare_enable(motg->clk);
if (motg->core_clk)
- clk_enable(motg->core_clk);
+ clk_prepare_enable(motg->core_clk);
if (motg->pdata->phy_type == SNPS_28NM_INTEGRATED_PHY &&
motg->pdata->otg_control == OTG_PMIC_CONTROL) {
@@ -1468,7 +1468,7 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
if (IS_ERR(motg->pclk_src))
goto put_clk;
clk_set_rate(motg->pclk_src, INT_MAX);
- clk_enable(motg->pclk_src);
+ clk_prepare_enable(motg->pclk_src);
} else
motg->pclk_src = ERR_PTR(-ENOENT);
@@ -1511,8 +1511,8 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
goto free_regs;
}
- clk_enable(motg->clk);
- clk_enable(motg->pclk);
+ clk_prepare_enable(motg->clk);
+ clk_prepare_enable(motg->pclk);
ret = msm_hsusb_init_vddcx(motg, 1);
if (ret) {
@@ -1532,7 +1532,7 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
}
if (motg->core_clk)
- clk_enable(motg->core_clk);
+ clk_prepare_enable(motg->core_clk);
writel(0, USB_USBINTR);
writel(0, USB_OTGSC);
@@ -1579,8 +1579,8 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
free_irq:
free_irq(motg->irq, motg);
disable_clks:
- clk_disable(motg->pclk);
- clk_disable(motg->clk);
+ clk_disable_unprepare(motg->pclk);
+ clk_disable_unprepare(motg->clk);
ldo_exit:
msm_hsusb_ldo_init(motg, 0);
vddcx_exit:
@@ -1593,7 +1593,7 @@ put_core_clk:
clk_put(motg->pclk);
put_pclk_src:
if (!IS_ERR(motg->pclk_src)) {
- clk_disable(motg->pclk_src);
+ clk_disable_unprepare(motg->pclk_src);
clk_put(motg->pclk_src);
}
put_clk:
@@ -1643,12 +1643,12 @@ static int __devexit msm_otg_remove(struct
platform_device *pdev)
if (cnt >= PHY_SUSPEND_TIMEOUT_USEC)
dev_err(phy->dev, "Unable to suspend PHY\n");
- clk_disable(motg->pclk);
- clk_disable(motg->clk);
+ clk_disable_unprepare(motg->pclk);
+ clk_disable_unprepare(motg->clk);
if (motg->core_clk)
- clk_disable(motg->core_clk);
+ clk_disable_unprepare(motg->core_clk);
if (!IS_ERR(motg->pclk_src)) {
- clk_disable(motg->pclk_src);
+ clk_disable_unprepare(motg->pclk_src);
clk_put(motg->pclk_src);
}
msm_hsusb_ldo_init(motg, 0);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: check port changes before hub runtime suspend
On Fri, Sep 21, 2012 at 1:04 AM, Alan Stern wrote: > > I vaguely remember seeing this same effect with one of my hubs. If a > port status change occurred before the hub was suspended, the hub would > not issue a remote wakeup request. This was a bug in the hub. Other Looks it is a bug of the hub, see below. > hubs behaved better. > >> This patch can fix the problem in the above case. > > What happens if you put the msleep(1) after the new > check_ports_change() call? If a new device is connected into the '05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB' during this 10sec, the new connection can't trigger a remote wakeup interrupt from ehci. But If it is connected into the hub of '0424:9514 Standard Microsystems Corp' during the period, it will cause a ehci remote wakeup interrupt. Looks we need to introduce a quirk to fix the bug hub. If you have no objection, I will figure out a new patch to fix the bug device. Thanks -- Ming Lei -- 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-next] net1080: Neaten netdev_dbg use
From: Joe Perches Date: Thu, 20 Sep 2012 17:10:23 -0700 > Remove unnecessary temporary variable and #ifdef DEBUG block. > > Signed-off-by: Joe Perches Applied, thanks Joe. -- 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 port power off discussion
> > Where I would like to see this work go is to have a certain set of > "safe" internal USB devices be powered off by default when they are > suspended. I think fingerprint readers and webcams would be a good > start, but we probably can't do bluetooth, 3G modems, BMCs, etc. We > would need a new USB driver flag to allow drivers to opt-in to the > automatic port power off on suspend. We should probably turn that on by > default and see if anyone has issues. > If I understand correctly, only below ports can be power off compared current's. - The internal port which is not connected any devices - The internal port which is connected non remote-wakeup featured device, and the port power can be off through user space application - any other ports? For fingerprint, how can we let it re-use? Unless there is another interrupt to indicate when we touch it or other things? > Sarah Sharp > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
On Fri, Sep 21, 2012 at 5:16 AM, David Miller wrote: > From: Oliver Neukum > Date: Thu, 20 Sep 2012 23:04:38 +0200 > >> On Thursday 20 September 2012 17:02:27 David Miller wrote: >>> >>> There seems to be some discussion about the legitimacy of doing things >>> this way, and in any event the patches were an RFC. >>> >>> Please resubmit as a non-RFC once all the issues have been worked >>> out, if appropriate. >> >> Just to make this clear, I'd like to state that the discussion involved >> only the third, last patch in the series. The first two are fine and make >> sense by themselves. > > I want changes in those, see my replies. No problem, I will send out -v2 of the first two patches later. thanks, -- Ming Lei -- 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: set hub's default autosuspend delay as 0
On Fri, Sep 21, 2012 at 12:43 AM, Rajaram R wrote: > On Thu, Sep 20, 2012 at 9:38 PM, Ming Lei wrote: >> >> On Thu, Sep 20, 2012 at 11:23 PM, Ming Lei wrote: >> > >> > I will try to study 'lsusb' to see if there is one problem and try to >> > solve it. >> >> If what you concern is about accessing device via libusb, it should be >> OK since the device will be resumed in its open() and suspended in >> its close(). >> >> Could you let me know if there is other thing which may cause 'lsusb' >> mess if we change hub's autosuspend delay as 0? > > Did you try a fast connect and disconnect of a USB Stick( Mass > Storage) ? I just did it, and there is no any problem from the view of usb hub function. > Does it enumerate/mount properly everytime? Sometimes it may enumerate not successfully because it is disconnected during enumeration. But it is nothing to do with the patch because it may happen without the patch. If you need a log, I can provide it to you since it is a bit big. Thanks, -- Ming Lei -- 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: set hub's default autosuspend delay as 0
On Fri, Sep 21, 2012 at 12:49 AM, Alan Stern wrote: > On Thu, 20 Sep 2012, Ming Lei wrote: > >> On Thu, Sep 20, 2012 at 10:48 PM, Alan Stern >> wrote: >> > On Thu, 20 Sep 2012, Ming Lei wrote: >> > >> >> This patch sets hub device's default autosuspend delay as 0 to >> >> speedup bus suspend, see comments in code for details. >> > >> > The explanation in the comments assumes that the only reasons for hubs >> > to wake up are because of a connect change or a wakeup request from a >> > child. This is not correct. >> > >> > Hubs can also be woken up by the user. Have you tried running lsusb on >> > a system with several USB devices attached to the same hub and the >> > autosuspend delay set to 0? It's a mess. >> >> Looks no mess, see log below: >> >> [ 513.732513] hub 1-1.2:1.0: state 7 ports 4 chg evt 0008 >> [ 513.826019] usb 1-1.2.3: link qh256-0001/ee780800 start 6 [1/0 us] >> [ 513.826141] hub 1-1.2.3:1.0: state 7 ports 4 chg evt >> [ 513.826293] hub 1-1.2.3:1.0: hub_suspend >> [ 513.826324] usb 1-1.2.3: unlink qh256-0001/ee780800 start 6 [1/0 us] >> [ 513.842559] usb 1-1.2.3: usb auto-suspend, wakeup 1 >> [ 513.863067] hub 1-1.2:1.0: hub_suspend >> [ 513.863128] usb 1-1.2: unlink qh256-0001/ee6c7e00 start 2 [1/0 us] >> [ 513.873413] usb 1-1.2: usb auto-suspend, wakeup 1 >> [ 513.894287] hub 1-1:1.0: hub_suspend >> [ 513.894317] usb 1-1: unlink qh256-0001/eea03dc0 start 1 [1/0 us] >> [ 513.904357] usb 1-1: usb auto-suspend, wakeup 1 >> [ 513.925506] hub 1-0:1.0: hub_suspend >> [ 513.925720] usb usb1: bus auto-suspend, wakeup 1 >> [ 513.925750] ehci-omap ehci-omap.0: suspend root hub >> >> [root@tom-pandaboard 1-1.2]# lsusb >> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. >> Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB >> Bus 001 Device 007: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / >> D-Link DUB-H4 USB 2.0 Hub > > Your log above shows four devices (usb1, 1-1, 1-1.2, and 1-1.2.3) but > the lsusb output shows five devices (1, 2, 3, 4, and 7). So the log > isn't complete. It is complete because the device 0424:ec00 is an unbound built-in usbnet device(smsc95xx). I unbound it because its driver doesn't support runtime suspend. > > The results will be more impressive if you plug three of the hubs > directly into the fourth and attach the fourth hub to the computer. OK, I will try to do it. > >> > I think it would make more sense to set the autosuspend delay to >> > something more like 50 or 100 ms. Maybe even as low as 20. But 0 >> > seems too small. >> >> IMO, suppose it is a problem, we should try to use 0 to make it >> working because 'lsusb' is just a tool which isn't involved into actual >> hub function. >> >> I will try to study 'lsusb' to see if there is one problem and try to solve >> it. > > The problem isn't in lsusb. The problem is that the autosuspend > timeout should not be too small. As I explained it in another email, there shouldn't be the problem since the device will be resumed in open() when it is accessed via libusb and be suspended in its close(), should there? Thanks, -- Ming Lei -- 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] ACPI: Allow acpi binding with usb3.0 hub
Len, do you have any comments on the ACPI code itself? The description
about why the code is needed for the USB core seems sane, but the actual
patch code is all ACPI core stuff, so you need to review that.
On Fri, Aug 17, 2012 at 02:44:09PM +0800, Lan Tianyu wrote:
> usb port's position and connectability can't be identified on some boards
> via usb hub's register. ACPI _UPC and _PLD can help to resolve such issue
> and so it is necessary to bind usb with acpi. This patch is to allow acpi
> binding with usb3.0 hub.
>
> Current acpi only can bind one struct device to one acpi device node.
> This can not work with usb3.0 hub. Because the usb3.0 hub has two logical
> devices. Each works for usb2.0 and usb3.0 devices. In the liux usb subsystem,
> those two logical hubs are treated as two seperate devices that have two
> struct
> devices. But in the ACPI DSDT, these two logical hubs share one acpi device
> node. So there is a requirement to bind multi struct devices to one acpi
> node. This patch is to resolve such problem.
>
> Following is the acpi device nodes' description under xhci hcd.
> Device (XHC)
> Device (RHUB)
> Device (HSP1)
> Device (HSP2)
> Device (HSP3)
> Device (HSP4)
> Device (SSP1)
> Device (SSP2)
> Device (SSP3)
> Device (SSP4)
>
> Topology in the linux
> device XHC
> usb2.0 logical hubusb3.0 logical hub
> HSP1SSP1
> HSP2SSP2
> HSP3SSP3
> HSP4SSP4
Hi Tianyu,
You're correct that the USB core and the xHCI driver has a slightly
different architecture than the ACPI representation. We have one PCI
device that has two USB buses/roothubs underneath it. That's because
external USB 3.0 hubs show up as two USB devices: a USB 3.0 only
portion, and a USB 2.0 portion. We wanted roothubs to act the same way.
The architecture looks something like this:
struct pci_dev
|
struct usb_hcd *primary_hcd -- struct usb_hcd *secondary_hcd
| |
struct usb_bus struct usb_bus
| |
struct usb_device *root_hub struct usb_device *root_hub
| |
struct device struct device
Where the primary_hcd is for the USB 2.0 roothub, and the secondary_hcd
is for the USB 3.0 roothub.
So you're trying to bind one ACPI node (RHUB) to the struct device
contained in those two root_hubs, correct? That goal seems sane to me.
Sarah Sharp
>
> This patch also modifies the output of /proc/acpi/wakeup. One acpi node
> can be associated with multi devices. Just like following.
>
> XHC S4 *enabledpci::00:14.0
> RHUB S0 disabledusb:usb1
> disabledusb:usb2
>
> Signed-off-by: Lan Tianyu
> ---
> v2: Add lock to protect physical_node related data in bind() and unbind().
> Add an example here of the syntax change to the contents of
> /proc/acpi/wakeup. Replace
> link file name physical_node0 with physical_node when physical_node_id is 0.
> ---
> drivers/acpi/glue.c| 135
>
> drivers/acpi/proc.c| 57 ---
> drivers/acpi/scan.c|2 +
> drivers/pnp/pnpacpi/core.c |7 +--
> include/acpi/acpi_bus.h| 15 -
> 5 files changed, 139 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 243ee85..d1a2d74 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -25,6 +25,8 @@
> static LIST_HEAD(bus_type_list);
> static DECLARE_RWSEM(bus_type_sem);
>
> +#define PHYSICAL_NODE_STRING "physical_node"
> +
> int register_acpi_bus_type(struct acpi_bus_type *type)
> {
> if (acpi_disabled)
> @@ -124,84 +126,119 @@ acpi_handle acpi_get_child(acpi_handle parent, u64
> address)
>
> EXPORT_SYMBOL(acpi_get_child);
>
> -/* Link ACPI devices with physical devices */
> -static void acpi_glue_data_handler(acpi_handle handle,
> -void *context)
> -{
> - /* we provide an empty handler */
> -}
> -
> -/* Note: a success call will increase reference count by one */
> -struct device *acpi_get_physical_device(acpi_handle handle)
> -{
> - acpi_status status;
> - struct device *dev;
> -
> - status = acpi_get_data(handle, acpi_glue_data_handler, (void **)&dev);
> - if (ACPI_SUCCESS(status))
> - return get_device(dev);
> - return NULL;
> -}
> -
> -EXPORT_SYMBOL(acpi_get_physical_device);
> -
> static int acpi_bind_one(struct device *dev, acpi_handle handle)
> {
> struct acpi_device *acpi_dev;
> acpi_status status;
> + struct acpi_device_physical_node *physical_node;
> + char physical_node_name[
[PATCH net-next] net1080: Neaten netdev_dbg use
Remove unnecessary temporary variable and #ifdef DEBUG block.
Signed-off-by: Joe Perches
---
drivers/net/usb/net1080.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 29e06e1..c062a3e 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -417,12 +417,9 @@ static int net1080_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
u16 hdr_len, packet_len;
if (!(skb->len & 0x01)) {
-#ifdef DEBUG
- struct net_device *net = dev->net;
netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
- skb->len, net->hard_header_len, dev->hard_mtu,
- net->mtu);
-#endif
+ skb->len, dev->net->hard_header_len, dev->hard_mtu,
+ dev->net->mtu);
dev->net->stats.rx_frame_errors++;
nc_ensure_sync(dev);
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB port power off discussion
Two weeks ago at Linux Plumbers Conference, I presented about the Intel Lynx Point USB port power off mechanism. This email is a report out of what was discussed, and a kick off point for further discussion. LPC Report out -- Slides are here: http://dl.dropbox.com/u/96820575/sarah-sharp-lpt-port-power-off2-mini.pdf The video is here: http://linuxplumbers.ubicast.tv/videos/usb-port-power-off-kerneluserspace-api/ (I apologize in advance for the mispronunciation of Tianyu's name.) Basic idea: The Intel Lynx Point port power off mechanism is a way for Linux to use ACPI to completely power off USB ports, but that means we lose hot plug/unplug events. The general consensus was: - If we come up with a sensible automatic port power policy, and have all ports use it by default, then we're likely to run into a lot of broken ACPI tables. We could add a boot option to change the policy to "on" so that users have an easy way to test if the ACPI tables are bad. - If we have the port power policy default to on, but add a Power Top option to turn the policy to auto, we really won't get a lot of users or testing. It might be best to turn it to 'auto' and see if any users scream. We can always change it to 'on' later. - We probably don't want to power external ports off by default. There's just too much risk of users seeing "dead" USB ports. Powering off internal empty ports by default is fine. - We need to expose all information ACPI provides to userspace via sysfs. Some users will want to know which ports are power ganged together, because they may have a USB device that is charging but not enumerated on a port, and we have no way of detecting that. The power resources may not have a name or number, so we will have to arbitrarily number them. - Len Brown mentioned that it's likely that other types of system devices will expose power resources in the same way it's done for USB devices. Rafael Wysocki mentioned that it would be nice to get a more generic representation of the power resources into struct device. - Possibly lsusb should show the power policy for each port, as part of the roothub verbose listing. Next Steps -- Rafael wanted to see the whole patchset series. The patches have gone in over several months (and some of them are only in greg/usb-next or linux-next). Here is the series from earliest to latest patches: 38ac0f1 ACPI: Add _PLD support da0af6e usb: Bind devices to ACPI devices when possible 54d3f8c usb: Set device removable state based on ACPI USB data f397d7c usb: add struct usb_hub_port to store port related members. bebc56d usb: move struct usb_device->children to struct usb_hub_port->child 336c5c3 usb: convert port_owners type from void * to struct dev_state * 7fc2cc3 usb: Rename temp variable "config" to "val" in the set_avoid_reset_quirk() 4d9e408 usb: add decriptor of persist fail for some morph usb devices 2d36684 usb/endpoint: Set release callback in the struct device_type instead of in the device itself directly 7fda953 usb: convert USB_QUIRK_RESET_MORPHS to USB_QUIRK_RESET 9c20890 usb: redefine DeviceRemovable and wHubDelay as _le16 fa2a956 usb: make usb port a real device ff823c7 usb: move children to struct usb_port d557542 usb/acpi: Bind ACPI node to USB port, not usb_device. 05f9168 usb/acpi: Store info on device removability. 693d8eb xhci: Handle clear PORT_POWER feature. f7ac778 usb/acpi: Use ACPI methods to power off ports. 3a22b87 usb: Fail a get config when the port is powered off. ca9c9d0 usb : Add sysfs files to control port power. ca3c153 usb: add little-endian transform for DeviceRemovable of usb3.0 hub The end result of those patches is that we expose a sysfs file per USB port to userspace to allow users to set power to either on or off. The port will only be powered off if all ports under the same power resource have the sysfs file set to off. There's no kernel policy behind the "auto" power policy. Tianyu sent a recent patchset to add a policy that turns off ports that ACPI says is not user visible and is not connectable, but only if there isn't a USB device currently connected to it: http://marc.info/?l=linux-usb&m=134668553729981&w=2 http://marc.info/?l=linux-usb&m=134668554029982&w=2 Next steps are to get those auto policy patches merged (they're probably too late for 3.7 right now), and agree on a generic power resource management in struct device. Where I would like to see this work go is to have a certain set of "safe" internal USB devices be powered off by default when they are suspended. I think fingerprint readers and webcams would be a good start, but we probably can't do bluetooth, 3G modems, BMCs, etc. We would need a new USB driver flag to allow drivers to opt-in to the automatic port power off on suspend. We should probably turn that on by default and see if anyone has issues. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe
Re: [PATCHv4 7/9] arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
On 08/23/2012 02:35 AM, Tony Prisk wrote: > Bindings for gpio, interrupt controller, power management controller, > timer, realtime clock, serial uart, ehci and uhci controllers and > framebuffer controllers used on the arch-vt8500 platform. > > Framebuffer binding also specifies a 'display' node which is required > for determining the lcd panel data. Overall, these bindings look okay, but there is some effort to standardize a binding for displays: http://comments.gmane.org/gmane.linux.drivers.devicetree/21386 I would like to see that used rather than something custom. Rob -- 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] net: qmi_wwan: call subdriver with control intf only
From: Bjørn Mork Date: Mon, 10 Sep 2012 22:15:50 +0200 > This fixes a hang on suspend due to calling wdm_suspend on > the unregistered data interface. The hang should have been > a NULL pointer reference had it not been for a logic error > in the cdc_wdm code. > > commit 230718bd net: qmi_wwan: bind to both control and data interface > > changed qmi_wwan to use cdc_wdm as a subdriver for devices with > a two-interface QMI/wwan function. The commit failed to update > qmi_wwan_suspend and qmi_wwan_resume, which were written to handle > either a single combined interface function, or no subdriver at all. > > The result was that we called into the subdriver both when the > control interface was suspended and when the data interface was > suspended. Calling the subdriver suspend function with an > unregistered interface is not supported and will make the > subdriver bug out. > > Signed-off-by: Bjørn Mork 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: [PATCH v2] USB: remove dbg() usage in USB networking drivers
From: Greg Kroah-Hartman Date: Wed, 19 Sep 2012 20:46:14 +0100 > From: Greg Kroah-Hartman > > The dbg() USB macro is so old, it predates me. The USB networking drivers are > the last hold-out using this macro, and we want to get rid of it, so replace > the usage of it with the proper netdev_dbg() or dev_dbg() (depending on the > context) calls. > > Some places we end up using a local variable for the debug call, so also > convert the other existing dev_* calls to use it as well, to save tiny amounts > of code space. > > Signed-off-by: Greg Kroah-Hartman > --- > v2: Addressed review comments from Joe Perches > > Again, I am glad to take this in the usb-next tree if wanted, whatever is > easiest. I'll take this into net-next, applied, thanks Greg. -- 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: Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
On Wed, Sep 12, 2012 at 04:36:53PM -0700, Sarah Sharp wrote: > Would you be willing to run some tests for me? In particular, I need > the dmesg with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned > on, along with a usbmon trace of the scanner running twice under one of > your EHCI-only systems, and a trace of two scans under xHCI. The > documentation for how to capture a usbmon trace is in the kernel source > directory in Documentation/usb/usbmon.txt. Hi Michal, any chance of you sending me these logs and usbmon traces? If you have any questions about how to capture them, let me know. Thanks, Sarah Sharp -- 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
libusbx-1.0.13 has been released
Hi, It with pleasure that I would like to announce the release of libusbx 1.0.13. This version brings the following notable changes: * [MAJOR] Fix a typo in the API with struct libusb_config_descriptor where MaxPower was used instead of bMaxPower, as per the specs. If your application was accessing the MaxPower attribute, and you need to maintain compatibility with libusb or older versions, please see APPENDIX A below. * Fix broken support for the 0.1 -> 1.0 libusb-compat layer * Fix unwanted cancellation of pending timeouts as well as major timeout related bugs * Fix handling of HID and composite devices on Windows * Introduce LIBUSBX_API_VERSION macro * Add Cypress FX/FX2 firmware upload sample, based on fxload from http://linux-hotplug.sourceforge.net * Add libusb0 (libusb-win32) and libusbK driver support on Windows. Note that while the drivers allow it, isochronous transfers are not supported yet in libusbx. Also not supported yet is the use of libusb-win32 filter drivers on composite interfaces * Add support for the new get_capabilities ioctl on Linux and avoid unnecessary splitting of bulk transfers * Improve support for newer Intel and Renesas USB 3.0 controllers on Windows * Harmonize the device number for root hubs across platforms * Other bug fixes and improvements Release archives can be obtained from: https://sourceforge.net/projects/libusbx/files/releases/1.0.13/ For more information, please visit: http://libusbx.org Regards, /Pete ~~ APPENDIX A - Maintaining code compatibility with versions of libusb and libusbx that use MaxPower: If you must to maintain compatibility with versions of the library that aren't using the bMaxPower attribute in struct libusb_config_descriptor the recommended way is to use the new LIBUSBX_API_VERSION macro with an #ifdef. For instance, if your code was written as follows: if (dev->config[0].MaxPower < 250) Then you should modify it to have: #if defined(LIBUSBX_API_VERSION) && (LIBUSBX_API_VERSION >= 0x01000100) if (dev->config[0].bMaxPower < 250) #else if (dev->config[0].MaxPower < 250) #endif ~~ -- 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: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
From: Oliver Neukum Date: Thu, 20 Sep 2012 23:04:38 +0200 > On Thursday 20 September 2012 17:02:27 David Miller wrote: >> >> There seems to be some discussion about the legitimacy of doing things >> this way, and in any event the patches were an RFC. >> >> Please resubmit as a non-RFC once all the issues have been worked >> out, if appropriate. > > Just to make this clear, I'd like to state that the discussion involved > only the third, last patch in the series. The first two are fine and make > sense by themselves. I want changes in those, see my replies. -- 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: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
On Thursday 20 September 2012 17:02:27 David Miller wrote: > > There seems to be some discussion about the legitimacy of doing things > this way, and in any event the patches were an RFC. > > Please resubmit as a non-RFC once all the issues have been worked > out, if appropriate. Just to make this clear, I'd like to state that the discussion involved only the third, last patch in the series. The first two are fine and make sense by themselves. 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: [RFC PATCH v1 1/3] usbnet: introduce usbnet_link_change API
From: Ming Lei Date: Tue, 18 Sep 2012 22:23:19 +0800 > +void usbnet_link_change(struct usbnet *dev, int link, int need_reset) Please use 'bool' for link and need_reset. -- 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: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
There seems to be some discussion about the legitimacy of doing things this way, and in any event the patches were an RFC. Please resubmit as a non-RFC once all the issues have been worked out, if appropriate. 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: [PATCH v3] HID: keep dev_rdesc unmodified and use it for comparisons
> The dev_rdesc member of the hid_device structure is meant to store the
> original
> report descriptor received from the device, but it is currently passed to any
> report_fixup method before it is copied to the rdesc member. This patch uses a
> temporary buffer to shield dev_rdesc from the side effects of many HID
> drivers'
> report_fixup implementations.
>
> usbhid's hid_post_reset checks the report descriptor currently returned by the
> device against a descriptor that may have been modified by a driver's
> report_fixup method. That leaves some devices nonfunctional after a resume,
> with
> a "reset_resume error 1" reported. This patch checks the new descriptor
> against
> the unmodified dev_rdesc instead and uses the original, instead of modified,
> report size.
>
> BugLink: http://bugs.launchpad.net/bugs/1049623
> Signed-off-by: Kevin Daughtridge
> ---
Looks like it will work, thank you Kevin. The comments below are just
suggestions, I am fine with the patch as is.
> drivers/hid/hid-core.c| 16 +---
> drivers/hid/usbhid/hid-core.c |6 +++---
> 2 files changed, 16 insertions(+), 6 deletions(-)
>
> Changed in this version: added a temporary buffer to work around report_fixup
> inconsistencies; using dev_rsize instead of rsize to allocate and read new
> descriptor.
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 8bcd168..5de3bb3 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -757,6 +757,7 @@ int hid_open_report(struct hid_device *device)
> struct hid_item item;
> unsigned int size;
> __u8 *start;
> + __u8 *buf;
It is sad to have to add a temporary here.
> __u8 *end;
> int ret;
> static int (*dispatch_type[])(struct hid_parser *parser,
> @@ -775,12 +776,21 @@ int hid_open_report(struct hid_device *device)
> return -ENODEV;
> size = device->dev_rsize;
>
> + buf = kmemdup(start, size, GFP_KERNEL);
> + if (buf == NULL)
> + return -ENOMEM;
> +
> if (device->driver->report_fixup)
> - start = device->driver->report_fixup(device, start, &size);
> + start = device->driver->report_fixup(device, buf, &size);
> + else
> + start = buf;
>
> - device->rdesc = kmemdup(start, size, GFP_KERNEL);
> - if (device->rdesc == NULL)
> + start = kmemdup(start, size, GFP_KERNEL);
> + kfree(buf);
Changing the semantics of the callback did not seem appealing, but it
does not prevent us from using our own version internally. So, how
about something like this:
static __u8 *hid_alloc_rdesc(struct hid_device *devicew,
const __u8 *start, unsigned int *size)
{
__u8 *rdesc = kmemdup(start, *size, GFP_KERNEL);
if (rdesc && device->driver->report_fixup) {
__u8 *tmp = device->driver->report_fixup(device, rdesc, size);
if (tmp != rdesc) {
tmp = kmemdup(tmp, *size, GFP_KERNEL);
kfree(rdesc);
rdesc = tmp;
}
}
return rdesc;
}
> + if (start == NULL)
> return -ENOMEM;
> +
> + device->rdesc = start;
> device->rsize = size;
>
> parser = vzalloc(sizeof(struct hid_parser));
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index dedd8e4..8e0c4bf94 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -1415,20 +1415,20 @@ static int hid_post_reset(struct usb_interface *intf)
>* configuration descriptors passed, we already know that
>* the size of the HID report descriptor has not changed.
>*/
> - rdesc = kmalloc(hid->rsize, GFP_KERNEL);
> + rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
> if (!rdesc) {
> dbg_hid("couldn't allocate rdesc memory (post_reset)\n");
> return 1;
> }
> status = hid_get_class_descriptor(dev,
> interface->desc.bInterfaceNumber,
> - HID_DT_REPORT, rdesc, hid->rsize);
> + HID_DT_REPORT, rdesc, hid->dev_rsize);
> if (status < 0) {
> dbg_hid("reading report descriptor failed (post_reset)\n");
> kfree(rdesc);
> return 1;
> }
> - status = memcmp(rdesc, hid->rdesc, hid->rsize);
> + status = memcmp(rdesc, hid->dev_rdesc, hid->dev_rsize);
> kfree(rdesc);
> if (status != 0) {
> dbg_hid("report descriptor changed\n");
Thanks,
Henrik
--
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 03/29] ARM: OMAP1: Make plat/mux.h omap1 only
On Wed, Sep 19, 2012 at 02:05:39PM -0700, Tony Lindgren wrote:
> We are moving omap2+ to use the device tree based pinctrl-single.c
> and will be removing the old mux framework. This will remove the
> omap1 specific parts from plat-omap.
>
> Cc: Felipe Balbi
> Cc: Grant Likely
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Richard Purdie
> Cc: Florian Tobias Schandinat
> Cc: Tomi Valkeinen
> Cc: linux-usb@vger.kernel.org
> Cc: linux-pcm...@lists.infradead.org
> Cc: spi-devel-gene...@lists.sourceforge.net
> Signed-off-by: Tony Lindgren
for drivers/usb:
Acked-by: Felipe Balbi
> ---
> arch/arm/mach-omap1/board-ams-delta.c |2 -
> arch/arm/mach-omap1/board-fsample.c |2 -
> arch/arm/mach-omap1/board-generic.c |2 -
> arch/arm/mach-omap1/board-h2.c|2 -
> arch/arm/mach-omap1/board-h3.c|2 -
> arch/arm/mach-omap1/board-innovator.c |2 -
> arch/arm/mach-omap1/board-nokia770.c |2 -
> arch/arm/mach-omap1/board-osk.c |2 -
> arch/arm/mach-omap1/board-palmte.c|2 -
> arch/arm/mach-omap1/board-palmtt.c|2 -
> arch/arm/mach-omap1/board-palmz71.c |2 -
> arch/arm/mach-omap1/board-perseus2.c |2 -
> arch/arm/mach-omap1/board-sx1.c |2 -
> arch/arm/mach-omap1/board-voiceblue.c |2 -
> arch/arm/mach-omap1/devices.c |2 -
> arch/arm/mach-omap1/i2c.c |2 -
> arch/arm/mach-omap1/include/mach/mux.h|0
> arch/arm/mach-omap1/io.c |2 -
> arch/arm/mach-omap1/mcbsp.c |2 -
> arch/arm/mach-omap1/mux.c | 58
> arch/arm/mach-omap1/pm.c |2 -
> arch/arm/mach-omap1/serial.c |2 -
> arch/arm/mach-omap1/usb.c |2 -
> arch/arm/mach-omap2/common.c |1
> arch/arm/mach-omap2/hsmmc.c |1
> arch/arm/plat-omap/Makefile |2 -
> arch/arm/plat-omap/i2c.c |1
> arch/arm/plat-omap/include/plat/omap-serial.h |2 -
> arch/arm/plat-omap/mux.c | 90
> -
> drivers/pcmcia/omap_cf.c |2 -
> drivers/spi/spi-omap-uwire.c |2 -
> drivers/usb/host/ohci-omap.c |2 -
> drivers/usb/musb/tusb6010_omap.c |1
> drivers/usb/otg/isp1301_omap.c|2 -
> drivers/video/backlight/omap1_bl.c|2 -
> drivers/video/omap/lcd_osk.c |2 -
> 36 files changed, 84 insertions(+), 126 deletions(-)
> rename arch/arm/{plat-omap/include/plat/mux.h =>
> mach-omap1/include/mach/mux.h} (100%)
> delete mode 100644 arch/arm/plat-omap/mux.c
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c
> b/arch/arm/mach-omap1/board-ams-delta.c
> index ab1e51f..05af063 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -37,7 +37,7 @@
>
> #include
> #include
> -#include
> +#include
>
> #include
> #include
> diff --git a/arch/arm/mach-omap1/board-fsample.c
> b/arch/arm/mach-omap1/board-fsample.c
> index 6d98552..4b784f2 100644
> --- a/arch/arm/mach-omap1/board-fsample.c
> +++ b/arch/arm/mach-omap1/board-fsample.c
> @@ -28,7 +28,7 @@
> #include
>
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-omap1/board-generic.c
> b/arch/arm/mach-omap1/board-generic.c
> index 04b5fda..4ec579f 100644
> --- a/arch/arm/mach-omap1/board-generic.c
> +++ b/arch/arm/mach-omap1/board-generic.c
> @@ -22,7 +22,7 @@
> #include
> #include
>
> -#include
> +#include
>
> #include
>
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index 5560a40..124db5c 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -38,7 +38,7 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
> index edc2487..a6f28a6 100644
> --- a/arch/arm/mach-omap1/board-h3.c
> +++ b/arch/arm/mach-omap1/board-h3.c
> @@ -40,7 +40,7 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-omap1/board-innovator.c
> b/arch/arm/mach-omap1/board-innovator.c
> index f21c296..0eb9881 100644
> --- a/arch/arm/mach-omap1/board-innovator.c
> +++ b/arch/arm/mach-omap1/board-innovator.c
> @@ -31,7 +31,7 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-omap1/board-nokia770.c
> b/arch/arm/mach-omap1/board-nokia770.c
> index ec01f03..fb3a6e9 100644
> --- a/arch/arm/mach-omap1/board-nokia770.
[PATCH v3] HID: keep dev_rdesc unmodified and use it for comparisons
The dev_rdesc member of the hid_device structure is meant to store the original
report descriptor received from the device, but it is currently passed to any
report_fixup method before it is copied to the rdesc member. This patch uses a
temporary buffer to shield dev_rdesc from the side effects of many HID drivers'
report_fixup implementations.
usbhid's hid_post_reset checks the report descriptor currently returned by the
device against a descriptor that may have been modified by a driver's
report_fixup method. That leaves some devices nonfunctional after a resume, with
a "reset_resume error 1" reported. This patch checks the new descriptor against
the unmodified dev_rdesc instead and uses the original, instead of modified,
report size.
BugLink: http://bugs.launchpad.net/bugs/1049623
Signed-off-by: Kevin Daughtridge
---
drivers/hid/hid-core.c| 16 +---
drivers/hid/usbhid/hid-core.c |6 +++---
2 files changed, 16 insertions(+), 6 deletions(-)
Changed in this version: added a temporary buffer to work around report_fixup
inconsistencies; using dev_rsize instead of rsize to allocate and read new
descriptor.
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8bcd168..5de3bb3 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -757,6 +757,7 @@ int hid_open_report(struct hid_device *device)
struct hid_item item;
unsigned int size;
__u8 *start;
+ __u8 *buf;
__u8 *end;
int ret;
static int (*dispatch_type[])(struct hid_parser *parser,
@@ -775,12 +776,21 @@ int hid_open_report(struct hid_device *device)
return -ENODEV;
size = device->dev_rsize;
+ buf = kmemdup(start, size, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
if (device->driver->report_fixup)
- start = device->driver->report_fixup(device, start, &size);
+ start = device->driver->report_fixup(device, buf, &size);
+ else
+ start = buf;
- device->rdesc = kmemdup(start, size, GFP_KERNEL);
- if (device->rdesc == NULL)
+ start = kmemdup(start, size, GFP_KERNEL);
+ kfree(buf);
+ if (start == NULL)
return -ENOMEM;
+
+ device->rdesc = start;
device->rsize = size;
parser = vzalloc(sizeof(struct hid_parser));
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index dedd8e4..8e0c4bf94 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1415,20 +1415,20 @@ static int hid_post_reset(struct usb_interface *intf)
* configuration descriptors passed, we already know that
* the size of the HID report descriptor has not changed.
*/
- rdesc = kmalloc(hid->rsize, GFP_KERNEL);
+ rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
if (!rdesc) {
dbg_hid("couldn't allocate rdesc memory (post_reset)\n");
return 1;
}
status = hid_get_class_descriptor(dev,
interface->desc.bInterfaceNumber,
- HID_DT_REPORT, rdesc, hid->rsize);
+ HID_DT_REPORT, rdesc, hid->dev_rsize);
if (status < 0) {
dbg_hid("reading report descriptor failed (post_reset)\n");
kfree(rdesc);
return 1;
}
- status = memcmp(rdesc, hid->rdesc, hid->rsize);
+ status = memcmp(rdesc, hid->dev_rdesc, hid->dev_rsize);
kfree(rdesc);
if (status != 0) {
dbg_hid("report descriptor changed\n");
--
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: BEEMO(OPTION) alias PANTECH P4200 LTE-Modem
On Thu, 2012-09-20 at 19:55 +0200, Thomas Schäfer wrote: > One mysterious thing: > > at&v at /dev/ttyACM via minicom > > crashs/resets the modem. Sounds like a firmware bug. I've heard of this on one or two other occasions. Clearly nobody on that firmware team put the device through a conformance test :) Or if they did, they didn't care enough to fix it, because their connection manager probably "just doesn't do that". > > Other at-command like ate, ati, c+cgdcont > work, but getting all settings via at&v fails. > > > > Have other pantech-modems this feature too? UM190 doesn't crash; it correctly displays current settings. Dan -- 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: BEEMO(OPTION) alias PANTECH P4200 LTE-Modem
One mysterious thing: at&v at /dev/ttyACM via minicom crashs/resets the modem. Other at-command like ate, ati, c+cgdcont work, but getting all settings via at&v fails. Have other pantech-modems this feature too? Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: check port changes before hub runtime suspend
On Thu, 20 Sep 2012, Ming Lei wrote: > On Thu, Sep 20, 2012 at 10:43 PM, Alan Stern > wrote: > > On Thu, 20 Sep 2012, Ming Lei wrote: > > > >> It is very common that hub status endpoint has a long 'bInterval', > >> for example, it may be 11(128ms for HS device) or 12(256ms for HS > >> device), so the device connection change may be reported a bit > >> later via status pipe. > > > > In fact, the USB spec requires FS hubs to have bInterval set to 255 and > > HS hubs to have bInterval set to 12. > > > >> So there may have device connection changes happened already on the > >> downstream ports, and no status URB completes when it is killed > >> in hub auto-suspend path, which may miss the connection change event > >> and let hub suspend successfully. > >> > >> This patch introduces check_ports_changed() to check port change event > >> in auto-suspend path, and recover hub state and return -EBUSY if > >> change events are found. > >> > >> The disadvantage is that some delay may be introduced in hub auto-suspend > >> path. > > > > This is not necessary. If a connect change occurred but hadn't been > > reported when the hub was suspended, then the hub will issue a wakeup > > request. The connect change will not get lost. > > You mean the wakeup request is remote wakeup? At least, from ehci_irq, > only PCD interrupt handles remote wakeup irq. > > But from '7.1.7.7 Resume' part of USB 2.0 spec: > >Additionally, the device can signal the system to resume operation >if its remote wakeup capability has been enabled by the USB System >Software > > At this time, the remote wakeup capability hasn't been enabled for the hub, > so the wakeup might not be generated. True, the remote wakeup capability is not enabled at the time the connect change happens. But it does get enabled before the hub is suspended, so once the hub is suspended it should issue a remote wakeup request right away. > I have tested the case by adding 'msleep(1)' after hub_quiesce() > inside hub_suspend(), then plug a new device into the hub during the > time, but current usbcore can't find the connection. I vaguely remember seeing this same effect with one of my hubs. If a port status change occurred before the hub was suspended, the hub would not issue a remote wakeup request. This was a bug in the hub. Other hubs behaved better. > This patch can fix the problem in the above case. What happens if you put the msleep(1) after the new check_ports_change() call? 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 2/2] USB: set hub's default autosuspend delay as 0
On Thu, 20 Sep 2012, Ming Lei wrote: > On Thu, Sep 20, 2012 at 10:48 PM, Alan Stern > wrote: > > On Thu, 20 Sep 2012, Ming Lei wrote: > > > >> This patch sets hub device's default autosuspend delay as 0 to > >> speedup bus suspend, see comments in code for details. > > > > The explanation in the comments assumes that the only reasons for hubs > > to wake up are because of a connect change or a wakeup request from a > > child. This is not correct. > > > > Hubs can also be woken up by the user. Have you tried running lsusb on > > a system with several USB devices attached to the same hub and the > > autosuspend delay set to 0? It's a mess. > > Looks no mess, see log below: > > [ 513.732513] hub 1-1.2:1.0: state 7 ports 4 chg evt 0008 > [ 513.826019] usb 1-1.2.3: link qh256-0001/ee780800 start 6 [1/0 us] > [ 513.826141] hub 1-1.2.3:1.0: state 7 ports 4 chg evt > [ 513.826293] hub 1-1.2.3:1.0: hub_suspend > [ 513.826324] usb 1-1.2.3: unlink qh256-0001/ee780800 start 6 [1/0 us] > [ 513.842559] usb 1-1.2.3: usb auto-suspend, wakeup 1 > [ 513.863067] hub 1-1.2:1.0: hub_suspend > [ 513.863128] usb 1-1.2: unlink qh256-0001/ee6c7e00 start 2 [1/0 us] > [ 513.873413] usb 1-1.2: usb auto-suspend, wakeup 1 > [ 513.894287] hub 1-1:1.0: hub_suspend > [ 513.894317] usb 1-1: unlink qh256-0001/eea03dc0 start 1 [1/0 us] > [ 513.904357] usb 1-1: usb auto-suspend, wakeup 1 > [ 513.925506] hub 1-0:1.0: hub_suspend > [ 513.925720] usb usb1: bus auto-suspend, wakeup 1 > [ 513.925750] ehci-omap ehci-omap.0: suspend root hub > > [root@tom-pandaboard 1-1.2]# lsusb > Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. > Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB > Bus 001 Device 007: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / > D-Link DUB-H4 USB 2.0 Hub Your log above shows four devices (usb1, 1-1, 1-1.2, and 1-1.2.3) but the lsusb output shows five devices (1, 2, 3, 4, and 7). So the log isn't complete. The results will be more impressive if you plug three of the hubs directly into the fourth and attach the fourth hub to the computer. > > I think it would make more sense to set the autosuspend delay to > > something more like 50 or 100 ms. Maybe even as low as 20. But 0 > > seems too small. > > IMO, suppose it is a problem, we should try to use 0 to make it > working because 'lsusb' is just a tool which isn't involved into actual > hub function. > > I will try to study 'lsusb' to see if there is one problem and try to solve > it. The problem isn't in lsusb. The problem is that the autosuspend timeout should not be too small. 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: BEEMO(OPTION) alias PANTECH P4200 LTE-Modem
On Wed, 2012-09-19 at 20:45 +0200, Bjørn Mork wrote: > Thomas Schäfer writes: > > > I collected some additional information about this device. > > > > The windows-view: > > http://www.cis.uni-muenchen.de/~thomas/pantech-p4200-usb.png > > > > and the usbsnoop-logfile: > > http://www.cis.uni-muenchen.de/~thomas/pantech-p4200-usbsnoop.log.bz2 > > > > Has anybody suggestions, what could I do next? > > I am wondering exactly how qmi_wwan does "not work"... I *know* the Novatel/Verizon USB 551L does QMI, because my Windows snoops show QMI on the normal cdc-ether port that the device has, but for some reason I was never able to get qmi_wwan to work with the device. Maybe the same thing going on here? I didn't have a lot of time to play around with it at the time, but I tried all the different interface matching options in qmi_wwan (combined, separate, etc) and nothing got the device to respond with QMI under Linux. Dan > That snoop contains lots of QMI, so it is definitely a device which > qmi_wwan should handle. Note that the snoop does have the "Set Instance > ID" (0x0020) ctl message which may be important to some devices. And it > sets the data format to "raw IP", which may be persistent and therefore > need resetting to 802.3 framing in Linux. Try including both these > messages before starting a data session in Linux. > > Decoded contents of pantech-p4200-usbsnoop.log.bz2 with a slightly > obfuscated IMEI: > > QMI frame #0 > << QMUX: > << length = 15 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 1 > << tlv_length = 4 > << message = "Allocate CID" (0x0022) > << TLV: > << type = "Service" (0x01) > << length = 1 > << value = 01 > << translated = 1 > QMI frame #1 > >> QMUX: > >> length = 23 > >> flags = 0x80 > >> service = "ctl" > >> client = 0 > >> QMI: > >> flags = "response" > >> transaction = 1 > >> tlv_length = 12 > >> message = "Allocate CID" (0x0022) > >> TLV: > >> type = "Result" (0x02) > >> length = 4 > >> value = 00:00:00:00 > >> translated = SUCCESS > >> TLV: > >> type = "Allocation Info" (0x01) > >> length = 2 > >> value = 01:03 > >> translated = [ service = '1' cid = '3' ] > QMI frame #2 > << QMUX: > << length = 15 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 2 > << tlv_length = 4 > << message = "Allocate CID" (0x0022) > << TLV: > << type = "Service" (0x01) > << length = 1 > << value = 01 > << translated = 1 > QMI frame #3 > >> QMUX: > >> length = 23 > >> flags = 0x80 > >> service = "ctl" > >> client = 0 > >> QMI: > >> flags = "response" > >> transaction = 2 > >> tlv_length = 12 > >> message = "Allocate CID" (0x0022) > >> TLV: > >> type = "Result" (0x02) > >> length = 4 > >> value = 00:00:00:00 > >> translated = SUCCESS > >> TLV: > >> type = "Allocation Info" (0x01) > >> length = 2 > >> value = 01:04 > >> translated = [ service = '1' cid = '4' ] > QMI frame #4 > << QMUX: > << length = 15 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 3 > << tlv_length = 4 > << message = "Allocate CID" (0x0022) > << TLV: > << type = "Service" (0x01) > << length = 1 > << value = 02 > << translated = 2 > QMI frame #5 > >> QMUX: > >> length = 23 > >> flags = 0x80 > >> service = "ctl" > >> client = 0 > >> QMI: > >> flags = "response" > >> transaction = 3 > >> tlv_length = 12 > >> message = "Allocate CID" (0x0022) > >> TLV: > >> type = "Result" (0x02) > >> length = 4 > >> value = 00:00:00:00 > >> translated = SUCCESS > >> TLV: > >> type = "Allocation Info" (0x01) > >> length = 2 > >> value = 02:02 > >> translated = [ service = '2' cid = '2' ] > QMI frame #6 > << QMUX: > << length = 15 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 4 > << tlv_length = 4 > << message = "Allocate CID" (0x0022) > << TLV: > << type = "Service" (0x01) > << length = 1 > << value = 03 > << translated = 3 > QMI frame #7 > >> QMUX: > >> length = 23 > >> flags = 0x80 > >> se
Re: [PATCH 2/2] USB: set hub's default autosuspend delay as 0
On Thu, Sep 20, 2012 at 9:38 PM, Ming Lei wrote: > > On Thu, Sep 20, 2012 at 11:23 PM, Ming Lei wrote: > > > > I will try to study 'lsusb' to see if there is one problem and try to > > solve it. > > If what you concern is about accessing device via libusb, it should be > OK since the device will be resumed in its open() and suspended in > its close(). > > Could you let me know if there is other thing which may cause 'lsusb' > mess if we change hub's autosuspend delay as 0? Did you try a fast connect and disconnect of a USB Stick( Mass Storage) ? Does it enumerate/mount properly everytime? > > Thanks > -- > Ming Lei > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: qcaux: add Pantech vendor class match
On Wed, 2012-09-19 at 22:02 +0200, Bjørn Mork wrote:
> The three Pantech devices UML190 (106c:3716), UML290 (106c:3718) and
> P4200 (106c:3721) all use the same subclasses to identify vendor
> specific functions. Replace the existing device specific entries
> with generic vendor matching, adding support for the P4200.
Yeah, this looks right. I just reverified that the UM190 follows the
same pattern; WMC on 0xFE and DIAG on 0xFF. I don't know for sure that
NMEA is 0xFD, but the UM190 *does* have a 0xFD descriptor as interface
#3.
Acked-by: Dan Williams
> Cc:
> Cc: Thomas Schäfer
> Cc: Dan Williams
> Signed-off-by: Bjørn Mork
> ---
> drivers/usb/serial/qcaux.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/serial/qcaux.c b/drivers/usb/serial/qcaux.c
> index a4edc7e..9b1b96f 100644
> --- a/drivers/usb/serial/qcaux.c
> +++ b/drivers/usb/serial/qcaux.c
> @@ -36,8 +36,6 @@
> #define UTSTARCOM_PRODUCT_UM175_V1 0x3712
> #define UTSTARCOM_PRODUCT_UM175_V2 0x3714
> #define UTSTARCOM_PRODUCT_UM175_ALLTEL 0x3715
> -#define PANTECH_PRODUCT_UML190_VZW 0x3716
> -#define PANTECH_PRODUCT_UML290_VZW 0x3718
>
> /* CMOTECH devices */
> #define CMOTECH_VENDOR_ID0x16d8
> @@ -68,11 +66,9 @@ static struct usb_device_id id_table[] = {
> { USB_DEVICE_AND_INTERFACE_INFO(LG_VENDOR_ID, LG_PRODUCT_VX4400_6000,
> 0xff, 0xff, 0x00) },
> { USB_DEVICE_AND_INTERFACE_INFO(SANYO_VENDOR_ID,
> SANYO_PRODUCT_KATANA_LX, 0xff, 0xff, 0x00) },
> { USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
> SAMSUNG_PRODUCT_U520, 0xff, 0x00, 0x00) },
> - { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
> PANTECH_PRODUCT_UML190_VZW, 0xff, 0xff, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
> PANTECH_PRODUCT_UML190_VZW, 0xff, 0xfe, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
> PANTECH_PRODUCT_UML290_VZW, 0xff, 0xfd, 0xff) }, /* NMEA */
> - { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
> PANTECH_PRODUCT_UML290_VZW, 0xff, 0xfe, 0xff) }, /* WMC */
> - { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
> PANTECH_PRODUCT_UML290_VZW, 0xff, 0xff, 0xff) }, /* DIAG */
> + { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff)
> }, /* NMEA */
> + { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfe, 0xff)
> }, /* WMC */
> + { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xff, 0xff)
> }, /* DIAG */
> { },
> };
> MODULE_DEVICE_TABLE(usb, id_table);
--
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: set hub's default autosuspend delay as 0
On Thu, Sep 20, 2012 at 11:23 PM, Ming Lei wrote: > > I will try to study 'lsusb' to see if there is one problem and try to solve > it. If what you concern is about accessing device via libusb, it should be OK since the device will be resumed in its open() and suspended in its close(). Could you let me know if there is other thing which may cause 'lsusb' mess if we change hub's autosuspend delay as 0? Thanks -- Ming Lei -- 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 00/34] i.MX multi-platform support
On Thursday 20 September 2012, Shawn Guo wrote: > > On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: > > The first five branches are scheduled to go through the arm-soc tree, so > > I'm fine with that. For the sound/for-3.7 branch, I'd like to know when > > to expect that hitting mainline. If it always gets in very early during the > > merge window, it's probably ok to put the imx/multi-platform patches into > > the same branch as the other ones in arm-soc and wait for the sound stuff > > to hit mainline first, otherwise I'd suggest we start a second > > next/multiplatform-2 branch for imx and send the first part early on > > but then wait with the second batch before sound gets in. > > > It seems that we will have to go with next/multiplatform-2. I just > tried to merge the series with linux-next together, and got some > non-trivial conflicts with media and mtd tree. I might have to rebase > my series on top of these trees to sort out those conflicts. That said, > I will have several dependencies outside arm-soc tree, and have to pend > my series until all those trees get merged into mainline. Ok, fair enough. I think we can put it in arm-soc/for-next as a staging branch anyway to give it some exposure to linux-next, and then we can decide whether a rebase is necessary before sending it to Linus. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: check port changes before hub runtime suspend
On Thu, Sep 20, 2012 at 10:43 PM, Alan Stern wrote: > On Thu, 20 Sep 2012, Ming Lei wrote: > >> It is very common that hub status endpoint has a long 'bInterval', >> for example, it may be 11(128ms for HS device) or 12(256ms for HS >> device), so the device connection change may be reported a bit >> later via status pipe. > > In fact, the USB spec requires FS hubs to have bInterval set to 255 and > HS hubs to have bInterval set to 12. > >> So there may have device connection changes happened already on the >> downstream ports, and no status URB completes when it is killed >> in hub auto-suspend path, which may miss the connection change event >> and let hub suspend successfully. >> >> This patch introduces check_ports_changed() to check port change event >> in auto-suspend path, and recover hub state and return -EBUSY if >> change events are found. >> >> The disadvantage is that some delay may be introduced in hub auto-suspend >> path. > > This is not necessary. If a connect change occurred but hadn't been > reported when the hub was suspended, then the hub will issue a wakeup > request. The connect change will not get lost. You mean the wakeup request is remote wakeup? At least, from ehci_irq, only PCD interrupt handles remote wakeup irq. But from '7.1.7.7 Resume' part of USB 2.0 spec: Additionally, the device can signal the system to resume operation if its remote wakeup capability has been enabled by the USB System Software At this time, the remote wakeup capability hasn't been enabled for the hub, so the wakeup might not be generated. I have tested the case by adding 'msleep(1)' after hub_quiesce() inside hub_suspend(), then plug a new device into the hub during the time, but current usbcore can't find the connection. This patch can fix the problem in the above case. Thanks, -- Ming Lei -- 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: set hub's default autosuspend delay as 0
On Thu, Sep 20, 2012 at 10:48 PM, Alan Stern wrote: > On Thu, 20 Sep 2012, Ming Lei wrote: > >> This patch sets hub device's default autosuspend delay as 0 to >> speedup bus suspend, see comments in code for details. > > The explanation in the comments assumes that the only reasons for hubs > to wake up are because of a connect change or a wakeup request from a > child. This is not correct. > > Hubs can also be woken up by the user. Have you tried running lsusb on > a system with several USB devices attached to the same hub and the > autosuspend delay set to 0? It's a mess. Looks no mess, see log below: [ 513.732513] hub 1-1.2:1.0: state 7 ports 4 chg evt 0008 [ 513.826019] usb 1-1.2.3: link qh256-0001/ee780800 start 6 [1/0 us] [ 513.826141] hub 1-1.2.3:1.0: state 7 ports 4 chg evt [ 513.826293] hub 1-1.2.3:1.0: hub_suspend [ 513.826324] usb 1-1.2.3: unlink qh256-0001/ee780800 start 6 [1/0 us] [ 513.842559] usb 1-1.2.3: usb auto-suspend, wakeup 1 [ 513.863067] hub 1-1.2:1.0: hub_suspend [ 513.863128] usb 1-1.2: unlink qh256-0001/ee6c7e00 start 2 [1/0 us] [ 513.873413] usb 1-1.2: usb auto-suspend, wakeup 1 [ 513.894287] hub 1-1:1.0: hub_suspend [ 513.894317] usb 1-1: unlink qh256-0001/eea03dc0 start 1 [1/0 us] [ 513.904357] usb 1-1: usb auto-suspend, wakeup 1 [ 513.925506] hub 1-0:1.0: hub_suspend [ 513.925720] usb usb1: bus auto-suspend, wakeup 1 [ 513.925750] ehci-omap ehci-omap.0: suspend root hub [root@tom-pandaboard 1-1.2]# lsusb Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 007: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub [root@tom-pandaboard 1-1.2]# lsusb --version lsusb (usbutils) 004 > > I think it would make more sense to set the autosuspend delay to > something more like 50 or 100 ms. Maybe even as low as 20. But 0 > seems too small. IMO, suppose it is a problem, we should try to use 0 to make it working because 'lsusb' is just a tool which isn't involved into actual hub function. I will try to study 'lsusb' to see if there is one problem and try to solve it. Thanks, -- Ming Lei -- 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: cannot submit urb 0, error -22: internal error followed by USB hung tasks
On 19/09/12 21:00, Alan Stern wrote: > It would be good if you could determine for certain which device has > the problem. Maybe run some tests where you use only the headset or > only the webcam. I spent time trying to reproduce problems with only the headset attached, with no luck. Then the same with the camera, no luck. Then with both, and boom, it failed rather quickly. I uploaded a log where you can see all the output from this. Even the mouse went down during this failure. After a reboot, I tried again, and with both I again got it to fail rather quickly, though this time the "cannot submit urb" was the only error message. Then I noticed something strange: guvcview reported it could no longer open the mic on the headset, whereas with skype it was still usable. Both could still display video and record from the mic on the camera. Then I tried changing the sampling rate on the headset in guvcview (was wondering if I remember correctly and that was the problem), and upon trying to start the recording, I lost (at least) my mouse again. Attached that log, too. One way to reproduce this seems to be to start calls on skype, and disconnect them from my side. Things then go bonkers at the moment of the disconnect. I've tried to reproduce this on Windows to see if it wasn't a hardware problem, but failed. (I suppose it could still be hardware problem with the Windows drivers having workarounds, of course) > Also, it might help if you run your tests with CONFIG_USB_DEBUG > enabled. Once we know a little more about what's going on, I may ask > you to capture a usbmon trace showing an example of the failure. I attached logs from the two reproductions of the problem, with CONFIG_USB_DEBUG enabled, in bugzilla. -- GCP -- 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 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: > The first five branches are scheduled to go through the arm-soc tree, so > I'm fine with that. For the sound/for-3.7 branch, I'd like to know when > to expect that hitting mainline. If it always gets in very early during the > merge window, it's probably ok to put the imx/multi-platform patches into > the same branch as the other ones in arm-soc and wait for the sound stuff > to hit mainline first, otherwise I'd suggest we start a second > next/multiplatform-2 branch for imx and send the first part early on > but then wait with the second batch before sound gets in. > It seems that we will have to go with next/multiplatform-2. I just tried to merge the series with linux-next together, and got some non-trivial conflicts with media and mtd tree. I might have to rebase my series on top of these trees to sort out those conflicts. That said, I will have several dependencies outside arm-soc tree, and have to pend my series until all those trees get merged into mainline. Shawn -- 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: set hub's default autosuspend delay as 0
On Thu, 20 Sep 2012, Ming Lei wrote: > This patch sets hub device's default autosuspend delay as 0 to > speedup bus suspend, see comments in code for details. The explanation in the comments assumes that the only reasons for hubs to wake up are because of a connect change or a wakeup request from a child. This is not correct. Hubs can also be woken up by the user. Have you tried running lsusb on a system with several USB devices attached to the same hub and the autosuspend delay set to 0? It's a mess. I think it would make more sense to set the autosuspend delay to something more like 50 or 100 ms. Maybe even as low as 20. But 0 seems too small. 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
[PATCH v2] uas: remove aborted field, replace with status bit.
Signed-off-by: Gerd Hoffmann
---
drivers/usb/storage/uas.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 1d326c5..42976ec 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -64,13 +64,13 @@ enum {
DATA_IN_URB_INFLIGHT= (1 << 9),
DATA_OUT_URB_INFLIGHT = (1 << 10),
COMMAND_COMPLETED = (1 << 11),
+ COMMAND_ABORTED = (1 << 12),
};
/* Overrides scsi_pointer */
struct uas_cmd_info {
unsigned int state;
unsigned int stream;
- unsigned int aborted;
struct urb *cmd_urb;
struct urb *data_in_urb;
struct urb *data_out_urb;
@@ -163,7 +163,7 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
struct uas_cmd_info *ci = (void *)&cmnd->SCp;
scmd_printk(KERN_INFO, cmnd, "%s %p tag %d, inflight:"
- "%s%s%s%s%s%s%s%s%s%s%s\n",
+ "%s%s%s%s%s%s%s%s%s%s%s%s\n",
caller, cmnd, cmnd->request->tag,
(ci->state & SUBMIT_STATUS_URB) ? " s-st" : "",
(ci->state & ALLOC_DATA_IN_URB) ? " a-in" : "",
@@ -175,7 +175,8 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
(ci->state & COMMAND_INFLIGHT) ? " CMD" : "",
(ci->state & DATA_IN_URB_INFLIGHT) ? " IN": "",
(ci->state & DATA_OUT_URB_INFLIGHT) ? " OUT" : "",
- (ci->state & COMMAND_COMPLETED) ? " done" : "");
+ (ci->state & COMMAND_COMPLETED) ? " done" : "",
+ (ci->state & COMMAND_ABORTED) ? " abort" : "");
}
static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller)
@@ -302,7 +303,7 @@ static void uas_data_cmplt(struct urb *urb)
} else {
sdb->resid = sdb->length - urb->actual_length;
}
- if (cmdinfo->aborted) {
+ if (cmdinfo->state & COMMAND_ABORTED) {
return;
}
uas_try_complete(cmnd, __func__);
@@ -570,7 +571,6 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd,
cmdinfo->state = SUBMIT_STATUS_URB |
ALLOC_CMD_URB | SUBMIT_CMD_URB;
- cmdinfo->aborted = 0;
switch (cmnd->sc_data_direction) {
case DMA_FROM_DEVICE:
@@ -652,7 +652,7 @@ static int uas_eh_abort_handler(struct scsi_cmnd *cmnd)
int ret;
uas_log_cmd_state(cmnd, __func__);
- cmdinfo->aborted = 1;
+ cmdinfo->state |= COMMAND_ABORTED;
ret = uas_eh_task_mgmt(cmnd, "ABORT TASK", TMF_ABORT_TASK);
if (cmdinfo->state & DATA_IN_URB_INFLIGHT)
usb_kill_urb(cmdinfo->data_in_urb);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] uas: remove aborted field, replace with status bit.
Signed-off-by: Gerd Hoffmann
---
drivers/usb/storage/uas.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 1d326c5..42976ec 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -64,13 +64,13 @@ enum {
DATA_IN_URB_INFLIGHT= (1 << 9),
DATA_OUT_URB_INFLIGHT = (1 << 10),
COMMAND_COMPLETED = (1 << 11),
+ COMMAND_ABORTED = (1 << 12),
};
/* Overrides scsi_pointer */
struct uas_cmd_info {
unsigned int state;
unsigned int stream;
- unsigned int aborted;
struct urb *cmd_urb;
struct urb *data_in_urb;
struct urb *data_out_urb;
@@ -163,7 +163,7 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
struct uas_cmd_info *ci = (void *)&cmnd->SCp;
scmd_printk(KERN_INFO, cmnd, "%s %p tag %d, inflight:"
- "%s%s%s%s%s%s%s%s%s%s%s\n",
+ "%s%s%s%s%s%s%s%s%s%s%s%s\n",
caller, cmnd, cmnd->request->tag,
(ci->state & SUBMIT_STATUS_URB) ? " s-st" : "",
(ci->state & ALLOC_DATA_IN_URB) ? " a-in" : "",
@@ -175,7 +175,8 @@ static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const
char *caller)
(ci->state & COMMAND_INFLIGHT) ? " CMD" : "",
(ci->state & DATA_IN_URB_INFLIGHT) ? " IN": "",
(ci->state & DATA_OUT_URB_INFLIGHT) ? " OUT" : "",
- (ci->state & COMMAND_COMPLETED) ? " done" : "");
+ (ci->state & COMMAND_COMPLETED) ? " done" : "",
+ (ci->state & COMMAND_ABORTED) ? " abort" : "");
}
static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller)
@@ -302,7 +303,7 @@ static void uas_data_cmplt(struct urb *urb)
} else {
sdb->resid = sdb->length - urb->actual_length;
}
- if (cmdinfo->aborted) {
+ if (cmdinfo->state & COMMAND_ABORTED) {
return;
}
uas_try_complete(cmnd, __func__);
@@ -570,7 +571,6 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd,
cmdinfo->state = SUBMIT_STATUS_URB |
ALLOC_CMD_URB | SUBMIT_CMD_URB;
- cmdinfo->aborted = 0;
switch (cmnd->sc_data_direction) {
case DMA_FROM_DEVICE:
@@ -652,7 +652,7 @@ static int uas_eh_abort_handler(struct scsi_cmnd *cmnd)
int ret;
uas_log_cmd_state(cmnd, __func__);
- cmdinfo->aborted = 1;
+ cmdinfo->state |= COMMAND_ABORTED;
ret = uas_eh_task_mgmt(cmnd, "ABORT TASK", TMF_ABORT_TASK);
if (cmdinfo->state & DATA_IN_URB_INFLIGHT)
usb_kill_urb(cmdinfo->data_in_urb);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: check port changes before hub runtime suspend
On Thu, 20 Sep 2012, Ming Lei wrote: > It is very common that hub status endpoint has a long 'bInterval', > for example, it may be 11(128ms for HS device) or 12(256ms for HS > device), so the device connection change may be reported a bit > later via status pipe. In fact, the USB spec requires FS hubs to have bInterval set to 255 and HS hubs to have bInterval set to 12. > So there may have device connection changes happened already on the > downstream ports, and no status URB completes when it is killed > in hub auto-suspend path, which may miss the connection change event > and let hub suspend successfully. > > This patch introduces check_ports_changed() to check port change event > in auto-suspend path, and recover hub state and return -EBUSY if > change events are found. > > The disadvantage is that some delay may be introduced in hub auto-suspend > path. This is not necessary. If a connect change occurred but hadn't been reported when the hub was suspended, then the hub will issue a wakeup request. The connect change will not get lost. 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 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 08:47:10AM -0400, Mark Brown wrote: > On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote: > > On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: > > > > It's usually pretty early but Takashi will be on holiday this time so > > > I'm not sure if things might be different (he was going to send the pull > > > request from holiday). I also didn't guarantee that it'll be stable > > > yet, can someone please tell me what the depenency is here? > > > We need the patch to have all imx drivers mach/* inclusion free, > > so that we can enable multi-platform support for imx, which is the > > whole point of the series. > > That doesn't answer the question. What is the dependency - what is it > about this patch that something else depends on? Your cover letters > just say you'd like to do this but don't mention dependencies at all and > when I asked the question last night you said the same thing. I've not > seen the rest of the series... > Ah, right. You did get copied on the whole series. So the whole point of patch "ASoC: mx27vis: retrieve gpio numbers from platform_data" is to get rid of inclusion mach/iomux-mx27.h. This has to be done before we enable multi-platform support for imx, since mach/* has to be removed completely for multi-platform build. > > If your for-3.7 is not stable anyway, I guess the easiest the way > > It probably *is* stable but I'm not enthused about people pulling > unsigned tags. I might rebase, though - I'm going to finalise the tree > in the next few days. > > > to do it might be you drop the patch "ASoC: mx27vis: retrieve gpio > > numbers from platform_data" from your tree and I have it be part of > > the series to go via arm-soc tree as a whole. (This is the original > > plan that I mentioned in v1 cover letter) > > You just mentioned it as a preference (you said it's something you'd > like to do), please if you're doing this sort of cross tree thing be > explicit about what the inter-tree relationships are. If things need to > go in via the same tree say so explicitly (and ideally say way this is). > Ok, my bad. > The main reason I applied it straight away was that Javier mentioned > that it was a bug fix and it's near the merge window and these random > ARM cleanup serieses never seem to go in quickly. The series is planned for 3.7 merge window. Is it still possible for you to drop the patch from your tree to ease the process? Or I will hold my pull-request to arm-soc until you tell me you have your tree finalized. Shawn -- 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 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote: > On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: > > It's usually pretty early but Takashi will be on holiday this time so > > I'm not sure if things might be different (he was going to send the pull > > request from holiday). I also didn't guarantee that it'll be stable > > yet, can someone please tell me what the depenency is here? > We need the patch to have all imx drivers mach/* inclusion free, > so that we can enable multi-platform support for imx, which is the > whole point of the series. That doesn't answer the question. What is the dependency - what is it about this patch that something else depends on? Your cover letters just say you'd like to do this but don't mention dependencies at all and when I asked the question last night you said the same thing. I've not seen the rest of the series... > If your for-3.7 is not stable anyway, I guess the easiest the way It probably *is* stable but I'm not enthused about people pulling unsigned tags. I might rebase, though - I'm going to finalise the tree in the next few days. > to do it might be you drop the patch "ASoC: mx27vis: retrieve gpio > numbers from platform_data" from your tree and I have it be part of > the series to go via arm-soc tree as a whole. (This is the original > plan that I mentioned in v1 cover letter) You just mentioned it as a preference (you said it's something you'd like to do), please if you're doing this sort of cross tree thing be explicit about what the inter-tree relationships are. If things need to go in via the same tree say so explicitly (and ideally say way this is). The main reason I applied it straight away was that Javier mentioned that it was a bug fix and it's near the merge window and these random ARM cleanup serieses never seem to go in quickly. -- 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] USB: PHY: Re-organize Tegra USB PHY driver
Thanks Greg, for quick response. Venu > -Original Message- > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > Sent: Thursday, September 20, 2012 5:30 PM > To: Venu Byravarasu > Cc: ba...@ti.com; Stephen Warren; linux-ker...@vger.kernel.org; linux- > u...@vger.kernel.org; linux-te...@vger.kernel.org; Stephen Warren; > st...@rowland.harvard.edu > Subject: Re: [PATCH v2] USB: PHY: Re-organize Tegra USB PHY driver > > On Thu, Sep 20, 2012 at 10:50:51AM +0530, Venu Byravarasu wrote: > > Hi Greg & Felipe, > > > > Can any of you please review and merge this change? > > That's up to Felipe. -- 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] USB: PHY: Re-organize Tegra USB PHY driver
On Thu, Sep 20, 2012 at 10:50:51AM +0530, Venu Byravarasu wrote: > Hi Greg & Felipe, > > Can any of you please review and merge this change? That's up to Felipe. -- 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 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote: > It's usually pretty early but Takashi will be on holiday this time so > I'm not sure if things might be different (he was going to send the pull > request from holiday). I also didn't guarantee that it'll be stable > yet, can someone please tell me what the depenency is here? We need the patch to have all imx drivers mach/* inclusion free, so that we can enable multi-platform support for imx, which is the whole point of the series. If your for-3.7 is not stable anyway, I guess the easiest the way to do it might be you drop the patch "ASoC: mx27vis: retrieve gpio numbers from platform_data" from your tree and I have it be part of the series to go via arm-soc tree as a whole. (This is the original plan that I mentioned in v1 cover letter) Shawn -- 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 3/5] uas: remove aborted field, replace with status bit.
Hello. On 19-09-2012 16:40, Gerd Hoffmann wrote: --- You forgot to sign off on this one. WBR, Sergei -- 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 00/34] i.MX multi-platform support
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote: > The first five branches are scheduled to go through the arm-soc tree, so > I'm fine with that. For the sound/for-3.7 branch, I'd like to know when > to expect that hitting mainline. If it always gets in very early during the > merge window, it's probably ok to put the imx/multi-platform patches into > the same branch as the other ones in arm-soc and wait for the sound stuff > to hit mainline first, otherwise I'd suggest we start a second > next/multiplatform-2 branch for imx and send the first part early on > but then wait with the second batch before sound gets in. It's usually pretty early but Takashi will be on holiday this time so I'm not sure if things might be different (he was going to send the pull request from holiday). I also didn't guarantee that it'll be stable yet, can someone please tell me what the depenency is here? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: set hub's default autosuspend delay as 0
This patch sets hub device's default autosuspend delay as 0 to speedup bus suspend, see comments in code for details. Signed-off-by: Ming Lei --- drivers/usb/core/hub.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 382dc41..db17d24 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1625,6 +1625,40 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) desc = intf->cur_altsetting; hdev = interface_to_usbdev(intf); + /* +* Set default autosuspend delay as 0 to speedup bus suspend. +* Based on the below considerations: +* +* - The remote wakeup from child device and new connected +* device doesn't mean that there might be another new device +* which is going to be connected or disconnected to the hub, +* or there might be another wakeup from other devices, in +* the following seconds. +* +* - The wakeup event can be handled completely in hub_resume() +* and khubd, and the submitted status URB is just to check +* future changes on hub downstream ports. +* +* - the introduced hub resume delay during the autosuspend +* delay period doesn't matter for new device to be connected +* into the hub. +* +* - the child device should depend its own autosuspend delay +* to fit its use case and shoudn't depend on the delay of +* parent hub device. +* +* - suppose there is one device which will remote wakeup +* every 2 seconds periodically and does't care the resume +* delay, the bus can't be suspended with previous default +* autosuspend delay at all, not mention in case of several +* hubs connected in the path from the device to root hub. +* +* - it is safe to do so because the hub can't be auto-suspended +* until the remote wakeup is handled by khubd in the device +* remote wakeup path. +*/ + pm_runtime_set_autosuspend_delay(&hdev->dev, 0); + /* Hubs have proper suspend/resume support. */ usb_enable_autosuspend(hdev); -- 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
[PATCH 1/2] USB: check port changes before hub runtime suspend
It is very common that hub status endpoint has a long 'bInterval',
for example, it may be 11(128ms for HS device) or 12(256ms for HS
device), so the device connection change may be reported a bit
later via status pipe.
So there may have device connection changes happened already on the
downstream ports, and no status URB completes when it is killed
in hub auto-suspend path, which may miss the connection change event
and let hub suspend successfully.
This patch introduces check_ports_changed() to check port change event
in auto-suspend path, and recover hub state and return -EBUSY if
change events are found.
The disadvantage is that some delay may be introduced in hub auto-suspend
path.
Signed-off-by: Ming Lei
---
drivers/usb/core/hub.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 6dc41c6..382dc41 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3158,6 +3158,21 @@ int usb_port_resume(struct usb_device *udev,
pm_message_t msg)
#endif
+static int check_ports_changed(struct usb_hub *hub)
+{
+ int port1;
+
+ for (port1 = 1; port1 <= hub->hdev->maxchild; ++port1) {
+ u16 portstatus, portchange;
+ int status;
+
+ status = hub_port_status(hub, port1, &portstatus, &portchange);
+ if (!status && portchange)
+ return 1;
+ }
+ return 0;
+}
+
static int hub_suspend(struct usb_interface *intf, pm_message_t msg)
{
struct usb_hub *hub = usb_get_intfdata (intf);
@@ -3192,6 +3207,15 @@ static int hub_suspend(struct usb_interface *intf,
pm_message_t msg)
/* stop khubd and related activity */
hub_quiesce(hub, HUB_SUSPEND);
+
+ if (PMSG_IS_AUTO(msg)) {
+ /* check if there are changes pending on hub ports */
+ if (check_ports_change(hub)) {
+ hub_activate(hub, HUB_RESUME);
+ return -EBUSY;
+ }
+ }
+
return 0;
}
--
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 v2] USB: remove dbg() usage in USB networking drivers
On Thu, Sep 20, 2012 at 03:07:13AM -0700, Joe Perches wrote:
> On Wed, 2012-09-19 at 20:46 +0100, Greg Kroah-Hartman wrote:
> > The dbg() USB macro is so old, it predates me. The USB networking drivers
> > are
> > the last hold-out using this macro, and we want to get rid of it, so replace
> > the usage of it with the proper netdev_dbg() or dev_dbg() (depending on the
> > context) calls.
>
> OK, one more bit of trivia
>
> > diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
> []
> > @@ -422,8 +419,9 @@ static int net1080_rx_fixup(struct usbnet *dev, struct
> > sk_buff *skb)
> > if (!(skb->len & 0x01)) {
> > #ifdef DEBUG
> > struct net_device *net = dev->net;
> > - dbg("rx framesize %d range %d..%d mtu %d", skb->len,
> > - net->hard_header_len, dev->hard_mtu, net->mtu);
> > + netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
> > + skb->len, net->hard_header_len, dev->hard_mtu,
> > + net->mtu);
> > #endif
>
> maybe
> netdev_dbg(net, ...
>
> or remove the odd #ifdef DEBUG surround used to guard
> the otherwise unused net variable and use:
>
> netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
> skb->len, dev->net->hard_header_len, dev->hard_mtu,
> dev->net->mtu);
>
Yeah, that would be better.
Even better would be just to delete all of this debug crud from these
drivers. Almost all of the messages are there from when the developer
originally wrote the driver, trying to figure out what was going on.
>From what I have seen, in doing all of these cleanups, is that the need
for maybe a few debug lines that can be used if users have issues, but
the majority are just useless.
But, as I'm not the author or maintainer of these drivers, I'll be nice
and just leave them in, all I want to do is get rid of the old, foolish,
macros for debugging and use the proper dynamic debug code that works so
much better.
So I'll leave this change alone, and if someone wants to do the cleanup
better, the 3 liner above is fine with me to add later.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: remove dbg() usage in USB networking drivers
On Wed, 2012-09-19 at 20:46 +0100, Greg Kroah-Hartman wrote:
> The dbg() USB macro is so old, it predates me. The USB networking drivers are
> the last hold-out using this macro, and we want to get rid of it, so replace
> the usage of it with the proper netdev_dbg() or dev_dbg() (depending on the
> context) calls.
OK, one more bit of trivia
> diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
[]
> @@ -422,8 +419,9 @@ static int net1080_rx_fixup(struct usbnet *dev, struct
> sk_buff *skb)
> if (!(skb->len & 0x01)) {
> #ifdef DEBUG
> struct net_device *net = dev->net;
> - dbg("rx framesize %d range %d..%d mtu %d", skb->len,
> - net->hard_header_len, dev->hard_mtu, net->mtu);
> + netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
> +skb->len, net->hard_header_len, dev->hard_mtu,
> +net->mtu);
> #endif
maybe
netdev_dbg(net, ...
or remove the odd #ifdef DEBUG surround used to guard
the otherwise unused net variable and use:
netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
skb->len, dev->net->hard_header_len, dev->hard_mtu,
dev->net->mtu);
--
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: fix missed resume for auto-suspend failed interface
On Thursday 20 September 2012 16:26:18 Ming Lei wrote: > On Thu, Sep 20, 2012 at 3:29 PM, Oliver Neukum wrote: > > On Thursday 20 September 2012 13:28:51 Ming Lei wrote: > >> If one usb interface driver returns failure from its > >> suspend(auto) callback inside usb_suspend_both, its > >> resume() callback should be called to recover its > >> working state. > > > > NO! > > > > The interface is defined so that if you fail, this is your > > problem. You cannot simply change the API. This patch > > is absolutely wrong. > > Sorry, you are right, it is my fault, :-( No problem, that is why we review patches. And writing innovative patches means that some patches wil have fundamental problems. 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: [RFC PATCH 0/3] usbnet: support runtime PM triggered by link change
Ming Lei writes: > On Mon, Sep 17, 2012 at 4:04 PM, Oliver Neukum wrote: > >> 1) Does it actually save power? You are constantly waking up a CPU. > > Of course, it does. I don't know it will save how much power just on > usbnet device, but it may save power from usb hub and usb host > controller in the bus at least. > > Anyway we don't need to waste power if the link of usbnet is down. > > It just wake up CPU one time each 3sec. In modern linux distribution, > the CPU will be wakup tens times per second, so it shouldn't be a > big problem. I do not buy that constantly polling a device necessarily saves any power compared to keeping the USB link to the device alive. You need to measure the savings if you want us to believe that. You are not only waking the host CPU. You are also waking the device CPU. Any usbnet device will consist of more than one building block, having at least a network block, a USB block and a CPU. For all you know, the device CPU might be in deep sleep until it has to service either the network or USB block, and those might also be sleeping until they see an interrupt. Constantly polling the device to receive network link status might use considerably more power than keeping the USB link up waiting for a link notification. If you were to implement this feature anyway, then I would prefer a userspace based approach instead. I see no reason to keep the timer in the kernel. You could decide to suspend whenever the netdev is down, and only poll the link when userspace tries to bring up the netdev. That would let a userspace daemon implement the same feature by trying to bring up the netdev every 3 seconds (or whatever frequency the user selected). And it would allow me to avoid the polling until I know I have plugged in a cable. >> From that perspective it is possible that leaving on the ethernet is actually >> better in terms of power. Only measurements can answer that question. > > You know it is a bit difficult to test power save for this situation. And > most of runtime PM patches didn't provide power save data. In fact, > I'd like to do it, but I have not some equipment to measure it, :-(. We don't know, you don't know. But you claim that your change saves power, so please provide some documentation showing that it does. >> 2) Do we have many devices that would be serviced with this approach? > > At least I found asix can be serviced by this approach. Considered asix > is quite popular, it is worthy of the effort. Also the below devices can be > serviced by the patch in theory: > >dm9601.c / mcs7830.c / sierra_net.c The sierra_net.c driver is only used for wireless devices AFAIK. I really don't see the use case for network link based resume of that. There is no cable to plug. Userspace will have to initiate a connection. And the DirectIP device I've got (MC7710) supports remote wakeup. I assume that will be the case for all such devices, given that this is mostly a firmware feature. So the correct fix for sierra_net.c is to add support for remote wakeup. Then you will be able to suspend the device regardless of whether the link is up or down, without the constant polling. Bjørn -- 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: fix missed resume for auto-suspend failed interface
On Thu, Sep 20, 2012 at 3:29 PM, Oliver Neukum wrote: > On Thursday 20 September 2012 13:28:51 Ming Lei wrote: >> If one usb interface driver returns failure from its >> suspend(auto) callback inside usb_suspend_both, its >> resume() callback should be called to recover its >> working state. > > NO! > > The interface is defined so that if you fail, this is your > problem. You cannot simply change the API. This patch > is absolutely wrong. Sorry, you are right, it is my fault, :-( Thanks, -- Ming Lei -- 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
AW: AW: USB problem on beagleboard clone
> -Ursprüngliche Nachricht- > Von: Paul Walmsley [mailto:p...@pwsan.com] > Gesendet: Mittwoch, 19. September 2012 18:07 > An: Maximilian Schwerin > Cc: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org > Betreff: Re: AW: USB problem on beagleboard clone > > On Wed, 19 Sep 2012, Maximilian Schwerin wrote: > > > They're BeagleBoard XM clones. We're still trying to find > out what the > > real problem is. The problem persists across three separate layouts > > using the same USB device and application. We're currently > trying to see > > if this is related to MUSB only by using an EHCI port on > the same board > > with the same device and application. > > Perhaps you might try this patch: > > http://marc.info/?l=linux-omap&m=132976109928744&w=2 > > Background is here: > > http://comments.gmane.org/gmane.linux.ports.arm.omap/71633 > > The patch is for an EHCI issue, but MUSB is clocked from the > same DPLL. > > > - Paul > Thanks for the hint. I had this in my 3.2 kernel which also failed. I'll try if adding this to 3.6 has any effect. pgpyjT758fz5b.pgp Description: PGP signature
Re: [PATCH v2 00/34] i.MX multi-platform support
On Thursday 20 September 2012, Shawn Guo wrote: > > Here is the second post, which should have addressed the comments that > reviewers put on v1. > > It's available on branch below. > > git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform-v2 > > And it's based on the following branches. > > calxeda/multi-plat > arm-soc/multiplatform/platform-data > arm-soc/multiplatform/smp_ops > arm-soc/imx/cleanup > arm-soc/imx/dt > sound/for-3.7 > > Subsystem maintainers, > > I plan to send the whole series for 3.7 via arm-soc tree. Please let > me know if you have problem with that. Thanks. The first five branches are scheduled to go through the arm-soc tree, so I'm fine with that. For the sound/for-3.7 branch, I'd like to know when to expect that hitting mainline. If it always gets in very early during the merge window, it's probably ok to put the imx/multi-platform patches into the same branch as the other ones in arm-soc and wait for the sound stuff to hit mainline first, otherwise I'd suggest we start a second next/multiplatform-2 branch for imx and send the first part early on but then wait with the second batch before sound gets in. Arnd -- 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: fix missed resume for auto-suspend failed interface
On Thursday 20 September 2012 13:28:51 Ming Lei wrote: > If one usb interface driver returns failure from its > suspend(auto) callback inside usb_suspend_both, its > resume() callback should be called to recover its > working state. NO! The interface is defined so that if you fail, this is your problem. You cannot simply change the API. This patch is absolutely wrong. 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-next] net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200
One of the modes of Huawei E367 has this QMI/wwan interface:
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Huawei use subclass and protocol to identify vendor specific
functions, so adding a new vendor rule for this combination.
The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
the same subclass to identify the QMI/wwan function. Replace the
existing device specific UML290 entries with generic vendor matching,
adding support for the Pantech P4200.
The ZTE MF683 has 6 vendor specific interfaces, all using
ff/ff/ff for cls/sub/prot. Adding a match on interface #5 which
is a QMI/wwan interface.
Cc: Fangxiaozhi (Franko)
Cc: Thomas Schäfer
Cc: Dan Williams
Cc: Shawn J. Goff
Signed-off-by: Bjørn Mork
---
Hello David,
This is the net-next version of the previously posted patch with the
same title. I totally forgot that I had messed with the .driver_info
fields, making it impossible to apply the same patch to both net and
net-next.
Sorry about that. Please apply this version to net-next. The other
one should still be applied to net (if still possible) and stable.
Thanks,
Bjørn
drivers/net/usb/qmi_wwan.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index e7b53f0..ca25320 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -353,16 +353,20 @@ static const struct usb_device_id products[] = {
},
/* 2. Combined interface devices matching on class+protocol */
+ { /* Huawei E367 and possibly others in "Windows mode" */
+ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 1, 7),
+ .driver_info= (unsigned long)&qmi_wwan_info,
+ },
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
USB_CLASS_VENDOR_SPEC, 1, 17),
.driver_info= (unsigned long)&qmi_wwan_info,
},
- { /* Pantech UML290 */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718,
USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
+ { /* Pantech UML290, P4200 and more */
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC,
0xf0, 0xff),
.driver_info= (unsigned long)&qmi_wwan_info,
},
{ /* Pantech UML290 - newer firmware */
- USB_DEVICE_AND_INTERFACE_INFO(0x106c, 0x3718,
USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
+ USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC,
0xf1, 0xff),
.driver_info= (unsigned long)&qmi_wwan_info,
},
@@ -370,6 +374,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x19d2, 0x0055, 1)},/* ZTE (Vodafone) K3520-Z */
{QMI_FIXED_INTF(0x19d2, 0x0063, 4)},/* ZTE (Vodafone) K3565-Z */
{QMI_FIXED_INTF(0x19d2, 0x0104, 4)},/* ZTE (Vodafone) K4505-Z */
+ {QMI_FIXED_INTF(0x19d2, 0x0157, 5)},/* ZTE MF683 */
{QMI_FIXED_INTF(0x19d2, 0x0167, 4)},/* ZTE MF820D */
{QMI_FIXED_INTF(0x19d2, 0x0326, 4)},/* ZTE MF821D */
{QMI_FIXED_INTF(0x19d2, 0x1008, 4)},/* ZTE (Vodafone) K3570-Z */
--
1.7.10.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 02/12] usb: chipidea: udc: add pullup fuction, needed by the uvc gadget
On Wed, Sep 12, 2012 at 7:58 PM, Alexander Shishkin
wrote:
> From: Michael Grzeschik
>
> Add function to physicaly enable or disable of pullup connection on the USB-D+
> line. The uvc gaget will fail, if this function is not implemented.
>
> Cc:
> Signed-off-by: Michael Grzeschik
> Acked-by: Felipe Balbi
> Signed-off-by: Marc Kleine-Budde
> Signed-off-by: Alexander Shishkin
> ---
> drivers/usb/chipidea/udc.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 7801a3f..32ee870 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -78,8 +78,7 @@ static inline int ep_to_bit(struct ci13xxx *ci, int n)
> }
>
> /**
> - * hw_device_state: enables/disables interrupts & starts/stops device
> (execute
> - * without interruption)
> + * hw_device_state: enables/disables interrupts (execute without
> interruption)
> * @dma: 0 => disable, !0 => enable and set dma engine
> *
> * This function returns an error code
> @@ -91,9 +90,7 @@ static int hw_device_state(struct ci13xxx *ci, u32 dma)
> /* interrupt, error, port change, reset, sleep/suspend */
> hw_write(ci, OP_USBINTR, ~0,
> USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
> - hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> } else {
> - hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> hw_write(ci, OP_USBINTR, ~0, 0);
> }
Hi Marc, your above change break the function that load gadget before
plug usb cable.
Does your change is because the set/clear usbcmd.rs twice at
usb_gadget_probe_driver
/usb_gadget_remove_driver? If it is, do you mind I submit a patch to re-add it?
> return 0;
> @@ -1420,6 +1417,21 @@ static int ci13xxx_vbus_draw(struct usb_gadget
> *_gadget, unsigned mA)
> return -ENOTSUPP;
> }
>
> +/* Change Data+ pullup status
> + * this func is used by usb_gadget_connect/disconnet
> + */
> +static int ci13xxx_pullup(struct usb_gadget *_gadget, int is_on)
> +{
> + struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
> +
> + if (is_on)
> + hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> + else
> + hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> +
> + return 0;
> +}
> +
> static int ci13xxx_start(struct usb_gadget *gadget,
> struct usb_gadget_driver *driver);
> static int ci13xxx_stop(struct usb_gadget *gadget,
> @@ -1432,6 +1444,7 @@ static int ci13xxx_stop(struct usb_gadget *gadget,
> static const struct usb_gadget_ops usb_gadget_ops = {
> .vbus_session = ci13xxx_vbus_session,
> .wakeup = ci13xxx_wakeup,
> + .pullup = ci13xxx_pullup,
> .vbus_draw = ci13xxx_vbus_draw,
> .udc_start = ci13xxx_start,
> .udc_stop = ci13xxx_stop,
> --
> 1.7.10.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
--
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
