Re: [PATCH v12 00/13] Add tested id switch and vbus connect detect support for Chipidea
On Thu, Jul 25, 2013 at 07:55:23AM +0200, Marek Vasut wrote: Hi Peter, I have not tried the manual switching, but first, you need to close your vbus supply. I think we can close this issue, I will now be also getting MX28EVK. Thanks for all your help! Great. What's the problem? Any changes for this patchset? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 00/13] Add tested id switch and vbus connect detect support for Chipidea
Dear Peter Chen, This patchset adds tested otg id switch function and vbus connect and disconnect detection for chipidea driver. And fix kinds of bugs found at chipidea drivers after enabling id and vbus detection. This patch is fully tested at imx6 sabresd platform. My chipidea repo: https://github.com/hzpeterchen/linux-usb.git Patchset: Tested-by: Marek Vasut ma...@denx.de on two STMP3780-based boards (not yet mainline) and two MX28-based boards. Best regards, Marek Vasut -- 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 cdc-acm driver cause windows xp sp3 blue screen randomly
On Thu, 2013-07-25 at 10:06 +0800, Yingchun Li wrote: Ok， but the linux-cdc-acm.inf is provieded by us, so I think there should be something I can learn. Thanks anyway！ And the driver binds and operates. The inf file works. The kernel driver is buggy. The driver comes from the vendor. As such crashes are also reported with other devices, we also know that the device isn't to blame. You need to complain to the vendor. 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 v4] staging: usbip: replace pr_warning() with dev_warn().
On Thu, Jul 25, 2013, Greg KH gre...@linuxfoundation.org said: On Thu, Jul 25, 2013 at 10:19:31AM +0530, navin patidar wrote: -pr_warning(Unable to start control thread\n); +struct device *dev; + +if (ud-side == USBIP_STUB) +dev = container_of(ud, struct stub_device, ud)-udev-dev; +else +dev = container_of(ud, struct vhci_device, ud)-udev-dev; Putting '' in front of container_of seems odd, are you sure it's needed here? If ud is a pointer, everything else should just work properly without that. Removing '' caused following error. drivers/staging/usbip/usbip_event.c: In function ‘usbip_start_eh’: drivers/staging/usbip/usbip_event.c:93:8: error: incompatible types when assigning to type ‘struct device *’ from type ‘struct device’ drivers/staging/usbip/usbip_event.c:95:8: error: incompatible types when assigning to type ‘struct device *’ from type ‘struct device’ dev needs to be initialized with address of dev (struct device ) which is member of struct usb_device pointed by the udev. To make it more clear i can change it to dev = (container_of(ud, struct vhci_device, ud)-udev-dev); or struct vhci_device *vdev = container_of(ud, struct vhci_device, ud); dev = (vdev-udev-dev); Or perhaps: dev = container_of(ud, struct stub_device, ud).udev-dev; container_of() returns stub_device pointer so container_of(ud, struct stub_device, ud).udev-dev won't work. or -udev.dev; I don't remember which, but that should work, right? udev is also a pointer to usb_device structure inside stub_device structure. -udev-dev only will work. v4 patch gets compiled without any error or warning. and actually Joe Perches reviewed v3 of the patch and suggested changes. https://lkml.org/lkml/2013/6/27/15 regards, --navin-patidar -- 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: External HDD does not work with 3.11-rc2
On Wed, Jul 24, 2013 at 11:03 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 24 Jul 2013, Philipp Dreimann wrote: Hello, one of my external HDDs does not work using 3.11-rc2. The drive works using 3.10, and 3.9, except for a suspend/resume issue described here: https://bugzilla.redhat.com/show_bug.cgi?id=984189 . dmesg snipped: [ 119.334908] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd [ 119.347397] usb 4-1: Parent hub missing LPM exit latency info. Power management will be impacted. [ 119.350614] usb 4-1: New USB device found, idVendor=054c, idProduct=c005 [ 119.350620] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 119.350624] usb 4-1: Product: USB 3.0 SATA Bridge [ 119.350627] usb 4-1: Manufacturer: VIA Technologies Inc. [ 119.350630] usb 4-1: SerialNumber: l刁A柜鬨xffc2\xff80籁7鮘d [ 119.377782] usb-storage 4-1:1.0: USB Mass Storage device detected [ 119.377847] scsi6 : usb-storage 4-1:1.0 [ 119.377900] usbcore: registered new interface driver usb-storage [ 129.844989] scsi 6:0:0:0: Direct-Access Hitachi HDS5C3030BLE MZ6O PQ: 0 ANSI: 6 [ 129.845465] sd 6:0:0:0: Attached scsi generic sg1 type 0 [ 129.863425] sd 6:0:0:0: [sdb] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB) [ 129.871203] sd 6:0:0:0: [sdb] Write Protect is off [ 129.871209] sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00 [ 129.879196] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 160.787920] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd [ 160.800582] usb 4-1: Parent hub missing LPM exit latency info. Power management will be impacted. [ 160.801795] usb 4-1: device firmware changed [ 160.801857] usb 4-1: USB disconnect, device number 2 [ 160.801938] sd 6:0:0:0: Device offlined - not ready after error recovery [ 160.805190] sd 6:0:0:0: [sdb] READ CAPACITY failed [ 160.805194] sd 6:0:0:0: [sdb] [ 160.805195] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 160.805197] sd 6:0:0:0: [sdb] Sense not available. [ 160.805218] sd 6:0:0:0: [sdb] Asking for cache data failed [ 160.805220] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 160.805233] sdb: detected capacity change from 3000592982016 to 0 [ 160.805353] sd 6:0:0:0: [sdb] READ CAPACITY failed [ 160.805357] sd 6:0:0:0: [sdb] [ 160.805359] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 160.805361] sd 6:0:0:0: [sdb] Sense not available. [ 160.805383] sd 6:0:0:0: [sdb] No Caching mode page present [ 160.805386] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 160.805397] sd 6:0:0:0: [sdb] Attached SCSI disk [ 160.806605] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880212315e80 [ 160.806609] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880212315ec0 kernel log, lsusb and usbmon are attached. I tried usb2 and 3 ports, both have the same issue with this drive. Other drives work. The problem is caused by some program on your computer sending a command to the drive that it can't handle (SCSI INQUIRY command with a transfer length of 512). It is not a kernel problem. Thanks, I can reproduce the issue using kernel 3.9.9 and $ sg_inq -l 512 /dev/sdb I am guessing that this is the reason for the suspend/resume issues with 3.9 and 3.10 as well. A look at the program's code might reveal why this was not triggered on 3.9 and 3.10 as bad as on 3.11... -- 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 - bugfix for 3.11] usb/gadget: free opts struct on error recovery
Fix memory leaks introduced in commits:
40d133d7f542616cf9538508a372306e626a16e9
usb: gadget: f_ncm: convert to new function interface with backward
compatibility
fee562a6450b7806f1fbbe1469a67b5395b5c10a
usb: gadget: f_ecm: convert to new function interface with backward
compatibility
fcbdf12ebef73a6069e2a1aada1e546fb578a4aa
usb: gadget: f_phonet: convert to new function interface with backward
compatibility
b29002a157940752dfed2c488b2011f63f007d71
usb: gadget: f_eem: convert to new function interface with backward
compatibility
8cedba7c73af1369599b639cfeb66fe13aaa
usb: gadget: f_subset: convert to new function interface with backward
compatibility
f466c6353819326873fa48a02c6f2d7c903240d6
usb: gadget: f_rndis: convert to new function interface with backward
compatibility
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_ecm.c|7 +--
drivers/usb/gadget/f_eem.c|7 +--
drivers/usb/gadget/f_ncm.c|7 +--
drivers/usb/gadget/f_phonet.c |7 +--
drivers/usb/gadget/f_rndis.c |7 +--
drivers/usb/gadget/f_subset.c |7 +--
6 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/f_ecm.c b/drivers/usb/gadget/f_ecm.c
index 5d3561e..edab45d 100644
--- a/drivers/usb/gadget/f_ecm.c
+++ b/drivers/usb/gadget/f_ecm.c
@@ -959,8 +959,11 @@ static struct usb_function_instance *ecm_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = ecm_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_PTR(PTR_ERR(opts-net));
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, , ecm_func_type);
diff --git a/drivers/usb/gadget/f_eem.c b/drivers/usb/gadget/f_eem.c
index 90ee802..d00392d 100644
--- a/drivers/usb/gadget/f_eem.c
+++ b/drivers/usb/gadget/f_eem.c
@@ -593,8 +593,11 @@ static struct usb_function_instance *eem_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = eem_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_CAST(opts-net);
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, , eem_func_type);
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index 952177f..1c28fe1 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -1350,8 +1350,11 @@ static struct usb_function_instance *ncm_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = ncm_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_PTR(PTR_ERR(opts-net));
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, , ncm_func_type);
diff --git a/drivers/usb/gadget/f_phonet.c b/drivers/usb/gadget/f_phonet.c
index 3575427..eb3aa81 100644
--- a/drivers/usb/gadget/f_phonet.c
+++ b/drivers/usb/gadget/f_phonet.c
@@ -654,8 +654,11 @@ static struct usb_function_instance
*phonet_alloc_inst(void)
opts-func_inst.free_func_inst = phonet_free_inst;
opts-net = gphonet_setup_default();
- if (IS_ERR(opts-net))
- return ERR_PTR(PTR_ERR(opts-net));
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, ,
phonet_func_type);
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 191df35..717ed7f 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -963,8 +963,11 @@ static struct usb_function_instance *rndis_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = rndis_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_CAST(opts-net);
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, ,
rndis_func_type);
diff --git a/drivers/usb/gadget/f_subset.c b/drivers/usb/gadget/f_subset.c
index 5601e1d..7c8674f 100644
--- a/drivers/usb/gadget/f_subset.c
+++ b/drivers/usb/gadget/f_subset.c
@@ -505,8 +505,11 @@ static struct
Re: [PATCH 0/2] USBNET: max rx/tx qlen change
On Thu, 2013-07-25 at 13:47 +0800, Ming Lei wrote: Hi, There are two patches on computing max rx/tx qlen, and fix one performance problem on USB3 NIC. I am afraid bisectability on SS is impaired. Otherwise this looks good. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB_QUIRK_RESET_RESUME not working with xhci
Hi Sarah, Are there any news on this issue? suddenly i don't have usb analyser to find what actually happening (That is way too expensive for Hobbyist). But probably thinkpenguin.com can provide you some sample to track it down (CC them). Am 22.07.2013 20:54, schrieb Oleksij Rempel: Am 22.07.2013 19:33, schrieb Sarah Sharp: On Mon, Jul 22, 2013 at 11:43:53AM +0200, Oleksij Rempel wrote: Hello all, i'm working on ath9k_htc's suspend/resume issue and need your help. This devices has problems with suspend mode. After it resume, USB_PHY stay misconfigured. Only way to bring PHY back to normal is reset it. Normally it is not a problem for EHCI controllers - they will reset this adapter even without USB_QUIRK_RESET_RESUME. But it is not reseted on XHCI controller. At leas not on this one: lspci -nvvs 00:14.0 00:14.0 0c03: 8086:1e31 (rev 04) (prog-if 30 [XHCI]) Subsystem: 1043:1517 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 41 Region 0: Memory at f7d0 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Address: fee0a00c Data: 4122 Kernel driver in use: xhci_hcd here is some log after device resume: [ 6719.265241] ath9k_htc: Driver unloaded [ 6723.581445] usb 3-2: reset high-speed USB device number 32 using xhci_hcd [ 6723.602774] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880114a40800 [ 6723.602778] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880114a40840 [ 6723.602781] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880114a40880 [ 6723.602784] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880114a408c0 [ 6723.602786] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880114a40900 [ 6723.602790] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880114a40940 [ 6723.603138] usb 3-2: ath9k_htc: Firmware htc_9271.fw requested Is the code issuing a device reset, or is the code trying to reset the endpoints? This dmesg was generated without any extra code in kernel or firmware. Just USB_QUIRK_RESET_RESUME. My firmware workaround will do only USB_PHY reset, not complete device. In this case USB_PHY is FUSB200 ip core. Can you please enable CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING and send me the dmesg from shortly before the device is reset, through just after the device is reset. That will let me see if the xHCI host is allowing the device to be reset. attached. after module is removed in 2 seconds device will be suspended. After module load, it is resumed. But after some requests i'll get corrupt packets. Every data packet on EP4, bigger as 64byte will be corrupt. i _assume_ USB_PHY is misconnfigured. Beside, this endpoint has workaround in firmware to handle packets bigger 64bytes. For now i have fallowing workarounds: - use USB2.0 HC... device is resumed and reseted without any side effects. - reload xhci_hcd module... should it do device reset? - do USB_PHY of ath9k_htc from frimware. But it will generate disconnect event, new device number and so on. -- Regards, Oleksij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote: On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. The OMAP3 platforms still needs to be supported for non-dt :-s Can't you leave the existing PHY handling for legacy OMAP3 USB PHY until they are all converted? I don't expect that to take a long time now that the OMAP4 board files have been removed. Are there still drivers without DT bindings that hold up the removal of the OMAP3 board files? Otherwise I'd suggest delaying the phy subsystem by another merge window, until that is resolved. 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
[PATCH v2 3/3] net/usb/r8152: adjust relative ocp function
- fix the conversion between cpu and __le32
- replace some pla_ocp and usb_ocp functions with generic_ocp function
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 66 +
1 file changed, 23 insertions(+), 43 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ef033ab..11c51f2 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -514,37 +514,31 @@ int usb_ocp_write(struct r8152 *tp, u16 index, u16
byteen, u16 size, void *data)
static u32 ocp_read_dword(struct r8152 *tp, u16 type, u16 index)
{
- u32 data;
+ __le32 data;
- if (type == MCU_TYPE_PLA)
- pla_ocp_read(tp, index, sizeof(data), data);
- else
- usb_ocp_read(tp, index, sizeof(data), data);
+ generic_ocp_read(tp, index, sizeof(data), data, type);
return __le32_to_cpu(data);
}
static void ocp_write_dword(struct r8152 *tp, u16 type, u16 index, u32 data)
{
- if (type == MCU_TYPE_PLA)
- pla_ocp_write(tp, index, BYTE_EN_DWORD, sizeof(data), data);
- else
- usb_ocp_write(tp, index, BYTE_EN_DWORD, sizeof(data), data);
+ __le32 tmp = __cpu_to_le32(data);
+
+ generic_ocp_write(tp, index, BYTE_EN_DWORD, sizeof(tmp), tmp, type);
}
static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 index)
{
u32 data;
+ __le32 tmp;
u8 shift = index 2;
index = ~3;
- if (type == MCU_TYPE_PLA)
- pla_ocp_read(tp, index, sizeof(data), data);
- else
- usb_ocp_read(tp, index, sizeof(data), data);
+ generic_ocp_read(tp, index, sizeof(tmp), tmp, type);
- data = __le32_to_cpu(data);
+ data = __le32_to_cpu(tmp);
data = (shift * 8);
data = 0x;
@@ -553,7 +547,8 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16
index)
static void ocp_write_word(struct r8152 *tp, u16 type, u16 index, u32 data)
{
- u32 tmp, mask = 0x;
+ u32 mask = 0x;
+ __le32 tmp;
u16 byen = BYTE_EN_WORD;
u8 shift = index 2;
@@ -566,34 +561,25 @@ static void ocp_write_word(struct r8152 *tp, u16 type,
u16 index, u32 data)
index = ~3;
}
- if (type == MCU_TYPE_PLA)
- pla_ocp_read(tp, index, sizeof(tmp), tmp);
- else
- usb_ocp_read(tp, index, sizeof(tmp), tmp);
+ generic_ocp_read(tp, index, sizeof(tmp), tmp, type);
- tmp = __le32_to_cpu(tmp) ~mask;
- tmp |= data;
- tmp = __cpu_to_le32(tmp);
+ data |= __le32_to_cpu(tmp) ~mask;
+ tmp = __cpu_to_le32(data);
- if (type == MCU_TYPE_PLA)
- pla_ocp_write(tp, index, byen, sizeof(tmp), tmp);
- else
- usb_ocp_write(tp, index, byen, sizeof(tmp), tmp);
+ generic_ocp_write(tp, index, byen, sizeof(tmp), tmp, type);
}
static u8 ocp_read_byte(struct r8152 *tp, u16 type, u16 index)
{
u32 data;
+ __le32 tmp;
u8 shift = index 3;
index = ~3;
- if (type == MCU_TYPE_PLA)
- pla_ocp_read(tp, index, sizeof(data), data);
- else
- usb_ocp_read(tp, index, sizeof(data), data);
+ generic_ocp_read(tp, index, sizeof(tmp), tmp, type);
- data = __le32_to_cpu(data);
+ data = __le32_to_cpu(tmp);
data = (shift * 8);
data = 0xff;
@@ -602,7 +588,8 @@ static u8 ocp_read_byte(struct r8152 *tp, u16 type, u16
index)
static void ocp_write_byte(struct r8152 *tp, u16 type, u16 index, u32 data)
{
- u32 tmp, mask = 0xff;
+ u32 mask = 0xff;
+ __le32 tmp;
u16 byen = BYTE_EN_BYTE;
u8 shift = index 3;
@@ -615,19 +602,12 @@ static void ocp_write_byte(struct r8152 *tp, u16 type,
u16 index, u32 data)
index = ~3;
}
- if (type == MCU_TYPE_PLA)
- pla_ocp_read(tp, index, sizeof(tmp), tmp);
- else
- usb_ocp_read(tp, index, sizeof(tmp), tmp);
+ generic_ocp_read(tp, index, sizeof(tmp), tmp, type);
- tmp = __le32_to_cpu(tmp) ~mask;
- tmp |= data;
- tmp = __cpu_to_le32(tmp);
+ data |= __le32_to_cpu(tmp) ~mask;
+ tmp = __cpu_to_le32(data);
- if (type == MCU_TYPE_PLA)
- pla_ocp_write(tp, index, byen, sizeof(tmp), tmp);
- else
- usb_ocp_write(tp, index, byen, sizeof(tmp), tmp);
+ generic_ocp_write(tp, index, byen, sizeof(tmp), tmp, type);
}
static void r8152_mdio_write(struct r8152 *tp, u32 reg_addr, u32 value)
--
1.8.3.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 2/3] net/usb/r8152: make sure the USB buffer is DMA-able
Allocate the required memory before calling usb_control_msg. And
the additional memory copy is necessary.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 60 -
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ee13f9e..ef033ab 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -344,17 +344,41 @@ static const int multicast_filter_limit = 32;
static
int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
{
- return usb_control_msg(tp-udev, usb_rcvctrlpipe(tp-udev, 0),
+ int ret;
+ void *tmp;
+
+ tmp = kmalloc(size, GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ ret = usb_control_msg(tp-udev, usb_rcvctrlpipe(tp-udev, 0),
RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
- value, index, data, size, 500);
+ value, index, tmp, size, 500);
+
+ memcpy(data, tmp, size);
+ kfree(tmp);
+
+ return ret;
}
static
int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
{
- return usb_control_msg(tp-udev, usb_sndctrlpipe(tp-udev, 0),
+ int ret;
+ void *tmp;
+
+ tmp = kmalloc(size, GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ memcpy(tmp, data, size);
+
+ ret = usb_control_msg(tp-udev, usb_sndctrlpipe(tp-udev, 0),
RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
- value, index, data, size, 500);
+ value, index, tmp, size, 500);
+
+ kfree(tmp);
+ return ret;
}
static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
@@ -685,21 +709,14 @@ static void ocp_reg_write(struct r8152 *tp, u16 addr, u16
data)
static inline void set_ethernet_addr(struct r8152 *tp)
{
struct net_device *dev = tp-netdev;
- u8 *node_id;
+ u8 node_id[8] = {0};
- node_id = kmalloc(sizeof(u8) * 8, GFP_KERNEL);
- if (!node_id) {
- netif_err(tp, probe, dev, out of memory);
- return;
- }
-
- if (pla_ocp_read(tp, PLA_IDR, sizeof(u8) * 8, node_id) 0)
+ if (pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id) 0)
netif_notice(tp, probe, dev, inet addr fail\n);
else {
memcpy(dev-dev_addr, node_id, dev-addr_len);
memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
}
- kfree(node_id);
}
static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
@@ -882,15 +899,10 @@ static void rtl8152_set_rx_mode(struct net_device *netdev)
static void _rtl8152_set_rx_mode(struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- u32 tmp, *mc_filter;/* Multicast hash filter */
+ u32 mc_filter[2]; /* Multicast hash filter */
+ __le32 tmp[2];
u32 ocp_data;
- mc_filter = kmalloc(sizeof(u32) * 2, GFP_KERNEL);
- if (!mc_filter) {
- netif_err(tp, link, netdev, out of memory);
- return;
- }
-
clear_bit(RTL8152_SET_RX_MODE, tp-flags);
netif_stop_queue(netdev);
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
@@ -918,14 +930,12 @@ static void _rtl8152_set_rx_mode(struct net_device
*netdev)
}
}
- tmp = mc_filter[0];
- mc_filter[0] = __cpu_to_le32(swab32(mc_filter[1]));
- mc_filter[1] = __cpu_to_le32(swab32(tmp));
+ tmp[0] = __cpu_to_le32(swab32(mc_filter[1]));
+ tmp[1] = __cpu_to_le32(swab32(mc_filter[0]));
- pla_ocp_write(tp, PLA_MAR, BYTE_EN_DWORD, sizeof(u32) * 2, mc_filter);
+ pla_ocp_write(tp, PLA_MAR, BYTE_EN_DWORD, sizeof(tmp), tmp);
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
netif_wake_queue(netdev);
- kfree(mc_filter);
}
static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
--
1.8.3.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 1/3] net/usb/r815x: replace USB buffer from stack to DMA-able
Some USB buffers use stack which may not be DMA-able.
Use the buffers from kmalloc to replace those one.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r815x.c | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r815x.c b/drivers/net/usb/r815x.c
index 8523922..e9b99ba 100644
--- a/drivers/net/usb/r815x.c
+++ b/drivers/net/usb/r815x.c
@@ -24,34 +24,43 @@
static int pla_read_word(struct usb_device *udev, u16 index)
{
- int data, ret;
+ int ret;
u8 shift = index 2;
- __le32 ocp_data;
+ __le32 *tmp;
+
+ tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
index = ~3;
ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
RTL815x_REQ_GET_REGS, RTL815x_REQT_READ,
- index, MCU_TYPE_PLA, ocp_data, sizeof(ocp_data),
- 500);
+ index, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500);
if (ret 0)
- return ret;
+ goto out2;
- data = __le32_to_cpu(ocp_data);
- data = (shift * 8);
- data = 0x;
+ ret = __le32_to_cpu(*tmp);
+ ret = (shift * 8);
+ ret = 0x;
- return data;
+out2:
+ kfree(tmp);
+ return ret;
}
static int pla_write_word(struct usb_device *udev, u16 index, u32 data)
{
- __le32 ocp_data;
+ __le32 *tmp;
u32 mask = 0x;
u16 byen = BYTE_EN_WORD;
u8 shift = index 2;
int ret;
+ tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
data = mask;
if (shift) {
@@ -63,19 +72,20 @@ static int pla_write_word(struct usb_device *udev, u16
index, u32 data)
ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
RTL815x_REQ_GET_REGS, RTL815x_REQT_READ,
- index, MCU_TYPE_PLA, ocp_data, sizeof(ocp_data),
- 500);
+ index, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500);
if (ret 0)
- return ret;
+ goto out3;
- data |= __le32_to_cpu(ocp_data) ~mask;
- ocp_data = __cpu_to_le32(data);
+ data |= __le32_to_cpu(*tmp) ~mask;
+ *tmp = __cpu_to_le32(data);
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
RTL815x_REQ_SET_REGS, RTL815x_REQT_WRITE,
- index, MCU_TYPE_PLA | byen, ocp_data,
- sizeof(ocp_data), 500);
+ index, MCU_TYPE_PLA | byen, tmp, sizeof(*tmp),
+ 500);
+out3:
+ kfree(tmp);
return ret;
}
--
1.8.3.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: usb cdc-acm driver cause windows xp sp3 blue screen randomly
1) try to use different timeout 2) try to use C# or other DotNet language. If you can re-write your host application, another choice is to use a different driver like WinUSB to your device and then use libusb-1.0 API to communicate with your device. Ok， this way work for me, I will try to re-write the host application. If I finish the work, will let you know, thanks a lot. On Thu, Jul 25, 2013 at 12:53 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, Jul 25, 2013 at 12:39 PM, Yingchun Li sword.l.dra...@gmail.com wrote: Thanks xiaofan The usb device has been fixed by the chip romcode, so there is little chance for switching to HID. But can I implement a usb-serial driver with libusb, which just work like usbser.sys? I will check the libusb, thank you! No, you will not be able to make libusb (raw USB communication) to work like usbser.sys (use Serial Port API). Windows usbser.sys is not a good choice for your device. You will find those major USB to Serial chip vendors (Prolific, FTDI, TI, etc) all use vendor specific class and develop their own device driver under Windows. But if you can not change your firmware, you can also purchase commercial CDC-ACM driver from vendors like. I do not know how good they are and how expensive they are compared to changing your firmware. http://www.mcci.com/mcci-v5/hostside/usb_serial_drivers.html http://www.thesycon.de/eng/usb_cdcacm.shtml https://www.jungo.com/st/drivercore/cdc_acm_driver.html On the other hand, if you still want to stick with usbser.sys, you may be able to change your host application to avoid BSOD issues as mentioned in the Microchip forum thread. Ref: http://www.microchip.com/forums/tm.aspx?m=714138 Ref: http://www.microchip.com/forums/m469465.aspx 1) try to use different timeout 2) try to use C# or other DotNet language. If you can re-write your host application, another choice is to use a different driver like WinUSB to your device and then use libusb-1.0 API to communicate with your device. -- Xiaofan -- 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 cdc-acm driver cause windows xp sp3 blue screen randomly
On Thu, Jul 25, 2013 at 4:02 PM, Yingchun Li sword.l.dra...@gmail.com wrote: 1) try to use different timeout 2) try to use C# or other DotNet language. If you can re-write your host application, another choice is to use a different driver like WinUSB to your device and then use libusb-1.0 API to communicate with your device. Ok， this way work for me, I will try to re-write the host application. If I finish the work, will let you know, thanks a lot. Make sure you read the CDC-ACM spec here if you want to use libusb. http://www.usb.org/developers/devclass_docs/usbcdc11.pdf -- Xiaofan -- 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: Buffer size for ALSA USB PCM audio
At Wed, 24 Jul 2013 11:43:58 -0400 (EDT),
Alan Stern wrote:
On Wed, 24 Jul 2013, Takashi Iwai wrote:
I don't understand. Consider a simple playback example. Suppose the
user wants to keep the latency low, so he requests 2 periods per
buffer. snd-usb-audio ignores this value and decides to use 10 URBs,
which is equivalent to setting the buffer size to 10 periods.
You don't have to fill all 10 URBs to start the stream...
Maybe you don't have to, but it looks the driver does just that. From
snd_usb_endpoint_start():
if (snd_usb_endpoint_implicit_feedback_sink(ep)) {
for (i = 0; i ep-nurbs; i++) {
struct snd_urb_ctx *ctx = ep-urb + i;
list_add_tail(ctx-ready_list,
ep-ready_playback_urbs);
}
return 0;
}
for (i = 0; i ep-nurbs; i++) {
struct urb *urb = ep-urb[i].urb;
if (snd_BUG_ON(!urb))
goto __error;
if (usb_pipeout(ep-pipe)) {
prepare_outbound_urb(ep, urb-context);
} else {
prepare_inbound_urb(ep, urb-context);
}
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err 0) {
snd_printk(KERN_ERR cannot submit urb %d, error %d:
%s\n,
i, err, usb_error_string(err));
goto __error;
}
set_bit(i, ep-active_mask);
}
In this case, I'm particularly considering what happens when
snd_usb_endpoint_implicit_feedback_sink(ep) is false.
Besides, what's the reason for allocating 10 URBs if you're not going
to submit more than 2 of them at a time?
I don't know how you deduced 10 urbs in your example, but in general,
ep-nurbs is calculated so that the driver can hold at least two
ep-periods (i.e. double buffer). The USB audio driver has
essentially two buffers: an internal hardware buffer via URBs and an
intermediate buffer via vmalloc. The latter is exposed to user-space
and its content is copied to the URBs appropriately via complete
callbacks.
Due to this design, we just need two periods for URB buffers,
ideally, no matter how many periods are used in the latter buffer
specified by user. That's why no buffer_size is needed in ep-nurbs
estimation. The actual calculation is, however, a bit more
complicated to achieve enough fine-grained updates but yet not too big
buffer size. I guess this can be simplified / improved.
Takashi
--
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: v3.11-rc1 USB regressions
On 25.07.2013 02:30, Aaro Koskinen wrote: On Wed, Jul 24, 2013 at 09:04:28PM +0200, Daniel Mack wrote: On 24.07.2013 20:51, Aaro Koskinen wrote: When I revert fe4cb0912f8e737f8e4b8b38b9e692f8062f5423 and 8b125df5b24cfb0ec7fa1971e343cc0badc1827d, it works like before (3.10): I'm now running -rc2 with above fixes and reverts (the only way to get USB working). I'm seeing an additional issue, the following crash happens always on N900 when doing poweroff: Yes, with the mentioned patches reverted, musb_to_hcd() will return a faulty pointer. You can't easily revert them unfortunately. Your platform needs a real fix, I just have trouble understanding why a removed usb_add_hcd() would make the gadget code fail. Sorry for the trouble, but I don't currently have a board with musb in gadget mode to reproduce this issue. If you have any ideas what to look for, I can maybe try to debug this issue. Please try changing the .mode field of musb_board_data to MUSB_OTG in your board file (arch/arm/mach-omap2/board-rx51.c). That should bring back the call to usb_add_hcd(), provided that you have USB_MUSB_DUAL_ROLE=y. I still don't see a reason why this is should be necessary for peripheral-only use though. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On 07/24/2013 08:32 PM, Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. Indeed, I was also a bit surprised we still need non-dt support, since migration to this generic PHY framework in case of exynos was solely part of migration of the whole platform to DT. Two of the drivers that are being converted are also used on s5pv210, but there is currently no boards in mainline that would use devices covered by those drivers and s5pv210 will very likely get DT support in v3.13 anyway. But it seems omap still needs non-dt support in the PHY framework. --- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote: Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. There's a bunch of non-DT architectures that are in active use (blackfin for example) and I'd really hope that this is useful for some of them. The pushback here was about the fact that the subsystem was doing odd things with selecting device names which is odd in itself, I don't know if that had bled over into the DT bindings but it sounded like it might've done so. signature.asc Description: Digital signature
Re: [PATCH] staging: ozwpan: Fix coding style.
On 24/07/13 15:06, Rupesh Gujare wrote:
This patch fixes coding style issues reported by Dan here:-
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2012-June/027767.html
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozcdev.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 3e29760..73b582c 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -333,10 +333,11 @@ int oz_cdev_register(void)
{
int err;
struct device *dev;
+
memset(g_cdev, 0, sizeof(g_cdev));
err = alloc_chrdev_region(g_cdev.devnum, 0, 1, ozwpan);
if (err 0)
- goto out3;
+ return err;
oz_dbg(ON, Alloc dev number %d:%d\n,
MAJOR(g_cdev.devnum), MINOR(g_cdev.devnum));
cdev_init(g_cdev.cdev, oz_fops);
@@ -347,26 +348,26 @@ int oz_cdev_register(void)
err = cdev_add(g_cdev.cdev, g_cdev.devnum, 1);
if (err 0) {
oz_dbg(ON, Failed to add cdev\n);
- goto out2;
+ goto unregister;
}
g_oz_class = class_create(THIS_MODULE, ozmo_wpan);
if (IS_ERR(g_oz_class)) {
oz_dbg(ON, Failed to register ozmo_wpan class\n);
err = PTR_ERR(g_oz_class);
- goto out1;
+ goto delete;
}
dev = device_create(g_oz_class, NULL, g_cdev.devnum, NULL, ozwpan);
if (IS_ERR(dev)) {
oz_dbg(ON, Failed to create sysfs entry for cdev\n);
err = PTR_ERR(dev);
- goto out1;
+ goto delete;
}
return 0;
-out1:
+
+delete:
cdev_del(g_cdev.cdev);
-out2:
+unregister:
unregister_chrdev_region(g_cdev.devnum, 1);
-out3:
return err;
}
/*--
Greg,
Did you missed this patch ? Or did I made another mistake. :( ?
--
Regards,
Rupesh Gujare
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? -- Regards, Laurent Pinchart -- 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] staging: ozwpan: Fix coding style.
On Thu, Jul 25, 2013 at 10:30:30AM +0100, Rupesh Gujare wrote: Greg, Did you missed this patch ? Or did I made another mistake. :( ? Chillax. It has only been one day. Ask again after two or three weeks. regards, dan carpenter -- 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/1] TX throttling bug-fixing patch of AX88179_178A
On Thu, 2013-07-25 at 13:25 +0800, Ming Lei wrote: On Thu, Jul 25, 2013 at 1:10 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote: It depends if size of sg buffer(except for last one) in the sg list can be divided by usb endpoint's max packet size(512 or 1024), at least there is the constraint: http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-nextid=10e232c597ac757e7f8600649f7e872e86de190f I am wondering if network stack can meet that. If not, it might be a bit difficult because lots of USB host controller don't support that, and driver may have to support SG and non-SG at the same time for working well on all HCs. I do not see the problem. If one skb has 2 fragments of 32KB, couldn't they be split into 64 1K segments by the device driver ? OK, if length of fragments of all SKBs from network stack can always guarantee to be divided by 1024, that is fine, seems I worry about too much, :-) Unfortunately, there is no such guarantee. TSO permits sendfile() zero copy operation, so the frags can be of any size, any offset... In this mode, the first element (skb-head) will typically contains the headers, and there are way below 512 bytes. So even with lowering netdev-gso_max_size under PAGE_SIZE, most of the packets will need to be copied into a single segment. -- 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] staging: ozwpan: Fix coding style.
On 25/07/13 11:39, Dan Carpenter wrote: On Thu, Jul 25, 2013 at 10:30:30AM +0100, Rupesh Gujare wrote: Greg, Did you missed this patch ? Or did I made another mistake. :( ? Chillax. It has only been one day. Ask again after two or three weeks. All right Dan, Probably I was getting too impatient, while watching that other patches in queue are getting pulled in. :( -- Regards, Rupesh Gujare -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Laurent Pinchart wrote: On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. 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 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote: On Thursday 25 July 2013, Laurent Pinchart wrote: On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Fair enough :-) -- Regards, Laurent Pinchart -- 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
Suunto ANT+ stick
Hi, I have a Suunto ANT+ stick (designed to communicate with various training equipment) that works as a USB serial device. Unfortunately, it seems like its PCI IDs are missing; it doesn't come up unless I add vendor= and product= to the usbserial loading line explicitly. When I do, however, it works fine. More information: http://noelob.blogspot.com/2011/10/garmin-forerunner-405-in-ubuntu-1104.html The device looks like this in lsusb: Bus 004 Device 006: ID 0fcf:1008 Dynastream Innovations, Inc. Mini stick Suunto Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize032 idVendor 0x0fcf Dynastream Innovations, Inc. idProduct 0x1008 Mini stick Suunto bcdDevice1.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 2 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 2 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Do you think you could have a look? I'd be happy to test. The device works fine under Android (with USB-To-Go), so maybe there's a patch that can be pulled from there. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote: I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Well, it seemed like Greg's concerns had already been addressed anyway. signature.asc Description: Digital signature
Re: [PATCH v12 00/13] Add tested id switch and vbus connect detect support for Chipidea
Dear Peter Chen, On Thu, Jul 25, 2013 at 07:55:23AM +0200, Marek Vasut wrote: Hi Peter, I have not tried the manual switching, but first, you need to close your vbus supply. I think we can close this issue, I will now be also getting MX28EVK. Thanks for all your help! Great. What's the problem? Any changes for this patchset? No changes needed, I had VDD5V constantly tied to 5V so I didn't get the VBUS interrupt. Best regards, Marek Vasut -- 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: Audio I/O parameters
On Wed, Jul 24, 2013 at 2:42 AM, James Stone jamesmst...@gmail.com wrote: On Wed, Jul 24, 2013 at 12:23 AM, James Stone jamesmst...@gmail.com wrote: On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge he...@resisty.net wrote: On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote: On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 19 Jul 2013, James Stone wrote: The questions now are: Why are the same requests sent over and over again? Why does the ALSA driver attempt to set the clock frequency while the clock is actively in use? Has this behavior changed since the 3.5 kernel? Well, I think these requests may correspond to the lights flashing on and off on the front of the device. When starting the device in 3.5 at 256 frames/period (duplex), the lights flash on and off 2 times, in the current patched 3.8 version I have been using, the device lights flash on and off 4 times before starting jack with exactly the same settings - so it seems for some reason, the requests are going through multiple times on the 3.8 kernel but not on 3.5. I will send a 3.5 usbmon trace of a successful start off list (plus the same for 3.8?) if it would be useful. I don't know -- it's up to Clemens. Alan Stern Hi Alan, Just tried a few old kernels, and it seems that the bug I am experiencing was introduced at the start of 3.7 - kernel 3.6.11 is fine, and all the 3.7 series kernels are broken. So it seems it is not the updated ehci usb code that is directly responsible for the realtime audio problem. I have been trying the kernels from: http://kernel.ubuntu.com/~kernel-ppa/mainline/. Any suggestions on how to further zoom in on the culprit commit? Can you reproduce the problem on a 3.10 kernel? I suspect this is related to the commit 61a70950 ALSA: usb-audio: Move configuration to prepare in kernel 3.7, which introduced calls to set sample rate in prepare, even if the sample rate is unchanged. It looks like jackd calls prepare twice when starting, which is consistent with two get rate/set rate sequences. The unnecessary set rate shouldn't happen with kernel 3.10, as it includes fa92dd77 ALSA: usb - Avoid unnecessary sample rate changes on USB 2.0 clock sources, which says in the commit message: The Scarlett 2i2 seems to take almost 500 ms to set the sample rate, even if the clock is currently set to that value. This patch speeds up prepare of the device, by avoiding setting the clock to something it already is. Torstein Thanks for this info. I just tried it out, and the device starts up much more cleanly - no flashing lights etc. at longer latencies. It will still not start jackd at 256 frames/period, but this might need Clemen's do not trust too-big wMaxPacketSize values patch added.. Will report back. James Ok - this does seem to be a vast improvement over 3.8.x (and even, in some ways the 3.6x series) - with the addition of Clemen's patch. However, very low realtime latencies (which seemed to be somewhat possible - 64 frames/period or lower - in the 3.6x series) will no longer work properly. 128 frames/period looks fairly usable. Will continue with bisect to see if I can discover anything else. Ok -from the bisect, the problem of not being able to get to sub 64-frames per period starts with: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112 Could this be the offending deletion? http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/sound/usb/endpoint.c?id=fc600432cd23e35c85de2ff4468d816d6938a112 ?? James -- 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: Audio I/O parameters
James Stone wrote: Ok -from the bisect, the problem of not being able to get to sub 64-frames per period starts with: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112 This is a merge, which includes this commit: http://git.kernel.org/linus/e9ba389c5ffc. Could this be the offending deletion? http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/sound/usb/endpoint.c?id=fc600432cd23e35c85de2ff4468d816d6938a112 (There is a corresponding change in pcm.c.) The commit that you found by bisection got reverted later: http://git.kernel.org/linus/015618b902ae Please check that the code of Fix URB cancellation at stream start is in your current kernel. Regards, Clemens -- 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: Audio I/O parameters
On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch clem...@ladisch.de wrote: James Stone wrote: Ok -from the bisect, the problem of not being able to get to sub 64-frames per period starts with: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112 This is a merge, which includes this commit: http://git.kernel.org/linus/e9ba389c5ffc. Could this be the offending deletion? http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/sound/usb/endpoint.c?id=fc600432cd23e35c85de2ff4468d816d6938a112 (There is a corresponding change in pcm.c.) The commit that you found by bisection got reverted later: http://git.kernel.org/linus/015618b902ae Please check that the code of Fix URB cancellation at stream start is in your current kernel. well, in 3.10, it is not exactly the same as the above revertion. For example: /* just to be sure */ deactivate_urbs(ep, false); if (can_sleep) -- 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/1] TX throttling bug-fixing patch of AX88179_178A
On Thu, 2013-07-25 at 13:25 +0800, Ming Lei wrote: On Thu, Jul 25, 2013 at 1:10 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote: It depends if size of sg buffer(except for last one) in the sg list can be divided by usb endpoint's max packet size(512 or 1024), at least there is the constraint: http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-nextid=10e232c597ac757e7f8600649f7e872e86de190f I am wondering if network stack can meet that. If not, it might be a bit difficult because lots of USB host controller don't support that, and driver may have to support SG and non-SG at the same time for working well on all HCs. I do not see the problem. If one skb has 2 fragments of 32KB, couldn't they be split into 64 1K segments by the device driver ? OK, if length of fragments of all SKBs from network stack can always guarantee to be divided by 1024, that is fine, seems I worry about too much, :-) Not that I have any experience with USB drivers, but perhaps usb_sg_init()? Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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 7/7] usb: phy: msm: Lindent the code
Hi,
On Wed, 2013-07-24 at 15:22 +0300, Felipe Balbi wrote:
On Mon, Jun 24, 2013 at 06:27:44PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
I really don't like blind Lindent patches... sometimes it makes things
even worse.
It is not exactly blindly. I have removed some of the changes in the
platform_driver structure.
---
drivers/usb/phy/phy-msm-usb.c | 99
++---
1 file changed, 52 insertions(+), 47 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 6d05085..111f454 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -64,8 +64,8 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
if (init) {
ret = regulator_set_voltage(motg-vddcx,
- USB_PHY_VDD_DIG_VOL_MIN,
- USB_PHY_VDD_DIG_VOL_MAX);
+ USB_PHY_VDD_DIG_VOL_MIN,
+ USB_PHY_VDD_DIG_VOL_MAX);
like here, what's the point ?
It makes indentation the same like the majority of the code.
I could drop this patch if you like.
Thanks,
Ivan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] usb: phy: msm: Migrate to Managed Device Resource allocation
Hi,
On Wed, 2013-07-24 at 15:38 +0300, Felipe Balbi wrote:
Hi,
On Tue, Jul 09, 2013 at 06:47:08PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
Use managed device resources to clean up the probe/remove
and get DT support for free.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/phy/phy-msm-usb.c | 78
+++--
1 file changed, 20 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index ab1b880..cc37f5e 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1458,30 +1455,27 @@ static int __init msm_otg_probe(struct
platform_device *pdev)
* clock is introduced to remove the dependency on AXI
* bus frequency.
*/
- motg-core_clk = clk_get(pdev-dev, usb_hs_core_clk);
+ motg-core_clk = devm_clk_get(pdev-dev, usb_hs_core_clk);
if (IS_ERR(motg-core_clk))
motg-core_clk = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
no need to check for the resource when using devm_ioremap_resource()
dev_err(pdev-dev, failed to get platform resource mem\n);
- ret = -ENODEV;
- goto put_core_clk;
+ return -ENODEV;
}
- motg-regs = ioremap(res-start, resource_size(res));
+ motg-regs = devm_ioremap_resource(pdev-dev, res);
if (!motg-regs) {
dev_err(pdev-dev, ioremap failed\n);
don't print error messages when using devm_ioremap_resource()
Will fix these places and re-send,
Thank you,
Ivan
--
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 3/7] usb: phy: msm: Move regulator usage to managed resource allocation
On Wed, 2013-07-24 at 15:39 +0300, Felipe Balbi wrote: On Tue, Jul 09, 2013 at 06:47:09PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com This patch move global regulators variables to driver state structire and move allocation of the regulators to be devm managed. split into two patches please. One for moving the global regulators into your structure and a separate patch to move to devm_* Ok, will do and resend. Ivan -- 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: External HDD does not work with 3.11-rc2
On Thu, 25 Jul 2013, Philipp Dreimann wrote: kernel log, lsusb and usbmon are attached. I tried usb2 and 3 ports, both have the same issue with this drive. Other drives work. The problem is caused by some program on your computer sending a command to the drive that it can't handle (SCSI INQUIRY command with a transfer length of 512). It is not a kernel problem. Thanks, I can reproduce the issue using kernel 3.9.9 and $ sg_inq -l 512 /dev/sdb I am guessing that this is the reason for the suspend/resume issues with 3.9 and 3.10 as well. A look at the program's code might reveal why this was not triggered on 3.9 and 3.10 as bad as on 3.11... Do you know which program is the culprit? From the timing, it is likely to be something that udev runs. 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] Remove static sizing of usb_device_id arrays
In a message of Wed, 24 Jul 2013 15:52:08 -0700, Greg KH writes: On Sat, Jun 22, 2013 at 08:55:59PM +0200, Anders Hammarquist wrote: Signed-off-by: Anders Hammarquist i...@iko.pp.se --- drivers/usb/serial/ti_usb_3410_5052.c | 29 - 1 file changed, 24 insertions(+), 5 deletions(-) This patch, and your previous one, are no longer needed, right? They are needed until the module params for adding vendor and product ids are removed, and it sounded like the consensus was to keep them for a while. /Anders -- 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 V4] usb: Add Device Tree support to XHCI Platform driver
Hi, On Thu, Jul 25, 2013 at 02:10:46AM +0400, Sergei Shtylyov wrote: + compatible = xhci-platform; It again looks somewhat like a driver name, not a device name. What made you change the value from usb-xhci, Al? Look at [eo]hci-omap.txt in that directory. I asked. usb-xhci is too generic, so is xhci-platform. I rather have: compatible = snps,xhci if this is a synopsys IP -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] USBNET: max rx/tx qlen change
Hi, On Thu, Jul 25, 2013 at 3:38 PM, Oliver Neukum oneu...@suse.de wrote: On Thu, 2013-07-25 at 13:47 +0800, Ming Lei wrote: Hi, There are two patches on computing max rx/tx qlen, and fix one performance problem on USB3 NIC. I am afraid bisectability on SS is impaired. Otherwise this looks good. Bisectability on SS can't be impaired, and it is always the 2nd patch which fixes the performance issue on SS, and the 1st one only does code refactoring thing. 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 1/5] usb: xhci: add the suspend/resume functionality
HI,
On Wed, Jul 24, 2013 at 10:54:47AM -0700, Sarah Sharp wrote:
+#ifdef CONFIG_PM
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ return xhci_suspend(xhci);
+}
Where does the wakeup setting get taken into account?
Which wakeup setting are you talking about? Do you mean making sure the
wake on bits are set for the roothub ports when the bus is suspended?
Or do you mean that the platform device needs to have some way to enable
wake from S3/S4 for the xHCI host controller itself?
The latter. Not only does there need to be some mechanism to wake up
the system from S3/S4 when the xHCI controller detects a wakeup event;
there also has to be a way to enable or disable this mechanism
depending on the value of device_may_wakeup(dev).
Ok, that sounds like something that needs to be addressed on top of this
patch. Vikas, Abhilash, or Felipe, can you create a patch that fixes
this?
I won't have time for this at least for a couple months, if someone who
already has access to a chromebook with a working setup can handle that,
I'd be glad.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 7/7] usb: phy: msm: Lindent the code
Hi,
On Thu, Jul 25, 2013 at 04:40:51PM +0300, Ivan T. Ivanov wrote:
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 6d05085..111f454 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -64,8 +64,8 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg,
int init)
if (init) {
ret = regulator_set_voltage(motg-vddcx,
- USB_PHY_VDD_DIG_VOL_MIN,
- USB_PHY_VDD_DIG_VOL_MAX);
+ USB_PHY_VDD_DIG_VOL_MIN,
+ USB_PHY_VDD_DIG_VOL_MAX);
like here, what's the point ?
It makes indentation the same like the majority of the code.
I could drop this patch if you like.
yeah, I don't think it's worth to have this patch. Just looked at the
driver and, at least to my eyes, it didn't look all that bad. Matter of
taste though
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/5] usb: phy: phy-nop: add support for am335x PHY
Hi, On Fri, Jul 05, 2013 at 03:32:54PM +0200, Sebastian Andrzej Siewior wrote: The am335x PHY code is well hidden in multiple places. The glue layer uses the nop and does up/down in the background. This patch copies the power on / power off part out of dsps so it can be removed later in dsps. At this point I am not sure if it is better to write a new phy driver for am335x or just add the missing pieces to this one. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de hmm, if you do all of this then phy-nop doesn't make a lot of sense anymore. Can you add a few patches to start calling file and functions phy-generic/usb_phy_gen. Other than that looks good. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/5] arm: dts: am33xx: add USB phy nodes
On Fri, Jul 05, 2013 at 04:56:17PM +0200, Sebastian Andrzej Siewior wrote: On 07/05/2013 04:41 PM, Ruchika Kharwar wrote: On 07/05/2013 08:32 AM, Sebastian Andrzej Siewior wrote: The memory address contains three pieces that is the reset module which is currently the only one used and two other pices which seem interresting based on what the register. Please fix typos pices.. interresting.. also the description is not clear. Okay. What part is not clear? Well, this statement: ... which seem interresting based on what the register. seems like it misses something. based on what register \(does\|is\|implements\) ??? -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/5] usb: musb: dsps: remove the hardcoded phy pieces
Hi, On Fri, Jul 05, 2013 at 03:32:56PM +0200, Sebastian Andrzej Siewior wrote: dsps uses a nop driver which is added in dsps itself and does the PHY on/off calls within dsps. Since those calls are now moved the nop driver itself, we can now request the phy proper phy and remove those calls. Currently only the first musb interface is used so we only add one phy node for now. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de looks good, just wondering if this won't pose a regression since you're not substituting PHY handling with proper usb_phy_set_suspend() calls. -- balbi signature.asc Description: Digital signature
After entering D3 cold: URB ffff88020ea41000 submitted while active
https://bugzilla.kernel.org/show_bug.cgi?id=60621 Randomly after returning from S3 or enabling powersaving this trace goes to dmesg: [13108.297051] ehci-pci :00:1a.0: power state changed by ACPI to D3cold [13115.552813] [ cut here ] [13115.552841] WARNING: at drivers/usb/core/urb.c:327 usb_submit_urb+0x360/0x370 [usbcore]() [13115.552843] URB 88020ea41000 submitted while active [13115.552845] Modules linked in: hidp hid veth cpufreq_stats bridge stp llc af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan cdc_wdm qcserial usbnet usb_wwan usbserial mii iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec e1000e snd_hwdep sdhci_pci ehci_pci snd_pcm ehci_hcd thinkpad_acpi sdhci microcode psmouse xhci_hcd pcspkr hwmon snd_timer mmc_core i2c_i801 snd_page_alloc usbcore snd rfkill ptp usb_common pps_core soundcore evdev vboxnetflt(O) vboxdrv(O) loop tun fuse msr binfmt_misc acpi_call(O) openvswitch ipv6 autofs4 [13115.552888] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.10.1SIGN #29 [13115.552889] Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013 [13115.552890] 0009 88021e203d08 815a4258 88021e203d40 [13115.552892] 81096901 880213f28600 88020ea41180 880213f28650 [13115.552894] 880214756000 88021e203da0 8109696c [13115.552896] Call Trace: [13115.552897] IRQ [815a4258] dump_stack+0x19/0x1b [13115.552907] [81096901] warn_slowpath_common+0x61/0x80 [13115.552910] [8109696c] warn_slowpath_fmt+0x4c/0x50 [13115.552915] [815aa003] ? _raw_spin_unlock_irqrestore+0x33/0x40 [13115.552920] [a02f3a30] usb_submit_urb+0x360/0x370 [usbcore] [13115.552922] [a042fe96] wdm_int_callback+0x1c6/0x200 [cdc_wdm] [13115.552927] [a02f1615] usb_hcd_giveback_urb+0x55/0xc0 [usbcore] [13115.552931] [a03e8e4d] xhci_irq+0x42d/0x1400 [xhci_hcd] [13115.552935] [a03e9e31] xhci_msi_irq+0x11/0x20 [xhci_hcd] [13115.552938] [81115c36] handle_irq_event_percpu+0x56/0x250 [13115.552940] [81115e6d] handle_irq_event+0x3d/0x60 [13115.552942] [81118777] handle_edge_irq+0x77/0x130 [13115.552945] [8100436e] handle_irq+0x1e/0x30 [13115.552947] [815b342d] do_IRQ+0x4d/0xc0 [13115.552949] [815aa7ea] common_interrupt+0x6a/0x6a [13115.552950] EOI [814be9ec] ? cpuidle_enter_state+0x4c/0xc0 [13115.552954] [814beb29] cpuidle_idle_call+0xc9/0x280 [13115.552956] [8100b02e] arch_cpu_idle+0xe/0x30 [13115.552959] [810e3a7e] cpu_startup_entry+0xce/0x2d0 [13115.552961] [81592c0f] rest_init+0x7f/0x90 [13115.552964] [81aa4e34] start_kernel+0x3d5/0x3e1 [13115.552965] [81aa4868] ? repair_env_string+0x5c/0x5c [13115.552967] [81aa45a1] x86_64_start_reservations+0x2a/0x2c [13115.552968] [81aa466f] x86_64_start_kernel+0xcc/0xcf [13115.552969] ---[ end trace 2c05fe4cc22d7cf3 ]--- -- 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 4/5] usb: musb: dsps: use proper child nodes
On Fri, Jul 05, 2013 at 03:32:57PM +0200, Sebastian Andrzej Siewior wrote: This moves the two instances from the big node into two child nodes. The glue layer ontop does almost nothing. This could be two indepentant child nodes but I have no idea how 'ti,hwmods = usb_otg_hs;' affects the two musb controler. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de pretty good :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/5] musb: musb: dsps: remove instances variable
On Fri, Jul 05, 2013 at 03:32:58PM +0200, Sebastian Andrzej Siewior wrote: Remove the instances variable, there is no single use of it. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de nice :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] usb: dwc3: ep0: don't change to configured state too early
On Wed, Jul 24, 2013 at 02:01:27PM -0400, Alan Stern wrote: On Wed, 24 Jul 2013, Felipe Balbi wrote: Hi, On Tue, Jul 23, 2013 at 12:53:53PM -0400, Alan Stern wrote: I see. Doesn't the mass-storage gadget also use delayed status when going into the _un_configured state? no it doesn't, we bail out early if config number is zero, look at composite.c and you'll see in case of configuration zero, we just make sure to disable all endpoints and don't call -set_alt(): This is my fault, for not being more familiar with the composite framework, and no doubt I will regret asking this, but... Doesn't that approach leave the function drivers sitting around with all their resources still allocated? When do those resources get deallocated? When the gadget disconnects from the host? which resources are you talking about ? Endpoints ? -disable() should make sure to disable the endpoints, but it will only free the endpoints when the gadget driver is unbound. struct usb_requests will also be freed at -disable() time. Does this answer your question ? Yeah, I was mainly wondering about the usb_requests. is this a signal for you're good to go with your fix ? :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/16] usb: musb: dsps: init / shutdown the phy
On Mon, Jul 22, 2013 at 08:09:52PM +0200, Sebastian Andrzej Siewior wrote: If the init / shutdown function of the phy moves out of dsps into the phy driver, then dsps needs to call the callbacks of the phy driver to ensure that this happens. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de cool, eventually we should move these calls to musb_core.c though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 02/16] usb: phy: phy-nop: add support for am335x PHY
On Mon, Jul 22, 2013 at 08:09:53PM +0200, Sebastian Andrzej Siewior wrote: The am335x PHY code is well hidden in multiple places. The glue layer uses the nop and does up/down in the background. This patch copies the power on / power off part out of dsps so it can be removed later in dsps. At this point I am not sure if it is better to write a new phy driver for am335x or just add the missing pieces to this one. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de right, I replied to the wrong series, please add a patch renaming file and functions to phy-generic.c/usb_phy_gen_ or something similar. -- balbi signature.asc Description: Digital signature
Re: [PATCH V4] usb: Add Device Tree support to XHCI Platform driver
On Wed, Jul 24, 2013 at 6:10 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
Hello.
On 07/25/2013 01:21 AM, Sarah Sharp wrote:
It looks like all the feedback has been addressed, but I'm no device
tree expert.
Felipe, Matthijs, and Sergei, does this look good? If so, I'll queue to
my xhci tree.
Not quite there yet. Too bad I couldn't notice all the small issues at
once...
Sarah Sharp
On Tue, Jul 23, 2013 at 06:35:33PM -0400, Al Cooper wrote:
Add Device Tree match table to xhci-plat.c. Add DT bindings document.
Signed-off-by: Al Cooper alcoop...@gmail.com
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 14 ++
drivers/usb/host/xhci-plat.c | 10 ++
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
new file mode 100644
index 000..b88aee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -0,0 +1,14 @@
+USB XHCI controllers
I think the proper name is xHCI.
OK
+
+Required properties:
+ - compatible: should be xhci-platform.
+ - reg: should contain address and length of the standard XHCI
+register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Example:
+ xhci@f0931000 {
The node should be named just usb, not xhci (no programming interface
specific names), according to the ePAPR spec [1].
What about the existing node names ohci@ and ehci@?
+ compatible = xhci-platform;
It again looks somewhat like a driver name, not a device name. What made
you change the value from usb-xhci, Al? Look at [eo]hci-omap.txt in that
directory.
I changed the name because MODULE_DEVICE_TABLE() now uses the name and
that means the hotplug system will use it to identify the driver and
it seems like the
name should be unique enough to avoid confusion with something like
the xhci-pci driver.
+ reg = 0xf0931000 0x8c8;
+ interrupts = 0x0 0x4e 0x0;
+ };
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d718134..d547f24 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
[...]
@@ -212,11 +213,20 @@ static int xhci_plat_remove(struct platform_device
*dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id usb_xhci_of_match[] = {
+ { .compatible = xhci-platform },
+ {},
Consistency asks for a space inside {}. AFAIK, that's the usual Linux
style.
OK
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
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 06/16] usb: musb: dsps: rename ti81xx_driver_data to am33xx_driver_data
* Bin Liu | 2013-07-23 13:23:57 [-0500]: Hi Sebastian, Hi Liu, On Mon, Jul 22, 2013 at 1:09 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This patch renames the type struct from ti81xx_driver_data to am33xx_driver_data since it is not used for ti81xx anymore. The EOI member is also removed since the am33xx SoC does not have such register. The interrupt is acknowledged by writting into the stat register. I guess the EOI register is removed from the TRM because AM33xx does not use it, there is no need to write to it to acknowledge. It does not hurt to write to it though since the register still exists, it just does nothing, I guess. Is it really there or was it never there and it has been added to TRM by accident? But I am not sure if it is a good idea to remove eoi from the musb_dsps driver. If the intension is to merge the support for other SoC, such as AM35xx, AM18xx, then EOI handling might be still needed. I just don't know how those devices use EOI. If one of the architectures gets added which need an EOI then the offset can be 0 and the EOI will happen only if it is != 0. Regards, -Bin. Sebastian -- 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/16] usb: phy: phy-nop: add support for am335x PHY
* Felipe Balbi | 2013-07-25 17:33:30 [+0300]: On Mon, Jul 22, 2013 at 08:09:53PM +0200, Sebastian Andrzej Siewior wrote: right, I replied to the wrong series, please add a patch renaming file and functions to phy-generic.c/usb_phy_gen_ Sorry, I can't parse that. You want to rename phy-nop.c to phy-generic.c and add the additional functions in usb_phy_gen.c? or something similar. Sebastian -- 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: Buffer size for ALSA USB PCM audio
On Thu, 25 Jul 2013, Takashi Iwai wrote:
Besides, what's the reason for allocating 10 URBs if you're not going
to submit more than 2 of them at a time?
I don't know how you deduced 10 urbs in your example,
I made it up. :-)
but in general,
ep-nurbs is calculated so that the driver can hold at least two
ep-periods (i.e. double buffer). The USB audio driver has
essentially two buffers: an internal hardware buffer via URBs and an
intermediate buffer via vmalloc. The latter is exposed to user-space
and its content is copied to the URBs appropriately via complete
callbacks.
Due to this design, we just need two periods for URB buffers,
ideally, no matter how many periods are used in the latter buffer
specified by user. That's why no buffer_size is needed in ep-nurbs
estimation. The actual calculation is, however, a bit more
complicated to achieve enough fine-grained updates but yet not too big
buffer size. I guess this can be simplified / improved.
Ah, that makes sense. Thanks for the explanation.
The existing code has a problem: Under some conditions the URB queue
will be too short. EHCI requires at least 10 microframes on the queue
at all times (even when an URB is completing and is therefore no longer
on the queue) to avoid underruns. Well, 9 microframes is probably good
enough, but I'll use 10 to be safe. A typical arrangement of 2 URBs
each with 8 packets each (at 1 packet/uframe) violates this constraint,
and I have seen underruns in practice.
The patch below fixes this problem and drastically simplifies the
calculation. How does it look?
Alan Stern
Index: usb-3.10/sound/usb/endpoint.c
===
--- usb-3.10.orig/sound/usb/endpoint.c
+++ usb-3.10/sound/usb/endpoint.c
@@ -575,6 +575,7 @@ static int data_ep_set_params(struct snd
struct snd_usb_endpoint *sync_ep)
{
unsigned int maxsize, i, urb_packs, total_packs, packs_per_ms;
+ unsigned int min_queued_packs, max_packs;
int is_playback = usb_pipeout(ep-pipe);
int frame_bits = snd_pcm_format_physical_width(pcm_format) * channels;
@@ -608,11 +609,21 @@ static int data_ep_set_params(struct snd
else
ep-curpacksize = maxsize;
- if (snd_usb_get_speed(ep-chip-dev) != USB_SPEED_FULL)
+ if (snd_usb_get_speed(ep-chip-dev) != USB_SPEED_FULL) {
packs_per_ms = 8 ep-datainterval;
- else
+
+ /* high speed needs 10 USB uframes on the queue at all times */
+ min_queued_packs = DIV_ROUND_UP(10, 8 / packs_per_ms);
+ max_packs = MAX_PACKS_HS;
+ } else {
packs_per_ms = 1;
+ /* full speed needs one USB frame on the queue at all times */
+ min_queued_packs = 1;
+ max_packs = MAX_PACKS;
+ }
+ max_packs = min(max_packs, MAX_QUEUE * packs_per_ms);
+
if (is_playback !snd_usb_endpoint_implicit_feedback_sink(ep)) {
urb_packs = max(ep-chip-nrpacks, 1);
urb_packs = min(urb_packs, (unsigned int) MAX_PACKS);
@@ -625,42 +636,18 @@ static int data_ep_set_params(struct snd
if (sync_ep !snd_usb_endpoint_implicit_feedback_sink(ep))
urb_packs = min(urb_packs, 1U sync_ep-syncinterval);
- /* decide how many packets to be used */
- if (is_playback !snd_usb_endpoint_implicit_feedback_sink(ep)) {
- unsigned int minsize, maxpacks;
- /* determine how small a packet can be */
- minsize = (ep-freqn (16 - ep-datainterval))
- * (frame_bits 3);
- /* with sync from device, assume it can be 12% lower */
- if (sync_ep)
- minsize -= minsize 3;
- minsize = max(minsize, 1u);
- total_packs = (period_bytes + minsize - 1) / minsize;
- /* we need at least two URBs for queueing */
- if (total_packs 2) {
- total_packs = 2;
- } else {
- /* and we don't want too long a queue either */
- maxpacks = max(MAX_QUEUE * packs_per_ms, urb_packs * 2);
- total_packs = min(total_packs, maxpacks);
- }
- } else {
- while (urb_packs 1 urb_packs * maxsize = period_bytes)
- urb_packs = 1;
- total_packs = MAX_URBS * urb_packs;
- }
-
- ep-nurbs = (total_packs + urb_packs - 1) / urb_packs;
- if (ep-nurbs MAX_URBS) {
- /* too much... */
- ep-nurbs = MAX_URBS;
- total_packs = MAX_URBS * urb_packs;
- } else if (ep-nurbs 2) {
- /* too little - we need at least two packets
-* to ensure contiguous playback/capture
-*/
- ep-nurbs = 2;
+ /* each URB
Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A
On Thu, Jul 25, 2013 at 7:01 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2013-07-25 at 13:25 +0800, Ming Lei wrote: On Thu, Jul 25, 2013 at 1:10 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote: It depends if size of sg buffer(except for last one) in the sg list can be divided by usb endpoint's max packet size(512 or 1024), at least there is the constraint: http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-nextid=10e232c597ac757e7f8600649f7e872e86de190f I am wondering if network stack can meet that. If not, it might be a bit difficult because lots of USB host controller don't support that, and driver may have to support SG and non-SG at the same time for working well on all HCs. I do not see the problem. If one skb has 2 fragments of 32KB, couldn't they be split into 64 1K segments by the device driver ? OK, if length of fragments of all SKBs from network stack can always guarantee to be divided by 1024, that is fine, seems I worry about too much, :-) Unfortunately, there is no such guarantee. TSO permits sendfile() zero copy operation, so the frags can be of any size, any offset... USB protocol doesn't care offset or buffer start address, but has requirement on sg buffer size(except for last one) in sg list. In this mode, the first element (skb-head) will typically contains the headers, and there are way below 512 bytes. So even with lowering netdev-gso_max_size under PAGE_SIZE, most of the packets will need to be copied into a single segment. Maybe need to try it with TSO enabled, in my test on ax88179_178a NIC after applying your disabling TSO patch, tx throughput is less than 600Mbps, but rx is close to 900Mbps. On Thu, Jul 25, 2013 at 9:34 PM, Ben Hutchings bhutchi...@solarflare.com wrote: Not that I have any experience with USB drivers, but perhaps usb_sg_init()? USB SG library doesn't support submitting SG URB asynchronously, but that isn't a big deal. The problem is that many USB host controllers can't build one single packet from two buffers, what is why USB stack requires size of all buffers(except for last one) in sg list can be divided by max endpoint packet size.(1024 for usbnet) 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 - bugfix for 3.11] usb/gadget: free opts struct on error recovery
On Thu, Jul 25 2013, Andrzej Pietrasiewicz wrote:
Fix memory leaks introduced in commits:
40d133d7f542616cf9538508a372306e626a16e9
usb: gadget: f_ncm: convert to new function interface with backward
compatibility
fee562a6450b7806f1fbbe1469a67b5395b5c10a
usb: gadget: f_ecm: convert to new function interface with backward
compatibility
fcbdf12ebef73a6069e2a1aada1e546fb578a4aa
usb: gadget: f_phonet: convert to new function interface with backward
compatibility
b29002a157940752dfed2c488b2011f63f007d71
usb: gadget: f_eem: convert to new function interface with backward
compatibility
8cedba7c73af1369599b639cfeb66fe13aaa
usb: gadget: f_subset: convert to new function interface with backward
compatibility
f466c6353819326873fa48a02c6f2d7c903240d6
usb: gadget: f_rndis: convert to new function interface with backward
compatibility
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_ecm.c|7 +--
drivers/usb/gadget/f_eem.c|7 +--
drivers/usb/gadget/f_ncm.c|7 +--
drivers/usb/gadget/f_phonet.c |7 +--
drivers/usb/gadget/f_rndis.c |7 +--
drivers/usb/gadget/f_subset.c |7 +--
6 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/f_ecm.c b/drivers/usb/gadget/f_ecm.c
index 5d3561e..edab45d 100644
--- a/drivers/usb/gadget/f_ecm.c
+++ b/drivers/usb/gadget/f_ecm.c
@@ -959,8 +959,11 @@ static struct usb_function_instance *ecm_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = ecm_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_PTR(PTR_ERR(opts-net));
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, , ecm_func_type);
diff --git a/drivers/usb/gadget/f_eem.c b/drivers/usb/gadget/f_eem.c
index 90ee802..d00392d 100644
--- a/drivers/usb/gadget/f_eem.c
+++ b/drivers/usb/gadget/f_eem.c
@@ -593,8 +593,11 @@ static struct usb_function_instance *eem_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = eem_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_CAST(opts-net);
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, , eem_func_type);
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index 952177f..1c28fe1 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -1350,8 +1350,11 @@ static struct usb_function_instance
*ncm_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = ncm_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_PTR(PTR_ERR(opts-net));
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, , ncm_func_type);
diff --git a/drivers/usb/gadget/f_phonet.c b/drivers/usb/gadget/f_phonet.c
index 3575427..eb3aa81 100644
--- a/drivers/usb/gadget/f_phonet.c
+++ b/drivers/usb/gadget/f_phonet.c
@@ -654,8 +654,11 @@ static struct usb_function_instance
*phonet_alloc_inst(void)
opts-func_inst.free_func_inst = phonet_free_inst;
opts-net = gphonet_setup_default();
- if (IS_ERR(opts-net))
- return ERR_PTR(PTR_ERR(opts-net));
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, ,
phonet_func_type);
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 191df35..717ed7f 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -963,8 +963,11 @@ static struct usb_function_instance
*rndis_alloc_inst(void)
mutex_init(opts-lock);
opts-func_inst.free_func_inst = rndis_free_inst;
opts-net = gether_setup_default();
- if (IS_ERR(opts-net))
- return ERR_CAST(opts-net);
+ if (IS_ERR(opts-net)) {
+ struct net_device *net = opts-net;
+ kfree(opts);
+ return ERR_CAST(net);
+ }
config_group_init_type_name(opts-func_inst.group, ,
rndis_func_type);
diff --git a/drivers/usb/gadget/f_subset.c b/drivers/usb/gadget/f_subset.c
index 5601e1d..7c8674f 100644
---
Re: [PATCH 2/2] usb: dwc3: ep0: don't change to configured state too early
On Thu, 25 Jul 2013, Felipe Balbi wrote: On Wed, Jul 24, 2013 at 02:01:27PM -0400, Alan Stern wrote: On Wed, 24 Jul 2013, Felipe Balbi wrote: Hi, On Tue, Jul 23, 2013 at 12:53:53PM -0400, Alan Stern wrote: I see. Doesn't the mass-storage gadget also use delayed status when going into the _un_configured state? no it doesn't, we bail out early if config number is zero, look at composite.c and you'll see in case of configuration zero, we just make sure to disable all endpoints and don't call -set_alt(): This is my fault, for not being more familiar with the composite framework, and no doubt I will regret asking this, but... Doesn't that approach leave the function drivers sitting around with all their resources still allocated? When do those resources get deallocated? When the gadget disconnects from the host? which resources are you talking about ? Endpoints ? -disable() should make sure to disable the endpoints, but it will only free the endpoints when the gadget driver is unbound. struct usb_requests will also be freed at -disable() time. Does this answer your question ? Yeah, I was mainly wondering about the usb_requests. is this a signal for you're good to go with your fix ? :-) Sure, go ahead. 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 - bugfix for 3.11] usb/gadget: ether: put_usb_function on unbind
On Wed, Jul 24 2013, Andrzej Pietrasiewicz wrote:
Fix bugs introduced in
9c62ce83e4258bacc459faf57bf2ed83cce6be08
usb: gadget: ether: convert to new interface of f_ecm
94b5573e97729f0e1496d23b69cbe2c6b24ec0c3
usb: gadget: ether: convert to new interface of f_eem
8af5232d6f48896b151898ccb2e9e155481bb785
usb: gadget: ether: convert to new interface of f_subset
9bd4a10e1bf881af0b0a7c117c7092b558447047
usb: gadget: ether: convert to new interface of f_rndis
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/ether.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index f48712f..c1c113e 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -449,14 +449,20 @@ fail:
static int __exit eth_unbind(struct usb_composite_dev *cdev)
{
- if (has_rndis())
+ if (has_rndis()) {
+ usb_put_function(f_rndis);
usb_put_function_instance(fi_rndis);
- if (use_eem)
+ }
+ if (use_eem) {
+ usb_put_function(f_eem);
usb_put_function_instance(fi_eem);
- else if (can_support_ecm(cdev-gadget))
+ } else if (can_support_ecm(cdev-gadget)) {
+ usb_put_function(f_ecm);
usb_put_function_instance(fi_ecm);
- else
+ } else {
+ usb_put_function(f_geth);
usb_put_function_instance(fi_geth);
+ }
return 0;
}
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A
On Thu, 2013-07-25 at 22:52 +0800, Ming Lei wrote: [...] On Thu, Jul 25, 2013 at 9:34 PM, Ben Hutchings bhutchi...@solarflare.com wrote: Not that I have any experience with USB drivers, but perhaps usb_sg_init()? USB SG library doesn't support submitting SG URB asynchronously, but that isn't a big deal. The problem is that many USB host controllers can't build one single packet from two buffers, what is why USB stack requires size of all buffers(except for last one) in sg list can be divided by max endpoint packet size.(1024 for usbnet) Ugh. Maybe the USB stack should allow drivers to find out about and take advantage of a more flexible host controller. Sounds like it could be a big job, though. Ben. (glad not to be using any USB net devices) -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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 V4] usb: Add Device Tree support to XHCI Platform driver
On 25.07.2013 18:39, Alan Cooper wrote:
It looks like all the feedback has been addressed, but I'm no device
tree expert.
Felipe, Matthijs, and Sergei, does this look good? If so, I'll queue to
my xhci tree.
Not quite there yet. Too bad I couldn't notice all the small issues at
once...
Sarah Sharp
On Tue, Jul 23, 2013 at 06:35:33PM -0400, Al Cooper wrote:
Add Device Tree match table to xhci-plat.c. Add DT bindings document.
Signed-off-by: Al Cooper alcoop...@gmail.com
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 14 ++
drivers/usb/host/xhci-plat.c | 10 ++
2 files changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
new file mode 100644
index 000..b88aee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -0,0 +1,14 @@
[...]
+
+Required properties:
+ - compatible: should be xhci-platform.
+ - reg: should contain address and length of the standard XHCI
+register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Example:
+ xhci@f0931000 {
The node should be named just usb, not xhci (no programming interface
specific names), according to the ePAPR spec [1].
What about the existing node names ohci@ and ehci@?
Unfortunately, they are all wrong, as many others. It seems almost nobody
reads:
http://www.devicetree.org/Device_Tree_Usage
+ compatible = xhci-platform;
It again looks somewhat like a driver name, not a device name. What made
you change the value from usb-xhci, Al? Look at [eo]hci-omap.txt in that
directory.
I changed the name because MODULE_DEVICE_TABLE() now uses the name and
that means the hotplug system will use it to identify the driver and
it seems like the
name should be unique enough to avoid confusion with something like
the xhci-pci driver.
xhci-pci gets identified by the PCI device class, not the name. Maybe
indeed snps,xhci is better if this is Synopsys core you're doing the binding
for... I have no strong preference, it's just that xhci-platform doesn't
appeal to me.
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 15/16] dmaengine: add transfered member to dma_async_tx_descriptor
On 07/22/2013 08:10 PM, Sebastian Andrzej Siewior wrote: In USB RX path it is possible that the we receive less bytes than requested. Take the following example: The driver for USB-to-UART submits an URB with 256 bytes in size and the dmaengine driver in turn programs a transfer of 256 bytes. The transfer is programmed and the dma engine waits for the data to arrive. Once data is sent on the UART the dma engine begins to move data. If there was only one data byte in the USB packet received then the DMA engine will only move one byte due to USB restrictions / rules. The real size of the transfer has to be notified to the user / caller so he set this to the caller. This patch adds the transfered member to the dma_async_tx_descriptor where the caller can obtain the final size. I'm not sure that this will work. Once you've submitted the descriptor it is owned by the dmaengine driver and you are not allowed to dereference it anymore since the dmaengine driver might free the memory at any time. You should only reference the descriptor by the cookie returned by submit(). - Lars -- 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 01/21] usb/gadget: multi: fix error return code in cdc_do_config()
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Introduced by commit 59835a (usb: gadget: multi: use
function framework for ACM.)
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
Having said that, one comment inline:
---
drivers/usb/gadget/multi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/multi.c b/drivers/usb/gadget/multi.c
index 032b96a..867db32 100644
--- a/drivers/usb/gadget/multi.c
+++ b/drivers/usb/gadget/multi.c
@@ -225,8 +225,10 @@ static __init int cdc_do_config(struct usb_configuration
*c)
/* implicit port_num is zero */
f_acm_multi = usb_get_function(fi_acm);
- if (IS_ERR(f_acm_multi))
+ if (IS_ERR(f_acm_multi)) {
+ ret = PTR_ERR(f_acm_multi);
goto err_func_acm;
+ }
To be honest, I would just remove the err_func_acm label and change this
to:
if (IS_ERR(f_acm_multi))
return ERR_PTR(f_acm_multi);
ret = usb_add_function(c, f_acm_multi);
if (ret)
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH v2 02/21] usb/gadget: f_phonet: remove unused preprocessor conditional
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote: The compatibility layer which the USBF_PHONET_INCLUDED was a part of is no longer present - the USBF_PHONET_INCLUDED is not #defined by anyone anymore, so the ifndef is always true. Removing it. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com --- drivers/usb/gadget/f_phonet.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/f_phonet.c b/drivers/usb/gadget/f_phonet.c index 7944fb0..3575427 100644 --- a/drivers/usb/gadget/f_phonet.c +++ b/drivers/usb/gadget/f_phonet.c @@ -488,7 +488,6 @@ static int pn_bind(struct usb_configuration *c, struct usb_function *f) struct usb_ep *ep; int status, i; -#ifndef USBF_PHONET_INCLUDED struct f_phonet_opts *phonet_opts; phonet_opts = container_of(f-fi, struct f_phonet_opts, func_inst); @@ -507,7 +506,6 @@ static int pn_bind(struct usb_configuration *c, struct usb_function *f) return status; phonet_opts-bound = true; } -#endif /* Reserve interface IDs */ status = usb_interface_id(c, f); -- 1.7.0.4 -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
On Thu, Jul 25, 2013 at 12:30 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Mon, Jul 22, 2013 at 03:58:19PM +0800, Shuduo Sang wrote: On Mon, Jul 22, 2013 at 3:23 PM, George Cherian george.cher...@ti.com wrote: Yes, I run below script to capture picture. #!/bin/bash # camera_stress.sh # Testing the camera by BinLi for ((i=0; i10 ; i++)) do fswebcam --no-banner -r 352x288 -d /dev/video0 test_$i.jpg done It will randomly fail at later loops. The fail rate about 20%~30%. When it fail, I can see error messages by dmesg as below: [ 68.171039] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD [ 68.175030] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD [ 68.179026] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD [ 68.180082] usb 3-12: USB disconnect, device number 4 [ 68.450459] usb 3-12: new high-speed USB device number 5 using xhci_hcd [ 68.477960] usb 3-12: New USB device found, idVendor=5986, idProduct=0397 [ 68.477964] usb 3-12: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 68.477966] usb 3-12: Product: Integrated Camera [ 68.477968] usb 3-12: Manufacturer: Vimicro corp. [ 68.479107] uvcvideo: Found UVC 1.00 device Integrated Camera (5986:0397) [ 68.479821] input: Integrated Camera as /devices/pci:00/:00:14.0/usb3/3-12/3-12:1.0/input/input15 [ 321.389721] type=1400 audit(1374214638.182:29): apparmor=DENIED operation=capable parent=1 profile=/usr/sbin/cupsd pid=1232 comm=cupsd pid=1232 comm=cupsd c apability=36 capname=block_suspend That's a different issue. The log shows that your USB webcam disconnects, and that's why your script fails. Then the device re-connects. Hmm, I think you are right. I tried my script on another laptop with Lynx Point host and same webcam, it works very well. Sorry if my information misled you and George. Do other USB devices work after the camera disconnects? Does the webcam itself work (at least for a while) after you stop and restart the script? (Note that after a disconnect, the webcam may be present on /dev/video1 instead of /dev/video0, because your script had /dev/video0 open when the webcam re-connected.) Then I manually applied George's patch against 3.10.0 but the issue still happen when I use camera to capture picture. Can you explain what is the exact issue you face after applying the patch? Are you still getting ERROR Transfer event TRB DMA ptr not part of current TD Yes, after I applied your patch manually, I still getting this error. Seems fail rate is same. I'm still going to apply George's patch, because it does fix a different issue. Is there any code piece to triage the issue George's patch fix? Then I can do some verification with George's patch or without. I'm not sure if there's anything software can do if the webcam keeps disconnecting. That's usually an electrical issue. Have you tried a different USB cable? If the webcam is behind a hub, have you tried connecting it directly to the computer's roothub? If it's attached to the roothub, have you tried putting it behind an external hub? If none of that works, I can look at your logs, and try to figure out if there's anything software can do. Can you recompile your kernel with George's patch and CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on? Please send me the log from just before you start your script to when the device disconnects. 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
Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A
On Thu, 2013-07-25 at 22:52 +0800, Ming Lei wrote: Maybe need to try it with TSO enabled, in my test on ax88179_178a NIC after applying your disabling TSO patch, tx throughput is less than 600Mbps, but rx is close to 900Mbps. It looks like TCP stack could for this case allocate linear skbs (GFP_KERNEL context), using order-3 pages, and not adding frags on them, to avoid the skb_linearize() hazard (in GFP_ATOMIC) In case of retransmits, skb are small (one MSS) so the skb_linearize() should succeed most of the time. -- 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 06/16] usb: musb: dsps: rename ti81xx_driver_data to am33xx_driver_data
Sebastian, On Thu, Jul 25, 2013 at 9:41 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: * Bin Liu | 2013-07-23 13:23:57 [-0500]: Hi Sebastian, Hi Liu, On Mon, Jul 22, 2013 at 1:09 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This patch renames the type struct from ti81xx_driver_data to am33xx_driver_data since it is not used for ti81xx anymore. The EOI member is also removed since the am33xx SoC does not have such register. The interrupt is acknowledged by writting into the stat register. I guess the EOI register is removed from the TRM because AM33xx does not use it, there is no need to write to it to acknowledge. It does not hurt to write to it though since the register still exists, it just does nothing, I guess. Is it really there or was it never there and it has been added to TRM by accident? The EOI register IS in the USB subsystem of AM33xx, but the SoC does not use it because it uses level triggering for USB interrupt. But I am not sure if it is a good idea to remove eoi from the musb_dsps driver. If the intension is to merge the support for other SoC, such as AM35xx, AM18xx, then EOI handling might be still needed. I just don't know how those devices use EOI. If one of the architectures gets added which need an EOI then the offset can be 0 and the EOI will happen only if it is != 0. This patch cleaned up the use of EOI. Do you mean EOI handling will be added back with condition EOI offset != 0, when the support of new device which uses EIO is added? Regards, -Bin. Regards, -Bin. Sebastian -- 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 15/16] dmaengine: add transfered member to dma_async_tx_descriptor
On 07/25/2013 04:57 PM, Lars-Peter Clausen wrote: I'm not sure that this will work. Once you've submitted the descriptor it is owned by the dmaengine driver and you are not allowed to dereference it anymore since the dmaengine driver might free the memory at any time. You should only reference the descriptor by the cookie returned by submit(). I see. But it can't be reused before calling the callback if it is going to call the callback, right? So if this is a no-no, I'm left with an additional argument to the complete callback? - Lars Sebastian -- 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
[Pull Request] xhci: Bug fixes, now with more tags!
The following changes since commit 94190301ffa059c2d127b3a67ec5d161d5c62681: usb: option: add TP-LINK MA260 (2013-07-23 16:07:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-07-25 for you to fetch changes up to d66eaf9f89502971fddcb0de550b01fa6f409d83: xhci: fix null pointer dereference on ring_doorbell_for_active_rings (2013-07-25 08:10:09 -0700) xhci: Bug fixes, now with more tags! Hi Greg, Here's five bug fixes for 3.12. The three patches are marked for stable. Two fix NULL pointer dereferences. The third marked for stable suppresses some serious log spam from unnecessary xHCI driver warnings, whenever an isochronous short packet happens on an xHCI 1.0 host. The other two patches fix build warnings. Sarah Sharp George Cherian (1): usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 Oleksij Rempel (1): xhci: fix null pointer dereference on ring_doorbell_for_active_rings Olof Johansson (1): usb: xhci: Mark two functions __maybe_unused Randy Dunlap (1): usb: fix build warning in pci-quirks.h when CONFIG_PCI is not enabled Sarah Sharp (1): xhci: Avoid NULL pointer deref when host dies. drivers/usb/host/pci-quirks.h |1 + drivers/usb/host/xhci-pci.c |1 - drivers/usb/host/xhci-ring.c |2 +- drivers/usb/host/xhci.c | 17 - 4 files changed, 14 insertions(+), 7 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
Re: After entering D3 cold: URB ffff88020ea41000 submitted while active
On Thu, 2013-07-25 at 17:30 +0300, Oleksii Shevchuk wrote: Randomly after returning from S3 or enabling powersaving this trace goes to dmesg: [13115.552920] [a02f3a30] usb_submit_urb+0x360/0x370 [usbcore] [13115.552922] [a042fe96] wdm_int_callback+0x1c6/0x200 [cdc_wdm] [13115.552927] [a02f1615] usb_hcd_giveback_urb+0x55/0xc0 [usbcore] [13115.552931] [a03e8e4d] xhci_irq+0x42d/0x1400 [xhci_hcd] [13115.552935] [a03e9e31] xhci_msi_irq+0x11/0x20 [xhci_hcd] What device are you using? 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 5/5] xhci: fix null pointer dereference on ring_doorbell_for_active_rings
From: Oleksij Rempel li...@rempel-privat.de
in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.
This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 USB: xhci:
Correct assumptions about number of rings per endpoint
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1e57eaf..5b08cd8 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -434,7 +434,7 @@ static void ring_doorbell_for_active_rings(struct xhci_hcd
*xhci,
/* A ring has pending URBs if its TD list is not empty */
if (!(ep-ep_state EP_HAS_STREAMS)) {
- if (!(list_empty(ep-ring-td_list)))
+ if (ep-ring !(list_empty(ep-ring-td_list)))
xhci_ring_ep_doorbell(xhci, slot_id, ep_index, 0);
return;
}
--
1.8.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio I/O parameters
James Stone wrote: On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote: The commit that you found by bisection got reverted later: http://git.kernel.org/linus/015618b902ae Please check that the code of Fix URB cancellation at stream start is in your current kernel. well, in 3.10, it is not exactly the same as the above revertion. For example: /* just to be sure */ deactivate_urbs(ep, false); if (can_sleep) This is exactly the same as in commit 015618b902ae. Regards, Clemens -- 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 04/21] usb/gadget: create a utility module for mass_storage
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote: Converting to configfs requires making the f_mass_storage.c a module. But first we need to get rid of #include storage_common.c. This patch makes storage_common.c a separately compiled file, which is built as a utility module named u_ms.ko. After all mass storage users are converted to the new function interface this module can be eliminated by merging it with the mass storage function's module. USB descriptors are exported so that they can be accessed from f_mass_storage. FSG_VENDOR_ID and FSG_PRODUCT_ID are moved to their only user. Handling of CONFIG_USB_GADGET_DEBUG_FILES is moved to f_mass_storage.c. The fsg_num_buffers static is moved to FSG_MODULE_PARAMETER users, so instead of using a global variable the f_mass_storage introduces fsg_num_buffers member in fsg_common (and fsg_config). fsg_strings and fsg_stringtab are moved to f_mass_storage.c. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Ackedy-by: Michal Nazarewicz min...@mina86.com -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- signature.asc Description: PGP signature
[PATCH 2/5] usb: xhci: Mark two functions __maybe_unused
From: Olof Johansson o...@lixom.net
Resolves the following build warnings:
drivers/usb/host/xhci.c:332:13: warning: 'xhci_msix_sync_irqs' defined but not
used [-Wunused-function]
drivers/usb/host/xhci.c:3901:12: warning: 'xhci_change_max_exit_latency'
defined but not used [-Wunused-function]
These functions are not always used, and since they're marked static
they will produce build warnings:
- xhci_msix_sync_irqs is only used with CONFIG_PCI.
- xhci_change_max_exit_latency is a little more complicated with
dependencies on CONFIG_PM and CONFIG_PM_RUNTIME.
Instead of building a bigger maze of ifdefs in this code, I've just
marked both with __maybe_unused.
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 98aac74..6bbf511 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -329,7 +329,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
return;
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
int i;
@@ -3898,7 +3898,7 @@ int xhci_find_raw_port_number(struct usb_hcd *hcd, int
port1)
* Issue an Evaluate Context command to change the Maximum Exit Latency in the
* slot context. If that succeeds, store the new MEL in the xhci_virt_device.
*/
-static int xhci_change_max_exit_latency(struct xhci_hcd *xhci,
+static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci,
struct usb_device *udev, u16 max_exit_latency)
{
struct xhci_virt_device *virt_dev;
--
1.8.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] usb: fix build warning in pci-quirks.h when CONFIG_PCI is not enabled
From: Randy Dunlap rdun...@infradead.org
Fix warning when CONFIG_PCI is not enabled
(from commit 296365781903226a3fb8758901eaeec09d2798e4).
drivers/usb/host/pci-quirks.h: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
Signed-off-by: Randy Dunlap rdun...@infradead.org
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/pci-quirks.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index 4b8a209..978c849 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -13,6 +13,7 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
void sb800_prefetch(struct device *dev, int on);
#else
+struct pci_dev;
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
static inline void usb_amd_dev_put(void) {}
--
1.8.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] xhci: Avoid NULL pointer deref when host dies.
When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the register write to abort the command
ring, the xHCI driver will assume the host is dead, and call
usb_hc_died().
The USB device's slot_id is still set to zero, and the pointer stored at
xhci-devs[0] will always be NULL. The call to xhci_check_args in
xhci_free_dev should have caught the NULL virt_dev pointer.
However, xhci_free_dev is designed to free the xhci_virt_device
structures, even if the host is dead, so that we don't leak kernel
memory. xhci_free_dev checks the return value from the generic
xhci_check_args function. If the return value is -ENODEV, it carries on
trying to free the virtual device.
The issue is that xhci_check_args looks at the host controller state
before it looks at the xhci_virt_device pointer. It will return -ENIVAL
because the host is dead, and xhci_free_dev will ignore the return
value, and happily dereference the NULL xhci_virt_device pointer.
The fix is to make sure that xhci_check_args checks the xhci_virt_device
pointer before it checks the host state.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
further details. This patch doesn't solve the underlying issue, but
will ensure we don't see any more NULL pointer dereferences because of
the issue.
This patch should be backported to kernels as old as 3.1, that
contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a xhci: Don't
submit commands or URBs to halted hosts.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Vincent Thiele vincentthi...@gmail.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2c49f00..98aac74 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1181,9 +1181,6 @@ static int xhci_check_args(struct usb_hcd *hcd, struct
usb_device *udev,
}
xhci = hcd_to_xhci(hcd);
- if (xhci-xhc_state XHCI_STATE_HALTED)
- return -ENODEV;
-
if (check_virt_dev) {
if (!udev-slot_id || !xhci-devs[udev-slot_id]) {
printk(KERN_DEBUG xHCI %s called with unaddressed
@@ -1199,6 +1196,9 @@ static int xhci_check_args(struct usb_hcd *hcd, struct
usb_device *udev,
}
}
+ if (xhci-xhc_state XHCI_STATE_HALTED)
+ return -ENODEV;
+
return 1;
}
--
1.8.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
From: George Cherian george.cher...@ti.com
Xhci controllers with hci_version 0.96 gives spurious success
events on short packet completion. During webcam capture the
ERROR Transfer event TRB DMA ptr not part of current TD was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.
Note from Sarah:
The xHCI 1.0 spec changed how hardware handles short packets. The HW
will notify SW of the TRB where the short packet occurred, and it will
also give a successful status for the last TRB in a TD (the one with the
IOC flag set). On the second successful status, that warning will be
triggered in the driver.
Software is now supposed to not assume the TD is not completed until it
gets that last successful status. That means we have a slight race
condition, although it should have little practical impact. This patch
papers over that issue.
It's on my long-term to-do list to fix this race condition, but it is a
much more involved patch that will probably be too big for stable. This
patch is needed for stable to avoid serious log spam.
This patch should be backported to kernels as old as 3.0, that
contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b Intel xhci:
Ignore spurious successful event.
The patch will have to be modified for kernels older than 3.2, since
that kernel added the xhci_gen_setup function for xhci platform devices.
The correct conflict resolution for kernels older than 3.2 is to set
XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c | 1 -
drivers/usb/host/xhci.c | 7 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index cc24e39..f00cb20 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
}
if (pdev-vendor == PCI_VENDOR_ID_INTEL
pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
- xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
xhci-limit_active_eps = 64;
xhci-quirks |= XHCI_SW_BW_CHECKING;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6bbf511..41eb4fc 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4892,6 +4892,13 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
get_quirks(dev, xhci);
+ /* In xhci controllers which follow xhci 1.0 spec gives a spurious
+* success event after a short transfer. This quirk will ignore such
+* spurious event.
+*/
+ if (xhci-hci_version 0x96)
+ xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
+
/* Make sure the HC is halted. */
retval = xhci_halt(xhci);
if (retval)
--
1.8.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/21] usb/gadget: f_mass_storage: factor out a header file
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote: In order to prepare for the new function interface the f_mass_storage.c needs to be compiled as a module, and so a header file will be required. This patch factors out some code to a new f_mass_storage.h. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH 06/16] usb: musb: dsps: rename ti81xx_driver_data to am33xx_driver_data
Sebastian, On Thu, Jul 25, 2013 at 10:16 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/25/2013 05:12 PM, Bin Liu wrote: Sebastian, Hi Bin, Is it really there or was it never there and it has been added to TRM by accident? The EOI register IS in the USB subsystem of AM33xx, but the SoC does not use it because it uses level triggering for USB interrupt. I see. But I am not sure if it is a good idea to remove eoi from the musb_dsps driver. If the intension is to merge the support for other SoC, such as AM35xx, AM18xx, then EOI handling might be still needed. I just don't know how those devices use EOI. If one of the architectures gets added which need an EOI then the offset can be 0 and the EOI will happen only if it is != 0. This patch cleaned up the use of EOI. Do you mean EOI handling will be added back with condition EOI offset != 0, when the support of new device which uses EIO is added? That is my intention. Then should something like EOI cleanup be added into the commit message for better git log searching experience? I would think the EOI cleanup is more important then variable renaming in this patch. Or even better to separate the changes into two patches. Regards, -Bin. Sebastian Regards, -Bin. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio I/O parameters
On Thu, 25 Jul 2013, James Stone wrote: On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch clem...@ladisch.de wrote: James Stone wrote: Ok -from the bisect, the problem of not being able to get to sub 64-frames per period starts with: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112 This is a merge, which includes this commit: http://git.kernel.org/linus/e9ba389c5ffc. Could this be the offending deletion? http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/sound/usb/endpoint.c?id=fc600432cd23e35c85de2ff4468d816d6938a112 (There is a corresponding change in pcm.c.) The commit that you found by bisection got reverted later: http://git.kernel.org/linus/015618b902ae Please check that the code of Fix URB cancellation at stream start is in your current kernel. well, in 3.10, it is not exactly the same as the above revertion. For example: /* just to be sure */ deactivate_urbs(ep, false); if (can_sleep) Please try the patch from here: http://marc.info/?l=linux-usbm=137476385206265w=2 instead of the one I sent to you yesterday. I think it will fix this problem. 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 06/21] usb/gadget: f_mass_storage: add a level of indirection for luns storage
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
This is needed to prepare for configfs integration.
So far the luns have been allocated during gadget's initialization, based
on the nluns module parameter's value; the exact number is known when the
gadget is initialized and that number of luns is allocated in one go; they
all will be used.
When configfs is in place, the luns will be created one-by-one by the user.
Once the user is satisfied with the number of luns, they activate the
gadget. The number of luns must be = FSG_MAX_LUN (currently 8), but other
than that it is not known up front and the user need not use contiguous
numbering (apart from the default lun #0). On the other hand, the function
code uses lun numbers to identify them and the number needs to be used
as an index into an array.
Given the above, an array needs to be allocated, but it might happen that
7 out of its 8 elements will not be used. On my machine
sizeof(struct fsg_lun) == 462, so 3k of memory is allocated but not used
in the worst case.
By adding another level of indirection (allocating an array of pointers
to struct fsg_lun and then allocating individual luns instead of an array
of struct fsg_luns) at most 7 pointers are wasted, which is much less.
This patch also changes some for/while loops to cope with the fact
that in the luns array some entries are potentially empty.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
Still some minor comments inline:
---
drivers/usb/gadget/f_mass_storage.c | 56 +++---
1 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index c36e208..d01d1dd 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2439,7 +2443,7 @@ static void handle_exception(struct fsg_common *common)
* CONFIG_CHANGE cases.
*/
/* for (i = 0; i common-nluns; ++i) */
- /* common-luns[i].unit_attention_data = */
+ /* common-luns[i]-unit_attention_data = */
/* SS_RESET_OCCURRED; */
break;
It's a comment so it's not a big deal, but nonetheless, this should read:
- /* common-luns[i].unit_attention_data = */
- /* SS_RESET_OCCURRED; */
+ /* if (common-luns[i]) */
+ /* common-luns[i]-unit_attention_data = */
+ /* SS_RESET_OCCURRED; */
@@ -2659,16 +2664,25 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
* Create the LUNs, open their backing files, and register the
* LUN devices in sysfs.
*/
- curlun = kcalloc(nluns, sizeof(*curlun), GFP_KERNEL);
- if (unlikely(!curlun)) {
+ curlun_it = kcalloc(nluns, sizeof(*curlun_it), GFP_KERNEL);
+ if (unlikely(!curlun_it)) {
rc = -ENOMEM;
goto error_release;
}
- common-luns = curlun;
+ common-luns = curlun_it;
init_rwsem(common-filesem);
- for (i = 0, lcfg = cfg-luns; i nluns; ++i, ++curlun, ++lcfg) {
+ for (i = 0, lcfg = cfg-luns; i nluns; ++i, ++curlun_it, ++lcfg) {
+ struct fsg_lun *curlun;
+
+ *curlun_it = kzalloc(sizeof(**curlun_it), GFP_KERNEL);
+ curlun = *curlun_it;
I don't like the order of those statements. How about instead of the
two, first:
+ curlun = kzalloc(sizeof(*curlun), GFP_KERNEL);
here
+ if (!curlun) {
+ rc = -ENOMEM;
+ common-nluns = i;
+ goto error_release;
+ }
and assignment to memory here:
+ *curlun_it = curlun;
curlun-cdrom = !!lcfg-cdrom;
curlun-ro = lcfg-cdrom || lcfg-ro;
curlun-initially_ro = curlun-ro;
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH v2 07/21] usb/gadget: f_mass_storage: use usb_gstrings_attach
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index d01d1dd..c56e24b 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -242,6 +242,11 @@ static struct usb_gadget_strings fsg_stringtab = {
.strings= fsg_strings,
};
+static struct usb_gadget_strings *fsg_strings_array[] = {
+ fsg_stringtab,
+ NULL,
+};
+
/*-*/
struct fsg_dev;
@@ -2609,6 +2614,7 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
struct fsg_buffhd *bh;
struct fsg_lun **curlun_it;
struct fsg_lun_config *lcfg;
+ struct usb_string *us;
int nluns, i, rc;
char *pathbuf;
@@ -2651,14 +2657,13 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
common-ep0req = cdev-req;
common-cdev = cdev;
- /* Maybe allocate device-global string IDs, and patch descriptors */
- if (fsg_strings[FSG_STRING_INTERFACE].id == 0) {
- rc = usb_string_id(cdev);
- if (unlikely(rc 0))
- goto error_release;
- fsg_strings[FSG_STRING_INTERFACE].id = rc;
- fsg_intf_desc.iInterface = rc;
+ us = usb_gstrings_attach(cdev, fsg_strings_array,
+ ARRAY_SIZE(fsg_strings));
+ if (IS_ERR(us)) {
+ rc = PTR_ERR(us);
+ goto error_release;
}
+ fsg_intf_desc.iInterface = us[FSG_STRING_INTERFACE].id;
/*
* Create the LUNs, open their backing files, and register the
@@ -2951,11 +2956,6 @@ autoconf_fail:
/** ADD FUNCTION **/
-static struct usb_gadget_strings *fsg_strings_array[] = {
- fsg_stringtab,
- NULL,
-};
-
static int fsg_bind_config(struct usb_composite_dev *cdev,
struct usb_configuration *c,
struct fsg_common *common)
@@ -2968,7 +2968,6 @@ static int fsg_bind_config(struct usb_composite_dev
*cdev,
return -ENOMEM;
fsg-function.name= FSG_DRIVER_DESC;
- fsg-function.strings = fsg_strings_array;
fsg-function.bind= fsg_bind;
fsg-function.unbind = fsg_unbind;
fsg-function.setup = fsg_setup;
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Patch queue status?
Greg: What's the status of your USB patch queue? I've seen a bunch of notices about patches being applied -- is the queue empty yet? I ask because of this: http://marc.info/?l=linux-usbm=137356910824266w=2 which hasn't been merged yet. 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: After entering D3 cold: URB ffff88020ea41000 submitted while active
lspci -s 00:14.0 -vvv 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo Device 21fa Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 43 Region 0: Memory at f252 (64-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel driver in use: xhci_hcd Kernel modules: xhci_hcd System Information Manufacturer: LENOVO Product Name: 2306CTO Version: ThinkPad X230 On vanilla linux 3.10.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: After entering D3 cold: URB ffff88020ea41000 submitted while active
On Thu, 2013-07-25 at 18:45 +0300, Oleksii Shevchuk wrote: lspci -s 00:14.0 -vvv No. It happens with the wdm driver. What net device are you using? 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: After entering D3 cold: URB ffff88020ea41000 submitted while active
lsusb -s 001:004 Bus 001 Device 004: ID 1199:9013 Sierra Wireless, Inc. - Hardware | manufacturer: 'Sierra Wireless Inc' | model: 'Sierra Wireless MC8355 - Gobi 3000(TM) Module' | revision: 'D3200-STSUGN-1580 1 [Jul 08 2011 18:00:00]' -- 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: host: Faraday fotg210-hcd driver
Hi, On Thu, Jul 25, 2013 at 7:10 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jun 19, 2013 at 07:53:04PM +, Yuan-Hsin Chen wrote: FOTG210 is an OTG controller which can be configured as an USB2.0 host. FOTG210 host is an ehci-like controller with some differences. First, register layout of FOTG210 is incompatible with EHCI. Furthermore, FOTG210 is lack of siTDs which means iTDs are used for both HS and FS ISO transfer. Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com As your email now is bouncing, I'm going to revert this patch, I can't take a patch for a driver with no active maintainer, sorry. If someone else from Faraday will step up and maintain this, that would be great, please resend it with your email information. I see. My ex-colleague who takes over the driver will resend the patch later. Thanks. Yuan-Hsin 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 08/21] usb/gadget: f_mass_storage: split fsg_common initialization into a number of functions
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
When configfs is in place, the things related to intialization
of struct fsg_common will be split over a number of places.
This patch adds several functions which together cover the former
intialization routine fsg_common_init.
When configfs is in place, the luns will not be represented in sysfs,
so there will be no struct device associated with a lun.
To prepare for this some debug macros need to be adjusted. Two new
fields are added to struct fsg_lun: name and name_pfx.
The name is for storing a string which is presented to the user
instead of the dev_name. The name_pfx, if non-NULL, is prepended
to the name at printing time.
The name_pfx is for a future lun.0, which will be a default group in
mass_storage.name. By design at USB function configfs group's creation
time its name is not known (but instead set a bit later in
drivers/usb/gadget/configfs.c:function_make) and it is this name that
serves the purpose of the said name prefix. So instead of copying
a yet-unknown string a pointer to it is stored in struct fsg_lun.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
+int fsg_common_set_num_buffers(struct fsg_common *common, unsigned int n)
+{
+ struct fsg_buffhd *bh, *new_buffhds;
+ int i, rc;
+
+ rc = fsg_num_buffers_validate(n);
+ if (rc != 0)
+ return rc;
+
+ new_buffhds = kcalloc(n, sizeof *(new_buffhds), GFP_KERNEL);
+ if (!new_buffhds)
+ return -ENOMEM;
+
+ /* Data buffers cyclic list */
+ bh = new_buffhds;
+ i = n;
+ goto buffhds_first_it;
+ do {
+ bh-next = bh + 1;
+ ++bh;
+buffhds_first_it:
+ bh-buf = kmalloc(FSG_BUFLEN, GFP_KERNEL);
+ if (unlikely(!bh-buf))
+ goto error_release;
+ } while (--i);
+ bh-next = new_buffhds;
+
+ common-fsg_num_buffers = n;
+ kfree(common-buffhds);
Instead of kfree, fsg_common_free_buffers must be called here or
otherwise bh-buf won't get freed. In fact, I'd create an internal
implementation:
static void _fsg_common_free_buffers(struct fsg_buffhd *buffhds,
unsigned n) {
if (buffhds) {
struct fsg_buffhd *bh = buffhds;
while (n--) {
kfree(bh-buf);
++bh;
}
kfree(buffhds);
}
}
which could be used here, in error recovery below (error_release label),
and fsg_common_free_buffers().
+ common-buffhds = new_buffhds;
+
+ return 0;
+
+error_release:
+ bh = new_buffhds;
+ i = n - i;
+ while (i--) {
+ kfree(bh-buf);
+ bh++;
+ };
+
+ kfree(new_buffhds);
+
+ return -ENOMEM;
+}
+
+void fsg_common_free_buffers(struct fsg_common *common)
+{
+ struct fsg_buffhd *bh;
+ int i;
+
+ bh = common-buffhds;
+ i = common-fsg_num_buffers;
+ while (i--) {
+ kfree(bh-buf);
+ bh++;
+ };
+
+ kfree(common-buffhds);
+ common-buffhds = NULL;
+}
+int fsg_common_set_nluns(struct fsg_common *common, int nluns)
+{
+ struct fsg_lun **curlun;
+
+ /* Find out how many LUNs there should be */
+ if (nluns 1 || nluns FSG_MAX_LUNS) {
+ pr_err(invalid number of LUNs: %u\n, nluns);
+ return -EINVAL;
+ }
+
+ curlun = kcalloc(nluns, sizeof(*curlun), GFP_KERNEL);
+ if (unlikely(!curlun))
+ return -ENOMEM;
+
+ common-luns = curlun;
+ common-nluns = nluns;
+
+ pr_info(Number of LUNs=%d\n, common-nluns);
+
+ return 0;
This function is fishy. What if someone calls it after bunch of LUNs is
created? If that happens, those luns are lost. At the very least, it
should check if common-luns is NULL and if it is, return -EBUSY or
something.
+}
+
+void fsg_common_free_luns(struct fsg_common *common)
+{
+ kfree(common-luns);
+ common-luns = NULL;
Hmm... This should at least check if any of the common-luns[i] is not
NULL, no? To be on the safe side, I'd just call fsg_common_remove_luns
at the beginning and change fsg_common_remove_luns to set the pointers
to NULL and check whether they are NULL before removing.
+}
+void fsg_common_remove_luns(struct fsg_common *common)
+{
+ int i;
+
+ for (i = 0; i common-nluns; ++i)
+ fsg_common_remove_lun(common-luns[i], common-sysfs);
+}
+int fsg_common_create_lun(struct fsg_common *common, struct fsg_lun_config
*cfg,
+ unsigned int id, const char *name,
+ const char **name_pfx)
+{
+ struct fsg_lun *lun;
+ char *pathbuf;
+ int rc = -ENOMEM;
+ int name_len;
+
+ if (!common-nluns || !common-luns)
+ return -ENODEV;
+
+ if
Re: [PATCH v2 09/21] usb/gadget: f_mass_storage: use fsg_common_setup in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 19 +++
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index f1b0da8..0f40d35 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3019,16 +3019,9 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
return ERR_PTR(-EINVAL);
}
- /* Allocate? */
- if (!common) {
- common = kzalloc(sizeof *common, GFP_KERNEL);
- if (!common)
- return ERR_PTR(-ENOMEM);
- common-free_storage_on_release = 1;
- } else {
- memset(common, 0, sizeof *common);
- common-free_storage_on_release = 0;
- }
+ common = fsg_common_setup(common, !!common);
+ if (IS_ERR(common))
+ return common;
common-sysfs = true;
common-state = FSG_STATE_IDLE;
@@ -3068,8 +3061,6 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
}
common-luns = curlun_it;
- init_rwsem(common-filesem);
-
for (i = 0, lcfg = cfg-luns; i nluns; ++i, ++curlun_it, ++lcfg) {
struct fsg_lun *curlun;
@@ -3169,8 +3160,6 @@ buffhds_first_it:
common-can_stall = cfg-can_stall
!(gadget_is_at91(common-gadget));
- spin_lock_init(common-lock);
- kref_init(common-ref);
/* Tell the thread to start working */
common-thread_task =
@@ -3179,8 +3168,6 @@ buffhds_first_it:
rc = PTR_ERR(common-thread_task);
goto error_release;
}
- init_completion(common-thread_notifier);
- init_waitqueue_head(common-fsg_wait);
/* Information */
INFO(common, FSG_DRIVER_DESC , version: FSG_DRIVER_VERSION \n);
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [xhci] null pointer dereference on ring_doorbell_for_active_rings
Hi
I just started looking at this issue as well from xhci perspective.
From your Oops backtrace I can see that
ring_doorbell_for_active_rings() was called from handle_cmd_completion()
This should only happend if XHCI_RESET_EP_QUIRK is set, i.e. you have a
Fresco Logic host controller.
In that case the ep_index calculation in handle_cmd_completion() look
suspicious, it looks like we do a -1 subtraction twice.
/* Input ctx add_flags are the endpoint index plus one */
ep_index = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags)) - 1;
xhci_last_valid_endpoint() already does a -1
could you try something like:
- ep_index = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags)) - 1;
+ ep_index = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags));
and see if it helps?
-Mathias
On 07/09/2013 08:08 PM, Oleksij Rempel wrote:
You have right.
this problem didn't disappear, it just masked and have other side effect.
I get corrupt buffers after reloading of ath9k_htc(wifi usb adapter) ...
some times laptop will crash in same way like the bug i reported you
before.. If I reduce command buffer size (and size of urb) or reload
xhci_hcd module i can avoid crashes or buffer corruption. Looks like
some part of memory is corrupt.
Then i noticed some problems with usb mouse. It just stop to respond. I
assumed hardware problem, but after reloading xhci_hcd i can bring mouse
back. In case of mouse, i just can't check if buffers are ok.
PS: I had similar problem with i915. It got null pointer dereference by
attaching vga cable. See:
https://bugs.freedesktop.org/show_bug.cgi?id=48652#c107
But it seems to be fixed by disabling Intel VT-d. Suddenly it wont
solve problem with xhcd... may be this problems have same root.
Am 08.07.2013 18:37, schrieb Sarah Sharp:
On Sat, Jul 06, 2013 at 11:13:15AM +0200, Oleksij Rempel wrote:
Hi Sarah,
thanks you or who ever fixed this issue. With latest wireless-testing
i can't reproduce my crash any more. Instead i get this messages:
What kernel is your wireless-testing branch based on?
It would be nice to know which patch fixed your issue, since AFAIK we
didn't make a concerted effort to fix it yet. Any chance you can do a
git bisect? I'm afraid some other change in the wireless stack is
masking an xHCI driver bug.
Sarah Sharp
[ 4510.621603] ath9k_htc: Driver unloaded
[ 4516.407764] usb 3-2: reset high-speed USB device number 4 using
xhci_hcd
[ 4516.430175] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39c00
[ 4516.430179] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39c40
[ 4516.430181] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39c80
[ 4516.430183] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39cc0
[ 4516.430185] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39d00
[ 4516.430186] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39d40
[ 4516.430855] usb 3-2: ath9k_htc: Firmware htc_9271.fw requested
[ 4516.431139] usbcore: registered new interface driver ath9k_htc
Am 11.06.2013 19:34, schrieb Sarah Sharp:
On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on usb_autosuspend for ath9k_htc and triggered this
oops. Currently i do not know if real bug is in ath9k_htc or in
xhci. Same adapter with same kernel and my patches work fine on ehci
host... so may be it is xhci.
Which kernel version is this oops on? I suspect it's an xHCI issue.
Please turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG and
send me dmesg, from the beginning of connecting the device to when
it is
suspended and then resumed. That will be a lot of output, so feel free
to compress it.
Sarah Sharp
i get oops on this line:
426 static void ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
427 unsigned int slot_id,
428 unsigned int ep_index)
429 {
430 unsigned int stream_id;
431 struct xhci_virt_ep *ep;
432
433 ep = xhci-devs[slot_id]-eps[ep_index];
^^^ ^^^
changes for ath9k_htc are in attachment and photo of oops here:
https://plus.google.com/u/0/102032716864870215256/posts/a9d8nFsLhYK
--
Regards,
Oleksij
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..3d74575 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1368,6 +1368,7 @@ static struct usb_driver ath9k_hif_usb_driver
= {
.suspend = ath9k_hif_usb_suspend,
.resume = ath9k_hif_usb_resume,
.reset_resume = ath9k_hif_usb_resume,
+ .supports_autosuspend = 1,
#endif
.id_table = ath9k_hif_usb_ids,
.soft_unbind = 1,
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..20be8a1 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++
Re: [PATCH v2 11/21] usb/gadget: f_mass_storage: use fsg_common_set_nluns in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 22 +-
1 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 5a129c9..9981694 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3007,12 +3007,6 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
int nluns, i, rc;
char *pathbuf;
- /* Find out how many LUNs there should be */
- nluns = cfg-nluns;
- if (nluns 1 || nluns FSG_MAX_LUNS) {
- dev_err(gadget-dev, invalid number of LUNs: %u\n, nluns);
- return ERR_PTR(-EINVAL);
- }
common = fsg_common_setup(common, !!common);
if (IS_ERR(common))
@@ -3042,17 +3036,12 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
}
fsg_intf_desc.iInterface = us[FSG_STRING_INTERFACE].id;
- /*
- * Create the LUNs, open their backing files, and register the
- * LUN devices in sysfs.
- */
- curlun_it = kcalloc(nluns, sizeof(*curlun_it), GFP_KERNEL);
- if (unlikely(!curlun_it)) {
- rc = -ENOMEM;
- goto error_release;
- }
- common-luns = curlun_it;
+ rc = fsg_common_set_nluns(common, cfg-nluns);
+ if (rc)
+ goto error_release;
+ curlun_it = common-luns;
+ nluns = cfg-nluns;
for (i = 0, lcfg = cfg-luns; i nluns; ++i, ++curlun_it, ++lcfg) {
struct fsg_lun *curlun;
@@ -3116,7 +3105,6 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
goto error_luns;
}
}
- common-nluns = nluns;
/* Prepare inquiryString */
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH v2 13/21] usb/gadget: f_mass_storage: use fsg_common_set_cdev in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 23 ++-
1 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index b168a50..9f36e12 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3003,7 +3003,6 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
struct usb_gadget *gadget = cdev-gadget;
struct fsg_lun **curlun_it;
struct fsg_lun_config *lcfg;
- struct usb_string *us;
int nluns, i, rc;
char *pathbuf;
@@ -3024,19 +3023,9 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
fsg_common_set_ops(common, cfg-ops);
fsg_common_set_private_data(common, cfg-private_data);
- common-gadget = gadget;
- common-ep0 = gadget-ep0;
- common-ep0req = cdev-req;
- common-cdev = cdev;
-
- us = usb_gstrings_attach(cdev, fsg_strings_array,
- ARRAY_SIZE(fsg_strings));
- if (IS_ERR(us)) {
- rc = PTR_ERR(us);
+ rc = fsg_common_set_cdev(common, cdev, cfg-can_stall);
+ if (rc)
goto error_release;
- }
- fsg_intf_desc.iInterface = us[FSG_STRING_INTERFACE].id;
-
rc = fsg_common_set_nluns(common, cfg-nluns);
if (rc)
@@ -3118,14 +3107,6 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
: File-Stor Gadget),
i);
- /*
- * Some peripheral controllers are known not to be able to
- * halt bulk endpoints correctly. If one of them is present,
- * disable stalls.
- */
- common-can_stall = cfg-can_stall
- !(gadget_is_at91(common-gadget));
-
/* Tell the thread to start working */
common-thread_task =
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH v2 12/21] usb/gadget: f_mass_storage: use fsg_common_set_ops/_private_data in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote: fsg_common_init is a lengthy function. Now there are helper functions which cover all parts of it. Use them. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com --- drivers/usb/gadget/f_mass_storage.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c index 9981694..b168a50 100644 --- a/drivers/usb/gadget/f_mass_storage.c +++ b/drivers/usb/gadget/f_mass_storage.c @@ -3020,8 +3020,9 @@ struct fsg_common *fsg_common_init(struct fsg_common *common, kfree(common); return ERR_PTR(rc); } - common-ops = cfg-ops; - common-private_data = cfg-private_data; + + fsg_common_set_ops(common, cfg-ops); + fsg_common_set_private_data(common, cfg-private_data); common-gadget = gadget; common-ep0 = gadget-ep0; -- 1.7.0.4 -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH v2 14/21] usb/gadget: f_mass_storage: use fsg_common_create_luns in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 101
++-
1 files changed, 4 insertions(+), 97 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 9f36e12..3d4406a 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3000,12 +3000,7 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
struct usb_composite_dev *cdev,
struct fsg_config *cfg)
{
- struct usb_gadget *gadget = cdev-gadget;
- struct fsg_lun **curlun_it;
- struct fsg_lun_config *lcfg;
- int nluns, i, rc;
- char *pathbuf;
-
+ int i, rc;
common = fsg_common_setup(common, !!common);
if (IS_ERR(common))
@@ -3030,72 +3025,10 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
rc = fsg_common_set_nluns(common, cfg-nluns);
if (rc)
goto error_release;
- curlun_it = common-luns;
- nluns = cfg-nluns;
- for (i = 0, lcfg = cfg-luns; i nluns; ++i, ++curlun_it, ++lcfg) {
- struct fsg_lun *curlun;
-
- *curlun_it = kzalloc(sizeof(**curlun_it), GFP_KERNEL);
- curlun = *curlun_it;
- if (!curlun) {
- rc = -ENOMEM;
- common-nluns = i;
- goto error_release;
- }
- curlun-name = kzalloc(MAX_LUN_NAME_LEN, GFP_KERNEL);
- if (!curlun-name) {
- rc = -ENOMEM;
- common-nluns = i;
- goto error_release;
- }
- curlun-cdrom = !!lcfg-cdrom;
- curlun-ro = lcfg-cdrom || lcfg-ro;
- curlun-initially_ro = curlun-ro;
- curlun-removable = lcfg-removable;
- curlun-dev.release = fsg_lun_release;
- curlun-dev.parent = gadget-dev;
- /* curlun-dev.driver = fsg_driver.driver; XXX */
- dev_set_drvdata(curlun-dev, common-filesem);
- dev_set_name(curlun-dev, lun%d, i);
- snprintf(curlun-name, MAX_LUN_NAME_LEN,
- dev_name(curlun-dev));
-
- rc = device_register(curlun-dev);
- if (rc) {
- INFO(common, failed to register LUN%d: %d\n, i, rc);
- common-nluns = i;
- put_device(curlun-dev);
- kfree(curlun);
- goto error_release;
- }
-
- rc = device_create_file(curlun-dev,
- curlun-cdrom
- ? dev_attr_ro_cdrom
- : dev_attr_ro);
- if (rc)
- goto error_luns;
- rc = device_create_file(curlun-dev,
- curlun-removable
- ? dev_attr_file
- : dev_attr_file_nonremovable);
- if (rc)
- goto error_luns;
- rc = device_create_file(curlun-dev, dev_attr_nofua);
- if (rc)
- goto error_luns;
-
- if (lcfg-filename) {
- rc = fsg_lun_open(curlun, lcfg-filename);
- if (rc)
- goto error_luns;
- } else if (!curlun-removable) {
- ERROR(common, no file given for LUN%d\n, i);
- rc = -EINVAL;
- goto error_luns;
- }
- }
+ rc = fsg_common_create_luns(common, cfg);
+ if (rc)
+ goto error_release;
/* Prepare inquiryString */
i = get_default_bcdDevice();
@@ -3107,7 +3040,6 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
: File-Stor Gadget),
i);
-
/* Tell the thread to start working */
common-thread_task =
kthread_create(fsg_main_thread, common, file-storage);
@@ -3120,37 +3052,12 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
INFO(common, FSG_DRIVER_DESC , version: FSG_DRIVER_VERSION \n);
INFO(common, Number of LUNs=%d\n, common-nluns);
- pathbuf = kmalloc(PATH_MAX, GFP_KERNEL);
- for (i = 0, nluns = common-nluns, curlun_it = common-luns;
- i nluns;
- ++curlun_it, ++i) {
- struct fsg_lun *curlun = *curlun_it;
-
Re: [PATCH v2 15/21] usb/gadget: f_mass_storage: use fsg_common_set_inquiry_string in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 3d4406a..94b7bc3 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3000,7 +3000,7 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
struct usb_composite_dev *cdev,
struct fsg_config *cfg)
{
- int i, rc;
+ int rc;
common = fsg_common_setup(common, !!common);
if (IS_ERR(common))
@@ -3030,16 +3030,9 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
if (rc)
goto error_release;
- /* Prepare inquiryString */
- i = get_default_bcdDevice();
- snprintf(common-inquiry_string, sizeof common-inquiry_string,
- %-8s%-16s%04x, cfg-vendor_name ?: Linux,
- /* Assume product name dependent on the first LUN */
- cfg-product_name ?: ((*common-luns)-cdrom
- ? File-CD Gadget
- : File-Stor Gadget),
- i);
+ fsg_common_set_inquiry_string(common, cfg-vendor_name,
+ cfg-product_name);
/* Tell the thread to start working */
common-thread_task =
kthread_create(fsg_main_thread, common, file-storage);
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH v2 16/21] usb/gadget: f_mass_storage: use fsg_common_run_thread in fsg_common_init
On Fri, Jul 19 2013, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 94b7bc3..ba24236 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3033,21 +3033,13 @@ struct fsg_common *fsg_common_init(struct fsg_common
*common,
fsg_common_set_inquiry_string(common, cfg-vendor_name,
cfg-product_name);
- /* Tell the thread to start working */
- common-thread_task =
- kthread_create(fsg_main_thread, common, file-storage);
- if (IS_ERR(common-thread_task)) {
- rc = PTR_ERR(common-thread_task);
- goto error_release;
- }
/* Information */
INFO(common, FSG_DRIVER_DESC , version: FSG_DRIVER_VERSION \n);
- INFO(common, Number of LUNs=%d\n, common-nluns);
- DBG(common, I/O thread pid: %d\n, task_pid_nr(common-thread_task));
-
- wake_up_process(common-thread_task);
+ rc = fsg_common_run_thread(common);
+ if (rc)
+ goto error_release;
return common;
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: [PATCH 06/16] usb: musb: dsps: rename ti81xx_driver_data to am33xx_driver_data
Hi, On Thu, Jul 25, 2013 at 10:28:37AM -0500, Bin Liu wrote: Sebastian, On Thu, Jul 25, 2013 at 10:16 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/25/2013 05:12 PM, Bin Liu wrote: Sebastian, Hi Bin, Is it really there or was it never there and it has been added to TRM by accident? The EOI register IS in the USB subsystem of AM33xx, but the SoC does not use it because it uses level triggering for USB interrupt. I see. But I am not sure if it is a good idea to remove eoi from the musb_dsps driver. If the intension is to merge the support for other SoC, such as AM35xx, AM18xx, then EOI handling might be still needed. I just don't know how those devices use EOI. If one of the architectures gets added which need an EOI then the offset can be 0 and the EOI will happen only if it is != 0. This patch cleaned up the use of EOI. Do you mean EOI handling will be added back with condition EOI offset != 0, when the support of new device which uses EIO is added? That is my intention. Then should something like EOI cleanup be added into the commit message for better git log searching experience? I would think the EOI cleanup is more important then variable renaming in this patch. Or even better to separate the changes into two patches. perhaps two separate patches would be best, indeed. At least it would make it simpler to track regressions. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: at91_udc: Check gpio lookup results
Hi, On Tue, Jul 23, 2013 at 11:55:50AM -0700, Olof Johansson wrote: This resolves the following valid build warning: drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized] I switched from ? : to !! mostly to save from wrapping the lines while I was at it. Signed-off-by: Olof Johansson o...@lixom.net --- Felipe, this would be nice to see fixed for 3.11 but I'd argue that it's been here long enough to not really be needed for -stable. drivers/usb/gadget/at91_udc.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c index 073b938..f3dbcd0 100644 --- a/drivers/usb/gadget/at91_udc.c +++ b/drivers/usb/gadget/at91_udc.c @@ -1682,12 +1682,20 @@ static void at91udc_of_init(struct at91_udc *udc, board-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0, flags); - board-vbus_active_low = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0; + if (board-vbus_pin 0) + pr_err(%s: Failed to get atmel,vbus-gpio property\n, +np-full_name); + else + board-vbus_active_low = !!(flags OF_GPIO_ACTIVE_LOW); should you even continue if you can't get the gpio ? If this gpio is optional, then it's not really and error, rather a debugging or informational message. BTW, this vbus-gpio looks, to me at least, like a fixed regulator controlled by a GPIO, no ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: at91_udc: Check gpio lookup results
On Thu, Jul 25, 2013 at 9:14 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Jul 23, 2013 at 11:55:50AM -0700, Olof Johansson wrote: This resolves the following valid build warning: drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized] I switched from ? : to !! mostly to save from wrapping the lines while I was at it. Signed-off-by: Olof Johansson o...@lixom.net --- Felipe, this would be nice to see fixed for 3.11 but I'd argue that it's been here long enough to not really be needed for -stable. drivers/usb/gadget/at91_udc.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c index 073b938..f3dbcd0 100644 --- a/drivers/usb/gadget/at91_udc.c +++ b/drivers/usb/gadget/at91_udc.c @@ -1682,12 +1682,20 @@ static void at91udc_of_init(struct at91_udc *udc, board-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0, flags); - board-vbus_active_low = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0; + if (board-vbus_pin 0) + pr_err(%s: Failed to get atmel,vbus-gpio property\n, +np-full_name); + else + board-vbus_active_low = !!(flags OF_GPIO_ACTIVE_LOW); should you even continue if you can't get the gpio ? If this gpio is optional, then it's not really and error, rather a debugging or informational message. That's what the code does today, and I wasn't trying to second-guess their decisions on that. Chances are firmware, in some instances, have left power on so continuing might do no harm. BTW, this vbus-gpio looks, to me at least, like a fixed regulator controlled by a GPIO, no ? Yes, it does. We have plenty of these kind of bindings from before everything had to be a regulator. -Olof -- 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 queue status?
On Thu, Jul 25, 2013 at 11:34:22AM -0400, Alan Stern wrote: Greg: What's the status of your USB patch queue? I've seen a bunch of notices about patches being applied -- is the queue empty yet? No it isn't empty yet, I tried to pick out most of the 3.11 patches from it for USB already, but I might have missed some, I still have 800+ patches to go :( I ask because of this: http://marc.info/?l=linux-usbm=137356910824266w=2 which hasn't been merged yet. That's for 3.12, right? That's why I haven't merged it yet, don't worry, it's not lost. 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
[PATCH] usb: dwc3: core: modify IO memory resource after deferred probe completes
From: Ivan T. Ivanov iiva...@mm-sol.com
When deferred probe happens driver will try to ioremap multiple times
and will fail. Memory resource.start variable is a global variable,
modifications in this field will be accumulated on every probe.
Fix this by moving the above operations after driver hold all
required PHY's.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/dwc3/core.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 607bef8..50c833f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -384,21 +384,6 @@ static int dwc3_probe(struct platform_device *pdev)
dev_err(dev, missing memory resource\n);
return -ENODEV;
}
- dwc-xhci_resources[0].start = res-start;
- dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
- DWC3_XHCI_REGS_END;
- dwc-xhci_resources[0].flags = res-flags;
- dwc-xhci_resources[0].name = res-name;
-
- res-start += DWC3_GLOBALS_REGS_START;
-
-/*
- * Request memory region but exclude xHCI regs,
- * since it will be requested by the xhci-plat driver.
- */
- regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
@@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ dwc-xhci_resources[0].start = res-start;
+ dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
+ DWC3_XHCI_REGS_END;
+ dwc-xhci_resources[0].flags = res-flags;
+ dwc-xhci_resources[0].name = res-name;
+
+ res-start += DWC3_GLOBALS_REGS_START;
+
+/*
+ * Request memory region but exclude xHCI regs,
+ * since it will be requested by the xhci-plat driver.
+ */
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
usb_phy_set_suspend(dwc-usb2_phy, 0);
usb_phy_set_suspend(dwc-usb3_phy, 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
