Re: kmemleak report on isp1763 and sierra MC8705
On 29/10/12 06:14 PM, Alan Stern wrote: On Mon, 29 Oct 2012, Richard Retanubun wrote: Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm "khubd", pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [] usb_cache_string+0x74/0xac [usbcore] [] usb_enumerate_device+0x44/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) It doesn't get released during usb_serial_disconnect(). It gets released during usb_release_dev() in drivers/usb/core/usb.c. Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? Probably not. I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. They aren't all that closely related. usb_release_dev() won't be called until all references to the USB device have been dropped. Maybe there's an extra reference hanging around. Alan Stern Thanks a lot for the hint Alan. I added a dev_dbg print in usb_release_dev() and saw that in the builds where there is a leak, this was simply never called! the last line printed in a trace with all dev_dbg on is this "usb_disable_device nuking all URBs" When the sierra modem is unplugged, the cleanup sequence never calls usb_release_dev() (on PL2303 it always calls usb_release_dev() This is the current state of versions from linux-stable 3.0.y (3.0.51) - Have the issue 3.2.y (3.2.33) - Have the issue 3.4.y (3.4.18) - Have the issue 3.5.y (3.5.7) - Does not have the issue (but leaks because the portdata patches is not backported yet) 3.6.y (3.6.6) - Does not have the issue So a diff between 3.4.y and 3.5.y ought to narrow it down further. I am posting just in case someone recalls a particular patch I should be trying out first... -- RR -- -- 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 3/5] usb: expose usb port's pm qos flags to user space
On Fri, 9 Nov 2012, Lan Tianyu wrote: > This patch is to expose usb port's pm qos flags(pm_qos_no_power_off, > pm_qos_remote_wakeup) to user space. The pm_qos_no_power_off will > be used to control usb port auto power off mechanism from user space. Something here doesn't look right... > @@ -1289,8 +1290,16 @@ static int usb_hub_create_port_device(struct usb_hub > *hub, > retval = device_register(&port_dev->dev); > if (retval) > goto error_register; > + > + retval = dev_pm_qos_expose_flags(&port_dev->dev, > + PM_QOS_FLAG_NO_POWER_OFF); > + if (retval) > + goto error_expose_pm_qos; > + > return 0; > > +error_expose_pm_qos: > + device_unregister(&port_dev->dev); > error_register: > put_device(&port_dev->dev); device_unregister() calls put_device() for you. You probably want device_del() instead of device_unregister(). 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
[GIT PULL] USB patches
Hi Greg, Here are gadget patches for v3.8, and it also conflicts with your usb-next branch. Below you can find my resolution (suggested by Kuninori): diff --cc drivers/usb/renesas_usbhs/fifo.c index c021b20,72ad375..9538f0f --- a/drivers/usb/renesas_usbhs/fifo.c +++ b/drivers/usb/renesas_usbhs/fifo.c @@@ -795,7 -798,7 +798,8 @@@ static void xfer_work(struct work_struc dev_dbg(dev, " %s %d (%d/ %d)\n", fifo->name, usbhs_pipe_number(pipe), pkt->length, pkt->zero); + usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->trans); + usbhs_pipe_enable(pipe); usbhsf_dma_start(pipe, fifo); dma_async_issue_pending(chan); } The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/gadget-for-v3.8 for you to fetch changes up to f72e3b78867142a19b77f1de0698ce8b03dc6cbd: usb: gadget: ncm: correct endianess conversion (2012-11-08 16:05:39 +0200) usb: gadget: patches for v3.8 renesas_usbhs implements ->pullup() method, switches over to devm_request_irq(), adds support for DMA Engine and got a few miscelaneous cleanups. The NCM gadget got an endianness fix and the Ethernet gadget a frame size fix. We're finally removing the g_file_storage gadget and sticking to g_mass_storage and the new tcm_usb_gadget gadgets since that was a huge duplicaton of effort anyway. While removing g_file_storage, we also had to fix a bunch of defconfigs which were still pointing to the old gadget. There's a big series getting us closer to being able to introduce our configfs interface. The series converts functions into loadable modules which will, eventually, be registered to the configfs interface. Other than that there's the usual typo fixes and miscelaneous cleanups all over the place. Alexandre Pereira da Silva (1): usb: gadget: lpc32xx_udc: Disable setup request error Dmytro Milinevskyy (1): usb: gadget: ncm: correct endianess conversion Ian Coolidge (1): usb: gadget: g_ether: fix frame size check Kuninori Morimoto (7): usb: renesas_usbhs: gadget: add usb_gadget_ops :: pullup support usb: renesas_usbhs: use devm_request_irq() usb: renesas_usbhs: fixup unreadable macro usb: renesas_usbhs: add DMAEngine support on mod_host usb: renesas_usbhs: remove debug information from usbhsh_hub_status_data() usb: renesas_usbhs: host: add endpoint user counter usb: renesas_usbhs: use transfer counter if IN direction bulk pipe Masanari Iida (1): usb: fix typo in drivers/usb Michal Nazarewicz (6): arch: Change defconfigs to point to g_mass_storage. usb: gadget: Remove File-backed Storage Gadget (g_file_storage). usb: gadget: storage_common: Remove FSG specific definitions. usb: gadget: storage_common: Drop #ifdefs used for the sake of FSG. usb: gadget: storage_common: Make fsg_lun_is_open() a function. usb: gadget: Remove reference to is_dualspeed from sysfs. Sebastian Andrzej Siewior (19): usb: gadget: ecm: Add IAD descriptor in SS mode usb: gadget: tcm_usb_gadget: NULL terminate the FS descriptor list usb: gadget: use a computation macro for INT endpoint interval usb: gadget storage: use a computation macro for INT endpoint interval usb: gadget: uac2: add some error recovery in afunc_bind() usb: gadget: network: fix bind() error path usb: gadget: audio: remove c->highpseed = true from f_midi and uac1 usb: gadget: midi: free hs descriptors usb: gadget: midi: make FS and HS available usb: gadget: phonet: free requests in pn_bind()'s error path usb: gadget: uvc: fix error path in uvc_function_bind() usb: gadget: always update HS/SS descriptors and create a copy of them usb: gadget: remove DMA_ADDR_INVALID from f_uac2 and gadgetfs usb: gadget: uac2: provide a variable for interface and alt settings usb: gadget: uac2: use the strings directly usb: gadget: let f_* use usb_string_ids_tab() where it makes sense usb: gadget: dummy_hdc: prepare for multiple instances usb: gadget: dummy_hcd: add setup / cleanup of multiple HW intances usb: gadget: dummy_hcd: remove global the_controller variable Documentation/DocBook/gadget.tmpl |2 +- Documentation/usb/mass-storage.txt | 15 +- arch/arm/configs/afeb9260_defconfig|2 +- arch/arm/configs/at91sam9260_defconfig |2 +- arch/arm/configs/at91sam9261_defconfig |2 +- arch/arm/configs/at91sam9263_defconfig |2 +- arch/arm/configs/at91sam9g20_defconfig |2 +- arch/arm/configs/corgi_defconfig |2 +- a
[GIT PULL] usb: dwc3: patches for v3.8 merge window
Hi Greg,
Here are dwc3 patches for v3.8. This will also conflict with your usb-next
branch and below you can find my resolution:
diff --cc drivers/usb/dwc3/core.c
index c14ebc9,2bd007d..4174054
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@@ -408,11 -355,6 +355,10 @@@ err0
static void dwc3_core_exit(struct dwc3 *dwc)
{
dwc3_event_buffers_cleanup(dwc);
- dwc3_free_event_buffers(dwc);
+
+ usb_phy_shutdown(dwc->usb2_phy);
+ usb_phy_shutdown(dwc->usb3_phy);
+
}
#define DWC3_ALIGN_MASK (16 - 1)
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/dwc3-for-v3.8
for you to fetch changes up to e32672f0bc7ec8421aa8e580e9f2216d3bec2505:
usb: dwc3: core: don't kfree() devm_kzalloc()'ed memory (2012-11-08 15:26:41
+0200)
usb: dwc3: patches for v3.8
We can finaly drop HAVE_CLK dependency from exynos glue layer
now that clk API provides no-op stubs when it's not linked
into the kernel.
We're also switching over event buffer allocation to devm_kzalloc()
and moving the allocation out of dwc3_core_init() so that can be
re-used when implementing PM support for v3.9.
After the introduction of PLATFORM_DEVID_AUTO, we can also drop the
homebrew platform device ID handling we had on dwc3 core and let
driver core take care of that for us.
Exynos glue layer learns about DeviceTree and drops platform_data
support completely.
Felipe Balbi (4):
usb: dwc3: core: switch event buffer allocation to devm_kzalloc()
usb: dwc3: core: move event buffer allocation out of dwc3_core_init()
usb: dwc3: drop HAVE_CLK dependency from Exynos glue layer
usb: dwc3: core: don't kfree() devm_kzalloc()'ed memory
Sebastian Andrzej Siewior (1):
usb: dwc3: remove custom unique id handling
Vivek Gautam (2):
usb: dwc3: exynos: add support for device tree
usb: dwc3: exynos: remove platform data support
drivers/usb/dwc3/Makefile | 14 +---
drivers/usb/dwc3/core.c| 76 +-
drivers/usb/dwc3/core.h| 3 --
drivers/usb/dwc3/dwc3-exynos.c | 49 ---
drivers/usb/dwc3/dwc3-omap.c | 16 ++---
drivers/usb/dwc3/dwc3-pci.c| 16 ++---
6 files changed, 43 insertions(+), 131 deletions(-)
--
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
[GIT PULL] usb: musb: patches for v3.8 merge window
Hi Greg,
MUSB changes for v3.8 follow. This will conflict with your usb-next branch,
below you can find the resolution I used:
diff --cc drivers/usb/musb/musb_dsps.c
index ff5f112,e770f79..cf08966a
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@@ -458,14 -489,24 +489,24 @@@ static int __devinit dsps_create_musb_p
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
- char res_name[10];
+ char res_name[11];
- int ret, musbid;
+ int ret;
- /* get memory resource */
- snprintf(res_name, sizeof(res_name), "musb%d", id);
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, res_name);
+ resources[0].start = dsps_control_module_phys[id];
+ resources[0].end = resources[0].start + SZ_4 - 1;
+ resources[0].flags = IORESOURCE_MEM;
+
+ glue->usb_ctrl[id] = devm_request_and_ioremap(&pdev->dev, resources);
+ if (glue->usb_ctrl[id] == NULL) {
+ dev_err(dev, "Failed to obtain usb_ctrl%d memory\n", id);
+ ret = -ENODEV;
+ goto err0;
+ }
+
+ /* first resource is for usbss, so start index from 1 */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, id + 1);
if (!res) {
- dev_err(dev, "%s get mem resource failed\n", res_name);
+ dev_err(dev, "failed to get memory for instance %d\n", id);
ret = -ENODEV;
goto err0;
}
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/musb-for-v3.8
for you to fetch changes up to d928cd2ef8f7f4194e479d4a66452901ec82ccda:
usb: musb: dsps: document dt bindings properly (2012-11-09 08:02:08 +0200)
usb: musb: patches for v3.8 merge window
We have here the usual set of cleanups for the MUSB driver; a
big set of patches converting platform_device_del() and
platform_device_put() into platform_device_unregister().
Another big set was applied converting to module_platform_driver()
macro in order to reduce some boilerplate code from all glue
layers.
Other than that, we had a series fixing one known silicon errata
where we couldn't read a few registers. In order to fix that
we're now using shadow variables for reads and only writing
to the registers which are known to break functionality when
read.
Afzal Mohammed (5):
usb: musb: dsps: remove platform callback
usb: musb: dsps: reduce musb instance to one
usb: musb: dsps: get resources by index
Revert "usb: musb: dsps: remove explicit NOP device creation"
usb: musb: dsps: document dt bindings properly
Philippe De Swert (1):
usb: musb: remove generic_interrupt
Santhapuri, Damodar (1):
usb: musb: dsps: control module handling (quirk)
Sebastian Andrzej Siewior (5):
usb: musb: read MUSB_POWER register only when required.
usb: musb: avoid FADDR read access
usb: musb: Perform only write access on MUSB_INTRRXE
usb: musb: Perform only write access on MUSB_INTRTXE
usb: musb: remove hand-crafted id handling
Sergei Shtylyov (1):
usb: musb: cppi_dma: export cppi_interrupt()
Srinivas Kandagatla (6):
usb: musb: am35x: use module_platform_driver macro
usb: musb: blackfin: use module_platform_driver macro
usb: musb: da8xx: use module_platform_driver macro
usb: musb: davinci: use module_platform_driver macro
usb: musb: tusb6010: use module_platform_driver macro
usb: musb: ux500: use module_platform_driver macro
Wei Yongjun (7):
usb: musb: am35x: use platform_device_unregister in am35x_remove()
usb: musb: blackfin: use platform_device_unregister in bfin_remove()
usb: musb: da8xx: use platform_device_unregister in da8xx_remove()
usb: musb: davinci: use platform_device_unregister in davinci_remove()
usb: musb: dsps: use platform_device_unregister in dsps_delete_musb_pdev()
usb: musb: tusb6010: use platform_device_unregister in tusb_remove()
usb: musb: ux500: use platform_device_unregister in ux500_remove()
.../devicetree/bindings/usb/am33xx-usb.txt | 8 +-
drivers/usb/musb/am35x.c | 34 +-
drivers/usb/musb/blackfin.c| 34 +-
drivers/usb/musb/cppi_dma.c| 1 +
drivers/usb/musb/da8xx.c | 34 +-
drivers/usb/musb/davinci.c | 34 +-
drivers/usb/musb/musb_core.c | 96
drivers/usb/musb/musb_core.h | 5 +-
drivers/usb/musb/musb_dsps.c | 125 -
drivers/usb/musb/
[GIT PULL] usb: xceiv: patches for v3.8 merge window
Hi Greg, Here are the transceiver patches for v3.8 merge window. Let me know if you want any changes. Have a nice weekend ps: for samsung folks, I'm sorry but I couldn't wait any longer. The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/xceiv-for-v3.8 for you to fetch changes up to 1789e52acc90c87484a109d6349eefe63cabb257: usb: phy: add R-Car USB phy driver (2012-11-01 12:17:53 +0200) usb: phy: patches for v3.8 merge window Not too many patches this time. First two patches are only cleanups where one of them switches over to module_platform_driver macro and the second removes inclusion of and is part of a bigger set of include cleanups from the Tegra folks. The only substantial change here is the addition of a driver for Renesas' R-Car USB Phy controller. Kuninori Morimoto (1): usb: phy: add R-Car USB phy driver Srinivas Kandagatla (1): usb: phy: mv_otg: use module_platform_driver macro Stephen Warren (1): usb: phy: tegra remove include of drivers/usb/otg/mv_otg.c| 14 +-- drivers/usb/phy/Kconfig | 12 +++ drivers/usb/phy/Makefile| 1 + drivers/usb/phy/rcar-phy.c | 220 drivers/usb/phy/tegra_usb_phy.c | 4 +- 5 files changed, 237 insertions(+), 14 deletions(-) create mode 100644 drivers/usb/phy/rcar-phy.c -- 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: Device detected as Digitalcamera (PTP?) instead of Portable Device (MTP?) - MS_COMP_MTP - WinXP
On 09.11.2012 16:40, Peter Stuge wrote: Microsoft OS Descriptors Thanks a lot. It seams that the Android [1] has the 'Microsoft OS Descriptors' implemented while Meego has not. Porting from the Android code don't seems to be straightforward for me - do you know a better solution? According Brett [2] the 'Microsoft OS Descriptors' are required to get MTP running on WinXP. They also say, that they are only requested if using 'Vendor Class Codes' - otherwise PHP is used. I personally would prefer using the MTP class codes - especially since they are supported by all current Windows versions. Regards, Charly [1] https://bitbucket.org/thekraven/lge-kernel-star/src/8fbcd136a82c/drivers/usb/gadget/f_mtp.c#cl-219 [2] http://www.digipedia.pl/usenet/thread/19505/14786/#post14156 -- 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 enclosures seem to require read(16) with >2TB drives
I recommend broadening this patch. T10 is discussing making READ (10), WRITE
(10), etc. obsolete in SBC-4 in favor of their 16-byte CDB counterparts.
The algorithm should be:
1. During discovery, determine if 16-byte CDBs are supported. There are
several ways to determine this:
a) REPORT SUPPORTED OPERATION CODES command succeeds and reports that READ (16)
et al are supported.
b) READ (16) command specifying a Transfer Length of zero succeeds.
c) READ CAPACITY (16) command succeeds and reports that the capacity is > 2 TiB.
d) (future) INQUIRY command succeeds fetching the Block Device Characteristics
VPD page and notices a new field added by the SBC-4 simplified SCSI feature set
proposal.
Since REPORT SUPPORTED OPERATION CODES is optional, it won't always work. READ
CAPACITY (16) used to be optional for < 2 TiB drives, so it won't always work
either. READ (16) will always work, but requires the drive to be spun up
beforehand (e.g., with START STOP UNIT).
2. if 16-byte CDBs are supported, then use them; only drop down to 10-byte CDBs
if 16-byte CDBs are unavailable. Don't make the decision by comparing the LBA
on every IO.
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Jason J. Herne
Sent: Friday, November 09, 2012 9:08 AM
To: linux-s...@vger.kernel.org
Cc: linux-usb@vger.kernel.org; st...@rowland.harvard.edu; Jason J. Herne
Subject: [PATCH] USB enclosures seem to require read(16) with >2TB drives
From: "Jason J. Herne"
Force large capacity (> 2TB) drives in USB enclosures to use READ(16) instead
of READ(10). Some(most/all?) enclosures do not like READ(10) commands when a
large capacity drive is installed.
Signed-off-by: Jason J. Herne
---
drivers/scsi/sd.c |7 +--
drivers/usb/storage/scsiglue.c |5 +
include/scsi/scsi_device.h |1 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 4b63c73..9b65ddf 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -649,7 +649,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
sector_t block = blk_rq_pos(rq);
sector_t threshold;
unsigned int this_count = blk_rq_sectors(rq);
- int ret, host_dif;
+ int ret, host_dif, force_read16;
unsigned char protect;
/*
@@ -797,6 +797,9 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
else
protect = 0;
+ /* Many large capacity USB drives/controllers require the use of
read(16). */
+ force_read16 = (sdkp->capacity > 0xULL && sdp->force_read_16);
+
if (host_dif == SD_DIF_TYPE2_PROTECTION) {
SCpnt->cmnd = mempool_alloc(sd_cdb_pool, GFP_ATOMIC);
@@ -833,7 +836,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
SCpnt->cmnd[29] = (unsigned char) (this_count >> 16) & 0xff;
SCpnt->cmnd[30] = (unsigned char) (this_count >> 8) & 0xff;
SCpnt->cmnd[31] = (unsigned char) this_count & 0xff;
- } else if (block > 0x) {
+ } else if (block > 0x || force_read16) {
SCpnt->cmnd[0] += READ_16 - READ_6;
SCpnt->cmnd[1] = protect | ((rq->cmd_flags & REQ_FUA) ? 0x8 :
0);
SCpnt->cmnd[2] = sizeof(block) > 4 ? (unsigned char) (block >>
56) & 0xff : 0;
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device *sdev)
US_FL_SCM_MULT_TARG)) &&
us->protocol == USB_PR_BULK)
us->use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev->force_read_16 = 1;
+
+
} else {
/* Non-disk-type devices don't need to blacklist any pages
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 5591ed5..e92b846 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -134,6 +134,7 @@ struct scsi_device {
* because we did a bus reset. */
unsigned use_10_for_rw:1; /* first try 10-byte read / write */
unsigned use_10_for_ms:1; /* first try 10-byte mode sense/select */
+ unsigned force_read_16:1; /* Use read(16) over read(10) */
unsigned skip_ms_page_8:1; /* do not use MODE SENSE page 0x08 */
unsigned skip_ms_page_3f:1; /* do not use MODE SENSE page 0x3f */
unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: usb: class: cdc-acm: /dev/ttyACM0 HowTo disable interrupt and control URBs
On 09.11.2012 15:43, Oliver Neukum wrote:
On Friday 09 November 2012 14:42:24 Markus Kolb wrote:
[...]
I've found e.g.
URB_NO_INTERRUPT and USBDEVFS_URB_NO_INTERRUPT in
http://code.metager.de/source/xref/linux/stable/drivers/usb/core/devio.c#1386
but how do I set this?
You don't. This is for usbfs. If your modem cannot handle status
transfers it makes no sense to use cdc-acm. You better blacklist the
device and use usb-serial.
Ok. Should the vendor_id/product_id combination be blacklisted in
cdc-acm?
I think the device is detected for cdc-acm because of
http://code.metager.de/source/xref/linux/stable/drivers/usb/class/cdc-acm.c#1653
1653/* control interfaces without any protocol set */
1654{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
1655USB_CDC_PROTO_NONE) },
Or is udev the right place to handle buggy descriptors?
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: USB enclosures seem to require read(16) with >2TB drives
On Fri, 9 Nov 2012, Jason J. Herne wrote: > Hello, I've noticed Linux seems to have issues with external USB > enclosures containing drives > 2 TB. The USB mass storage driver > apparently emulates a SCSI device and sends a read/write(10) for all Actually, it's the SCSI disk driver which decides whether to use the 10-byte or 16-byte commands. > requests where the target sector is not large enough to require the > use of read(16). The issue is that both of the enclosures I was able > to test with do not properly accept this read(10) command when a 3TB > drive (Seagate ST3000DM) is installed. A wireshark USB trace shows > the read(10) command is sent to the drive and the drive never > responds. The same drive/enclosure used in Windows 7 shows that > read(16) is always used to communicate with the drive and the drive > works without issue with Windows 7. > > A few notable points: > 1. The drive operates without issue when connected to an internal Sata > port on my computer. > 2. The enclosure operates without issue with Linux (using read(10) ) > when a <2TB drive is installed. > 3. I have reproduced this problem on several computers, and using > several Linux kernels, including 3.7.0-rc4-next. > > I first reported this to the linux-usb list thinking it was a USB > issue. At the request of Alan Stern I am also reporting it here. > > I'm not sure if I am taking the correct approach but I have written a > simple patch that resolves the problem for me. In essence, the patch > adds a new bit to scsi_device that indicates it should favor > read/write(16) over read/write(10). sd_prep_fn is modified to check > this bit, and use a 16 byte operations when a large capacity drive is > in use and this bit is on. Finally, the USB storage driver's scsi glue > code is modified to turn this bit on for all of its devices. Not sure > if this is the correct fix, but it works for me. I'm willing to It's not correct, because it will break USB drives that don't recognize the 16-byte commands. The bit should be set only for disks that have 2^32 or more blocks, or maybe only for disks that hold 2^41 or more bytes (and maybe only for USB disks). Since usb-storage doesn't know the disk's capacity, the decision about whether to set the new bit has to be made in the SCSI disk driver. 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: [RFC PATCH 5/5] usb: add usb port's pm qos flags request to change NO_POWER_OFF flag
On Fri, 9 Nov 2012, Lan Tianyu wrote: > Some usb devices can't be resumed correctly after power off. This > patch is to add pm qos flags request to change NO_POWER_OFF and > provide usb_device_allow_power_off() for device drivers to allow or > prohibit usb core to power off the device. If the reason for adding this request is to prevent the device from being powered off, then shouldn't the PM QOS flag be associated with device rather than with the port? In fact, it seems reasonable to have such a flag for both the device and the port. 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] USB enclosures seem to require read(16) with >2TB drives
From: "Jason J. Herne"
Force large capacity (> 2TB) drives in USB enclosures to use READ(16) instead
of READ(10). Some(most/all?) enclosures do not like READ(10) commands when a
large capacity drive is installed.
Signed-off-by: Jason J. Herne
---
drivers/scsi/sd.c |7 +--
drivers/usb/storage/scsiglue.c |5 +
include/scsi/scsi_device.h |1 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 4b63c73..9b65ddf 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -649,7 +649,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
sector_t block = blk_rq_pos(rq);
sector_t threshold;
unsigned int this_count = blk_rq_sectors(rq);
- int ret, host_dif;
+ int ret, host_dif, force_read16;
unsigned char protect;
/*
@@ -797,6 +797,9 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
else
protect = 0;
+ /* Many large capacity USB drives/controllers require the use of
read(16). */
+ force_read16 = (sdkp->capacity > 0xULL && sdp->force_read_16);
+
if (host_dif == SD_DIF_TYPE2_PROTECTION) {
SCpnt->cmnd = mempool_alloc(sd_cdb_pool, GFP_ATOMIC);
@@ -833,7 +836,7 @@ static int sd_prep_fn(struct request_queue *q, struct
request *rq)
SCpnt->cmnd[29] = (unsigned char) (this_count >> 16) & 0xff;
SCpnt->cmnd[30] = (unsigned char) (this_count >> 8) & 0xff;
SCpnt->cmnd[31] = (unsigned char) this_count & 0xff;
- } else if (block > 0x) {
+ } else if (block > 0x || force_read16) {
SCpnt->cmnd[0] += READ_16 - READ_6;
SCpnt->cmnd[1] = protect | ((rq->cmd_flags & REQ_FUA) ? 0x8 :
0);
SCpnt->cmnd[2] = sizeof(block) > 4 ? (unsigned char) (block >>
56) & 0xff : 0;
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 13b8bcd..6ff785e 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -251,6 +251,11 @@ static int slave_configure(struct scsi_device *sdev)
US_FL_SCM_MULT_TARG)) &&
us->protocol == USB_PR_BULK)
us->use_last_sector_hacks = 1;
+
+ /* Force read-16 for large capacity drives. */
+ sdev->force_read_16 = 1;
+
+
} else {
/* Non-disk-type devices don't need to blacklist any pages
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 5591ed5..e92b846 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -134,6 +134,7 @@ struct scsi_device {
* because we did a bus reset. */
unsigned use_10_for_rw:1; /* first try 10-byte read / write */
unsigned use_10_for_ms:1; /* first try 10-byte mode sense/select */
+ unsigned force_read_16:1; /* Use read(16) over read(10) */
unsigned skip_ms_page_8:1; /* do not use MODE SENSE page 0x08 */
unsigned skip_ms_page_3f:1; /* do not use MODE SENSE page 0x3f */
unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
--
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: [RFC PATCH 4/5] usb: add runtime pm support for usb port device
On Fri, 9 Nov 2012, Lan Tianyu wrote: > When pm qos flags is changing, the pm core will keep device not > in RPM_SUSPEND via pm_runtime_get_sync/put(dev). When the flags are > changed, this will affect usb device status. If NO_POWER_OFF flag was > set when the device was power off, it would need to be resumed and > suspended again without power off. If NO_POWER_OFF flag was cleared > when the device was suspended without power off, it would need to be > resumed and suspended again with power off inorder to save more power. > > This patch is to add runtime pm callback for usb port device. In the callback, > usb device attached to the port will be resumed and suspended. No, this is completely the wrong way around. The device's resume routine should force the port to resume, not the reverse. Think of the port device as a parent of the USB device (even though it's not represented that way in the device hierarchy) and you'll see why. Also, all this port stuff is making hub.c a real mess. Before going any farther, can you split it all out into a separate source file? 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
USB enclosures seem to require read(16) with >2TB drives
Hello, I've noticed Linux seems to have issues with external USB enclosures containing drives > 2 TB. The USB mass storage driver apparently emulates a SCSI device and sends a read/write(10) for all requests where the target sector is not large enough to require the use of read(16). The issue is that both of the enclosures I was able to test with do not properly accept this read(10) command when a 3TB drive (Seagate ST3000DM) is installed. A wireshark USB trace shows the read(10) command is sent to the drive and the drive never responds. The same drive/enclosure used in Windows 7 shows that read(16) is always used to communicate with the drive and the drive works without issue with Windows 7. A few notable points: 1. The drive operates without issue when connected to an internal Sata port on my computer. 2. The enclosure operates without issue with Linux (using read(10) ) when a <2TB drive is installed. 3. I have reproduced this problem on several computers, and using several Linux kernels, including 3.7.0-rc4-next. I first reported this to the linux-usb list thinking it was a USB issue. At the request of Alan Stern I am also reporting it here. I'm not sure if I am taking the correct approach but I have written a simple patch that resolves the problem for me. In essence, the patch adds a new bit to scsi_device that indicates it should favor read/write(16) over read/write(10). sd_prep_fn is modified to check this bit, and use a 16 byte operations when a large capacity drive is in use and this bit is on. Finally, the USB storage driver's scsi glue code is modified to turn this bit on for all of its devices. Not sure if this is the correct fix, but it works for me. I'm willing to revise my fix, provide testing, and collect any debug data if requested. The patch will follow in a separate e-mail. Background info: Enclosure #1 - Vantec NexStar CX USB 3.0/2.0 idVendor 0x174c ASMedia Technology Inc. idProduct 0x55aa bcdDevice1.00 iManufacturer2 ASMedia iProduct3 AS2105 Enclosure #2 - Rosewill idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x2338 JM20337 Hi-Speed USB to SATA & PATA Combo Bridge bcdDevice 1.00 Relevant posts to linux-usb: http://thread.gmane.org/gmane.linux.usb.general/74275 http://thread.gmane.org/gmane.linux.usb.general/74364 -- 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 2/5] usb: add usb port auto power off mechanism
On Fri, 9 Nov 2012, Lan Tianyu wrote: > This patch is to add usb port auto power off mechanism. > When usb device is suspending, usb core will send clear usb port's > POWER feature requst to power off port if all conditions were met. Actually, this is the wrong approach. What you should do, if all the conditions are met, is call pm_runtime_put(&port_dev->dev). Then the port's runtime suspend routine should be responsible for turning off the power. Similarly, whenever you want to make sure that a port is powered, you should call pm_runtime_get_sync(&port_dev->dev). 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: [RFC PATCH 2/5] usb: add usb port auto power off mechanism
On Fri, 9 Nov 2012, Lan Tianyu wrote:
> This patch is to add usb port auto power off mechanism.
> When usb device is suspending, usb core will send clear usb port's
> POWER feature requst to power off port if all conditions were met.
> These conditions are remote wakeup enable, pm qos NO_POWER_OFF flags
> and persist feature. When device is suspended and power off, usb core
You got the conditions wrong. You need remote wakeup to be
disabled, NO_POWER_OFF clear, and persist enabled.
> will ignore port's connect and enable change event to keep the device
> not being disconnected. When it resumes, power on port again.
> @@ -47,6 +48,7 @@ struct usb_port {
> struct device dev;
> struct dev_state *port_owner;
> enum usb_port_connect_type connect_type;
> + unsignedpower_state:1;
What's with the peculiar spacing?
> };
>
> struct usb_hub {
> @@ -166,6 +168,11 @@ MODULE_PARM_DESC(use_both_schemes,
> DECLARE_RWSEM(ehci_cf_port_reset_rwsem);
> EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
>
> +#define USB_PORT_POWER_STATE_ON 0
> +#define USB_PORT_POWER_STATE_OFF 1
Just call the new field power_on (and make it bool rather than
unsigned). Then these symbols won't be needed.
> @@ -2970,6 +2984,23 @@ int usb_port_suspend(struct usb_device *udev,
> pm_message_t msg)
> udev->port_is_suspended = 1;
> msleep(10);
> }
> +
> + /*
> + * Check whether current status is meeting requirement of
> + * usb port power off mechanism
> + */
> + if (!udev->do_remote_wakeup
> + && !(dev_pm_qos_flags(&port_dev->dev,
> + PM_QOS_FLAG_NO_POWER_OFF) == PM_QOS_FLAGS_ALL)
Why write it this complicated way? Just use !=.
> + && udev->persist_enabled
> + && !status) {
> + port_dev->power_state = USB_PORT_POWER_STATE_OFF;
> + if (clear_port_feature(udev->parent, port1,
> + USB_PORT_FEAT_POWER)) {
> + port_dev->power_state = USB_PORT_POWER_STATE_ON;
Do this the other way around: If clear_port_feature() succeeds, clear
port_dev->power_on.
> @@ -3094,6 +3144,25 @@ int usb_port_resume(struct usb_device *udev,
> pm_message_t msg)
> int status;
> u16 portchange, portstatus;
>
> +
> + set_bit(port1, hub->busy_bits);
> +
> + if (hub->ports[port1 - 1]->power_state == USB_PORT_POWER_STATE_OFF) {
> + set_port_feature(udev->parent, port1, USB_PORT_FEAT_POWER);
At this point you should set the port's power_on flag.
> +
> + /*
> + * Wait for usb hub port to be reconnected in order to make
> + * the resume procedure successful.
> + */
> + status = usb_port_wait_for_connected(hub, port1);
> + if (status < 0) {
> + dev_dbg(&udev->dev, "can't get reconnection after
> setting port power on, status %d\n",
> + status);
> + return status;
> + }
> + hub->ports[port1 - 1]->power_state = USB_PORT_POWER_STATE_ON;
Not here. The way you've got it, the power_on flag will be wrong if
usb_port_wait_for_connected fails.
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: [RFC PATCH 1/5] usb: Register usb port's acpi power resources
On Fri, 9 Nov 2012, Lan Tianyu wrote:
> This patch is to register usb port's acpi power resources. Create
> link between usb port device and its acpi power resource.
> +int usb_acpi_unregister_power_resources(struct usb_device *udev)
> +{
> + acpi_handle port_handle = DEVICE_ACPI_HANDLE(&udev->dev);
> +
> + if (!port_handle)
> + return -ENODEV;
> +
> + acpi_power_resource_register_device(&udev->dev, port_handle);
Don't you want to _un_-register the resource here?
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: Device detected as Digitalcamera (PTP?) instead of Portable Device (MTP?) - MS_COMP_MTP - WinXP
Karl Krach wrote: > How to be detected as USB\MS_COMP_MTP? Microsoft OS Descriptors http://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/windows/hardware/gg463179.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff553624%28v=vs.85%29.aspx //Peter -- 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: class: cdc-acm: /dev/ttyACM0 HowTo disable interrupt and control URBs
On Friday 09 November 2012 14:42:24 Markus Kolb wrote: > Hi, > > is it and how is it possible when using the acm_tty that > there is not sent any interrupt or control URB? It is not possible. > My connected device has problems handling this stuff and > doesn't respond to the bulk URB which is timed somewhere > between. > > I've found e.g. > URB_NO_INTERRUPT and USBDEVFS_URB_NO_INTERRUPT in > http://code.metager.de/source/xref/linux/stable/drivers/usb/core/devio.c#1386 > but how do I set this? You don't. This is for usbfs. If your modem cannot handle status transfers it makes no sense to use cdc-acm. You better blacklist the device and use usb-serial. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Hi, On Fri, Nov 09, 2012 at 06:50:44PM +0530, Praveen Paneri wrote: > Hi, > > On Fri, Nov 9, 2012 at 6:06 PM, Kyungmin Park wrote: > > On Fri, Nov 9, 2012 at 8:54 PM, Felipe Balbi wrote: > >> Hi, > >> > >> On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: > >>> Changes from v6: > >>> Modified register definitions according to the existing ones. > >>> Changed default PHY clk selection for SoCs. > >>> Improved binding text and rebased to the latest usb-next. > >>> > >>> Changes from v5: > >>> Moved clk_get() to driver's probe function. Now reference clock frequency > >>> selection value is stored in samsung_usbphy structure for later use. Used > >>> IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). > >>> > >>> Changes from v4: > >>> Moved header file contents to driver's source file > >>> Removed unnecessary print message from driver's probe function > >>> Dropped the Free Software Foundation address from the header > >>> Changed the platform data code to use __initdata > >>> > >>> Changes from v3: > >>> Replaced susbsys_initcall()/module_exit() by module_platform_driver(). > >>> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver > >>> is registered > >>> Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. > >>> > >>> Changes from v2: > >>> Changed the driver filenames to samsung-usbphy > >>> Changed 's3c' to 'samsung' for platform device as well as platform data > >>> Moved platform data structure to a separate file > >>> Rectified coding style related errors > >>> > >>> Changes from v1: > >>> Rebased patches to latest usb-next branch > >>> Changed the name 'sec_usbphy' to 'samsung_usbphy' > >>> > >>> This patch set introduces a phy driver for samsung SoCs. It uses the > >>> existing > >>> transceiver infrastructure to provide phy control functions. Use of this > >>> driver > >>> can be extended for usb host phy as well. Over the period of time all the > >>> phy > >>> related code for most of the samsung SoCs can be integrated here. > >>> Removing the existing phy code from mach-s3c64xx. Same can be done for > >>> other SoCs > >>> when they start supporting this phy driver. > >>> This driver is tested with smdk6410 and Exynos4210(with DT). > >>> > >>> Praveen Paneri (5): > >>> usb: phy: samsung: Introducing usb phy driver for hsotg > >>> usb: s3c-hsotg: Adding phy driver support > > For usb parts: > > Acked-by: Kyungmin Park > Thanks for the ack. > > > >>> ARM: S3C64XX: Removing old phy setup code > >>> ARM: S3C64XX: Enabling samsung-usbphy driver > >>> ARM: Exynos4210: Enabling samsung-usbphy driver > >> > >> guys I can't wait any longer. If I don't get proper Acks today, I will > >> go ahead without all the PHY changes from Samsung :-s > > > > To Praveen, > > > > To remove these dependency and merge issue, please send patches for > > each subsystem. In this case, usb patches for usb tree and others are > > for arm arch. > I will surely take care of this from now onwards. Hope these can be > taken as it is for now. Sure, but I still need Kukjin's 'say-so' for the arch/arm/plat-samsung and arch/arm/mach-exynos part. -- balbi signature.asc Description: Digital signature
usb: class: cdc-acm: /dev/ttyACM0 HowTo disable interrupt and control URBs
Hi, is it and how is it possible when using the acm_tty that there is not sent any interrupt or control URB? My connected device has problems handling this stuff and doesn't respond to the bulk URB which is timed somewhere between. I've found e.g. URB_NO_INTERRUPT and USBDEVFS_URB_NO_INTERRUPT in http://code.metager.de/source/xref/linux/stable/drivers/usb/core/devio.c#1386 but how do I set this? Can it be done with ioctl? Some notes would be fine. Thanks a lot Markus -- 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 v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Hi, On Fri, Nov 9, 2012 at 6:06 PM, Kyungmin Park wrote: > On Fri, Nov 9, 2012 at 8:54 PM, Felipe Balbi wrote: >> Hi, >> >> On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: >>> Changes from v6: >>> Modified register definitions according to the existing ones. >>> Changed default PHY clk selection for SoCs. >>> Improved binding text and rebased to the latest usb-next. >>> >>> Changes from v5: >>> Moved clk_get() to driver's probe function. Now reference clock frequency >>> selection value is stored in samsung_usbphy structure for later use. Used >>> IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). >>> >>> Changes from v4: >>> Moved header file contents to driver's source file >>> Removed unnecessary print message from driver's probe function >>> Dropped the Free Software Foundation address from the header >>> Changed the platform data code to use __initdata >>> >>> Changes from v3: >>> Replaced susbsys_initcall()/module_exit() by module_platform_driver(). >>> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver >>> is registered >>> Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. >>> >>> Changes from v2: >>> Changed the driver filenames to samsung-usbphy >>> Changed 's3c' to 'samsung' for platform device as well as platform data >>> Moved platform data structure to a separate file >>> Rectified coding style related errors >>> >>> Changes from v1: >>> Rebased patches to latest usb-next branch >>> Changed the name 'sec_usbphy' to 'samsung_usbphy' >>> >>> This patch set introduces a phy driver for samsung SoCs. It uses the >>> existing >>> transceiver infrastructure to provide phy control functions. Use of this >>> driver >>> can be extended for usb host phy as well. Over the period of time all the >>> phy >>> related code for most of the samsung SoCs can be integrated here. >>> Removing the existing phy code from mach-s3c64xx. Same can be done for >>> other SoCs >>> when they start supporting this phy driver. >>> This driver is tested with smdk6410 and Exynos4210(with DT). >>> >>> Praveen Paneri (5): >>> usb: phy: samsung: Introducing usb phy driver for hsotg >>> usb: s3c-hsotg: Adding phy driver support > For usb parts: > Acked-by: Kyungmin Park Thanks for the ack. > >>> ARM: S3C64XX: Removing old phy setup code >>> ARM: S3C64XX: Enabling samsung-usbphy driver >>> ARM: Exynos4210: Enabling samsung-usbphy driver >> >> guys I can't wait any longer. If I don't get proper Acks today, I will >> go ahead without all the PHY changes from Samsung :-s > > To Praveen, > > To remove these dependency and merge issue, please send patches for > each subsystem. In this case, usb patches for usb tree and others are > for arm arch. I will surely take care of this from now onwards. Hope these can be taken as it is for now. Thanks, Praveen > > Thank you, > Kyungmin Park >> >> -- >> balbi >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > -- > 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 v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
On Fri, Nov 9, 2012 at 8:54 PM, Felipe Balbi wrote: > Hi, > > On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: >> Changes from v6: >> Modified register definitions according to the existing ones. >> Changed default PHY clk selection for SoCs. >> Improved binding text and rebased to the latest usb-next. >> >> Changes from v5: >> Moved clk_get() to driver's probe function. Now reference clock frequency >> selection value is stored in samsung_usbphy structure for later use. Used >> IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). >> >> Changes from v4: >> Moved header file contents to driver's source file >> Removed unnecessary print message from driver's probe function >> Dropped the Free Software Foundation address from the header >> Changed the platform data code to use __initdata >> >> Changes from v3: >> Replaced susbsys_initcall()/module_exit() by module_platform_driver(). >> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver >> is registered >> Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. >> >> Changes from v2: >> Changed the driver filenames to samsung-usbphy >> Changed 's3c' to 'samsung' for platform device as well as platform data >> Moved platform data structure to a separate file >> Rectified coding style related errors >> >> Changes from v1: >> Rebased patches to latest usb-next branch >> Changed the name 'sec_usbphy' to 'samsung_usbphy' >> >> This patch set introduces a phy driver for samsung SoCs. It uses the existing >> transceiver infrastructure to provide phy control functions. Use of this >> driver >> can be extended for usb host phy as well. Over the period of time all the phy >> related code for most of the samsung SoCs can be integrated here. >> Removing the existing phy code from mach-s3c64xx. Same can be done for other >> SoCs >> when they start supporting this phy driver. >> This driver is tested with smdk6410 and Exynos4210(with DT). >> >> Praveen Paneri (5): >> usb: phy: samsung: Introducing usb phy driver for hsotg >> usb: s3c-hsotg: Adding phy driver support For usb parts: Acked-by: Kyungmin Park >> ARM: S3C64XX: Removing old phy setup code >> ARM: S3C64XX: Enabling samsung-usbphy driver >> ARM: Exynos4210: Enabling samsung-usbphy driver > > guys I can't wait any longer. If I don't get proper Acks today, I will > go ahead without all the PHY changes from Samsung :-s To Praveen, To remove these dependency and merge issue, please send patches for each subsystem. In this case, usb patches for usb tree and others are for arm arch. Thank you, Kyungmin Park > > -- > balbi > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- 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: core: hub power off when over-current detected
Hello. On 08-11-2012 22:48, Sergei Shtylyov wrote: USB specs says that if an over-current is detected then a hub must switch off all affected port, wait to cool down and then switch on. There are few controllers, which does not follow it, and expects software to switch off the port power. [...] This patch will add workaround for such controllers. Pratyush, I don't see where it waits for port to cool down and switch the power back on and I assume it's already done by the current code. Why claim that it's *you* who's doing it now? Sorry for the noise, I somehow missed your second paragraph. I think it will not affect others, even if HW switch off the port power. Signed-off-by: Pratyush Anand 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 v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Hi Kukjin, On Fri, Nov 9, 2012 at 5:24 PM, Felipe Balbi wrote: > Hi, > > On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: >> Changes from v6: >> Modified register definitions according to the existing ones. >> Changed default PHY clk selection for SoCs. >> Improved binding text and rebased to the latest usb-next. >> >> Changes from v5: >> Moved clk_get() to driver's probe function. Now reference clock frequency >> selection value is stored in samsung_usbphy structure for later use. Used >> IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). >> >> Changes from v4: >> Moved header file contents to driver's source file >> Removed unnecessary print message from driver's probe function >> Dropped the Free Software Foundation address from the header >> Changed the platform data code to use __initdata >> >> Changes from v3: >> Replaced susbsys_initcall()/module_exit() by module_platform_driver(). >> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver >> is registered >> Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. >> >> Changes from v2: >> Changed the driver filenames to samsung-usbphy >> Changed 's3c' to 'samsung' for platform device as well as platform data >> Moved platform data structure to a separate file >> Rectified coding style related errors >> >> Changes from v1: >> Rebased patches to latest usb-next branch >> Changed the name 'sec_usbphy' to 'samsung_usbphy' >> >> This patch set introduces a phy driver for samsung SoCs. It uses the existing >> transceiver infrastructure to provide phy control functions. Use of this >> driver >> can be extended for usb host phy as well. Over the period of time all the phy >> related code for most of the samsung SoCs can be integrated here. >> Removing the existing phy code from mach-s3c64xx. Same can be done for other >> SoCs >> when they start supporting this phy driver. >> This driver is tested with smdk6410 and Exynos4210(with DT). >> >> Praveen Paneri (5): >> usb: phy: samsung: Introducing usb phy driver for hsotg >> usb: s3c-hsotg: Adding phy driver support >> ARM: S3C64XX: Removing old phy setup code >> ARM: S3C64XX: Enabling samsung-usbphy driver >> ARM: Exynos4210: Enabling samsung-usbphy driver > > guys I can't wait any longer. If I don't get proper Acks today, I will > go ahead without all the PHY changes from Samsung :-s Can you please ack this patch series. Thanks, Praveen > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Hi, On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: > Changes from v6: > Modified register definitions according to the existing ones. > Changed default PHY clk selection for SoCs. > Improved binding text and rebased to the latest usb-next. > > Changes from v5: > Moved clk_get() to driver's probe function. Now reference clock frequency > selection value is stored in samsung_usbphy structure for later use. Used > IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). > > Changes from v4: > Moved header file contents to driver's source file > Removed unnecessary print message from driver's probe function > Dropped the Free Software Foundation address from the header > Changed the platform data code to use __initdata > > Changes from v3: > Replaced susbsys_initcall()/module_exit() by module_platform_driver(). > Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver > is registered > Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. > > Changes from v2: > Changed the driver filenames to samsung-usbphy > Changed 's3c' to 'samsung' for platform device as well as platform data > Moved platform data structure to a separate file > Rectified coding style related errors > > Changes from v1: > Rebased patches to latest usb-next branch > Changed the name 'sec_usbphy' to 'samsung_usbphy' > > This patch set introduces a phy driver for samsung SoCs. It uses the existing > transceiver infrastructure to provide phy control functions. Use of this > driver > can be extended for usb host phy as well. Over the period of time all the phy > related code for most of the samsung SoCs can be integrated here. > Removing the existing phy code from mach-s3c64xx. Same can be done for other > SoCs > when they start supporting this phy driver. > This driver is tested with smdk6410 and Exynos4210(with DT). > > Praveen Paneri (5): > usb: phy: samsung: Introducing usb phy driver for hsotg > usb: s3c-hsotg: Adding phy driver support > ARM: S3C64XX: Removing old phy setup code > ARM: S3C64XX: Enabling samsung-usbphy driver > ARM: Exynos4210: Enabling samsung-usbphy driver guys I can't wait any longer. If I don't get proper Acks today, I will go ahead without all the PHY changes from Samsung :-s -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: ncm: correct endianess conversion
Hi, On Fri, Nov 09, 2012 at 10:31:47AM +0100, Dmytro Milinevskyy wrote: > Hi Felipe, > > On Thu, Nov 8, 2012 at 8:30 PM, Felipe Balbi wrote: > > Hi, > > > > On Thu, Nov 08, 2012 at 08:07:57PM +0100, Dmytro Milinevskyy wrote: > >> > On Wed, Nov 07, 2012 at 02:14:00PM +0100, Dmytro Milinevskyy wrote: > >> >> Unfortunately I have some issues with git send-email. > >> >> I've attached the patch itself .. > >> > > >> > I'll apply it like that this time, but try to figure out how to send > >> > patches properly. We have some very helpful hints on > >> > Documentation/email-clients.txt which are hugely underused ;-) > >> > > >> well, I try to follow the rules as much as possible as long as tools > >> work ... =) > > > > git send-email has thousands of users and it works fine for them > > (including myself). Maybe you just misconfigured it ?!? ;-) > > > No, I was using it in the past w/o any issue. > In fact initial versions of the patch were sent exactly with git-send-email. > > However I lost my internet connection at home(some issues with ISP) > and at work place network environment somehow blocks > git-send-email(though thunderbird still can connect to the smtp server > ..). I don't think smtp server can make that distinction. Except for the message-id, there's nothing there which would help smtp server to figure out you're using git send-email. On top of that, it would be just extra work to maintain rules to block a tool which is essentially just sending an email. Make sure you're not missing some authentication with the mail server on your git send-email configuration. my 2 cents. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: core: hub power off when over-current detected
On 11/9/2012 12:53 AM, Sergei Shtylyov wrote:
Look at this fragment of ehci-hub.c:
Thanks Sergei for pointing it out.
I apologize for the noise. SPEAr is also an EHCI implementation. Having
following code, actually we should not need this patch for SPEAr.
Regards
Pratyush
807 if ((temp & PORT_OCC) && !ignore_oc){
808 status |= USB_PORT_STAT_C_OVERCURRENT << 16;
809
810 /*
811 * Hubs should disable port power on over-current.
812 * However, not all EHCI implementations do this
813 * automatically, even if they_do_ support per-port
814 * power switching; they're allowed to just limit
the
815 * current. khubd will turn the power back on.
816 */
817 if ((temp & PORT_OC) && HCS_PPC(ehci->hcs_params)) {
818 ehci_writel(ehci,
819 temp & ~(PORT_RWC_BITS |
PORT_POWER),
820 status_reg);
821 temp = ehci_readl(ehci, status_reg);
822 }
823 }
--
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: gadget: ncm: correct endianess conversion
Hi Felipe, On Thu, Nov 8, 2012 at 8:30 PM, Felipe Balbi wrote: > Hi, > > On Thu, Nov 08, 2012 at 08:07:57PM +0100, Dmytro Milinevskyy wrote: >> > On Wed, Nov 07, 2012 at 02:14:00PM +0100, Dmytro Milinevskyy wrote: >> >> Unfortunately I have some issues with git send-email. >> >> I've attached the patch itself .. >> > >> > I'll apply it like that this time, but try to figure out how to send >> > patches properly. We have some very helpful hints on >> > Documentation/email-clients.txt which are hugely underused ;-) >> > >> well, I try to follow the rules as much as possible as long as tools >> work ... =) > > git send-email has thousands of users and it works fine for them > (including myself). Maybe you just misconfigured it ?!? ;-) > No, I was using it in the past w/o any issue. In fact initial versions of the patch were sent exactly with git-send-email. However I lost my internet connection at home(some issues with ISP) and at work place network environment somehow blocks git-send-email(though thunderbird still can connect to the smtp server ..). thanks, -- dmytro > cheers > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Device detected as Digitalcamera (PTP?) instead of Portable Device (MTP?) - MS_COMP_MTP - WinXP
Hello, I'm using the Meego's MTP code on a TI8148 evaluation board (Inventra HDRC Peripheral Controller). When connecting to Win7 it's detected as Protable Device and I'm offered to open the explorer. But on WinXP it's detected as Digital Camera and thus I am offered to open scan- and image-editors and the explorer-icon is a camera. What do I have to do, to get the board detected as 'Portable Device'? When opening the Windows hardware manager, I can list the Compatible IDs. My Samsung mobile, which is detected correctly lists USB\MS_COMP_MTP USB\Class_06&SubClass_01&Prot_01 USB\Class_06&SubClass_01 USB\Class_06 while my device lacks of the first entry: USB\Class_06&SubClass_01&Prot_01 USB\Class_06&SubClass_01 USB\Class_06 Also the service of the mobile is WUDRFd and of my device only usbscan. According wpdmtp.inf MTP is used with USB\MS_COMP_MTP: [Generic.NTx86] %GenericMTP.DeviceDesc%=MTP, USB\MS_COMP_MTP In difference to this, PTP (ptpusb.inf) is used with "USB\Class_06&SubClass_01&Prot_01" [Generic] %GenericPTP.DeviceDesc%=PTP, USB\Class_06&SubClass_01&Prot_01 How to be detected as USB\MS_COMP_MTP? Thanks a lot in advance, Charly My Configuration is: #define BATTERY_LEVEL_DEFAULT 0 #define COPYRIGHT_INFO_DEFAULT "Do Not Copy" #define SYNC_PARTNER_DEFAULT "MyCompany MyDevice" #define DEVICE_FRIENDLY_NAME_DEFAULT "Friendly Device" #define STANDARD_VERSION_DEFAULT 100 #define VENDOR_EXTENSION_DEFAULT 0x0006 // Perceived Device Type // 0x0 Generic--> detect as digital camera + no explorer icon at all + offer scan-applications // 0x1 Still Image/Video Camera --> detect as digital camera + camera icon + offer scan-applications // 0x2 Media (Audio/Video) Player --> detect as digital camera + no explorer icon at all + offer scan-applications // 0x3 Mobile Handset--> detect as digital camera + camera icon + offer scan-applications // 0x4 Video Player // 0x5 Personal Information Manager / PDA --> detect as digital camera + camera icon + offer scan-applications // 0x6 Audio Recorder #define DEVICE_TYPE_DEFAULT 0x0003 #define MTP_VERSION_DEFAULT 100 #define MTP_EXTENSION_DEFAULT "microsoft.com: 1.0; microsoft.com/WMPPD: 11.0; " #define FUNCTIONAL_MODE_DEFAULT 0 #define MANUFACTURER_DEFAULT "My Company" #define MODEL_DEFAULT "My Device" #define SERIAL_NO_DEFAULT "0001" // Device Version - software or firmware version #define DEVICE_VERSION_DEFAULT "Prototype" -- 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
[RFC PATCH 4/5] usb: add runtime pm support for usb port device
When pm qos flags is changing, the pm core will keep device not
in RPM_SUSPEND via pm_runtime_get_sync/put(dev). When the flags are
changed, this will affect usb device status. If NO_POWER_OFF flag was
set when the device was power off, it would need to be resumed and
suspended again without power off. If NO_POWER_OFF flag was cleared
when the device was suspended without power off, it would need to be
resumed and suspended again with power off inorder to save more power.
This patch is to add runtime pm callback for usb port device. In the callback,
usb device attached to the port will be resumed and suspended.
Signed-off-by: Lan Tianyu
---
drivers/usb/core/hub.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f0e1b29..3ba6a96 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1264,9 +1264,55 @@ static void usb_hub_remove_port_device(struct usb_hub
*hub,
device_unregister(&hub->ports[port1 - 1]->dev);
}
+static int usb_port_runtime_suspend(struct device *dev)
+{
+ struct usb_port *port_dev = to_usb_port(dev);
+ int ret;
+
+ if (!port_dev->child)
+ return 0;
+
+ ret = pm_runtime_suspend(&port_dev->child->dev);
+ if (ret == 1 || ret == 0 || ret == -EBUSY)
+ return 0;
+ else
+ return ret;
+}
+
+static int usb_port_runtime_resume(struct device *dev)
+{
+ struct usb_port *port_dev = to_usb_port(dev);
+ int ret;
+
+ if (!port_dev->child)
+ return 0;
+
+ ret = pm_runtime_resume(&port_dev->child->dev);
+ if (ret == 1 || ret == 0)
+ return 0;
+ else
+ return ret;
+}
+
+static int usb_port_runtime_idle(struct device *dev)
+{
+ struct usb_port *port_dev = to_usb_port(dev);
+
+ return pm_runtime_suspend(&port_dev->dev);
+}
+
+static const struct dev_pm_ops usb_port_pm_ops = {
+#ifdef CONFIG_USB_SUSPEND
+.runtime_suspend = usb_port_runtime_suspend,
+.runtime_resume = usb_port_runtime_resume,
+.runtime_idle =usb_port_runtime_idle,
+#endif
+};
+
struct device_type usb_port_device_type = {
.name = "usb_port",
.release = usb_port_device_release,
+ .pm = &usb_port_pm_ops,
};
static int usb_hub_create_port_device(struct usb_hub *hub,
@@ -1291,6 +1337,8 @@ static int usb_hub_create_port_device(struct usb_hub *hub,
if (retval)
goto error_register;
+ pm_runtime_enable(&port_dev->dev);
+
retval = dev_pm_qos_expose_flags(&port_dev->dev,
PM_QOS_FLAG_NO_POWER_OFF);
if (retval)
--
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
[RFC PATCH 5/5] usb: add usb port's pm qos flags request to change NO_POWER_OFF flag
Some usb devices can't be resumed correctly after power off. This
patch is to add pm qos flags request to change NO_POWER_OFF and
provide usb_device_allow_power_off() for device drivers to allow or
prohibit usb core to power off the device.
Signed-off-by: Lan Tianyu
---
drivers/usb/core/hub.c | 49
1 file changed, 49 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3ba6a96..fe05dff 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -49,6 +49,7 @@ struct usb_port {
struct dev_state *port_owner;
enum usb_port_connect_type connect_type;
unsignedpower_state:1;
+ struct dev_pm_qos_request pm_qos;
};
struct usb_hub {
@@ -203,6 +204,42 @@ static struct usb_hub *hdev_to_hub(struct usb_device *hdev)
return usb_get_intfdata(hdev->actconfig->interface[0]);
}
+/**
+ * usb_device_allow_power_off - Allow or prohibit power off device.
+ * @udev: target usb device
+ * @set: choice of allow or prohibit
+ *
+ * Clearing or setting usb port's pm qos flag PM_QOS_FLAG_NO_POWER_OFF
+ * to allow or prohibit target usb device to be power off.
+ */
+int usb_device_allow_power_off(struct usb_device *udev, bool set)
+{
+ struct usb_port *port_dev;
+ struct dev_pm_qos_request *pm_qos;
+ s32 value;
+ int ret;
+
+ if (!udev->parent)
+ return -EINVAL;
+
+ port_dev =
+ hdev_to_hub(udev->parent)->ports[udev->portnum - 1];
+ pm_qos = &port_dev->pm_qos;
+ value = pm_qos->data.flr.flags;
+
+ if (set)
+ value &= ~PM_QOS_FLAG_NO_POWER_OFF;
+ else
+ value |= PM_QOS_FLAG_NO_POWER_OFF;
+
+ pm_runtime_get_sync(&port_dev->dev);
+ ret = dev_pm_qos_update_request(pm_qos, value);
+ pm_runtime_put(&port_dev->dev);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_device_allow_power_off);
+
static int usb_device_supports_lpm(struct usb_device *udev)
{
/* USB 2.1 (and greater) devices indicate LPM support through
@@ -1254,6 +1291,9 @@ static void usb_port_device_release(struct device *dev)
{
struct usb_port *port_dev = to_usb_port(dev);
+ pm_runtime_get_sync(dev);
+ dev_pm_qos_remove_request(&port_dev->pm_qos);
+ pm_runtime_put(dev);
dev_pm_qos_hide_flags(dev);
kfree(port_dev);
}
@@ -1344,8 +1384,17 @@ static int usb_hub_create_port_device(struct usb_hub
*hub,
if (retval)
goto error_expose_pm_qos;
+ pm_runtime_get_sync(&port_dev->dev);
+ retval = dev_pm_qos_add_request(&port_dev->dev, &port_dev->pm_qos,
+ DEV_PM_QOS_FLAGS, 0);
+ if (retval)
+ goto error_add_qos_request;
+
+ pm_runtime_put(&port_dev->dev);
return 0;
+error_add_qos_request:
+ pm_runtime_put(&port_dev->dev);
error_expose_pm_qos:
device_unregister(&port_dev->dev);
error_register:
--
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
[RFC PATCH 2/5] usb: add usb port auto power off mechanism
This patch is to add usb port auto power off mechanism.
When usb device is suspending, usb core will send clear usb port's
POWER feature requst to power off port if all conditions were met.
These conditions are remote wakeup enable, pm qos NO_POWER_OFF flags
and persist feature. When device is suspended and power off, usb core
will ignore port's connect and enable change event to keep the device
not being disconnected. When it resumes, power on port again.
Signed-off-by: Lan Tianyu
---
drivers/usb/core/hub.c | 78 ++--
1 file changed, 75 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d0e1f08..1e9a395 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -47,6 +48,7 @@ struct usb_port {
struct device dev;
struct dev_state *port_owner;
enum usb_port_connect_type connect_type;
+ unsignedpower_state:1;
};
struct usb_hub {
@@ -166,6 +168,11 @@ MODULE_PARM_DESC(use_both_schemes,
DECLARE_RWSEM(ehci_cf_port_reset_rwsem);
EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
+#define USB_PORT_POWER_STATE_ON0
+#define USB_PORT_POWER_STATE_OFF 1
+
+#define HUB_PORT_RECONNECT_TRIES 20
+
#define HUB_DEBOUNCE_TIMEOUT 1500
#define HUB_DEBOUNCE_STEP25
#define HUB_DEBOUNCE_STABLE 100
@@ -174,6 +181,7 @@ EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
container_of(_dev, struct usb_port, dev)
static int usb_reset_and_verify_device(struct usb_device *udev);
+static int hub_port_debounce(struct usb_hub *hub, int port1);
static inline char *portspeed(struct usb_hub *hub, int portstatus)
{
@@ -851,7 +859,12 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
dev_dbg(hub->intfdev, "trying to enable port power on "
"non-switchable hub\n");
for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++)
- set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
+ if (hub->ports[port1 - 1]->power_state
+ == USB_PORT_POWER_STATE_ON)
+ set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
+ else
+ clear_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_POWER);
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -2876,6 +2889,7 @@ EXPORT_SYMBOL_GPL(usb_enable_ltm);
int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
{
struct usb_hub *hub = hdev_to_hub(udev->parent);
+ struct usb_port *port_dev = hub->ports[udev->portnum - 1];
int port1 = udev->portnum;
int status;
@@ -2970,6 +2984,23 @@ int usb_port_suspend(struct usb_device *udev,
pm_message_t msg)
udev->port_is_suspended = 1;
msleep(10);
}
+
+ /*
+* Check whether current status is meeting requirement of
+* usb port power off mechanism
+*/
+ if (!udev->do_remote_wakeup
+ && !(dev_pm_qos_flags(&port_dev->dev,
+ PM_QOS_FLAG_NO_POWER_OFF) == PM_QOS_FLAGS_ALL)
+ && udev->persist_enabled
+ && !status) {
+ port_dev->power_state = USB_PORT_POWER_STATE_OFF;
+ if (clear_port_feature(udev->parent, port1,
+ USB_PORT_FEAT_POWER)) {
+ port_dev->power_state = USB_PORT_POWER_STATE_ON;
+ }
+ }
+
usb_mark_last_busy(hub->hdev);
return status;
}
@@ -3053,6 +3084,25 @@ static int finish_port_resume(struct usb_device *udev)
return status;
}
+static int usb_port_wait_for_connected(struct usb_hub *hub, int port1)
+{
+ int status, i;
+
+ for (i = 0; i < HUB_PORT_RECONNECT_TRIES; i++) {
+ status = hub_port_debounce(hub, port1);
+ if (status & USB_PORT_STAT_CONNECTION) {
+ /*
+* just clear enable-change feature since debounce
+* has cleared connect-change feature.
+*/
+ clear_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_C_ENABLE);
+ return 0;
+ }
+ }
+ return -ETIMEDOUT;
+}
+
/*
* usb_port_resume - re-activate a suspended usb device's upstream port
* @udev: device to re-activate, not a root hub
@@ -3094,6 +3144,25 @@ int usb_port_resume(struct usb_device *udev,
pm_message_t msg)
int status;
u16 portchange, portstatus;
+
+ set_bit(port1, hub->busy_bits);
+
+ if (hu
[RFC PATCH 3/5] usb: expose usb port's pm qos flags to user space
This patch is to expose usb port's pm qos flags(pm_qos_no_power_off,
pm_qos_remote_wakeup) to user space. The pm_qos_no_power_off will
be used to control usb port auto power off mechanism from user space.
Signed-off-by: Lan Tianyu
---
drivers/usb/core/hub.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1e9a395..f0e1b29 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1254,6 +1254,7 @@ static void usb_port_device_release(struct device *dev)
{
struct usb_port *port_dev = to_usb_port(dev);
+ dev_pm_qos_hide_flags(dev);
kfree(port_dev);
}
@@ -1289,8 +1290,16 @@ static int usb_hub_create_port_device(struct usb_hub
*hub,
retval = device_register(&port_dev->dev);
if (retval)
goto error_register;
+
+ retval = dev_pm_qos_expose_flags(&port_dev->dev,
+ PM_QOS_FLAG_NO_POWER_OFF);
+ if (retval)
+ goto error_expose_pm_qos;
+
return 0;
+error_expose_pm_qos:
+ device_unregister(&port_dev->dev);
error_register:
put_device(&port_dev->dev);
exit:
--
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
[RFC PATCH 0/5] usb: usb port power off mechanism
The patchset is based on the pm qos flags patches and now on the linux-pm's next tree and pm-qos. http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=shortlog;h=refs/heads/pm-qos usb: add usb port's pm qos flags request to change NO_POWER_OFF flag usb: add runtime pm support for usb port device usb: expose usb port's pm qos flags to user space usb: add usb port auto power off mechanism usb: Register usb port's acpi power resources drivers/usb/core/hub.c | 187 +++ drivers/usb/core/usb-acpi.c | 23 ++ drivers/usb/core/usb.h |6 ++ 3 files changed, 212 insertions(+), 4 deletions(-) -- 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
[RFC PATCH 1/5] usb: Register usb port's acpi power resources
This patch is to register usb port's acpi power resources. Create
link between usb port device and its acpi power resource.
Signed-off-by: Lan Tianyu
---
drivers/usb/core/hub.c |3 ++-
drivers/usb/core/usb-acpi.c | 23 +++
drivers/usb/core/usb.h |6 ++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 55c086e..d0e1f08 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2072,7 +2072,7 @@ void usb_disconnect(struct usb_device **pdev)
spin_unlock_irq(&device_state_lock);
hub_free_dev(udev);
-
+ usb_acpi_unregister_power_resources(udev);
put_device(&udev->dev);
}
@@ -2365,6 +2365,7 @@ int usb_new_device(struct usb_device *udev)
(void) usb_create_ep_devs(&udev->dev, &udev->ep0, udev);
usb_mark_last_busy(udev);
pm_runtime_put_sync_autosuspend(&udev->dev);
+ usb_acpi_register_power_resources(udev);
return err;
fail:
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index cef4252..7388df3 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -216,6 +216,29 @@ static struct acpi_bus_type usb_acpi_bus = {
.find_device = usb_acpi_find_device,
};
+int usb_acpi_register_power_resources(struct usb_device *udev)
+{
+ acpi_handle port_handle = DEVICE_ACPI_HANDLE(&udev->dev);
+
+ if (!port_handle)
+ return -ENODEV;
+
+ if (acpi_power_resource_register_device(&udev->dev, port_handle) < 0)
+ return -ENODEV;
+ return 0;
+}
+
+int usb_acpi_unregister_power_resources(struct usb_device *udev)
+{
+ acpi_handle port_handle = DEVICE_ACPI_HANDLE(&udev->dev);
+
+ if (!port_handle)
+ return -ENODEV;
+
+ acpi_power_resource_register_device(&udev->dev, port_handle);
+ return 0;
+}
+
int usb_acpi_register(void)
{
return register_acpi_bus_type(&usb_acpi_bus);
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 1633f6e..0de01a6 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -175,7 +175,13 @@ extern int usb_acpi_register(void);
extern void usb_acpi_unregister(void);
extern acpi_handle usb_get_hub_port_acpi_handle(struct usb_device *hdev,
int port1);
+extern int usb_acpi_register_power_resources(struct usb_device *udev);
+extern int usb_acpi_unregister_power_resources(struct usb_device *udev);
#else
static inline int usb_acpi_register(void) { return 0; };
static inline void usb_acpi_unregister(void) { };
+static inline int usb_acpi_register_power_resources(struct usb_device *udev)
+ { return 0; }
+static inline int usb_acpi_unregister_power_resources(struct usb_device *udev)
+ { return 0; }
#endif
--
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
