Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling
On 04/01/2014 11:28 PM, Alan Stern wrote: On Tue, 1 Apr 2014, Hannes Reinecke wrote: So if the above reasoning is okay then this patch should be doing the trick: diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 771c16b..0e72374 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -189,6 +189,7 @@ scsi_abort_command(struct scsi_cmnd *scmd) /* * Retry after abort failed, escalate to next level. */ + scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED; SCSI_LOG_ERROR_RECOVERY(3, scmd_printk(KERN_INFO, scmd, scmd %p previous abort failed\n, scmd)); (Beware of line breaks) Can you test with it? I don't understand. This doesn't solve the fundamental problem (namely that you escalate before aborting a running command). All it does is clear the SCSI_EH_ABORT_SCHEDULED flag before escalating. Which was precisely the point :-) Hmm. The comment might've been clearer. What this patch is _supposed_ to be doing is that it'll clear the SCSI_EH_ABORT_SCHEDULED flag it it has been set. Which means this will be the second time scsi_abort_command() has been called for the same command. IE the first abort went out, did its thing, but now the same command has timed out again. So this flag gets cleared, and scsi_abort_command() returns FAILED, and _no_ asynchronous abort is being scheduled. scsi_times_out() will then proceed to call scsi_eh_scmd_add(). But as we've cleared the SCSI_EH_ABORT_SCHEDULED flag the SCSI_EH_CANCEL_CMD flag will continue to be set, and the command will be aborted with the main SCSI EH routine. It looks to me as if it should do what you desire, namely abort the command asynchronously the first time, and invoking the SCSI EH the second time. Am I wrong? I don't know -- I'll have to try it out. Currently I'm busy with a bunch of other stuff, so it will take some time. Looking through the code, I have to wonder why scsi_times_out() modifies scmd-result. Won't this value get overwritten by the LLDD when the command eventually terminates? Yes. However, the 'DID_TIME_OUT' is just a marker that the internal timeout code triggered. If the LLDD overwrites it with a 'real' error code everything's fine. Even worse, what happens in the event of a race where the command terminates normally just before scsi_times_out() changes scmd-result? _That_ is the least of our worries. _If_ the LLDD completes the command while scsi_times_out() is running the whole thing is going down the drain anyway, as the command will be terminated by the LLDD, and we can only hope that we didn't mess up our reference counting. Otherwise we'd have EH running on a stale command, which is going to be a fun to watch. But looking closer, it might be that the line modifying the result in scsi_times_out() is indeed pointless, seeing that it's being set in scsi_eh_abort_handler(), too. I'll be checking if we can simply remove that line. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
[PATCHv4] rebind: Add rebind mechanism for runtime-resume
Despite the needs_binding flag, the interface rebind was never
done for the PM runtime resume. This patch fixes this issue
by triggering the rebind in usb runtime resume.
The rebind procedure needs to be called with the device lock.
However, depending the call path (remote wakeup, local resume),
the device lock may or may not already be held in usb runtime
resume. So, use a work queue to take the lock unconditionally.
Signed-off-by: Loic Poulain loic.poul...@intel.com
---
drivers/usb/core/driver.c | 12
drivers/usb/core/usb.c| 14 ++
include/linux/usb.h | 2 ++
3 files changed, 28 insertions(+)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 81e..b8d4f38 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1834,11 +1834,23 @@ int usb_runtime_resume(struct device *dev)
{
struct usb_device *udev = to_usb_device(dev);
int status;
+ struct usb_interface*intf;
+ int i;
/* Runtime resume for a USB device means resuming both the device
* and all its interfaces.
*/
status = usb_resume_both(udev, PMSG_AUTO_RESUME);
+
+/* Schedule a safe device locked rebind if necessary */
+ for (i = 0; i udev-actconfig-desc.bNumInterfaces; i++) {
+ intf = udev-actconfig-interface[i];
+ if (intf-needs_binding) {
+ schedule_work(udev-rebind_ws);
+ break;
+ }
+ }
+
return status;
}
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 4d11449..9ec90a3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -265,6 +265,7 @@ static void usb_release_dev(struct device *dev)
udev = to_usb_device(dev);
hcd = bus_to_hcd(udev-bus);
+ cancel_work_sync(udev-rebind_ws);
usb_destroy_configuration(udev);
usb_release_bos_descriptor(udev);
usb_put_hcd(hcd);
@@ -386,6 +387,17 @@ static unsigned usb_bus_is_wusb(struct usb_bus *bus)
return hcd-wireless;
}
+/* Internal function to queue device's interfaces rebind */
+static void usb_queue_rebind_interfaces(struct work_struct *ws)
+{
+ int rc;
+ struct usb_device *udev =
+ container_of(ws, struct usb_device, rebind_ws);
+
+ usb_lock_device(udev);
+ usb_unbind_and_rebind_marked_interfaces(udev);
+ usb_unlock_device(udev);
+}
/**
* usb_alloc_dev - usb device constructor (usbcore-internal)
@@ -487,6 +499,8 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
dev-parent = parent;
INIT_LIST_HEAD(dev-filelist);
+ INIT_WORK(dev-rebind_ws, usb_queue_rebind_interfaces);
+
#ifdef CONFIG_PM
pm_runtime_set_autosuspend_delay(dev-dev,
usb_autosuspend_delay * 1000);
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 6b7ec37..dae32df 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -508,6 +508,7 @@ struct usb3_lpm_parameters {
* to keep track of the number of functions that require USB 3.0 Link Power
* Management to be disabled for this usb_device. This count should only
* be manipulated by those functions, with the bandwidth_mutex is held.
+ * @rebind_ws: used for scheduling interface rebind with device lock
*
* Notes:
* Usbcore drivers should not set usbdev-state directly. Instead use
@@ -587,6 +588,7 @@ struct usb_device {
struct usb3_lpm_parameters u1_params;
struct usb3_lpm_parameters u2_params;
unsigned lpm_disable_count;
+ struct work_struct rebind_ws;
};
#defineto_usb_device(d) container_of(d, struct usb_device, dev)
--
1.8.3.2
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
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/1] usb: option driver, add support for Telit UE910v2
option driver, added VID/PID for Telit UE910v2 modem
Signed-off-by: Daniele Palmas dnl...@gmail.com
---
drivers/usb/serial/option.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 68fc9fe..367c7f0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -243,6 +243,7 @@ static void option_instat_callback(struct urb *urb);
#define TELIT_PRODUCT_CC864_DUAL 0x1005
#define TELIT_PRODUCT_CC864_SINGLE 0x1006
#define TELIT_PRODUCT_DE910_DUAL 0x1010
+#define TELIT_PRODUCT_UE910_V2 0x1012
#define TELIT_PRODUCT_LE9200x1200
/* ZTE PRODUCTS */
@@ -1041,6 +1042,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_DUAL) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_SINGLE) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
.driver_info = (kernel_ulong_t)telit_le920_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff,
0xff, 0xff) }, /* ZTE WCDMA products */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: musb: dsps: move debugfs_remove_recursive()
When the platform initialization fails due to missing resources, it will return -EPROBE_DEFER after dsps_musb_init() has been called. dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs nodes. At a later point in time, the probe will be retried, and dsps_musb_dbg_init() will be called again. debugfs_create_dir() will fail this time, as the node already exists, and so the entire device probe will fail with -ENOMEM. Fix this by moving debugfs_remove_recursive() from dsps_remove() to the plaform's exit function, so it will be cleanly torn down when the probe fails. It also feels more natural this way, as .exit is the counterpart to .init. Signed-off-by: Daniel Mack zon...@gmail.com --- Only the current 'next' branch which will be merged into 3.15 is affected. drivers/usb/musb/musb_dsps.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev-parent); del_timer_sync(glue-timer); - usb_phy_shutdown(musb-xceiv); + debugfs_remove_recursive(glue-dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); - debugfs_remove_recursive(glue-dbgfs_root); - return 0; } -- 1.8.5.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
[RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
We have historic problem that the gadget will not work if the gadget
is build-in and the udc driver is defered probe due to some
resources are not ready. Below links are related to this problem.
http://marc.info/?l=linux-usbm=139380872501745w=2
http://marc.info/?l=linux-usbm=137991612311893w=2
http://marc.info/?l=linux-usbm=137706435611447w=2
This patch saves pointer of usb_gadget_driver when the udc is
not ready, and redo usb_gadget_probe_driver when the udc is ready
This method may not be good enough, but we need to find a way
to fix this problem, so I post this RFC to see if to see comments,
someone may have a better solution:)
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc-core.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 27768a7..1b991ef 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -48,6 +48,11 @@ struct usb_udc {
static struct class *udc_class;
static LIST_HEAD(udc_list);
static DEFINE_MUTEX(udc_lock);
+/*
+ * Only used for saving usb_gadget_driver pointer
+ * when the udc is not ready
+ */
+struct usb_gadget_driver *saved_gadget_driver;
/* - */
@@ -272,7 +277,12 @@ EXPORT_SYMBOL_GPL(usb_add_gadget_udc_release);
*/
int usb_add_gadget_udc(struct device *parent, struct usb_gadget *gadget)
{
- return usb_add_gadget_udc_release(parent, gadget, NULL);
+ int ret = usb_add_gadget_udc_release(parent, gadget, NULL);
+ if (!ret saved_gadget_driver) {
+ usb_gadget_probe_driver(saved_gadget_driver);
+ saved_gadget_driver = NULL;
+ }
+ return ret;
}
EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
@@ -406,7 +416,8 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver)
goto found;
}
- pr_debug(couldn't find an available UDC\n);
+ pr_debug(couldn't find an UDC, retry probe when udc is ready\n);
+ saved_gadget_driver = driver;
mutex_unlock(udc_lock);
return -ENODEV;
found:
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
Hi Peter, On 04/02/2014 10:47 AM, Peter Chen wrote: We have historic problem that the gadget will not work if the gadget is build-in and the udc driver is defered probe due to some resources are not ready. Below links are related to this problem. http://marc.info/?l=linux-usbm=139380872501745w=2 http://marc.info/?l=linux-usbm=137991612311893w=2 http://marc.info/?l=linux-usbm=137706435611447w=2 This patch saves pointer of usb_gadget_driver when the udc is not ready, and redo usb_gadget_probe_driver when the udc is ready This method may not be good enough, but we need to find a way to fix this problem, so I post this RFC to see if to see comments, someone may have a better solution:) I have sent patch fixing this problem few weeks ago: http://www.spinics.net/lists/linux-usb/msg102795.html Best regards, Robert Baldyga -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] u_ether: move hardware transmit to RX workqueue
Hello, W dniu 06.03.2014 17:04, Felipe Balbi pisze: Hi, On Thu, Mar 06, 2014 at 11:42:49PM +0800, Weinn Jheng wrote: In order to reduce the interrupt times in the embedded system, a receiving workqueue is introduced. This modification also enhanced the overall throughput as the benefits of reducing interrupt occurrence. Signed-off-by: Weinn Jheng clanlab.p...@gmail.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: David S. Miller da...@davemloft.net Dave, does this look ok from NAPI point of view ? I used Felipe's master branch, the relevant commit seems to be: 716fb91dfe1777bd6d5e598f3d3572214b3ed296 usb: gadget: u_ether: move hardware transmit to RX NAPI With the patch applied I get kernel bug: [ 31.017960] [ cut here ] [ 31.021998] kernel BUG at include/linux/netdevice.h:502! [ 31.027284] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM [ 31.032745] Modules linked in: g_ether usb_f_rndis usb_f_ecm_subset usb_f_ecm u_ether libcomposite [ 31.041675] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-rc8+ #291 [ 31.047996] task: c0588720 ti: c057e000 task.ti: c057e000 [ 31.053385] PC is at eth_start+0x80/0x84 [u_ether] [ 31.058144] LR is at __netif_schedule+0x80/0x88 [ 31.062642] pc : [bf012720]lr : [c03145b4]psr: 6193 [ 31.062642] sp : c057fca0 ip : c057fc80 fp : c057fcb4 [ 31.074078] r10: e76c4c88 r9 : 0001 r8 : 000a [ 31.079278] r7 : e6f4fcfc r6 : r5 : e6f4fce0 r4 : e6f4fce0 [ 31.085777] r3 : r2 : c058681c r1 : 0001 r0 : [ 31.092278] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 31.099643] Control: 10c5387d Table: 56578019 DAC: 0015 [ 31.105362] Process swapper (pid: 0, stack limit = 0xc057e238) [ 31.68] Stack: (0xc057fca0 to 0xc058) [ 31.115506] fca0: 000b e642a480 c057fcdc c057fcb8 bf01287c bf0126ac bf01a998 e642a480 [ 31.123651] fcc0: 0001 e769a580 e642a480 c057fcfc c057fce0 bf0197fc bf012730 [ 31.131797] fce0: bf019728 e6474d40 e769a580 0001 c057fd64 c057fd00 bf002804 bf019734 [ 31.139943] fd00: c057fd44 c057fd10 c02ce518 c02cc734 e7abef80 c0047750 c03afae8 [ 31.148088] fd20: e76c4c24 e76c4c10 c03af9a8 bf0314e4 e76c4c7c [ 31.156234] fd40: e76c4c10 e76c4c24 e74fb000 c05c79d8 0010 c057fdac c057fd68 [ 31.164380] fd60: c02d04a0 bf001f10 c057e000 e76c4c24 e74fb000 c03afb20 c03af9a8 [ 31.172525] fd80: c02d03bc e6f456c0 e74fb000 e76c4c10 e76c4c24 0010 [ 31.180671] fda0: c057fde4 c057fdb0 c02ccf78 c02d03c8 c057fdfc c057fdc0 c0046a00 c03af9e0 [ 31.188817] fdc0: 2dd8 e6f456c0 e76c4c10 e74fb000 0001 c057fe14 c057fde8 [ 31.196963] fde0: c02cedd4 c02cceec c05c4370 e76c4c10 e76c4c10 0148 c05c79d8 [ 31.205108] fe00: 0007 c057fe5c c057fe18 c02cffc4 c02ced18 001e [ 31.213254] fe20: c057fe80 c05ecc40 e76c4c24 000b e6f45900 c059c5cc 0058 [ 31.221399] fe40: c05c4370 c057fe9c c057fe60 c005fae0 c02cf91c [ 31.229545] fe60: c00723b8 c00728b4 c059c578 0006 c059c578 c059c5cc e6f45900 [ 31.237691] fe80: c0614900 c05c4370 e7ffcb80 c057febc c057fea0 c005fdac c005fa80 [ 31.245837] fea0: 0002 c059c578 c059c5cc c057fed4 c057fec0 c0062478 c005fd6c [ 31.253983] fec0: c05afee8 0058 c057fee4 c057fed8 c005f3d0 c00623e8 c057ff04 c057fee8 [ 31.262128] fee0: c0010698 c005f3a8 0020 c0614928 c057ff30 0001 c057ff2c c057ff08 [ 31.270274] ff00: c00085f0 c0010664 c001088c 6013 c057ff64 c05c4370 [ 31.278420] ff20: c057ff84 c057ff30 c0013e04 c0008590 c058681c 1aec c058681c [ 31.286566] ff40: c057e000 c057e000 c05860dc c057e000 c05c4370 c05c4370 e7ffcb80 c057ff84 [ 31.294711] ff60: c057ff78 c057ff78 c0010888 c001088c 6013 c057ff9c c057ff88 [ 31.302857] ff80: c005f198 c0010868 c05691a0 c057ffb4 c057ffa0 c03a631c c005f138 [ 31.311003] ffa0: c056a0ec c0586b48 c057fff4 c057ffb8 c053da50 c03a62a8 [ 31.319148] ffc0: c053d544 c05691a0 10c53c7d c058605c c056919c c0589a6c [ 31.327294] ffe0: 30004059 c057fff8 30008070 c053d7bc [ 31.335463] [bf012720] (eth_start [u_ether]) from [bf01287c] (gether_connect+0x158/0x1bc [u_ether]) [ 31.344814] [bf01287c] (gether_connect [u_ether]) from [bf0197fc] (ecm_set_alt+0xd4/0x22c [usb_f_ecm]) [ 31.354451] [bf0197fc] (ecm_set_alt [usb_f_ecm]) from [bf002804] (composite_setup+0x900/0x1088 [libcomposite]) [ 31.364751] [bf002804] (composite_setup [libcomposite]) from [c02d04a0] (s3c_hsotg_complete_setup+0xe4/0x508) [ 31.374961] [c02d04a0] (s3c_hsotg_complete_setup) from [c02ccf78] (s3c_hsotg_complete_request+0x98/0x14c) [ 31.384837] [c02ccf78] (s3c_hsotg_complete_request) from
[PATCH] USB : Gadget : fsl: Fix the fault issue on rmmod
completion in udc_controller-done should be assign with proper value before complete called. The complete called in fsl_udc_release which intern called from usb_del_gadget_udc, so moving assignment before calling usb_del_gadget_udc Signed-off-by: Suresh Gupta suresh.gu...@freescale.com --- drivers/usb/gadget/fsl_udc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index 5a0f89c..e55d04f 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -2537,8 +2537,8 @@ static int __exit fsl_udc_remove(struct platform_device *pdev) if (!udc_controller) return -ENODEV; - usb_del_gadget_udc(udc_controller-gadget); udc_controller-done = done; + usb_del_gadget_udc(udc_controller-gadget); fsl_udc_clk_release(); -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 RESEND 4/4] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
On Tue, Mar 25, 2014 at 03:27:30PM +0100, Alexander Gordeev wrote: On Thu, Mar 06, 2014 at 01:56:46PM -0800, Sarah Sharp wrote: What do you mean by this sentence? Are you fixing some bug in those two functions, or just cleaning up how they look? Either way, this should really be two patches. Hi Sarah, Any feedback on v2? Sarah? Thanks! Sarah Sharp -- Regards, Alexander Gordeev agord...@redhat.com -- Regards, Alexander Gordeev agord...@redhat.com -- 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/3] USB: musb: dsps: handle babble interrupts
When the dsps isr sees a babble error, pass it down to the core for
fixup. Also, provide a .reset hook so the core can call us back.
A babble interrupt error occured when a USB mass storage device
(CHIPSBNK v3.3.9.1, 1e3d:2093) was disconnected from a AM33xx host.
Signed-off-by: Daniel Mack zon...@gmail.com
Reported-by: Thomas Mellenthin mellent...@teufel.de
---
drivers/usb/musb/musb_dsps.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e2fd263..264d6f9 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -329,9 +329,21 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
* value but DEVCTL.BDEVICE is invalid without DEVCTL.SESSION set.
* Also, DRVVBUS pulses for SRP (but not at 5V) ...
*/
- if (is_host_active(musb) usbintr MUSB_INTR_BABBLE)
+ if (is_host_active(musb) usbintr MUSB_INTR_BABBLE) {
pr_info(CAUTION: musb: Babble Interrupt Occurred\n);
+ /*
+* When a babble condition occurs, the musb controller removes
+* the session and is no longer in host mode. Hence, all
+* devices connected to its root hub get disconnected.
+*
+* Hand this error down to the musb core isr, so it can
+* recover.
+*/
+ musb-int_usb = MUSB_INTR_BABBLE | MUSB_INTR_DISCONNECT;
+ musb-int_tx = musb-int_rx = 0;
+ }
+
if (usbintr ((1 wrp-drvvbus) wrp-usb_shift)) {
int drvvbus = dsps_readl(reg_base, wrp-status);
void __iomem *mregs = musb-mregs;
@@ -524,6 +536,16 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
+static void dsps_musb_reset(struct musb *musb)
+{
+ struct device *dev = musb-controller;
+ struct dsps_glue *glue = dev_get_drvdata(dev-parent);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+
+ dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
+ udelay(100);
+}
+
static struct musb_platform_ops dsps_ops = {
.init = dsps_musb_init,
.exit = dsps_musb_exit,
@@ -533,6 +555,7 @@ static struct musb_platform_ops dsps_ops = {
.try_idle = dsps_musb_try_idle,
.set_mode = dsps_musb_set_mode,
+ .reset = dsps_musb_reset,
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
--
1.8.5.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 2/3] USB: musb: Add a work_struct to recover from babble errors
Handle BABBLE interrupt error conditions from a work struct handler.
This indirection is necessary as we can't be certain that the phy
functions don't sleep.
Platform layer implementation may pass a babble error down to the core
in order to handle it.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c | 35 +++
drivers/usb/musb/musb_core.h | 1 +
2 files changed, 36 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0757690..61da471 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -848,6 +848,10 @@ b_host:
}
}
+ /* handle babble condition */
+ if (int_usb MUSB_INTR_BABBLE)
+ schedule_work(musb-recover_work);
+
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
* supporting transfer phasing to prevent exceeding ISO bandwidth
@@ -1746,6 +1750,34 @@ static void musb_irq_work(struct work_struct *data)
}
}
+/* Recover from babble interrupt conditions */
+static void musb_recover_work(struct work_struct *data)
+{
+ struct musb *musb = container_of(data, struct musb, recover_work);
+ int status;
+
+ musb_platform_reset(musb);
+
+ usb_phy_vbus_off(musb-xceiv);
+ udelay(100);
+
+ usb_phy_vbus_on(musb-xceiv);
+ udelay(100);
+
+ /*
+* When a babble condition occurs, the musb controller removes the
+* session bit and the endpoint config is lost.
+*/
+ if (musb-dyn_fifo)
+ status = ep_config_from_table(musb);
+ else
+ status = ep_config_from_hw(musb);
+
+ /* start the session again */
+ if (status == 0)
+ musb_start(musb);
+}
+
/* --
* Init support
*/
@@ -1913,6 +1945,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
+ INIT_WORK(musb-recover_work, musb_recover_work);
INIT_DELAYED_WORK(musb-deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(musb-finish_resume_work, musb_host_finish_resume);
@@ -2008,6 +2041,7 @@ fail4:
fail3:
cancel_work_sync(musb-irq_work);
+ cancel_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
if (musb-dma_controller)
@@ -2073,6 +2107,7 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb-dma_controller);
cancel_work_sync(musb-irq_work);
+ cancel_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 5514e4c..47e8874 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,6 +297,7 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
+ struct work_struct recover_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
u16 hwvers;
--
1.8.5.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 0/3] USB: musb: handle babble errors on dsps platform
On an AM335x platform, I'm seeing babble interrupts occuring when one specific mass storage device is disconnected from the bus. The device identfies itself as: idVendor 0x1e3d Chipsbank Microelectronics Co., Ltd idProduct 0x2093 bcdDevice1.00 iManufacturer 1 CHIPSBNK iProduct2 v3.3.9.1 iSerial 3 2115370076435400 I took the logic Ravi Babu implemented in May 2013, and addressed Felipe's comments on the thread back then. The result very much differs from the original implemention. I also factored out the actual recovery to a work struct, so we don't re-introduce 'scheduling while atomic' trouble. The platform layer reset is in fact necessary according to my tests. Let me know what you think. Thanks, Daniel Daniel Mack (3): USB: musb: add reset hook to platform ops USB: musb: Add a work_struct to recover from babble errors USB: musb: dsps: handle babble interrupts drivers/usb/musb/musb_core.c | 35 +++ drivers/usb/musb/musb_core.h | 8 drivers/usb/musb/musb_dsps.c | 25 - 3 files changed, 67 insertions(+), 1 deletion(-) -- 1.8.5.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/3] USB: musb: add reset hook to platform ops
Babble interrupts require us to reset the DSPS glue layer. In order to
handle all other recovery tasks independently, add a new hook for
platform-specific implementations of the actual reset.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7083e82..5514e4c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,6 +192,7 @@ struct musb_platform_ops {
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
+ void(*reset)(struct musb *musb);
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -552,6 +553,12 @@ static inline void musb_platform_try_idle(struct musb
*musb,
musb-ops-try_idle(musb, timeout);
}
+static inline void musb_platform_reset(struct musb *musb)
+{
+ if (musb-ops-reset)
+ musb-ops-reset(musb);
+}
+
static inline int musb_platform_get_vbus_status(struct musb *musb)
{
if (!musb-ops-vbus_status)
--
1.8.5.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 1/3] USB: musb: add reset hook to platform ops
On 02-04-2014 15:58, Daniel Mack wrote:
Babble interrupts require us to reset the DSPS glue layer. In order to
handle all other recovery tasks independently, add a new hook for
platform-specific implementations of the actual reset.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7083e82..5514e4c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,6 +192,7 @@ struct musb_platform_ops {
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
+ void(*reset)(struct musb *musb);
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -552,6 +553,12 @@ static inline void musb_platform_try_idle(struct musb
*musb,
musb-ops-try_idle(musb, timeout);
}
+static inline void musb_platform_reset(struct musb *musb)
+{
+ if (musb-ops-reset)
+ musb-ops-reset(musb);
+}
+
I think tis patch should be merged with the patch #2. It's not good that
you add a function that's not called yet.
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 1/3] USB: musb: add reset hook to platform ops
On 02-04-2014 15:58, Daniel Mack wrote:
Babble interrupts require us to reset the DSPS glue layer. In order to
handle all other recovery tasks independently, add a new hook for
platform-specific implementations of the actual reset.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7083e82..5514e4c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,6 +192,7 @@ struct musb_platform_ops {
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
+ void(*reset)(struct musb *musb);
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -552,6 +553,12 @@ static inline void musb_platform_try_idle(struct musb
*musb,
musb-ops-try_idle(musb, timeout);
}
+static inline void musb_platform_reset(struct musb *musb)
+{
+ if (musb-ops-reset)
+ musb-ops-reset(musb);
+}
+
I think this patch should be merged with the patch #2. It's not good that
you add a function that's not called yet.
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
[PATCH] phy: don't return error from the stubs
Returning 0 from the stubs for the functions that are used
for PHY controlling. The interface should not appear to be
failing with every operation when the framework is not
enabled.
This fixes an issue in dwc3 driver, where the driver fails
the moment first phy_*() call is made when the framework is
not enabled.
Reported-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
include/linux/phy/phy.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e2f5ca9..00d6949 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -174,22 +174,22 @@ void devm_of_phy_provider_unregister(struct device *dev,
#else
static inline int phy_pm_runtime_get(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_pm_runtime_get_sync(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_pm_runtime_put(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_pm_runtime_put_sync(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline void phy_pm_runtime_allow(struct phy *phy)
@@ -204,27 +204,27 @@ static inline void phy_pm_runtime_forbid(struct phy *phy)
static inline int phy_init(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_exit(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_power_on(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_power_off(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_get_bus_width(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline void phy_set_bus_width(struct phy *phy, int bus_width)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb audio breaks ohci-pci
On Tue, 1 Apr 2014, Dennis New wrote: On Tue, 1 Apr 2014 22:38:39 -0400 (EDT), Alan Stern wrote: On Tue, 1 Apr 2014, Dennis New wrote: [...] This indicates that the OHCI host controller just stopped working. Then about a minute later, the audio device disconnected. Yep, that's what happened. I manually disconnected the usb audio device though. And then tried plugging it back in, but got no response. No response because the hub driver was hung. But something should have shown up in the usbmon trace, depending on how badly the OHCI controller was messed up. Did you stop the trace before plugging the device back in? Nope, it was running the whole time, for almost an hour after the crash. There was no further activity coming from 3u. I guess that means the OHCI controller was pretty thoroughly hosed. 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: [PATCHv4] rebind: Add rebind mechanism for runtime-resume
On Wed, 2 Apr 2014, Poulain, Loic wrote: Despite the needs_binding flag, the interface rebind was never done for the PM runtime resume. This patch fixes this issue by triggering the rebind in usb runtime resume. The rebind procedure needs to be called with the device lock. However, depending the call path (remote wakeup, local resume), the device lock may or may not already be held in usb runtime resume. So, use a work queue to take the lock unconditionally. Signed-off-by: Loic Poulain loic.poul...@intel.com --- How does this differ from the v3 patch? You should include a description of the changes here, below the --- tear line. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] libusbg: Fix wrong malloc sizes in allocate functions.
Functions usbg_allocate_function() and usbg_allocate_binding()
had allocated sizeof(usbg_config) instead of usbg_function
and usbg_binding.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
index 3e1766e..68943c4 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -530,7 +530,7 @@ static usbg_function *usbg_allocate_function(char *path,
char *name,
{
usbg_function *f;
- f = malloc(sizeof(usbg_config));
+ f = malloc(sizeof(usbg_function));
if (f) {
f-name = strdup(name);
f-path = strdup(path);
@@ -552,7 +552,7 @@ static usbg_binding *usbg_allocate_binding(char *path, char
*name,
{
usbg_binding *b;
- b = malloc(sizeof(usbg_config));
+ b = malloc(sizeof(usbg_binding));
if (b) {
b-name = strdup(name);
b-path = strdup(path);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] libusbg: Fix missing read of bcdDevice.
Value of bcdDevice has been never read from Config FS and this field was leaved uninitialized. Change usbg_parse_gadget_attrs() to read also from this file. Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com --- src/usbg.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/src/usbg.c b/src/usbg.c index f1671d7..3e1766e 100644 --- a/src/usbg.c +++ b/src/usbg.c @@ -903,6 +903,12 @@ static int usbg_parse_gadget_attrs(char *path, char *name, else goto out; + ret = usbg_read_hex(path, name, bcdDevice, buf); + if (ret == USBG_SUCCESS) + g_attrs-bcdDevice = (uint16_t) buf; + else + goto out; + ret = usbg_read_hex(path, name, bDeviceClass, buf); if (ret == USBG_SUCCESS) g_attrs-bDeviceClass = (uint8_t)buf; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Small bug fixes and rework of API.
Dear Matt, In this series of patch I have fixed some bugs introduced some time ago. First of it was a copy-pasta bug in functions which allocates memory and the second one was missing read of bcdDevice gadget attribute. Second part of this series contains small rework of libusbg API. In those patches I have change functions related to configuration and function. Currently when user would like to get a function, he should pass the whole name as in ConfigFS, but user should not need to know what is the naming convention of this file system. After those patches user will specify function type and instance name instead of string with file name from ConfigFS. Similar changes has been done in configuration related functions. After my changes user will have to specify only the ID (number) for configuration. Label may be omitted and library will use some default name. ID of configuration is unique so it's enough to get configuration. This series of patch depends on all my previous series. I have also updated github pull request. Please review and merge. -- BR's Krzysztof Opasiak Samsung RD Institute Poland Samsung Electronics Krzysztof Opasiak (5): libusbg: Fix missing read of bcdDevice. libusbg: Fix wrong malloc sizes in allocate functions. libusbg: Add checking for legal function type. libusbg: Replace usage of function name with type and instance. libusbg: Use config ID and label instead of config name. examples/gadget-acm-ecm.c |4 +- examples/show-gadgets.c | 29 +-- include/usbg/usbg.h | 64 --- src/usbg.c| 451 ++--- 4 files changed, 365 insertions(+), 183 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] libusbg: Add checking for legal function type.
Function type provided by user to functions should
be checked before usage to avoid errors.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
index 68943c4..e2e4600 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -284,6 +284,13 @@ static int usbg_lookup_function_type(char *name)
return i;
}
+static inline const char *usbg_get_function_type_name(
+ usbg_function_type type)
+{
+ return type 0 type sizeof(function_names)/sizeof(char *) ?
+ function_names[type] : NULL;
+}
+
static int bindings_select(const struct dirent *dent)
{
if (dent-d_type == DT_LNK)
@@ -1732,6 +1739,7 @@ int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
{
char fpath[USBG_MAX_PATH_LENGTH];
char name[USBG_MAX_PATH_LENGTH];
+ const char *type_name;
usbg_function *func;
int ret = USBG_ERROR_INVALID_PARAM;
int n, free_space;
@@ -1739,11 +1747,11 @@ int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
if (!g || !f)
return ret;
- /**
-* @todo Check for legal function type
-*/
- n = snprintf(name, sizeof(name), %s.%s,
- function_names[type], instance);
+ type_name = usbg_get_function_type_name(type);
+ if (!type_name)
+ goto out;
+
+ n = snprintf(name, sizeof(name), %s.%s, type_name, instance);
if (n = sizeof(name)) {
ret = USBG_ERROR_PATH_TOO_LONG;
goto out;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] libusbg: Use config ID and label instead of config name.
Naming convention of Config FS should not be exposed
to user of library. All API functions should use
configuration ID (configuration number) as unique
identificator and configuration label as human
readable description.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
examples/gadget-acm-ecm.c |4 +-
examples/show-gadgets.c |9 +-
include/usbg/usbg.h | 35 +---
src/usbg.c| 200 +++--
4 files changed, 168 insertions(+), 80 deletions(-)
diff --git a/examples/gadget-acm-ecm.c b/examples/gadget-acm-ecm.c
index 8eb4aeb..7a8b71b 100644
--- a/examples/gadget-acm-ecm.c
+++ b/examples/gadget-acm-ecm.c
@@ -97,8 +97,8 @@ int main(void)
goto out2;
}
- usbg_ret = usbg_create_config(g, c.1, NULL /* use defaults */,
c_strs,
- c);
+ usbg_ret = usbg_create_config(g, 1, The only one,
+ NULL /* use defaults */, c_strs, c);
if (usbg_ret != USBG_SUCCESS) {
fprintf(stderr, Error creating config\n);
fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
diff --git a/examples/show-gadgets.c b/examples/show-gadgets.c
index 971beb4..1ae3860 100644
--- a/examples/show-gadgets.c
+++ b/examples/show-gadgets.c
@@ -57,7 +57,7 @@ void show_gadget(usbg_gadget *g)
fprintf(stdout, idVendor\t\t0x%04x\n, g_attrs.idVendor);
fprintf(stdout, idProduct\t\t0x%04x\n, g_attrs.idProduct);
- usbg_get_gadget_strs(g, LANG_US_ENG, g_strs);
+ usbg_ret = usbg_get_gadget_strs(g, LANG_US_ENG, g_strs);
if (usbg_ret != USBG_SUCCESS) {
fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
usbg_strerror(usbg_ret));
@@ -121,10 +121,11 @@ void show_config(usbg_config *c)
usbg_function_type type;
usbg_config_attrs c_attrs;
usbg_config_strs c_strs;
- int usbg_ret;
+ int usbg_ret, id;
- usbg_get_config_name(c, buf, USBG_MAX_STR_LENGTH);
- fprintf(stdout, Configuration '%s'\n, buf);
+ usbg_get_config_label(c, buf, USBG_MAX_STR_LENGTH);
+ id = usbg_get_config_id(c);
+ fprintf(stdout, Configuration: '%s' ID: %d\n, buf, id);
usbg_ret = usbg_get_config_attrs(c, c_attrs);
if (usbg_ret != USBG_SUCCESS) {
diff --git a/include/usbg/usbg.h b/include/usbg/usbg.h
index 35b35f7..b4e9f9d 100644
--- a/include/usbg/usbg.h
+++ b/include/usbg/usbg.h
@@ -36,6 +36,7 @@
#define DEFAULT_UDCNULL
#define LANG_US_ENG0x0409
+#define DEFAULT_CONFIG_LABEL config
#define USBG_MAX_STR_LENGTH 256
#define USBG_MAX_PATH_LENGTH PATH_MAX
@@ -265,10 +266,14 @@ extern usbg_function *usbg_get_function(usbg_gadget *g,
/**
* @brief Get a configuration by name
* @param g Pointer to gadget
- * @param name Name of the configuration
+ * @param id Identify of configuration
+ * @param label Configuration label. If not NULL this function will return
+ * valid value only if configuration with given id exist and has this label.
+ * If NULL this function will return config with given id (if such exist)
+ * and ignore this param.
* @return Pointer to config or NULL if a matching config isn't found
*/
-extern usbg_config *usbg_get_config(usbg_gadget *g, const char *name);
+extern usbg_config *usbg_get_config(usbg_gadget *g, int id, const char *label);
/* USB gadget/config/function/binding removal */
@@ -546,31 +551,39 @@ extern const char
*usbg_get_function_type_str(usbg_function_type type);
/**
* @brief Create a new USB gadget configuration
* @param g Pointer to gadget
- * @param name Name of configuration
+ * @param id Identify of configuration
+ * @param label configuration label, if NULL, default is used
* @param c_attrs Configuration attributes to be set
* @param c_strs Configuration strings to be set
* @param c Pointer to be filled with pointer to configuration
* @note Given strings are assumed to be in US English
* @return 0 on success usbg_error if error occurred
*/
-extern int usbg_create_config(usbg_gadget *g, char *name,
+extern int usbg_create_config(usbg_gadget *g, int id, const char *label,
usbg_config_attrs *c_attrs, usbg_config_strs *c_strs,
usbg_config **c);
/**
- * @brief Get config name length
- * @param c Config which name length should be returned
- * @return Length of name string or usbg_error if error occurred.
+ * @brief Get config label length
+ * @param c Config which label length should be returned
+ * @return Length of label or usbg_error if error occurred.
*/
-extern size_t usbg_get_config_name_len(usbg_config *c);
+extern size_t usbg_get_config_label_len(usbg_config *c);
/**
- * @brieg Get config name
+ * @brieg Get config label
* @param c Pointer to config
- * @param buf Buffer where name should be copied
+ * @param buf Buffer where label should be copied
* @param len Length of given buffer
*
[PATCH 4/5] libusbg: Replace usage of function name with type and instance.
User of library should not use directly function name but
only type of the function and name of instance. Using this
will separate user for naming convention on Config FS.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
examples/show-gadgets.c | 20 ++--
include/usbg/usbg.h | 29 --
src/usbg.c | 239 ++-
3 files changed, 184 insertions(+), 104 deletions(-)
diff --git a/examples/show-gadgets.c b/examples/show-gadgets.c
index df86cb9..971beb4 100644
--- a/examples/show-gadgets.c
+++ b/examples/show-gadgets.c
@@ -70,11 +70,13 @@ void show_gadget(usbg_gadget *g)
void show_function(usbg_function *f)
{
- char buf[USBG_MAX_STR_LENGTH];
+ char instance[USBG_MAX_STR_LENGTH];
+ usbg_function_type type;
int usbg_ret;
usbg_function_attrs f_attrs;
- usbg_get_function_name(f, buf, USBG_MAX_STR_LENGTH);
+ usbg_get_function_instance(f, instance, USBG_MAX_STR_LENGTH);
+ type = usbg_get_function_type(f);
usbg_ret = usbg_get_function_attrs(f, f_attrs);
if (usbg_ret != USBG_SUCCESS) {
fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
@@ -82,8 +84,9 @@ void show_function(usbg_function *f)
return;
}
- fprintf(stdout, Function '%s'\n, buf);
- switch (usbg_get_function_type(f)) {
+ fprintf(stdout, Function, type: %s instance: %s\n,
+ usbg_get_function_type_str(type), instance);
+ switch (type) {
case F_SERIAL:
case F_ACM:
case F_OBEX:
@@ -114,7 +117,8 @@ void show_config(usbg_config *c)
{
usbg_binding *b;
usbg_function *f;
- char buf[USBG_MAX_STR_LENGTH], buf2[USBG_MAX_STR_LENGTH];
+ char buf[USBG_MAX_STR_LENGTH], instance[USBG_MAX_STR_LENGTH];
+ usbg_function_type type;
usbg_config_attrs c_attrs;
usbg_config_strs c_strs;
int usbg_ret;
@@ -144,8 +148,10 @@ void show_config(usbg_config *c)
usbg_for_each_binding(b, c) {
usbg_get_binding_name(b, buf, USBG_MAX_STR_LENGTH);
f = usbg_get_binding_target(b);
- usbg_get_function_name(f, buf2, USBG_MAX_STR_LENGTH);
- fprintf(stdout, %s - %s\n, buf, buf2);
+ usbg_get_function_instance(f, instance, USBG_MAX_STR_LENGTH);
+ type = usbg_get_function_type(f);
+ fprintf(stdout, %s - %s %s\n, buf,
+ usbg_get_function_type_str(type), instance);
}
}
diff --git a/include/usbg/usbg.h b/include/usbg/usbg.h
index d416624..35b35f7 100644
--- a/include/usbg/usbg.h
+++ b/include/usbg/usbg.h
@@ -255,10 +255,12 @@ extern usbg_gadget *usbg_get_gadget(usbg_state *s, const
char *name);
/**
* @brief Get a function by name
* @param g Pointer to gadget
- * @param name Name of the function
+ * @param type Function type
+ * @param instance Instance of function
* @return Pointer to function or NULL if a matching function isn't found
*/
-extern usbg_function *usbg_get_function(usbg_gadget *g, const char *name);
+extern usbg_function *usbg_get_function(usbg_gadget *g,
+ usbg_function_type type, const char *instance);
/**
* @brief Get a configuration by name
@@ -517,20 +519,27 @@ extern int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
char *instance, usbg_function_attrs *f_attrs, usbg_function
**f);
/**
- * @brief Get function name length
- * @param f Config which name length should be returned
+ * @brief Get function instance name length
+ * @param f function which name length should be returned
* @return Length of name string or usbg_error if error occurred.
*/
-extern size_t usbg_get_function_name_len(usbg_function *f);
+extern size_t usbg_get_function_instance_len(usbg_function *f);
/**
- * @brieg Get config name
+ * @brief Get function instance name
* @param f Pointer to function
- * @param buf Buffer where name should be copied
+ * @param buf Buffer where instance name should be copied
* @param len Length of given buffer
* @return 0 on success or usbg_error if error occurred.
*/
-extern int usbg_get_function_name(usbg_function *f, char *buf, size_t len);
+extern int usbg_get_function_instance(usbg_function *f, char *buf, size_t len);
+
+/**
+ * @brief Get function type as a string
+ * @param type Function type
+ * @return String suitable for given function type
+ */
+extern const char *usbg_get_function_type_str(usbg_function_type type);
/* USB configurations allocation and configuration */
@@ -706,8 +715,8 @@ extern int usbg_get_gadget_udc(usbg_gadget *g, char *buf,
size_t len);
/**
* @brief Get type of given function
* @param f Pointer to function
- * @return Type of function
- * @warning Pointer to function has to be valid.
+ * @return usbg_function_type (0 or above) or
+ * usbg_error (below 0) if error occurred
*/
extern
RE: [PATCH 2/5] libusbg: Fix wrong malloc sizes in allocate functions.
From: Krzysztof Opasiak Functions usbg_allocate_function() and usbg_allocate_binding() had allocated sizeof(usbg_config) instead of usbg_function and usbg_binding. ... usbg_function *f; - f = malloc(sizeof(usbg_config)); + f = malloc(sizeof(usbg_function)); Use the much safer: f = malloc(sizeof (*f)); David -- 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
libusbg - is really fork required?
Dear Matt, I have done a lot of work in libusbg. I have sent you about 80 patches, but you did not review nor merge any of them. Current code statistics in my git tree looks like: $ git blame include/usbg/usbg.h | grep Opasiak | wc -l 601 $ git blame src/usbg.c | grep Opasiak | wc -l 2032 $ git blame include/usbg/usbg.h | grep Porter | wc -l 270 $ git blame src/usbg.c | grep Porter | wc -l 355 Other statistic can be found here: https://github.com/kopasiak/libusbg I have forked the github project and created a pull request but you also didn’t answer. I have tried to contact you many times using IRC but you have not respond for over 3 months. Current situation is hard to accept. I have put a lot of effort to development of this library. I have fixed a lot of bugs which were present in version 0.0.1 and 0.1.0. Moreover I have done most of things placed by you in TODO lists and reworked API. I have also add missing remove gadget functionality what made this library usable and working. I see 3 possible solutions of this situation: 1) You become more active, review and merge all the patches and participate in further development 2) You will provide me RW access to libusbg github account what determines that I will become maintainer/submaintainer of this project and merge those patches and continue development 3) If you will still ignore my patches, emails and IRC messages I will have to announce that project is dead and maintainer is unresponsive. Project will be forked and development will be continued in other repository. Please make a decision what should be the future of this project. Of course I'm also opened for other solutions if you have some good ideas. I hope that fork will not be necessary. -- BR's Krzysztof Opasiak Samsung RD Institute Poland Samsung Electronics -- 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: [GIT PULL] USB patches for 3.15-rc1
Hi, On Wednesday 02 April 2014 11:12 AM, Loc Ho wrote: Hi, USB patches for 3.15-rc1 Here's the big USB pull request for 3.15-rc1. Hmm. I'm getting this when testing: warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct dependencies (HAS_IOMEM OF (ARM64 || COMPILE_TEST)) which looks like AHCI_XGENE doesn't have the proper dependency on OF (or alternatively PHY_XGENE has an incorrect dependemcy on OF). According to google it looks like Fengguang reported this on kbuild-all, but nowhere else. The actual build then succeeds. But the Kconfig warning is real and implies that something is seriously wrong wrt the dependencies for this thing. It looks like the select PHY_XGENE came in through the libata update, but this USB update actually brought in the config PHY_XGENE and thus this error. Which makes me wonder how this all worked. Why does that select PHY_XGENE exist when apparently it's not needed? Regardless, there's something broken somewhere. Odd, I don't know what to do to fix this up properly. Loc Ho, this came in from your patch, any ideas? Shouldn't we let the users to enable PHY_XGENE (maybe add in the platform defconfig)? Thanks Kishon -- 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/5] libusbg: Fix wrong malloc sizes in allocate functions.
-Original Message- From: David Laight [mailto:david.lai...@aculab.com] Sent: Wednesday, April 02, 2014 3:03 PM To: Krzysztof Opasiak; mpor...@linaro.org; linux- u...@vger.kernel.org Cc: Andrzej Pietrasiewicz; Karol Lewandowski; Stanislaw Wadas; ty317@samsung.com; Marek Szyprowski; Robert Baldyga Subject: RE: [PATCH 2/5] libusbg: Fix wrong malloc sizes in allocate functions. From: Krzysztof Opasiak Functions usbg_allocate_function() and usbg_allocate_binding() had allocated sizeof(usbg_config) instead of usbg_function and usbg_binding. ... usbg_function *f; - f = malloc(sizeof(usbg_config)); + f = malloc(sizeof(usbg_function)); Use the much safer: f = malloc(sizeof (*f)); Really good idea. Will be changed in v2. -- BR's Krzysiek -- 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] libusbg: Replace usage of function name with type and instance.
From: Opasiak User of library should not use directly function name but only type of the function and name of instance. Using this will separate user for naming convention on Config FS. Personally I'd have thought it much better to pass in a string name rather than a function number. Far less scope for stupid errors. You probably still want to check that the name passed is one of the expected names. David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with resume after s2ram
On Tue, 1 Apr 2014, Peter Münster wrote:
On Tue, Apr 01 2014, Alan Stern wrote:
Also, I'd like to track down the problem when both devices are plugged
into front ports. Can you try that as well, again without the new
diagnostic patch? If the problem in this case is caused by a separate
bug then we may not learn anything, but it's worth a try.
Another thing I'd like to figure out is why 3.9 works okay when
CONFIG_USB_SUSPEND is disabled.
Below is 0aa2832dd0d9d860 back-ported to 3.9. Please try testing a 3.9
kernel with this patch installed (and also the first diagnostic patch,
if it applies with no errors), with CONFIG_USB_SUSPEND _enabled_ and
the mouse plugged into the rear port.
If this combination works, then maybe you can do yet another
git-bisect. Search between 3.9 and 0aa2832dd0d9d860, and at each step
merge this patch into the kernel you are testing before you build it.
Alan Stern
Index: 3.9/drivers/usb/core/hub.c
===
--- 3.9.orig/drivers/usb/core/hub.c
+++ 3.9/drivers/usb/core/hub.c
@@ -2880,9 +2880,11 @@ static int usb_disable_function_remotewa
* Linux (2.6) currently has NO mechanisms to initiate that: no khubd
* timer, no SRP, no requests through sysfs.
*
- * If CONFIG_USB_SUSPEND isn't enabled, devices only really suspend when
- * the root hub for their bus goes into global suspend ... so we don't
- * (falsely) update the device power state to say it suspended.
+ * If CONFIG_USB_SUSPEND isn't enabled, non-SuperSpeed devices really get
+ * suspended only when their bus goes into global suspend (i.e., the root
+ * hub is suspended). Nevertheless, we change @udev-state to
+ * USB_STATE_SUSPENDED as this is the device's logical state. The actual
+ * upstream port setting is stored in @udev-port_is_suspended.
*
* Returns 0 on success, else negative errno.
*/
@@ -2893,6 +2895,7 @@ int usb_port_suspend(struct usb_device *
enum pm_qos_flags_status pm_qos_stat;
int port1 = udev-portnum;
int status;
+ boolreally_suspend = true;
/* enable remote wakeup when appropriate; this lets the device
* wake up the upstream hub (including maybe the root hub).
@@ -2949,9 +2952,19 @@ int usb_port_suspend(struct usb_device *
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
- else
+ else if (PMSG_IS_AUTO(msg))
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
+ /*
+* For system suspend, we do not need to enable the suspend feature
+* on individual USB-2 ports. The devices will automatically go
+* into suspend a few ms after the root hub stops sending packets.
+* The USB 2.0 spec calls this global suspend.
+*/
+ else {
+ really_suspend = false;
+ status = 0;
+ }
if (status) {
dev_dbg(hub-intfdev, can't suspend port %d, status %d\n,
port1, status);
@@ -2987,8 +3000,10 @@ int usb_port_suspend(struct usb_device *
(PMSG_IS_AUTO(msg) ? auto- : ),
udev-do_remote_wakeup);
usb_set_device_state(udev, USB_STATE_SUSPENDED);
- udev-port_is_suspended = 1;
- msleep(10);
+ if (really_suspend) {
+ udev-port_is_suspended = 1;
+ msleep(10);
+ }
}
/*
--
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/3] USB: musb: add reset hook to platform ops
On 04/02/2014 02:12 PM, Sergei Shtylyov wrote:
On 02-04-2014 15:58, Daniel Mack wrote:
+static inline void musb_platform_reset(struct musb *musb)
+{
+if (musb-ops-reset)
+musb-ops-reset(musb);
+}
+
I think this patch should be merged with the patch #2. It's not good that
you add a function that's not called yet.
Well, that's common practice in the kernel I'd say in order to keep the
changes small. But it's a matter of maintainer's taste after all, so if
Felipe wants me to, I can easily squash the two together.
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 4/5] libusbg: Replace usage of function name with type and instance.
-Original Message- From: David Laight [mailto:david.lai...@aculab.com] Sent: Wednesday, April 02, 2014 3:09 PM To: Krzysztof Opasiak; mpor...@linaro.org; linux- u...@vger.kernel.org Cc: Andrzej Pietrasiewicz; Karol Lewandowski; Stanislaw Wadas; ty317@samsung.com; Marek Szyprowski; Robert Baldyga Subject: RE: [PATCH 4/5] libusbg: Replace usage of function name with type and instance. From: Opasiak User of library should not use directly function name but only type of the function and name of instance. Using this will separate user for naming convention on Config FS. Personally I'd have thought it much better to pass in a string name rather than a function number. Far less scope for stupid errors. You probably still want to check that the name passed is one of the expected names. In my opinion both approach are considerable. Currently function type is represented in library using usbg_function_type enum. This approach also has some advantages, you can simply iterate over function types and checking the correctness of parameter is far faster and simpler than checking if provided string is one of correct function type. Moreover operating on enum is easier for API user than operating on string, think about copying, passing to function, memory allocation etc. Of course we could provide array of function names and users could use cons char* pointer but I don't see any advantages in using such pointer instead of enum. Moreover, I'm not a fan of writing few times the same string because compiler will not notify you about typos. If you make a typo in enum value name (and there is no other enum value with such name) you will get compilation error. When you will use acm string and make a typo amc you won't get any errors or even warnings. BR's Krzysiek -- 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: libusbg - is really fork required?
On Wed, Apr 02, 2014 at 03:05:03PM +0200, Krzysztof Opasiak wrote: Dear Matt, I have done a lot of work in libusbg. I have sent you about 80 patches, but you did not review nor merge any of them. Current code statistics in my git tree looks like: $ git blame include/usbg/usbg.h | grep Opasiak | wc -l 601 $ git blame src/usbg.c | grep Opasiak | wc -l 2032 $ git blame include/usbg/usbg.h | grep Porter | wc -l 270 $ git blame src/usbg.c | grep Porter | wc -l 355 Other statistic can be found here: https://github.com/kopasiak/libusbg I have forked the github project and created a pull request but you also didn��t answer. I have tried to contact you many times using IRC but you have not respond for over 3 months. Current situation is hard to accept. Yes, I apologize for the situation, we can fix it now. First, the work is great. I've caught up on everything but the last series and will apply it all now. I don't want you to give up on this or have the idea that I don't value your participation in this..and frankly, you've taken this a long way already. So, see my comment on the pull request. I'm prepared to merge all of this except the last series libusbg: Add remove gadget/config/func/binding functionality as that still needs some thought as far as changing the API wrt to function names use. Let's start there and get caught up to the present. 1) You become more active, review and merge all the patches and participate in further development I'm finally starting to do that now. ;) 2) You will provide me RW access to libusbg github account what determines that I will become maintainer/submaintainer of this project and merge those patches and continue development After we do merge the updated pull request I plan to add you as a co-maintainer with RW access to the github tree. We'll update the docs to reflect that. Thanks for your persistence here. Regards, Matt -- 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 RESEND 4/4] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
On 04/02/2014 02:41 PM, Alexander Gordeev wrote: On Tue, Mar 25, 2014 at 03:27:30PM +0100, Alexander Gordeev wrote: On Thu, Mar 06, 2014 at 01:56:46PM -0800, Sarah Sharp wrote: What do you mean by this sentence? Are you fixing some bug in those two functions, or just cleaning up how they look? Either way, this should really be two patches. Hi Sarah, Any feedback on v2? Hi Thanks for the patches, I'll queue patch 2/2 for usb-linus once 3.15-rc1 comes out. But I'm going to omit patch 1/2 because it doesn't really improve code readability and doesn't change functionality. At this stage I'd like to avoid extra patches as much as possible. And besides, it adds one extra line of code -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] libusbg: Replace usage of function name with type and instance.
On Wed, Apr 02, 2014 at 03:34:55PM +0200, Krzysztof Opasiak wrote: -Original Message- From: David Laight [mailto:david.lai...@aculab.com] Sent: Wednesday, April 02, 2014 3:09 PM To: Krzysztof Opasiak; mpor...@linaro.org; linux- u...@vger.kernel.org Cc: Andrzej Pietrasiewicz; Karol Lewandowski; Stanislaw Wadas; ty317@samsung.com; Marek Szyprowski; Robert Baldyga Subject: RE: [PATCH 4/5] libusbg: Replace usage of function name with type and instance. From: Opasiak User of library should not use directly function name but only type of the function and name of instance. Using this will separate user for naming convention on Config FS. Personally I'd have thought it much better to pass in a string name rather than a function number. Far less scope for stupid errors. You probably still want to check that the name passed is one of the expected names. In my opinion both approach are considerable. Currently function type is represented in library using usbg_function_type enum. This approach also has some advantages, you can simply iterate over function types and checking the correctness of parameter is far faster and simpler than checking if provided string is one of correct function type. Moreover operating on enum is easier for API user than operating on string, think about copying, passing to function, memory allocation etc. Of course we could provide array of function names and users could use cons char* pointer but I don't see any advantages in using such pointer instead of enum. Moreover, I'm not a fan of writing few times the same string because compiler will not notify you about typos. If you make a typo in enum value name (and there is no other enum value with such name) you will get compilation error. When you will use acm string and make a typo amc you won't get any errors or even warnings. This was the whole point of having the enumed function types in the first place, allow the compiler to help us find errors. So yes, I agree, don't go down the path of passing in a string. There's other subtle string naming requirements in the gadget configfs API that ultimately we should hide. Like the requirement on the gadget instance string or the syntax for configuration instances, for example. -Matt -- 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] phy: don't return error from the stubs
On Wed, Apr 02, 2014 at 03:25:43PM +0300, Heikki Krogerus wrote: Returning 0 from the stubs for the functions that are used for PHY controlling. The interface should not appear to be failing with every operation when the framework is not enabled. This fixes an issue in dwc3 driver, where the driver fails the moment first phy_*() call is made when the framework is not enabled. Reported-by: Chew, Chiau Ee chiau.ee.c...@intel.com Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com Yeah, I'll ack this one because for platforms who really don't need to SW control a PHY, we need at least *one* way of not depending on it. Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] USB patches for 3.15-rc1
Hi, On Wednesday, April 02, 2014 06:36:13 PM Kishon Vijay Abraham I wrote: Hi, On Wednesday 02 April 2014 11:12 AM, Loc Ho wrote: Hi, USB patches for 3.15-rc1 Here's the big USB pull request for 3.15-rc1. Hmm. I'm getting this when testing: warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct dependencies (HAS_IOMEM OF (ARM64 || COMPILE_TEST)) which looks like AHCI_XGENE doesn't have the proper dependency on OF (or alternatively PHY_XGENE has an incorrect dependemcy on OF). According to google it looks like Fengguang reported this on kbuild-all, but nowhere else. The actual build then succeeds. But the Kconfig warning is real and implies that something is seriously wrong wrt the dependencies for this thing. It looks like the select PHY_XGENE came in through the libata update, but this USB update actually brought in the config PHY_XGENE and thus this error. Which makes me wonder how this all worked. Why does that select PHY_XGENE exist when apparently it's not needed? Regardless, there's something broken somewhere. Odd, I don't know what to do to fix this up properly. Loc Ho, this came in from your patch, any ideas? Shouldn't we let the users to enable PHY_XGENE (maybe add in the platform defconfig)? The idea that PHY drivers have to be explicitly enabled to make other drivers work doesn't sound very attractive. I would prefer to go with Loc's idea of dropping COMPILE_TEST dependency and making the AHCI_XGENE driver available only on ARM64. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] u_ether: move hardware transmit to RX workqueue
W dniu 02.04.2014 16:39, clanlab.proj pisze: Hi Andrzej, My device supports rndis only and the platform was beased on Android. Sorry I cannot test with the behavior like what you've did. Could you provide the board information to me and maybe I can trying to get one? It's a board with an s5pc110 chip. Btw, when I tested g_ether gadget by enable/disable from Android UI it looks all fine. Are you using it as a loadable module, or compiled-in? Does Android UI really control g_ether? Or perhaps it controls android gadget, which is a different thing than g_ether? Android gadget is not in mainline kernel. Sorry I cannot test the plug/un-plug behavior for you. What I imagine is that you have a (development) board with an ARM and an UDC (OTG) chip, and you connect the board to a PC host. So it should be possible to detach the cable and attach it again, shouldn't it? I'll try to figure out if it can be fixed or improved by code reviewing. It looks like eth_stop should be called somewhere when the gadget is unplugged. But as it is now it is called only when g_ether module is unloaded. AP -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel 3.13, Eaton 5E 1500i UPS and usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -110
Hello Alan, thanks for Your reply. under both 3.10 and 3.13 kernels, I only get it just got a bit more complicated.. we've found, it randomly sometimes works, sometimes not on all those kernels (3.10, 3.13, 3.14), so it's not that on =3.13 it doesn't work and for 3.14 it works. I'll try to gather some debug info on failing cases and report further.. nik [Apr 1 10:56] usb 2-1.1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -110 Error code -110 is -ETIMEDOUT. I don't know why a command would time out under one kernel but not another. under 3.14 it works. However I'd really love to get this working under 3.10.x kernel, so my idea was to backport needed fixes/patches to 3.10 (possibly getting them to -stable if appropriate). I don't see any obvious patches in git to try, so I was wandering, maybe somebody could give me a hint on what to check? It's pretty hard to say without more information. For example, usbmon traces under 3.13 and 3.14 would be a good start. It might also help to see a kernel log with CONFIG_USB_DEBUG enabled. or is this all nonsense? Instead of trying to backport patches, why not just upgrade the whole kernel? 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 -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28.rijna 168, 709 00 Ostrava tel.: +420 591 166 214 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - pgp3dspFaucw7.pgp Description: PGP signature
AW: BUG: Kernel Panic: skb_over_panic with am335 - musb - ax88760
Hi, thanks for the quick Answer, The other cpsw's are also occupied for other uses. I had a meeting with my customer yesterday and we hopefully found another solution using a VLAN-Routing, so we only need the two CPSWs. But because I've the AX88760 here, I try to give more information on this bug next week to get it fixed although we don't need it any more. Best Regards Pascal Speck -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Felipe Balbi Gesendet: Montag, 31. März 2014 16:57 An: Iktek Cc: ba...@ti.com; linux-usb@vger.kernel.org Betreff: Re: BUG: Kernel Panic: skb_over_panic with am335 - musb - ax88760 Hi, (please always keep linux-usb@vger.kernel.org in cc) On Mon, Mar 31, 2014 at 11:05:23AM +0200, Iktek wrote: im not very familiar with reporting Bugs, this is my first Try, so please be indulgent to me, when I do something wrong. I hope, Im thinking on all Information you need and I have the right person. I dont really know if the problem is sourced on musb or the ASIX driver. The error is reproducible every time I start the system over NFS and I have the possibility to debug into the kernel within KGDB, but at this moment I dont know the structure of musb networking, so I dont know where to start debugging. Could you please give me a fast answer, if Im right on this way telling you if you want dedicated support you shouldn't be depending on a mailing list giving you *free* advice. the bug or if I should try something else and provide more information. I really need this working driver for a very time-critical project of one of my customers and Im willing to work on a fix if you tell me how. what is your customer doing and why can't s/he use the internal ethernet controller from AM335x ? There are two CPSW ports in that device. I have the following Problem: When booting the Linux Kernel with the following constellation: AM335 -MUSB - AX88760 over NFS I get the following Output: [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.14.0-rc7+ (root@ThinkPad) (gcc version 4.7.3 (Buildroot 2013.11) ) #19 Sun Mar 30 18:55:05 CEST 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI AM335x BeagleBone [0.00] cma: CMA: reserved 16 MiB at 9f00 [0.00] Memory policy: Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES2.0 (sgx neon ) [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs rw nfsroot=192.168.30.235:/srv/root nolock rsize=4096 wsize=4096 ip=192.168.30.236:192.168.30.235:192.168.30.2:255.255.255.0:Xenon:eth1 :off kgdbwait kgdboc=ttyO0,115200 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] allocated 1048576 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 493272K/524288K available (6076K kernel code, 391K rwdata, 1832K rodata, 191K init, 422K bss, 31016K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] .text : 0xc0008000 - 0xc07c14ac (7910 kB) [0.00] .init : 0xc07c2000 - 0xc07f1d24 ( 192 kB) [0.00] .data : 0xc07f2000 - 0xc0853e60 ( 392 kB) [0.00].bss : 0xc0853e60 - 0xc08bd878 ( 423 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: timer2 at 2400 Hz [0.09] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns [0.26] OMAP clocksource: timer1 at 2400 Hz [0.000200] Console: colour dummy device 80x30 [0.000226] Calibrating delay loop... 996.14
Re: BUG: Kernel Panic: skb_over_panic with am335 - musb - ax88760
Hi, A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Apr 02, 2014 at 05:29:36PM +0200, Pascal Speck wrote: Hi, thanks for the quick Answer, The other cpsw's are also occupied for other uses. I had a meeting with my customer yesterday and we hopefully found another solution using a VLAN-Routing, so we only need the two CPSWs. But because I've the AX88760 here, I try to give more information on this bug next week to get it fixed although we don't need it any more. Alright, please fix your email client to follow our netiquette. There are hints for numerous email clients on Documentation/email-clients.txt cheers -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] USB patches for 3.15-rc1
Hi, USB patches for 3.15-rc1 Here's the big USB pull request for 3.15-rc1. Hmm. I'm getting this when testing: warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct dependencies (HAS_IOMEM OF (ARM64 || COMPILE_TEST)) which looks like AHCI_XGENE doesn't have the proper dependency on OF (or alternatively PHY_XGENE has an incorrect dependemcy on OF). According to google it looks like Fengguang reported this on kbuild-all, but nowhere else. The actual build then succeeds. But the Kconfig warning is real and implies that something is seriously wrong wrt the dependencies for this thing. It looks like the select PHY_XGENE came in through the libata update, but this USB update actually brought in the config PHY_XGENE and thus this error. Which makes me wonder how this all worked. Why does that select PHY_XGENE exist when apparently it's not needed? Regardless, there's something broken somewhere. Odd, I don't know what to do to fix this up properly. Loc Ho, this came in from your patch, any ideas? Shouldn't we let the users to enable PHY_XGENE (maybe add in the platform defconfig)? This is another option but PHY_XGENE is required by AHCI_XGENE . If one selects AHCI_XGENE, it should select its dependency. -Loc -- 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 libata/for-3.15-fixes] libata: drop COMPILE_TEST from AHCI_XGENE
On Wed, Apr 02, 2014 at 11:53:57AM -0400, Tejun Heo wrote: config AHCI_XGENE tristate APM X-Gene 6.0Gbps AHCI SATA host controller support - depends on ARM64 || COMPILE_TEST + depends on ARM64 select PHY_XGENE So, an alternative would be doing select PHY_XGENE if ARM64 butI don't think it'd be worthwhile to go above and beyond for COMPILE_TEST and it might cause other linkage issues down the road. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: When the platform initialization fails due to missing resources, it will return -EPROBE_DEFER after dsps_musb_init() has been called. dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs nodes. At a later point in time, the probe will be retried, and dsps_musb_dbg_init() will be called again. debugfs_create_dir() will fail this time, as the node already exists, and so the entire device probe will fail with -ENOMEM. Fix this by moving debugfs_remove_recursive() from dsps_remove() to the plaform's exit function, so it will be cleanly torn down when the probe fails. It also feels more natural this way, as .exit is the counterpart to .init. Signed-off-by: Daniel Mack zon...@gmail.com --- Only the current 'next' branch which will be merged into 3.15 is affected. drivers/usb/musb/musb_dsps.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev-parent); del_timer_sync(glue-timer); - usb_phy_shutdown(musb-xceiv); + debugfs_remove_recursive(glue-dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); - debugfs_remove_recursive(glue-dbgfs_root); I don't think this is the right fix. debugfs_remove_recursive is supposed to remove the directory as well. Why isn't dsps_musb_exit() called ? I can see it being called from musb_remove() - musb_shutdown() - musb_platform_exit(). Looks like the problem is elsewhere. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
On 04/02/2014 06:05 PM, Felipe Balbi wrote: On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev-parent); del_timer_sync(glue-timer); - usb_phy_shutdown(musb-xceiv); +debugfs_remove_recursive(glue-dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); -debugfs_remove_recursive(glue-dbgfs_root); I don't think this is the right fix. debugfs_remove_recursive is supposed to remove the directory as well. Why isn't dsps_musb_exit() called ? dsps_musb_exit() is called, hence my fix works :) The question is rather why dsps_remove() isn't called. For me, the fix looked obvious, as resources that are claimed in dsps_musb_init() should obviously be freed in its counterpart function, dsps_musb_exit(). For reasons of readability if not for any other :) 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 libata/for-3.15-fixes] libata: drop COMPILE_TEST from AHCI_XGENE
On Wed, Apr 02, 2014 at 11:53:57AM -0400, Tejun Heo wrote: Applied the following patch to libata/for-3.15-fixes. Thanks. --- 8 --- From 9c23f2cf7f6e107e85eef57fdf3049a93b6e157c Mon Sep 17 00:00:00 2001 From: Tejun Heo t...@kernel.org Date: Wed, 2 Apr 2014 11:47:04 -0400 AHCI_XGENE is only applicable on ARM64 but it can also be enabled for compile testing; however, AHCI_XGENE selects PHY_XGENE which has other arch specific dependencies. This leads to the following warning when enabling it on other archs for compile testing. warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct dependencies (HAS_IOMEM OF (ARM64 || COMPILE_TEST)) Let's drop COMPILE_TEST from AHCI_XGENE. Signed-off-by: Tejun Heo t...@kernel.org Reported-by: Linus Torvalds torva...@linux-foundation.org Cc: Loc Ho l...@apm.com Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com So, apparently, this isn't enough as this would allow enabling PHY_XGENE regardless of HAS_IOMEM or OF. From kconfig-language.txt, Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. We can add all the necessary dependencies to AHCI_XGENE but I think the the right thing to do is turning it into a proper dependency. Will prep another patch. Thanks. -- tejun -- 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 libata/for-3.15-fixes] libata: make AHCI_XGENE depend on PHY_XGENE
AHCI_XGENE is only applicable on ARM64 but it can also be enabled for compile testing; however, AHCI_XGENE selects PHY_XGENE which has other arch specific dependencies. This leads to the following warning when enabling it on other archs for compile testing. warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct dependencies (HAS_IOMEM OF (ARM64 || COMPILE_TEST)) Selecting a config option which itself has dependencies can easily lead to broken configurations. For now, let's just make AHCI_XGENE depend on PHY_XGENE which has all the necessary dependencies already. Signed-off-by: Tejun Heo t...@kernel.org Reported-by: Linus Torvalds torva...@linux-foundation.org Cc: Loc Ho l...@apm.com Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- drivers/ata/Kconfig |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 20e03a7..2e4da3b 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -134,8 +134,7 @@ config AHCI_SUNXI config AHCI_XGENE tristate APM X-Gene 6.0Gbps AHCI SATA host controller support - depends on ARM64 || COMPILE_TEST - select PHY_XGENE + depends on PHY_XGENE help This option enables support for APM X-Gene SoC SATA host controller. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Small bug fixes and rework of API.
Dear Matt, In this series of patch I have fixed some bugs introduced some time ago. First of it was a copy-pasta bug in functions which allocates memory and the second one was missing read of bcdDevice gadget attribute. Second part of this series contains small rework of libusbg API. In those patches I have change functions related to configuration and function. Currently when user would like to get a function, he should pass the whole name as in ConfigFS, but user should not need to know what is the naming convention of this file system. After those patches user will specify function type and instance name instead of string with file name from ConfigFS. Similar changes has been done in configuration related functions. After my changes user will have to specify only the ID (number) for configuration. Label may be omitted and library will use some default name. ID of configuration is unique so it's enough to get configuration. This series of patch depends on patches from github pull request #1. You can also find those patches in pull request #2. Please review and merge. -- BR's Krzysztof Opasiak Samsung RD Institute Poland --- Changes since v1: -replace malloc(sizeof(type_name)) with malloc(sizeof(*var)) Krzysztof Opasiak (5): libusbg: Fix missing read of bcdDevice. libusbg: Fix wrong malloc sizes in allocate functions. libusbg: Add checking for legal function type. libusbg: Replace usage of function name with type and instance. libusbg: Use config ID and label instead of config name. examples/gadget-acm-ecm.c |4 +- examples/show-gadgets.c | 29 +-- include/usbg/usbg.h | 64 --- src/usbg.c| 455 ++--- 4 files changed, 367 insertions(+), 185 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] libusbg: Add checking for legal function type.
Function type provided by user to functions should
be checked before usage to avoid errors.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
index fa8dece..34b68b5 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -283,6 +283,13 @@ static int usbg_lookup_function_type(char *name)
return i;
}
+static inline const char *usbg_get_function_type_name(
+ usbg_function_type type)
+{
+ return type 0 type sizeof(function_names)/sizeof(char *) ?
+ function_names[type] : NULL;
+}
+
static int bindings_select(const struct dirent *dent)
{
if (dent-d_type == DT_LNK)
@@ -1473,6 +1480,7 @@ int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
{
char fpath[USBG_MAX_PATH_LENGTH];
char name[USBG_MAX_PATH_LENGTH];
+ const char *type_name;
usbg_function *func;
int ret = USBG_ERROR_INVALID_PARAM;
int n, free_space;
@@ -1480,11 +1488,11 @@ int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
if (!g || !f)
return ret;
- /**
-* @todo Check for legal function type
-*/
- n = snprintf(name, sizeof(name), %s.%s,
- function_names[type], instance);
+ type_name = usbg_get_function_type_name(type);
+ if (!type_name)
+ goto out;
+
+ n = snprintf(name, sizeof(name), %s.%s, type_name, instance);
if (n = sizeof(name)) {
ret = USBG_ERROR_PATH_TOO_LONG;
goto out;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] libusbg: Fix missing read of bcdDevice.
Value of bcdDevice has been never read from Config FS and this field was leaved uninitialized. Change usbg_parse_gadget_attrs() to read also from this file. Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com --- src/usbg.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/src/usbg.c b/src/usbg.c index be83407..e472463 100644 --- a/src/usbg.c +++ b/src/usbg.c @@ -844,6 +844,12 @@ static int usbg_parse_gadget_attrs(char *path, char *name, else goto out; + ret = usbg_read_hex(path, name, bcdDevice, buf); + if (ret == USBG_SUCCESS) + g_attrs-bcdDevice = (uint16_t) buf; + else + goto out; + ret = usbg_read_hex(path, name, bDeviceClass, buf); if (ret == USBG_SUCCESS) g_attrs-bDeviceClass = (uint8_t)buf; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] libusbg: Replace usage of function name with type and instance.
User of library should not use directly function name but
only type of the function and name of instance. Using this
will separate user for naming convention on Config FS.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
examples/show-gadgets.c | 20 ++--
include/usbg/usbg.h | 29 --
src/usbg.c | 239 ++-
3 files changed, 184 insertions(+), 104 deletions(-)
diff --git a/examples/show-gadgets.c b/examples/show-gadgets.c
index df86cb9..971beb4 100644
--- a/examples/show-gadgets.c
+++ b/examples/show-gadgets.c
@@ -70,11 +70,13 @@ void show_gadget(usbg_gadget *g)
void show_function(usbg_function *f)
{
- char buf[USBG_MAX_STR_LENGTH];
+ char instance[USBG_MAX_STR_LENGTH];
+ usbg_function_type type;
int usbg_ret;
usbg_function_attrs f_attrs;
- usbg_get_function_name(f, buf, USBG_MAX_STR_LENGTH);
+ usbg_get_function_instance(f, instance, USBG_MAX_STR_LENGTH);
+ type = usbg_get_function_type(f);
usbg_ret = usbg_get_function_attrs(f, f_attrs);
if (usbg_ret != USBG_SUCCESS) {
fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
@@ -82,8 +84,9 @@ void show_function(usbg_function *f)
return;
}
- fprintf(stdout, Function '%s'\n, buf);
- switch (usbg_get_function_type(f)) {
+ fprintf(stdout, Function, type: %s instance: %s\n,
+ usbg_get_function_type_str(type), instance);
+ switch (type) {
case F_SERIAL:
case F_ACM:
case F_OBEX:
@@ -114,7 +117,8 @@ void show_config(usbg_config *c)
{
usbg_binding *b;
usbg_function *f;
- char buf[USBG_MAX_STR_LENGTH], buf2[USBG_MAX_STR_LENGTH];
+ char buf[USBG_MAX_STR_LENGTH], instance[USBG_MAX_STR_LENGTH];
+ usbg_function_type type;
usbg_config_attrs c_attrs;
usbg_config_strs c_strs;
int usbg_ret;
@@ -144,8 +148,10 @@ void show_config(usbg_config *c)
usbg_for_each_binding(b, c) {
usbg_get_binding_name(b, buf, USBG_MAX_STR_LENGTH);
f = usbg_get_binding_target(b);
- usbg_get_function_name(f, buf2, USBG_MAX_STR_LENGTH);
- fprintf(stdout, %s - %s\n, buf, buf2);
+ usbg_get_function_instance(f, instance, USBG_MAX_STR_LENGTH);
+ type = usbg_get_function_type(f);
+ fprintf(stdout, %s - %s %s\n, buf,
+ usbg_get_function_type_str(type), instance);
}
}
diff --git a/include/usbg/usbg.h b/include/usbg/usbg.h
index b496787..fadbe07 100644
--- a/include/usbg/usbg.h
+++ b/include/usbg/usbg.h
@@ -256,10 +256,12 @@ extern usbg_gadget *usbg_get_gadget(usbg_state *s, const
char *name);
/**
* @brief Get a function by name
* @param g Pointer to gadget
- * @param name Name of the function
+ * @param type Function type
+ * @param instance Instance of function
* @return Pointer to function or NULL if a matching function isn't found
*/
-extern usbg_function *usbg_get_function(usbg_gadget *g, const char *name);
+extern usbg_function *usbg_get_function(usbg_gadget *g,
+ usbg_function_type type, const char *instance);
/**
* @brief Get a configuration by name
@@ -462,20 +464,27 @@ extern int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
char *instance, usbg_function_attrs *f_attrs, usbg_function
**f);
/**
- * @brief Get function name length
- * @param f Config which name length should be returned
+ * @brief Get function instance name length
+ * @param f function which name length should be returned
* @return Length of name string or usbg_error if error occurred.
*/
-extern size_t usbg_get_function_name_len(usbg_function *f);
+extern size_t usbg_get_function_instance_len(usbg_function *f);
/**
- * @brieg Get config name
+ * @brief Get function instance name
* @param f Pointer to function
- * @param buf Buffer where name should be copied
+ * @param buf Buffer where instance name should be copied
* @param len Length of given buffer
* @return 0 on success or usbg_error if error occurred.
*/
-extern int usbg_get_function_name(usbg_function *f, char *buf, size_t len);
+extern int usbg_get_function_instance(usbg_function *f, char *buf, size_t len);
+
+/**
+ * @brief Get function type as a string
+ * @param type Function type
+ * @return String suitable for given function type
+ */
+extern const char *usbg_get_function_type_str(usbg_function_type type);
/* USB configurations allocation and configuration */
@@ -651,8 +660,8 @@ extern int usbg_get_gadget_udc(usbg_gadget *g, char *buf,
size_t len);
/**
* @brief Get type of given function
* @param f Pointer to function
- * @return Type of function
- * @warning Pointer to function has to be valid.
+ * @return usbg_function_type (0 or above) or
+ * usbg_error (below 0) if error occurred
*/
extern
[PATCH v2 5/5] libusbg: Use config ID and label instead of config name.
Naming convention of Config FS should not be exposed
to user of library. All API functions should use
configuration ID (configuration number) as unique
identificator and configuration label as human
readable description.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
examples/gadget-acm-ecm.c |4 +-
examples/show-gadgets.c |9 +-
include/usbg/usbg.h | 35 +---
src/usbg.c| 200 +++--
4 files changed, 168 insertions(+), 80 deletions(-)
diff --git a/examples/gadget-acm-ecm.c b/examples/gadget-acm-ecm.c
index 8eb4aeb..7a8b71b 100644
--- a/examples/gadget-acm-ecm.c
+++ b/examples/gadget-acm-ecm.c
@@ -97,8 +97,8 @@ int main(void)
goto out2;
}
- usbg_ret = usbg_create_config(g, c.1, NULL /* use defaults */,
c_strs,
- c);
+ usbg_ret = usbg_create_config(g, 1, The only one,
+ NULL /* use defaults */, c_strs, c);
if (usbg_ret != USBG_SUCCESS) {
fprintf(stderr, Error creating config\n);
fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
diff --git a/examples/show-gadgets.c b/examples/show-gadgets.c
index 971beb4..1ae3860 100644
--- a/examples/show-gadgets.c
+++ b/examples/show-gadgets.c
@@ -57,7 +57,7 @@ void show_gadget(usbg_gadget *g)
fprintf(stdout, idVendor\t\t0x%04x\n, g_attrs.idVendor);
fprintf(stdout, idProduct\t\t0x%04x\n, g_attrs.idProduct);
- usbg_get_gadget_strs(g, LANG_US_ENG, g_strs);
+ usbg_ret = usbg_get_gadget_strs(g, LANG_US_ENG, g_strs);
if (usbg_ret != USBG_SUCCESS) {
fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
usbg_strerror(usbg_ret));
@@ -121,10 +121,11 @@ void show_config(usbg_config *c)
usbg_function_type type;
usbg_config_attrs c_attrs;
usbg_config_strs c_strs;
- int usbg_ret;
+ int usbg_ret, id;
- usbg_get_config_name(c, buf, USBG_MAX_STR_LENGTH);
- fprintf(stdout, Configuration '%s'\n, buf);
+ usbg_get_config_label(c, buf, USBG_MAX_STR_LENGTH);
+ id = usbg_get_config_id(c);
+ fprintf(stdout, Configuration: '%s' ID: %d\n, buf, id);
usbg_ret = usbg_get_config_attrs(c, c_attrs);
if (usbg_ret != USBG_SUCCESS) {
diff --git a/include/usbg/usbg.h b/include/usbg/usbg.h
index fadbe07..1407f10 100644
--- a/include/usbg/usbg.h
+++ b/include/usbg/usbg.h
@@ -37,6 +37,7 @@
#define DEFAULT_UDCNULL
#define LANG_US_ENG0x0409
+#define DEFAULT_CONFIG_LABEL config
#define USBG_MAX_STR_LENGTH 256
#define USBG_MAX_PATH_LENGTH PATH_MAX
@@ -266,10 +267,14 @@ extern usbg_function *usbg_get_function(usbg_gadget *g,
/**
* @brief Get a configuration by name
* @param g Pointer to gadget
- * @param name Name of the configuration
+ * @param id Identify of configuration
+ * @param label Configuration label. If not NULL this function will return
+ * valid value only if configuration with given id exist and has this label.
+ * If NULL this function will return config with given id (if such exist)
+ * and ignore this param.
* @return Pointer to config or NULL if a matching config isn't found
*/
-extern usbg_config *usbg_get_config(usbg_gadget *g, const char *name);
+extern usbg_config *usbg_get_config(usbg_gadget *g, int id, const char *label);
/* USB gadget allocation and configuration */
@@ -491,31 +496,39 @@ extern const char
*usbg_get_function_type_str(usbg_function_type type);
/**
* @brief Create a new USB gadget configuration
* @param g Pointer to gadget
- * @param name Name of configuration
+ * @param id Identify of configuration
+ * @param label configuration label, if NULL, default is used
* @param c_attrs Configuration attributes to be set
* @param c_strs Configuration strings to be set
* @param c Pointer to be filled with pointer to configuration
* @note Given strings are assumed to be in US English
* @return 0 on success usbg_error if error occurred
*/
-extern int usbg_create_config(usbg_gadget *g, char *name,
+extern int usbg_create_config(usbg_gadget *g, int id, const char *label,
usbg_config_attrs *c_attrs, usbg_config_strs *c_strs,
usbg_config **c);
/**
- * @brief Get config name length
- * @param c Config which name length should be returned
- * @return Length of name string or usbg_error if error occurred.
+ * @brief Get config label length
+ * @param c Config which label length should be returned
+ * @return Length of label or usbg_error if error occurred.
*/
-extern size_t usbg_get_config_name_len(usbg_config *c);
+extern size_t usbg_get_config_label_len(usbg_config *c);
/**
- * @brieg Get config name
+ * @brieg Get config label
* @param c Pointer to config
- * @param buf Buffer where name should be copied
+ * @param buf Buffer where label should be copied
* @param len Length of given buffer
*
[PATCH v2 2/5] libusbg: Fix wrong malloc sizes in allocate functions.
Functions usbg_allocate_function() and usbg_allocate_binding()
had allocated sizeof(usbg_config) instead of usbg_function
and usbg_binding.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
index e472463..fa8dece 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -482,7 +482,7 @@ static usbg_gadget *usbg_allocate_gadget(char *path, char
*name,
{
usbg_gadget *g;
- g = malloc(sizeof(usbg_gadget));
+ g = malloc(sizeof(*g));
if (g) {
TAILQ_INIT(g-functions);
TAILQ_INIT(g-configs);
@@ -506,7 +506,7 @@ static usbg_config *usbg_allocate_config(char *path, char
*name,
{
usbg_config *c;
- c = malloc(sizeof(usbg_config));
+ c = malloc(sizeof(*c));
if (c) {
TAILQ_INIT(c-bindings);
c-name = strdup(name);
@@ -529,7 +529,7 @@ static usbg_function *usbg_allocate_function(char *path,
char *name,
{
usbg_function *f;
- f = malloc(sizeof(usbg_config));
+ f = malloc(sizeof(*f));
if (f) {
f-name = strdup(name);
f-path = strdup(path);
@@ -551,7 +551,7 @@ static usbg_binding *usbg_allocate_binding(char *path, char
*name,
{
usbg_binding *b;
- b = malloc(sizeof(usbg_config));
+ b = malloc(sizeof(*b));
if (b) {
b-name = strdup(name);
b-path = strdup(path);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][next] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote: Hi, On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote: On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote: This fixes a regression on Keystone 2 platforms caused by patch 57303488cd37da58263e842de134dc65f7c626d5 usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds optional support of generic phy in DWC3 core. On Keystone 2 platforms the USB is not working now because CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs return -ENOSYS always. The log shows: dwc3 269.dwc3: failed to initialize core dwc3: probe of 269.dwc3 failed with error -38 Hence, fix it by making NULL a valid phy reference in Generic PHY APIs stubs in the same way as it was done by the patch 04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL a valid phy reference. CC: Kishon Vijay Abraham I kis...@ti.com CC: Felipe Balbi ba...@ti.com CC: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com nice :-) Acked-by: Felipe Balbi ba...@ti.com Greg, if your tree isn't closed yet, could you consider this patch still for v3.15 merge window ? Grygorii found a regression on Keystone platforms which this patch fixes. Let me know if you need the original patch and myself or Kishon can send it to you. Just checking whether the fix was picked up for the 3.14 merge window ? Regards, Santosh -- 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: libusbg - is really fork required?
-Original Message- From: Matt Porter [mailto:mpor...@linaro.org] Sent: Wednesday, April 02, 2014 3:45 PM To: Krzysztof Opasiak Yes, I apologize for the situation, we can fix it now. First, the work is great. I've caught up on everything but the last series and will apply it all now. I don't want you to give up on this or have the idea that I don't value your participation in this..and frankly, you've taken this a long way already. So, see my comment on the pull request. I'm prepared to merge all of this except the last series libusbg: Add remove gadget/config/func/binding functionality as that still needs some thought as far as changing the API wrt to function names use. Let's start there and get caught up to the present. Sounds reasonable to me. In my opinion a good place to start the top of my today patches [1] but without remove functionality in the tree. I have everything prepared and I suggest: 1) Merge github pull request #1 [2]. This pull request contains all patches from the list except of those which contains remove gadget/func etc functionality and without today patches: Small bug fixes and rework of API. So that are the patches with which you are up to date as you write above. 2) Review and merge pull request #2 [3]. This pull request contains 5 patches which I have sent today (v2 version). There are some important bug fixes with memory management and uninitialized variable which I think should be reviewed and merged asap to keep libusbg working correctly 3) Review and consider pull request #3 [4]. This pull request contains patches with remove functionality. I'm opened for your suggestions and waiting for your remarks about them and I hope that we can go through this quickly and after some changes it will be also reasonable to merge this. 4) I think that here will be a good place to bump version of libusbg to 0.2.0 because library will be in usable and working state. 1) You become more active, review and merge all the patches and participate in further development I'm finally starting to do that now. ;) Great looking forward for some remarks:) 2) You will provide me RW access to libusbg github account what determines that I will become maintainer/submaintainer of this project and merge those patches and continue development After we do merge the updated pull request I plan to add you as a co-maintainer with RW access to the github tree. We'll update the docs to reflect that. Thanks for your persistence here. Sounds good to me :) looking forward for merge and suitable access rights:) I hope that our future cooperation will be much more active and beneficial for this project;) Footnotes: 1 - http://marc.info/?l=linux-usbm=139646061726183w=2 2 - https://github.com/libusbg/libusbg/pull/1 3 - https://github.com/libusbg/libusbg/pull/2 4 - https://github.com/libusbg/libusbg/pull/3 -- BR's Krzysiek -- 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][next] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
On Wed, Apr 02, 2014 at 01:53:19PM -0400, Santosh Shilimkar wrote: On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote: Hi, On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote: On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote: This fixes a regression on Keystone 2 platforms caused by patch 57303488cd37da58263e842de134dc65f7c626d5 usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds optional support of generic phy in DWC3 core. On Keystone 2 platforms the USB is not working now because CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs return -ENOSYS always. The log shows: dwc3 269.dwc3: failed to initialize core dwc3: probe of 269.dwc3 failed with error -38 Hence, fix it by making NULL a valid phy reference in Generic PHY APIs stubs in the same way as it was done by the patch 04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL a valid phy reference. CC: Kishon Vijay Abraham I kis...@ti.com CC: Felipe Balbi ba...@ti.com CC: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com nice :-) Acked-by: Felipe Balbi ba...@ti.com Greg, if your tree isn't closed yet, could you consider this patch still for v3.15 merge window ? Grygorii found a regression on Keystone platforms which this patch fixes. Let me know if you need the original patch and myself or Kishon can send it to you. Just checking whether the fix was picked up for the 3.14 merge window ? 3.14 is long released, the merge window for that was months ago. 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][next] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
On Wednesday 02 April 2014 02:16 PM, Greg KH wrote: On Wed, Apr 02, 2014 at 01:53:19PM -0400, Santosh Shilimkar wrote: On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote: Hi, On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote: On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote: This fixes a regression on Keystone 2 platforms caused by patch 57303488cd37da58263e842de134dc65f7c626d5 usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds optional support of generic phy in DWC3 core. On Keystone 2 platforms the USB is not working now because CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs return -ENOSYS always. The log shows: dwc3 269.dwc3: failed to initialize core dwc3: probe of 269.dwc3 failed with error -38 Hence, fix it by making NULL a valid phy reference in Generic PHY APIs stubs in the same way as it was done by the patch 04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL a valid phy reference. CC: Kishon Vijay Abraham I kis...@ti.com CC: Felipe Balbi ba...@ti.com CC: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com nice :-) Acked-by: Felipe Balbi ba...@ti.com Greg, if your tree isn't closed yet, could you consider this patch still for v3.15 merge window ? Grygorii found a regression on Keystone platforms which this patch fixes. Let me know if you need the original patch and myself or Kishon can send it to you. Just checking whether the fix was picked up for the 3.14 merge window ? 3.14 is long released, the merge window for that was months ago. Sorry for the typo. I mean for upcoming v3.15 merge window. regards, Santosh -- 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][next] phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
On Wed, Apr 02, 2014 at 02:17:19PM -0400, Santosh Shilimkar wrote: On Wednesday 02 April 2014 02:16 PM, Greg KH wrote: On Wed, Apr 02, 2014 at 01:53:19PM -0400, Santosh Shilimkar wrote: On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote: Hi, On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote: On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote: This fixes a regression on Keystone 2 platforms caused by patch 57303488cd37da58263e842de134dc65f7c626d5 usb: dwc3: adapt dwc3 core to use Generic PHY Framework which adds optional support of generic phy in DWC3 core. On Keystone 2 platforms the USB is not working now because CONFIG_GENERIC_PHY isn't set and, as result, Generic PHY APIs stubs return -ENOSYS always. The log shows: dwc3 269.dwc3: failed to initialize core dwc3: probe of 269.dwc3 failed with error -38 Hence, fix it by making NULL a valid phy reference in Generic PHY APIs stubs in the same way as it was done by the patch 04c2facad8fee66c981a51852806d8923336f362 drivers: phy: Make NULL a valid phy reference. CC: Kishon Vijay Abraham I kis...@ti.com CC: Felipe Balbi ba...@ti.com CC: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com nice :-) Acked-by: Felipe Balbi ba...@ti.com Greg, if your tree isn't closed yet, could you consider this patch still for v3.15 merge window ? Grygorii found a regression on Keystone platforms which this patch fixes. Let me know if you need the original patch and myself or Kishon can send it to you. Just checking whether the fix was picked up for the 3.14 merge window ? 3.14 is long released, the merge window for that was months ago. Sorry for the typo. I mean for upcoming v3.15 merge window. My trees are now empty now, with everything I had for the 3.15-rc1 merge window already in Linus's tree. So I suggest looking there to see if this made it in or not. If not, be sure to resend it. 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
OOPS w/3.13.6
$ uname -a Linux hellcat 3.13.6-gentoo #1 SMP PREEMPT Tue Mar 18 15:37:31 MDT 2014 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux $ dmesg [83321.560506] usb 4-4.3.3: Failed to set U1 timeout to 0x0,error code -71 [83321.560516] BUG: unable to handle kernel NULL pointer dereference at 0010 [83321.560530] IP: [81484707] usb_enable_link_state+0x37/0x350 [83321.560539] PGD 0 [83321.560542] Oops: [#1] PREEMPT SMP [83321.560547] Modules linked in: snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek nouveau cfbfillrect cfbimgblt mxm_wmi wmi fbcon cfbcopyarea snd_hda_intel i2c_algo_bit bitblit ttm softcursor snd_hda_codec font drm_kms_helper snd_hwdep x86_pkg_temp_thermal snd_pcm drm coretemp snd_page_alloc fb snd_timer fbdev snd e1000e ptp pps_core video [83321.560601] CPU: 4 PID: 5366 Comm: usb-storage Not tainted 3.13.6-gentoo #1 [83321.560605] Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A12 01/10/2013 [83321.560609] task: 880506139a00 ti: 88045169c000 task.ti: 88045169c000 [83321.560614] RIP: 0010:[81484707] [81484707] usb_enable_link_state+0x37/0x350 [83321.560621] RSP: 0018:88045169dbf8 EFLAGS: 00010246 [83321.560624] RAX: RBX: 8805fc791800 RCX: 0001 [83321.560628] RDX: 0001 RSI: 8805fc791800 RDI: 880601322400 [83321.560632] RBP: 0001 R08: 0400 R09: 03d0 [83321.560636] R10: 0006 R11: 03cf R12: 8800de988000 [83321.560640] R13: 0003 R14: 880601322400 R15: 880601322400 [83321.560644] FS: () GS:88061dd0() knlGS: [83321.560648] CS: 0010 DS: ES: CR0: 80050033 [83321.560651] CR2: 0010 CR3: 0188f000 CR4: 001407e0 [83321.560655] Stack: [83321.560657] 81803a23 ffb9 88061dd14680 [83321.560664] 880506139a00 81483b6c 0010 8805fc791800 [83321.560675] 880601322400 8800de988000 0003 0003 [83321.560682] Call Trace: [83321.560686] [81483b6c] ? usb_set_lpm_timeout+0x12c/0x140 [83321.560691] [81484aa8] ? usb_enable_lpm+0x88/0xb0 [83321.560695] [81484bef] ? usb_disable_lpm+0xbf/0xd0 [83321.560700] [81484c2e] ? usb_unlocked_disable_lpm+0x2e/0x60 [83321.560705] [81487c53] ? usb_reset_and_verify_device+0x93/0x630 [83321.560710] [810a6fc0] ? try_to_wake_up+0x2a0/0x2a0 [83321.560715] [814882f8] ? usb_reset_device+0x108/0x180 [83321.560721] [814c3d11] ? usb_stor_port_reset+0x61/0x70 [83321.560726] [814c3d8c] ? usb_stor_invoke_transport+0x6c/0x480 [83321.560731] [814c51c5] ? usb_stor_control_thread+0x145/0x250 [83321.560736] [814c5080] ? fill_inquiry_response+0x20/0x20 [83321.560740] [814c5080] ? fill_inquiry_response+0x20/0x20 [83321.560745] [8109c73c] ? kthread+0xbc/0xe0 [83321.560750] [810a] ? create_new_namespaces+0x130/0x1a0 [83321.560756] [8109c680] ? __kthread_parkme+0x70/0x70 [83321.560760] [8167df3c] ? ret_from_fork+0x7c/0xb0 [83321.560765] [8109c680] ? __kthread_parkme+0x70/0x70 [83321.560769] Code: 48 89 6c 24 40 89 d5 4c 89 74 24 58 83 fd 01 49 89 fe 4c 89 64 24 48 0f 94 c1 4c 89 6c 24 50 4c 89 7c 24 60 48 8b 86 e0 02 00 00 48 8b 40 10 0f b7 50 08 0f 84 bb 00 00 00 83 fd 02 40 0f 94 c6 [83321.560837] RIP [81484707] usb_enable_link_state+0x37/0x350 [83321.560843] RSP 88045169dbf8 [83321.560845] CR2: 0010 [83321.568066] ---[ end trace dacc74e95425c8bf ]--- [83321.811713] usb 4-4: USB disconnect, device number 2 [83321.811717] usb 4-4.3: USB disconnect, device number 3 [83321.811728] usb 4-4.3.3: USB disconnect, device number 6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: turn phy on
Hi, On Wed, Apr 02, 2014 at 09:26:27PM +0200, Rabin Vincent wrote: 30a70b026b4cde4 (usb: musb: fix obex in g_nokia.ko causing kernel panic) broke USB gadget support on Pandaboard because it simply deletes the call to phy_power_on() and the PHY is therefore never turned on. Fix it by actually turning the phy on. Cc: sta...@vger.kernel.org Signed-off-by: Rabin Vincent ra...@rab.in --- drivers/usb/musb/musb_gadget.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index d4aa779..09d5883 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1850,6 +1850,7 @@ static int musb_gadget_start(struct usb_gadget *g, } pm_runtime_get_sync(musb-controller); + phy_power_on(musb-phy); dev_dbg(musb-controller, registering driver %s\n, driver-function); @@ -1963,6 +1964,7 @@ static int musb_gadget_stop(struct usb_gadget *g, * that currently misbehaves. */ + phy_power_off(musb-phy); hmmm... not the best place, I have been waiting for -rc1 to be out to send this version: commit e8fbe7b90021960907e885e0b7a9b52d378b0202 Author: Felipe Balbi ba...@ti.com Date: Fri Mar 28 14:31:47 2014 -0500 usb: musb: fix PHY power on/off commi 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic) removed phy_power_on() and phy_power_off() calls from runtime PM callbacks but it failed to note that the driver depended on pm_runtime_get_sync() calls to power up the PHY, thus leaving some platforms without any means to have a working PHY. Fix that by enabling the phy during omap2430_musb_init() and killing it in omap2430_musb_exit(). Fixes: 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic) Cc: sta...@vger.kernel.org # v3.14 Cc: Pali Rohár pali.ro...@gmail.com Cc: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com Reported-by: Michael Scott hashcod...@gmail.com Tested-by: Michael Scott hashcod...@gmail.com Reported-by: Rabin Vincent ra...@rab.in Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index d341c14..819a7cd 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -416,6 +416,7 @@ static int omap2430_musb_init(struct musb *musb) omap_musb_set_mailbox(glue); phy_init(musb-phy); + phy_power_on(musb-phy); pm_runtime_put_noidle(musb-controller); return 0; @@ -478,6 +479,7 @@ static int omap2430_musb_exit(struct musb *musb) del_timer_sync(musb_idle_timer); omap2430_low_level_exit(musb); + phy_power_off(musb-phy); phy_exit(musb-phy); return 0; and I'm much more inclined to send this one instead since it has been tested by other folks already. I was even going to Cc you, as you can see on that Reported-by tag. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
Hi Mathias, The patch looks fine. Mathias is taking over for xHCI driver maintainership in 3.15. He's currently handling queuing bug fix patches for 3.14 while I finish queueing feature patches for 3.15. Mathias, will you test and queue this up for 3.14? Did you pick this patch up anywhere yet or are there still issues with it? I just want to make sure it doesn't slip through the cracks. (Maybe I just didn't see it yet... are you still queueing patches in sarah/xhci.git or do you have your own repository somewhere?) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
Hi, On Wed, Apr 02, 2014 at 06:16:23PM +0200, Daniel Mack wrote: On 04/02/2014 06:05 PM, Felipe Balbi wrote: On Wed, Apr 02, 2014 at 11:46:51AM +0200, Daniel Mack wrote: diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 3372ded..e2fd263 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,8 +470,9 @@ static int dsps_musb_exit(struct musb *musb) struct dsps_glue *glue = dev_get_drvdata(dev-parent); del_timer_sync(glue-timer); - usb_phy_shutdown(musb-xceiv); + debugfs_remove_recursive(glue-dbgfs_root); + return 0; } @@ -708,8 +709,6 @@ static int dsps_remove(struct platform_device *pdev) pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); - debugfs_remove_recursive(glue-dbgfs_root); I don't think this is the right fix. debugfs_remove_recursive is supposed to remove the directory as well. Why isn't dsps_musb_exit() called ? dsps_musb_exit() is called, hence my fix works :) The question is rather why dsps_remove() isn't called. For me, the fix looked obvious, as resources that are claimed in dsps_musb_init() should obviously be freed in its counterpart function, dsps_musb_exit(). For reasons of readability if not for any other :) you're correct, for whatever reason I read it as moving the lines the other way around (from _exit() to _remove()). I'll queue this once -rc1 is tagged. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3] u_ether: move hardware transmit to RX workqueue
Hi, On Wed, Apr 02, 2014 at 05:07:28PM +0200, Andrzej Pietrasiewicz wrote: W dniu 02.04.2014 16:39, clanlab.proj pisze: Hi Andrzej, My device supports rndis only and the platform was beased on Android. Sorry I cannot test with the behavior like what you've did. Could you provide the board information to me and maybe I can trying to get one? It's a board with an s5pc110 chip. Btw, when I tested g_ether gadget by enable/disable from Android UI it looks all fine. Are you using it as a loadable module, or compiled-in? Does Android UI really control g_ether? Or perhaps it controls android gadget, which is a different thing than g_ether? Android gadget is not in mainline kernel. Sorry I cannot test the plug/un-plug behavior for you. What I imagine is that you have a (development) board with an ARM and an UDC (OTG) chip, and you connect the board to a PC host. So it should be possible to detach the cable and attach it again, shouldn't it? I'll try to figure out if it can be fixed or improved by code reviewing. It looks like eth_stop should be called somewhere when the gadget is unplugged. But as it is now it is called only when g_ether module is unloaded. well, if we don't get to a resolution for this, we will have to revert that patch once -rc1 is out. -- balbi signature.asc Description: Digital signature
RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
Hi Peter, On 04/02/2014 10:47 AM, Peter Chen wrote: We have historic problem that the gadget will not work if the gadget is build-in and the udc driver is defered probe due to some resources are not ready. Below links are related to this problem. http://marc.info/?l=linux-usbm=139380872501745w=2 http://marc.info/?l=linux-usbm=137991612311893w=2 http://marc.info/?l=linux-usbm=137706435611447w=2 This patch saves pointer of usb_gadget_driver when the udc is not ready, and redo usb_gadget_probe_driver when the udc is ready This method may not be good enough, but we need to find a way to fix this problem, so I post this RFC to see if to see comments, someone may have a better solution:) I have sent patch fixing this problem few weeks ago: http://www.spinics.net/lists/linux-usb/msg102795.html Our idea is the same, but your patch is better than me. Felipe queued this patch or not? If it is not, you may need to send v2 that return -ENODEV for not find udc to see if he has further comments, let's try to fix this problem at mainline asap. Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
