[PATCH v2] usb: gadget: serial: replace {V,}DBG macro with dev_{v,}dbg
Replace the VDBG and DBG macro with the kernels proper debug macros
(dev_vdbg and dev_dbg) in f_acm.c, f_obex.c f_serial.c
Signed-off-by: Richard Leitner richard.leit...@skidata.com
---
v2: - rebased on Linux v3.17-rc1
- fixed some PARENTHESIS_ALIGNMENT checkpatch.pl warnings
---
drivers/usb/gadget/function/f_acm.c| 49 ++--
drivers/usb/gadget/function/f_obex.c | 28 +++---
drivers/usb/gadget/function/f_serial.c | 19 +++--
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/gadget/function/f_acm.c
b/drivers/usb/gadget/function/f_acm.c
index ab1065a..6da4685 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -313,15 +313,15 @@ static void acm_complete_set_line_coding(struct usb_ep
*ep,
struct usb_composite_dev *cdev = acm-port.func.config-cdev;
if (req-status != 0) {
- DBG(cdev, acm ttyGS%d completion, err %d\n,
- acm-port_num, req-status);
+ dev_dbg(cdev-gadget-dev, acm ttyGS%d completion, err %d\n,
+ acm-port_num, req-status);
return;
}
/* normal completion */
if (req-actual != sizeof(acm-port_line_coding)) {
- DBG(cdev, acm ttyGS%d short resp, len %d\n,
- acm-port_num, req-actual);
+ dev_dbg(cdev-gadget-dev, acm ttyGS%d short resp, len %d\n,
+ acm-port_num, req-actual);
usb_ep_set_halt(ep);
} else {
struct usb_cdc_line_coding *value = req-buf;
@@ -397,14 +397,16 @@ static int acm_setup(struct usb_function *f, const struct
usb_ctrlrequest *ctrl)
default:
invalid:
- VDBG(cdev, invalid control req%02x.%02x v%04x i%04x l%d\n,
- ctrl-bRequestType, ctrl-bRequest,
- w_value, w_index, w_length);
+ dev_vdbg(cdev-gadget-dev,
+invalid control req%02x.%02x v%04x i%04x l%d\n,
+ctrl-bRequestType, ctrl-bRequest,
+w_value, w_index, w_length);
}
/* respond with data transfer or status phase? */
if (value = 0) {
- DBG(cdev, acm ttyGS%d req%02x.%02x v%04x i%04x l%d\n,
+ dev_dbg(cdev-gadget-dev,
+ acm ttyGS%d req%02x.%02x v%04x i%04x l%d\n,
acm-port_num, ctrl-bRequestType, ctrl-bRequest,
w_value, w_index, w_length);
req-zero = 0;
@@ -428,10 +430,12 @@ static int acm_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
if (intf == acm-ctrl_id) {
if (acm-notify-driver_data) {
- VDBG(cdev, reset acm control interface %d\n, intf);
+ dev_vdbg(cdev-gadget-dev,
+reset acm control interface %d\n, intf);
usb_ep_disable(acm-notify);
} else {
- VDBG(cdev, init acm ctrl interface %d\n, intf);
+ dev_vdbg(cdev-gadget-dev,
+init acm ctrl interface %d\n, intf);
if (config_ep_by_speed(cdev-gadget, f, acm-notify))
return -EINVAL;
}
@@ -440,11 +444,13 @@ static int acm_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
} else if (intf == acm-data_id) {
if (acm-port.in-driver_data) {
- DBG(cdev, reset acm ttyGS%d\n, acm-port_num);
+ dev_dbg(cdev-gadget-dev,
+ reset acm ttyGS%d\n, acm-port_num);
gserial_disconnect(acm-port);
}
if (!acm-port.in-desc || !acm-port.out-desc) {
- DBG(cdev, activate acm ttyGS%d\n, acm-port_num);
+ dev_dbg(cdev-gadget-dev,
+ activate acm ttyGS%d\n, acm-port_num);
if (config_ep_by_speed(cdev-gadget, f,
acm-port.in) ||
config_ep_by_speed(cdev-gadget, f,
@@ -467,7 +473,7 @@ static void acm_disable(struct usb_function *f)
struct f_acm*acm = func_to_acm(f);
struct usb_composite_dev *cdev = f-config-cdev;
- DBG(cdev, acm ttyGS%d deactivated\n, acm-port_num);
+ dev_dbg(cdev-gadget-dev, acm ttyGS%d deactivated\n, acm-port_num);
gserial_disconnect(acm-port);
usb_ep_disable(acm-notify);
acm-notify-driver_data = NULL;
@@ -537,8 +543,8 @@ static int acm_notify_serial_state(struct f_acm *acm)
spin_lock(acm-lock);
if (acm-notify_req) {
- DBG(cdev, acm ttyGS%d serial state %04x\n,
- acm-port_num,
Re: [PATCH v2] usb: phy: msm: Make phy_reset clk and reset line optional.
Thanks Felipe, On 20/08/14 16:57, Felipe Balbi wrote: On Thu, Jul 17, 2014 at 09:16:40PM +0100, Srinivas Kandagatla wrote: This patch makes the phy reset clk and reset line optional as this clk is not available on boards like IFC6410 with APQ8064. phy-reset clk is only used as argument to the mach level callbacks, so this patch adds condition before clk_get calls so that the driver wouldn't fail on SOCs which do not have this support. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- Hi Felipe, With this new patch now the error message is only printed if the SOC actually supports the phy reset clk, for SOCs like APQ8064 where there is no phy reset clock or the callback which takes it there is no point in doing a clk_get call in the first place. doesn't apply. Please rebase on top of v3.17-rc1 this is because a previous version of the same patch got applied. Anyway I will rebase this patch and send v3. thanks, srini -- To unsubscribe from this list: send the line unsubscribe 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 v3] usb: phy: msm: Make phy_reset clk and reset line optional.
This patch makes the phy reset clk and reset line optional as this clk
is not available on boards like IFC6410 with APQ8064.
phy-reset clk is only used as argument to the mach level callbacks, so
this patch adds condition before clk_get calls so that the driver
wouldn't fail on SOCs which do not have this support.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
Hi Felipe,
With this new patch now the error message is only printed if the SOC actually
supports
the phy reset clk, for SOCs like APQ8064 where there is no phy reset clock or
the callback which takes it there is no point in doing a clk_get call in the
first place.
Changes since v2:
- rebased patch on top of v3.17-rc1
Thanks,
srini
drivers/usb/phy/phy-msm-usb.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index e4108ee..7f6aa32 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -281,7 +281,7 @@ static int msm_otg_phy_clk_reset(struct msm_otg *motg)
{
int ret = 0;
- if (motg-pdata-phy_clk_reset motg-phy_reset_clk)
+ if (motg-pdata-phy_clk_reset)
ret = motg-pdata-phy_clk_reset(motg-phy_reset_clk);
else if (motg-phy_rst)
ret = reset_control_reset(motg-phy_rst);
@@ -1554,11 +1554,14 @@ static int msm_otg_probe(struct platform_device *pdev)
phy = motg-phy;
phy-dev = pdev-dev;
- motg-phy_reset_clk = devm_clk_get(pdev-dev,
+ if (motg-pdata-phy_clk_reset) {
+ motg-phy_reset_clk = devm_clk_get(pdev-dev,
np ? phy : usb_phy_clk);
- if (IS_ERR(motg-phy_reset_clk)) {
- dev_err(pdev-dev, failed to get usb_phy_clk\n);
- motg-phy_reset_clk = NULL;
+
+ if (IS_ERR(motg-phy_reset_clk)) {
+ dev_err(pdev-dev, failed to get usb_phy_clk\n);
+ return PTR_ERR(motg-phy_reset_clk);
+ }
}
motg-clk = devm_clk_get(pdev-dev, np ? core : usb_hs_clk);
--
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
[PATCH] usb: gadget: serial: remove PREFIX macro
Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with
the hardcoded ttyGS string.
This macro was mostly used in a few debug/warning messages and a lot of
hardcoded ttyGS existed beneath. It may have been used for renaming the
tty, but if done so most debug messages would have ignored this.
Due to the fact the usage of this PREFIX in all debug calls would have
resulted in a hard to read/grep code it is removed completely.
Signed-off-by: Richard Leitner richard.leit...@skidata.com
---
changes from RFC to PATCH:
- rebased on v3.17-rc1
- fixed some PARENTHESIS_ALIGNMENT checkpatch.pl warnings
---
drivers/usb/gadget/function/u_serial.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..491082a 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -55,11 +55,8 @@
* for a telephone or fax link. And ttyGS2 might be something that just
* needs a simple byte stream interface for some messaging protocol that
* is managed in userspace ... OBEX, PTP, and MTP have been mentioned.
- */
-
-#define PREFIX ttyGS
-
-/*
+ *
+ *
* gserial is the lifecycle interface, used by USB functions
* gs_port is the I/O nexus, used by the tty driver
* tty_struct links to the tty/filesystem framework
@@ -385,9 +382,9 @@ __acquires(port-port_lock)
list_del(req-list);
req-zero = (gs_buf_data_avail(port-port_write_buf) == 0);
- pr_vdebug(PREFIX %d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n,
- port-port_num, len, *((u8 *)req-buf),
- *((u8 *)req-buf+1), *((u8 *)req-buf+2));
+ pr_vdebug(ttyGS%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n,
+ port-port_num, len, *((u8 *)req-buf),
+ *((u8 *)req-buf+1), *((u8 *)req-buf+2));
/* Drop lock while we call out of driver; completions
* could be issued while we do so. Disconnection may
@@ -503,13 +500,13 @@ static void gs_rx_push(unsigned long _port)
switch (req-status) {
case -ESHUTDOWN:
disconnect = true;
- pr_vdebug(PREFIX %d: shutdown\n, port-port_num);
+ pr_vdebug(ttyGS%d: shutdown\n, port-port_num);
break;
default:
/* presumably a transient fault */
- pr_warning(PREFIX %d: unexpected RX status %d\n,
- port-port_num, req-status);
+ pr_warn(ttyGS%d: unexpected RX status %d\n,
+ port-port_num, req-status);
/* FALLTHROUGH */
case 0:
/* normal completion */
@@ -537,9 +534,8 @@ static void gs_rx_push(unsigned long _port)
if (count != size) {
/* stop pushing; TTY layer can't handle more */
port-n_read += count;
- pr_vdebug(PREFIX %d: rx block %d/%d\n,
- port-port_num,
- count, req-actual);
+ pr_vdebug(ttyGS%d: rx block %d/%d\n,
+ port-port_num, count, req-actual);
break;
}
port-n_read = 0;
@@ -569,7 +565,7 @@ static void gs_rx_push(unsigned long _port)
if (do_push)
tasklet_schedule(port-push);
else
- pr_warning(PREFIX %d: RX not scheduled?\n,
+ pr_warn(ttyGS%d: RX not scheduled?\n,
port-port_num);
}
}
@@ -985,7 +981,7 @@ static void gs_unthrottle(struct tty_struct *tty)
* read queue backs up enough we'll be NAKing OUT packets.
*/
tasklet_schedule(port-push);
- pr_vdebug(PREFIX %d: unthrottle\n, port-port_num);
+ pr_vdebug(ttyGS%d: unthrottle\n, port-port_num);
}
spin_unlock_irqrestore(port-port_lock, flags);
}
@@ -1295,7 +1291,7 @@ static int userial_init(void)
return -ENOMEM;
gs_tty_driver-driver_name = g_serial;
- gs_tty_driver-name = PREFIX;
+ gs_tty_driver-name = ttyGS;
/* uses dynamically assigned dev_t values */
gs_tty_driver-type = TTY_DRIVER_TYPE_SERIAL;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH] drivers: usb: fsl: Check IP version 2.4 for mph USB controller
Check 2.4 IP version for multi port host USB controller and
return FSL_USB_VER_2_4 macro
Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com
---
drivers/usb/host/fsl-mph-dr-of.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 9162d1b..e0315de 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -126,6 +126,7 @@ static int usb_get_ver_info(struct device_node *np)
/*
* returns 1 for usb controller version 1.6
* returns 2 for usb controller version 2.2
+* returns 3 for usb controller version 2.4
* returns 0 otherwise
*/
if (of_device_is_compatible(np, fsl-usb2-dr)) {
@@ -150,6 +151,8 @@ static int usb_get_ver_info(struct device_node *np)
ver = FSL_USB_VER_1_6;
else if (of_device_is_compatible(np, fsl-usb2-mph-v2.2))
ver = FSL_USB_VER_2_2;
+ else if (of_device_is_compatible(np, fsl-usb2-mph-v2.4))
+ ver = FSL_USB_VER_2_4;
else /* for previous controller versions */
ver = FSL_USB_VER_OLD;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe 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] drivers: usb :fsl: Add support for USB controller version-2.5
Add support for USB controller version-2.5 used in
T4240 rev2.0, T1024, B3421, T1040, T2080, LS1021A.
Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com
---
- Depends on commit 990c2c7829d98517228f2b2ff14919c83b75e124
drivers: usb: fsl: Check IP version 2.4 for mph USB controller
drivers/usb/host/fsl-mph-dr-of.c | 5 +
include/linux/fsl_devices.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index e0315de..45b9e36 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -127,6 +127,7 @@ static int usb_get_ver_info(struct device_node *np)
* returns 1 for usb controller version 1.6
* returns 2 for usb controller version 2.2
* returns 3 for usb controller version 2.4
+* returns 4 for usb controller version 2.5
* returns 0 otherwise
*/
if (of_device_is_compatible(np, fsl-usb2-dr)) {
@@ -136,6 +137,8 @@ static int usb_get_ver_info(struct device_node *np)
ver = FSL_USB_VER_2_2;
else if (of_device_is_compatible(np, fsl-usb2-dr-v2.4))
ver = FSL_USB_VER_2_4;
+ else if (of_device_is_compatible(np, fsl-usb2-dr-v2.5))
+ ver = FSL_USB_VER_2_5;
else /* for previous controller versions */
ver = FSL_USB_VER_OLD;
@@ -153,6 +156,8 @@ static int usb_get_ver_info(struct device_node *np)
ver = FSL_USB_VER_2_2;
else if (of_device_is_compatible(np, fsl-usb2-mph-v2.4))
ver = FSL_USB_VER_2_4;
+ else if (of_device_is_compatible(np, fsl-usb2-mph-v2.5))
+ ver = FSL_USB_VER_2_5;
else /* for previous controller versions */
ver = FSL_USB_VER_OLD;
}
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index a82296a..2a2f56b 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -24,6 +24,7 @@
#define FSL_USB_VER_1_61
#define FSL_USB_VER_2_22
#define FSL_USB_VER_2_43
+#define FSL_USB_VER_2_54
#include linux/types.h
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe 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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor
On 08/20/2014 02:13 AM, Peter Chen wrote: Thanks, so Xunbing, the imx6 hardware (chipidea core) have 8 endpoints, and support all four transfer type, it should be no problem to support RNDIS. But you shouldn't use RNDIS on Windows 7 or 8. As far as I recall they do not bring the RNDIS driver which is deprecated and only supported by Windows XP which is EOL by now. Windows 7 and 8 support CDC [0] and this is what you should look for. [0] http://msdn.microsoft.com/en-us/library/windows/hardware/ff538820%28v=vs.85%29.aspx Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB reset xhci_hcd for ELAN touchscreen
On Wed, Aug 20, 2014 at 08:20:43AM -0500, Jiri Kosina wrote:
On Mon, 14 Jul 2014, Johan Hovold wrote:
From 8101c0dfd42a232f1d2872de4f412d8d61d5646f Mon Sep 17 00:00:00 2001
From: Johan Hovold jo...@kernel.org
Date: Mon, 14 Jul 2014 18:43:31 +0200
Subject: [PATCH] HID: usbhid: add HID_QUIRK_IN
Add quirk to submit the interrupt-in urb already at start() rather than
at open().
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to input events.
It's not really super-nice, but if no other way around it has been found
to be possible in USB core, I am willing to take this.
Agreed, it's not that nice, but I'm not aware of any other way to
prevent the device firmware from disconnecting.
Autosuspend still seems to work, so it would not cause much overhead
for people not actually using the touchscreen (as long as autosuspend
is enabled) either.
---
drivers/hid/usbhid/hid-core.c | 26 +++---
include/linux/hid.h | 1 +
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 7b88f4c..4b5d986 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
struct usbhid_device *usbhid = hid-driver_data;
spin_lock_irqsave(usbhid-lock, flags);
- if (hid-open 0
+ if ((hid-open 0 || hid-quirks HID_QUIRK_IN)
!test_bit(HID_DISCONNECTED, usbhid-iofl)
!test_bit(HID_SUSPENDED, usbhid-iofl)
!test_and_set_bit(HID_IN_RUNNING, usbhid-iofl)) {
@@ -292,6 +292,8 @@ static void hid_irq_in(struct urb *urb)
case 0: /* success */
usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
+ if ((hid-quirks HID_QUIRK_IN) !hid-open)
+ break;
hid_input_report(urb-context, HID_INPUT_REPORT,
urb-transfer_buffer,
urb-actual_length, 1);
@@ -734,8 +736,10 @@ void usbhid_close(struct hid_device *hid)
if (!--hid-open) {
spin_unlock_irq(usbhid-lock);
hid_cancel_delayed_stuff(usbhid);
- usb_kill_urb(usbhid-urbin);
- usbhid-intf-needs_remote_wakeup = 0;
+ if (!(hid-quirks HID_QUIRK_IN)) {
+ usb_kill_urb(usbhid-urbin);
+ usbhid-intf-needs_remote_wakeup = 0;
+ }
} else {
spin_unlock_irq(usbhid-lock);
}
@@ -1133,6 +1137,20 @@ static int usbhid_start(struct hid_device *hid)
set_bit(HID_STARTED, usbhid-iofl);
+ hid-quirks |= HID_QUIRK_IN;/* FIXME */
This of course needs to be set on per-device basis :)
Of course.
+ if (hid-quirks HID_QUIRK_IN) {
+ ret = usb_autopm_get_interface(usbhid-intf);
+ if (ret)
+ goto fail;
+ usbhid-intf-needs_remote_wakeup = 1;
+ ret = hid_start_in(hid);
+ if (ret) {
+ dev_err(hid-dev,
+ failed to start in urb: %d\n, ret);
+ }
+ usb_autopm_put_interface(usbhid-intf);
+ }
+
/* Some keyboards don't work until their LEDs have been set.
* Since BIOSes do set the LEDs, it must be safe for any device
* that supports the keyboard boot protocol.
@@ -1165,6 +1183,8 @@ static void usbhid_stop(struct hid_device *hid)
if (WARN_ON(!usbhid))
return;
+ usbhid-intf-needs_remote_wakeup = 0;
+
clear_bit(HID_STARTED, usbhid-iofl);
spin_lock_irq(usbhid-lock); /* Sync with error and led handlers */
set_bit(HID_DISCONNECTED, usbhid-iofl);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 77632cf..13f81ae 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -286,6 +286,7 @@ struct hid_item {
#define HID_QUIRK_HIDINPUT_FORCE 0x0080
#define HID_QUIRK_NO_EMPTY_INPUT 0x0100
#define HID_QUIRK_NO_INIT_INPUT_REPORTS0x0200
+#define HID_QUIRK_IN 0x0400
0x0400 has been removed before dynamic quirks started to be possible,
so there is no potential clash, that's fine.
I'd just propose some more descriptive name for the quirk ... how about
something like HID_QUIRK_EARLY_INTERRUPT?
Yeah, IN was just a working name. How about HID_QUIRK_ALWAYS_POLL or
similar as it is not just about disconnect before the device is opened,
but also if there's an event after the device has been closed (e.g.
stopping X)?
Thanks,
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-core.c | 45 +++--
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c| 3 +--
drivers/phy/phy-exynos5250-sata.c | 2 +-
drivers/phy/phy-mvebu-sata.c| 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-samsung-usb2.c | 3 +--
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 4 +---
drivers/phy/phy-xgene.c | 2 +-
include/linux/phy/phy.h | 38 ---
14 files changed, 19 insertions(+), 92 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index 894fe74..3463983 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, NULL, ops, NULL);
+ gphy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 67a8c726..834b337 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -55,36 +55,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -210,10 +180,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -721,13 +687,11 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
int ret;
int id;
@@ -765,7 +729,6 @@ struct phy *phy_create(struct device *dev, struct
device_node *node,
phy-dev.of_node = node ?: dev-of_node;
phy-id = id;
phy-ops = ops;
- phy-init_data = init_data;
ret = dev_set_name(phy-dev, phy-%s.%d, dev_name(dev), id);
if (ret)
@@ -800,7 +763,6 @@ EXPORT_SYMBOL_GPL(phy_create);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Creates a new PHY device adding it to the PHY class.
* While at that, it also associates the device with the phy using devres.
@@ -808,8 +770,7 @@ EXPORT_SYMBOL_GPL(phy_create);
* then, devres data is freed.
*/
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
struct phy **ptr, *phy;
@@ -817,7 +778,7 @@ struct phy *devm_phy_create(struct device *dev, struct
device_node *node,
if (!ptr)
return ERR_PTR(-ENOMEM);
- phy = phy_create(dev, node, ops, init_data);
+ phy = phy_create(dev, node,
[PATCH 5/6] base: platform: name the device already during allocation
The device name is needed when assigning resources like
clocks or GPIOs to devices using lookups. If
PLATFORM_DEVICE_AUTO is used, the device name is not know
before platform_device_add is called after which it's too
late to assign that kind of resources as the drivers most
likely have already requested them.
By naming the device already in platform_device_alloc, the
resources can be assigned before platform_device_add is
called.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 69 +
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index ab4f4ce..d3a7022 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -194,11 +194,41 @@ void platform_device_put(struct platform_device *pdev)
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+* Automatically allocated device ID. We mark it as such so
+* that we remember it must be freed, and we append a suffix
+* to avoid namespace collision with explicit IDs.
+*/
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
+ if (pa-pdev.id_auto)
+ ida_simple_remove(platform_devid_ida, pa-pdev.id);
+
of_device_node_put(pa-pdev.dev);
kfree(pa-pdev.dev.platform_data);
kfree(pa-pdev.mfd_cell);
@@ -227,6 +257,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -307,28 +341,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
-* Automatically allocated device ID. We mark it as such so
-* that we remember it must be freed, and we append a suffix
-* to avoid namespace collision with explicit IDs.
-*/
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -371,7 +383,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -391,11 +402,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -413,8 +419,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
--
2.1.0
--
To unsubscribe from this
[PATCH 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/linux/phy/phy.h | 27 ++
3 files changed, 183 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index c6594af..8add515 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other
peripheral controllers
to make use of it. The PHY framework provides 2 APIs to create the PHY.
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
@@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get,
phy_pm_runtime_get_sync,
phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
phy_pm_runtime_forbid for performing PM operations.
-8. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made statically by directly registering
+phy_lookup structure which contains the name of the PHY device, the name of the
+device which the PHY will be bind to and Connection ID string. Alternatively a
+lookup can be made during runtime when a handle to the struct phy already
+exists.
+
+The framework offers the following APIs for registering and unregistering the
+lookups.
+
+void phy_register_lookup(struct phy_lookup *pl);
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+
+void phy_unregister_lookup(struct phy_lookup *pl);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..67a8c726 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -26,6 +26,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+
[PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some PHY
tuning based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/host.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..12bfd3c 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -29,8 +29,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
dma_set_coherent_mask(xhci-dev, dwc-dev-coherent_dma_mask);
@@ -60,22 +59,33 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
+ phy_create_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_create_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc-dev, failed to register xHCI device\n);
- goto err1;
+ goto err2;
}
return 0;
-
+err2:
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
err1:
platform_device_put(xhci);
-
-err0:
return ret;
}
void dwc3_host_exit(struct dwc3 *dwc)
{
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(dwc-xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(dwc-xhci-dev));
platform_device_unregister(dwc-xhci);
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] arm: omap3: twl: use the new lookup method with usb phy
Provide complete association for the phy and it's user
(musb) with the new phy lookup method.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..b78383c 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,14 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup twl4030_usb_lookup = {
+ .phy_name = phy-twl4030_usb.0,
+ .dev_id = musb-hdrc.0,
+ .con_id = usb,
};
static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
+ .usb_mode = T2_USB_MODE_ULPI,
};
static int omap3_batt_table[] = {
@@ -225,8 +221,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_register_lookup(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] phy: safer to_phy() macro
This makes to_phy() macro work with other variable names
besides dev.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 8cb6f81..9fda683 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -110,7 +110,7 @@ struct phy_init_data {
.port = _port,\
}
-#defineto_phy(dev) (container_of((dev), struct phy, dev))
+#defineto_phy(a) (container_of((a), struct phy, dev))
#defineof_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
This should fix the issue on ehci-exynos, wherein in the absence of
SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy
when the same is enabled. And thus the PHYs are not configured properly.
Reported-by: Sachin Kamat sachin.ka...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Reviewed-by: Jingoo Han jg1@samsung.com
---
- This patch was part of the series [PATCH 0/7] usb-phy: samsung: Cleanup the
unused drivers
https://lkml.org/lkml/2014/8/14/235. I have dropped the phy cleanup patches
from that series-
Patches 1-5.
- Rebased this patch on top of 3.17-rc1.
drivers/usb/host/ehci-exynos.c | 53 ++--
1 file changed, 8 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index cda0a2f..54944cc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
#include linux/usb/hcd.h
-#include linux/usb/otg.h
#include ehci.h
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -62,18 +57,6 @@ static int exynos_ehci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
- exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ehci-phy)) {
- ret = PTR_ERR(exynos_ehci-phy);
- if (ret != -ENXIO ret != -ENODEV) {
- dev_err(dev, no usb2 phy configured\n);
- return ret;
- }
- dev_dbg(dev, Failed to get usb2 phy\n);
- } else {
- exynos_ehci-otg = exynos_ehci-phy-otg;
- }
-
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -98,7 +81,7 @@ static int exynos_ehci_get_phy(struct device *dev,
}
dev_dbg(dev, Failed to get usb2 phy\n);
}
- exynos_ehci-phy_g[phy_number] = phy;
+ exynos_ehci-phy[phy_number] = phy;
}
return ret;
@@ -111,16 +94,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ehci-phy))
- return usb_phy_init(exynos_ehci-phy);
-
for (i = 0; ret == 0 i PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- ret = phy_power_on(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ ret = phy_power_on(exynos_ehci-phy[i]);
if (ret)
for (i--; i = 0; i--)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- phy_power_off(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ phy_power_off(exynos_ehci-phy[i]);
return ret;
}
@@ -131,14 +111,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
- if (!IS_ERR(exynos_ehci-phy)) {
- usb_phy_shutdown(exynos_ehci-phy);
- return;
- }
-
for (i = 0; i PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- phy_power_off(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ phy_power_off(exynos_ehci-phy[i]);
}
static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +206,6 @@ skip_phy:
goto fail_io;
}
- if (exynos_ehci-otg)
- exynos_ehci-otg-set_host(exynos_ehci-otg, hcd-self);
-
err = exynos_ehci_phy_enable(pdev-dev);
if (err) {
dev_err(pdev-dev, Failed to enable USB phy\n);
@@ -273,9 +245,6 @@ static int exynos_ehci_remove(struct platform_device *pdev)
usb_remove_hcd(hcd);
- if (exynos_ehci-otg)
- exynos_ehci-otg-set_host(exynos_ehci-otg, hcd-self);
-
exynos_ehci_phy_disable(pdev-dev);
clk_disable_unprepare(exynos_ehci-clk);
@@ -298,9 +267,6 @@ static int exynos_ehci_suspend(struct device *dev)
if (rc)
[PATCH v5 0/3] usb: gadget: f_fs: userspace API fixes and improvements
This patchset contains changes in FunctionFS making it easier and safer to use. It fixes bug in endpoint files handling code, adds new ioctl allowing to obtain endpoint descriptor, and introduces virtual address mapping which allows to separate endpoint address space in function from physical endpoint addresses, and introduces new endpoint files naming convention. Changelog: v5: - fix typo pointed by Sergei Shtylyov v4: https://lkml.org/lkml/2014/8/20/277 - change if() sequence into switch() statement v3: https://lkml.org/lkml/2014/7/30/115 - move fix for the redundant ep files problem into sepatare patch - merge user space API affecting changes into single patch - add flag switching between old and new style API v2: https://lkml.org/lkml/2014/7/25/296 - return proper endpont address in setup request handling - add patch usb: gadget: f_fs: add ioctl returning ep descriptor - add patch usb: gadget: f_fs: make numbers in ep file names the same as ep addresses v1: https://lkml.org/lkml/2014/7/18/1010 Robert Baldyga (3): usb: gadget: f_fs: fix the redundant ep files problem usb: gadget: f_fs: add ioctl returning ep descriptor usb: gadget: f_fs: virtual endpoint address mapping drivers/usb/gadget/function/f_fs.c | 111 +++- drivers/usb/gadget/function/u_fs.h | 4 ++ include/uapi/linux/usb/functionfs.h | 7 +++ 3 files changed, 109 insertions(+), 13 deletions(-) -- 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
[PATCH v5 3/3] usb: gadget: f_fs: virtual endpoint address mapping
This patch introduces virtual endpoint address mapping. It separates
function logic form physical endpoint addresses making it more hardware
independent.
Following modifications changes user space API, so to enable them user
have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors.
Endpoints are now refered using virtual endpoint addresses chosen by
user in endpoint descpriptors. This applies to each context when endpoint
address can be used:
- when accessing endpoint files in FunctionFS filesystemi (in file name),
- in setup requests directed to specific endpoint (in wIndex field),
- in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl.
In endpoint file names the endpoint address number is formatted as
double-digit hexadecimal value (ep%02x) which has few advantages -
it is easy to parse, allows to easly recognize endpoint direction basing
on its name (IN endpoint number starts with digit 8, and OUT with 0)
which can be useful for debugging purpose, and it makes easier to introduce
further features allowing to use each endpoint number in both directions
to have more endpoints available for function if hardware supports this
(for example we could have ep01 which is endpoint 1 with OUT direction,
and ep81 which is endpoint 1 with IN direction).
Physical endpoint address can be still obtained using ioctl named
FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle
USB transactions properly.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/gadget/function/f_fs.c | 23 +--
drivers/usb/gadget/function/u_fs.h | 2 ++
include/uapi/linux/usb/functionfs.h | 1 +
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index ac7b16d..a20ac8d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1555,7 +1555,10 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
epfile-ffs = ffs;
mutex_init(epfile-mutex);
init_waitqueue_head(epfile-wait);
- sprintf(epfiles-name, ep%u, i);
+ if (ffs-user_flags FUNCTIONFS_VIRTUAL_ADDR)
+ sprintf(epfiles-name, ep%02x, ffs-eps_addrmap[i]);
+ else
+ sprintf(epfiles-name, ep%u, i);
if (!unlikely(ffs_sb_create_file(ffs-sb, epfiles-name, epfile,
ffs_epfile_operations,
epfile-dentry))) {
@@ -2105,10 +2108,12 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
break;
case FUNCTIONFS_DESCRIPTORS_MAGIC_V2:
flags = get_unaligned_le32(data + 8);
+ ffs-user_flags = flags;
if (flags ~(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC |
FUNCTIONFS_HAS_SS_DESC |
- FUNCTIONFS_HAS_MS_OS_DESC)) {
+ FUNCTIONFS_HAS_MS_OS_DESC |
+ FUNCTIONFS_VIRTUAL_ADDR)) {
ret = -ENOSYS;
goto error;
}
@@ -2463,7 +2468,13 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type
type, u8 *valuep,
} else {
struct usb_request *req;
struct usb_ep *ep;
+ u8 bEndpointAddress;
+ /*
+* We back up bEndpointAddress because autoconfig overwrites
+* it with physical endpoint address.
+*/
+ bEndpointAddress = ds-bEndpointAddress;
pr_vdebug(autoconfig\n);
ep = usb_ep_autoconfig(func-gadget, ds);
if (unlikely(!ep))
@@ -2478,6 +2489,12 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type
type, u8 *valuep,
ffs_ep-req = req;
func-eps_revmap[ds-bEndpointAddress
USB_ENDPOINT_NUMBER_MASK] = idx + 1;
+ /*
+* If we use virtual address mapping, we restore
+* original bEndpointAddress value.
+*/
+ if (func-ffs-user_flags FUNCTIONFS_VIRTUAL_ADDR)
+ ds-bEndpointAddress = bEndpointAddress;
}
ffs_dump_mem(: Rewritten ep desc, ds, ds-bLength);
@@ -2922,6 +2939,8 @@ static int ffs_func_setup(struct usb_function *f,
ret = ffs_func_revmap_ep(func, le16_to_cpu(creq-wIndex));
if (unlikely(ret 0))
return ret;
+ if (func-ffs-user_flags FUNCTIONFS_VIRTUAL_ADDR)
+ ret = func-ffs-eps_addrmap[ret];
break;
default:
diff --git a/drivers/usb/gadget/function/u_fs.h
b/drivers/usb/gadget/function/u_fs.h
index d48897e..cd128e3 100644
---
[PATCH v5 2/3] usb: gadget: f_fs: add ioctl returning ep descriptor
This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
returns endpoint descriptor to userspace. It works only if function
is active.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/gadget/function/f_fs.c | 21 +
include/uapi/linux/usb/functionfs.h | 6 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 8096f22..ac7b16d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1032,6 +1032,27 @@ static long ffs_epfile_ioctl(struct file *file, unsigned
code,
case FUNCTIONFS_ENDPOINT_REVMAP:
ret = epfile-ep-num;
break;
+ case FUNCTIONFS_ENDPOINT_DESC:
+ {
+ int desc_idx;
+ struct usb_endpoint_descriptor *desc;
+
+ switch (epfile-ffs-gadget-speed) {
+ case USB_SPEED_SUPER:
+ desc_idx = 2;
+ break;
+ case USB_SPEED_HIGH:
+ desc_idx = 1;
+ break;
+ default:
+ desc_idx = 0;
+ }
+ desc = epfile-ep-descs[desc_idx];
+ ret = copy_to_user((void *)value, desc, sizeof(*desc));
+ if (ret)
+ ret = -EFAULT;
+ break;
+ }
default:
ret = -ENOTTY;
}
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 0154b28..7677108 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -265,6 +265,12 @@ struct usb_functionfs_event {
*/
#defineFUNCTIONFS_ENDPOINT_REVMAP _IO('g', 129)
+/*
+ * Returns endpoint descriptor. If function is not active returns -ENODEV.
+ */
+#defineFUNCTIONFS_ENDPOINT_DESC_IOR('g', 130, \
+struct usb_endpoint_descriptor)
+
#endif /* _UAPI__LINUX_FUNCTIONFS_H__ */
--
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: [PATCH v4 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
Hi Felipe, Will fix the commit log and rebase onto 3.17-rc1 for the next iteration. regards, Peter. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: hcd: add generic PHY support
Hi Sergei, On Thu, Aug 21, 2014 at 6:37 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. On 08/21/2014 04:44 PM, Vivek Gautam wrote: From Sergei Shtylyov sergei.shtyl...@cogentembedded.com Should be From:. Add the generic PHY support, analogous to the USB PHY support. Intended it to be used with the PCI EHCI/OHCI drivers and the xHCI platform driver. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo. (commit id = 70d2f61fc7559df3d5be32a9d01efdb9ee1b11d8) I was pondering on reposting this patch, along with the R8A779x device tree changes using it as Greg KH requested to see the users of this patch... Are we planning a repost of this patch, Yes, I'm planning this since Greg has lost v4. Ok, for now i will rebase my series for xhci-plat on this. Thanks :-) -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
Hi Felipe,
Thanks for reviewing, see my comments below: -
On Wed, 20 Aug 2014, Felipe Balbi wrote:
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host
+ usb-phy = usb3_phy;
+ phy-names = usb2-phy;
+ phys= usb2_picophy2;
why are you using different binding for usb2 and usb3 phys ? Why can't
you just:
phys-names = usb2-phy, usb3-phy;
phys= usb2_picophy2, usb3_phy;
??
Currently (in the vendor tree) one of the phys lives in drivers/usb/phy and the
other in drivers/phy.
I believe that is because one is only a usb phy and the other is a multi
function phy which can drive
PCI-E or USB3.
So to make that work, when dwc3/core.c gets the PHYS in dwc3_core_get_phy() we
need to use the different
bindings.
I think we are the only platform using one of each, but luckily
dwc3_core_get_phy()
has been written generically enough that it just works :-).
regards,
Peter.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Tegra xHCI support
On 18 August 2014 19:08, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware from the ChromiumOS tree [2]. Hi Andrew, do you have any information regarding the port assignments for the Blaze board? Would like to test this there. Thanks, Tomeu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
On Thu, Aug 21, 2014 at 02:33:40PM +0100, Peter Griffin wrote:
Hi Felipe,
Thanks for reviewing, see my comments below: -
On Wed, 20 Aug 2014, Felipe Balbi wrote:
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host
+ usb-phy = usb3_phy;
+ phy-names = usb2-phy;
+ phys= usb2_picophy2;
why are you using different binding for usb2 and usb3 phys ? Why can't
you just:
phys-names = usb2-phy, usb3-phy;
phys= usb2_picophy2, usb3_phy;
??
Currently (in the vendor tree) one of the phys lives in
drivers/usb/phy and the other in drivers/phy.
I believe that is because one is only a usb phy and the other is a
multi function phy which can drive PCI-E or USB3.
right, but for mainline, we can have both PHYs in drivers/phy only.
So to make that work, when dwc3/core.c gets the PHYS in
dwc3_core_get_phy() we need to use the different bindings.
I think we are the only platform using one of each, but luckily
dwc3_core_get_phy() has been written generically enough that it just
works :-).
true, but I want to drop support for the legacy drivers/usb/phy layer
from dwc3. I'll try to move all PHYs to drivers/phy for v3.18.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 2/2] usb: gadget: Add xilinx usb2 device support
On Thu, Aug 21, 2014 at 12:19:03PM +0530, sundeep subbaraya wrote: Hi Daniel, On Tue, Aug 19, 2014 at 3:26 PM, Daniel Mack dan...@zonque.org wrote: Hi, On 07/22/2014 11:08 AM, Subbaraya Sundeep Bhatta wrote: This patch adds xilinx usb2 device driver support Add some more information here, please. Copying the text from the Kconfig option is already a good start. drivers/usb/gadget/Kconfig | 14 + drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/udc-xilinx.c | 2261 +++ 3 files changed, 2276 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/udc-xilinx.c As your driver has a DT binding, you have to describe it in Documentation/devicetree/bindings. --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -459,6 +459,20 @@ config USB_EG20T ML7213/ML7831 is companion chip for Intel Atom E6xx series. ML7213/ML7831 is completely compatible for Intel EG20T PCH. +config USB_GADGET_XILINX + tristate Xilinx USB Driver + depends on COMPILE_TEST Why would you depend on that? Felipe asked to make this since this is USB soft IP driver and its dependencies have tendency to grow. that's not exactly what I asked :-) Usually you only add COMPILE_TEST when you have an ARCH dependency. So something like: depends on ARCH_ARM || COMPILE_TEST would make it clear that this driver is only available on ARM, but when doing my build tests, I'd still be able to compile it on x86. Also, your code uses device tree functions unconditionally, which is fine, but it must hence depend on 'OF'. Ok will add OF along with COMPILE_TEST so this would be: depends on OF || COMPILE_TEST -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
Hi Felipe, On Thu, 21 Aug 2014, Felipe Balbi wrote: Currently (in the vendor tree) one of the phys lives in drivers/usb/phy and the other in drivers/phy. I believe that is because one is only a usb phy and the other is a multi function phy which can drive PCI-E or USB3. right, but for mainline, we can have both PHYs in drivers/phy only. Ah ok, I didn't know that, so thanks for that info. So to make that work, when dwc3/core.c gets the PHYS in dwc3_core_get_phy() we need to use the different bindings. I think we are the only platform using one of each, but luckily dwc3_core_get_phy() has been written generically enough that it just works :-). true, but I want to drop support for the legacy drivers/usb/phy layer from dwc3. I'll try to move all PHYs to drivers/phy for v3.18. Ok, so for the next re-spin I will change this to just use the generic phy binding for both usb2 usb3 phys. In parallel I will also migrate over the drivers/usb/phy driver to be just a generic phy before I attempt to upstream it. regards, Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
Hi Peter, On Thu, Aug 21, 2014 at 03:03:47PM +0100, Peter Griffin wrote: Hi Felipe, On Thu, 21 Aug 2014, Felipe Balbi wrote: Currently (in the vendor tree) one of the phys lives in drivers/usb/phy and the other in drivers/phy. I believe that is because one is only a usb phy and the other is a multi function phy which can drive PCI-E or USB3. right, but for mainline, we can have both PHYs in drivers/phy only. Ah ok, I didn't know that, so thanks for that info. So to make that work, when dwc3/core.c gets the PHYS in dwc3_core_get_phy() we need to use the different bindings. I think we are the only platform using one of each, but luckily dwc3_core_get_phy() has been written generically enough that it just works :-). true, but I want to drop support for the legacy drivers/usb/phy layer from dwc3. I'll try to move all PHYs to drivers/phy for v3.18. Ok, so for the next re-spin I will change this to just use the generic phy binding for both usb2 usb3 phys. In parallel I will also migrate over the drivers/usb/phy driver to be just a generic phy before I attempt to upstream it. Thank you for understanding :-) -- balbi signature.asc Description: Digital signature
Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Thu, Aug 21, 2014 at 10:41:02AM -0400, Douglas Gilbert wrote: Perhaps we could add another bit flag in struct scsi_host_template such as: unsigned int transport_says_dont_scsi2_lun_cmd:1; then drivers/usb/storage/scsiglue.c could set that bit in its usb_stor_host_template and drivers/scsi/scsi.c could take heed (and not mask cmd-cmnd[1] with the LUN). Fully agreed. (except that I'd shorten the flag name to .no_scsi2lun :)) -- To unsubscribe from this list: send the line unsubscribe 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/4] usb: gadget: f_uvc: fix potential memory leak
From: Andrzej Pietrasiewicz andrze...@samsung.com
If uvc-control_buf is successfuly allocated but uvc-control_req
is not, uvc-control_buf is not freed in the error recovery path.
With this patch applied uvc-control_buf is freed unconditionally;
if it happens to be NULL kfree on it is safe anyway.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Acked-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/gadget/function/f_uvc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_uvc.c
b/drivers/usb/gadget/function/f_uvc.c
index e2a1f50..ff4340a 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -720,10 +720,9 @@ error:
if (uvc-video.ep)
uvc-video.ep-driver_data = NULL;
- if (uvc-control_req) {
+ if (uvc-control_req)
usb_ep_free_request(cdev-gadget-ep0, uvc-control_req);
- kfree(uvc-control_buf);
- }
+ kfree(uvc-control_buf);
usb_free_all_descriptors(f);
return ret;
--
1.8.5.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 2/4] usb: gadget/uvc: Add support for DMABUF importing
From: Philipp Zabel p.za...@pengutronix.de Activate the videobuf2 DMABUF support. As vb2-vmalloc supports the importer role only, exporting buffers isn't supported yet. When the exporter role will be implemented in vb2-vmalloc the UVC gadget driver will automatically gain support for it. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/usb/gadget/function/uvc_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c index 1c29bc9..8590f9f 100644 --- a/drivers/usb/gadget/function/uvc_queue.c +++ b/drivers/usb/gadget/function/uvc_queue.c @@ -132,7 +132,7 @@ static int uvc_queue_init(struct uvc_video_queue *queue, int ret; queue-queue.type = type; - queue-queue.io_modes = VB2_MMAP | VB2_USERPTR; + queue-queue.io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; queue-queue.drv_priv = queue; queue-queue.buf_struct_size = sizeof(struct uvc_buffer); queue-queue.ops = uvc_queue_qops; -- 1.8.5.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 4/4] usb: gadget/uvc: remove DRIVER_VERSION{,_NUMBER}
From: Michael Grzeschik m.grzesc...@pengutronix.de As the driver is mainline we can remove the version numbers. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/usb/gadget/function/uvc.h | 3 --- drivers/usb/gadget/function/uvc_v4l2.c | 2 +- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h index 7a9111d..0a283b1 100644 --- a/drivers/usb/gadget/function/uvc.h +++ b/drivers/usb/gadget/function/uvc.h @@ -96,9 +96,6 @@ extern unsigned int uvc_gadget_trace_param; * Driver specific constants */ -#define DRIVER_VERSION 0.1.0 -#define DRIVER_VERSION_NUMBER KERNEL_VERSION(0, 1, 0) - #define UVC_NUM_REQUESTS 4 #define UVC_MAX_REQUEST_SIZE 64 #define UVC_MAX_EVENTS 4 diff --git a/drivers/usb/gadget/function/uvc_v4l2.c b/drivers/usb/gadget/function/uvc_v4l2.c index ad48e81..bcd71ce 100644 --- a/drivers/usb/gadget/function/uvc_v4l2.c +++ b/drivers/usb/gadget/function/uvc_v4l2.c @@ -178,7 +178,7 @@ uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg) strlcpy(cap-card, cdev-gadget-name, sizeof(cap-card)); strlcpy(cap-bus_info, dev_name(cdev-gadget-dev), sizeof cap-bus_info); - cap-version = DRIVER_VERSION_NUMBER; + cap-version = LINUX_VERSION_CODE; cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING; break; } -- 1.8.5.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/4] UVC gadget patches for v3.18
Hi Felipe,
These patches have previously been posted to linux-usb. I've rebased them on
top of your master branch. Could you please apply them to your tree for v3.18 ?
Andrzej Pietrasiewicz (1):
usb: gadget: f_uvc: fix potential memory leak
Michael Grzeschik (2):
usb: gadget/uvc: Change KERN_INFO to KERN_DEBUG on request shutdown
usb: gadget/uvc: remove DRIVER_VERSION{,_NUMBER}
Philipp Zabel (1):
usb: gadget/uvc: Add support for DMABUF importing
drivers/usb/gadget/function/f_uvc.c | 5 ++---
drivers/usb/gadget/function/uvc.h | 3 ---
drivers/usb/gadget/function/uvc_queue.c | 2 +-
drivers/usb/gadget/function/uvc_v4l2.c | 2 +-
drivers/usb/gadget/function/uvc_video.c | 2 +-
5 files changed, 5 insertions(+), 9 deletions(-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: gadget/uvc: Change KERN_INFO to KERN_DEBUG on request shutdown
From: Michael Grzeschik m.grzesc...@pengutronix.de The disconnect of the USB Device is a common pattern for an UVC Camera. In many cases this will give us an meaningless information for all buffers that couldn't be enqueued. That patch changes this to KERN_DEBUG. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/usb/gadget/function/uvc_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c index a5eb9a3..1ff478a 100644 --- a/drivers/usb/gadget/function/uvc_video.c +++ b/drivers/usb/gadget/function/uvc_video.c @@ -171,7 +171,7 @@ uvc_video_complete(struct usb_ep *ep, struct usb_request *req) break; case -ESHUTDOWN:/* disconnect from host. */ - printk(KERN_INFO VS request cancelled.\n); + printk(KERN_DEBUG VS request cancelled.\n); uvc_queue_cancel(queue, 1); goto requeue; -- 1.8.5.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 v5 3/4] usb: hcd: Caibrate PHY post hcd reset
Some quirky PHYs may require to be calibrated post the
hcd initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along
with Synopsys's DWC3 controller, is one such PHY which needs
to be calibrated post xhci's reset at initialization time and
at resume time, to get the controller work at SuperSpeed.
So facilitating the HCDs to calibrate the PHY.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/core/hcd.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index c4ed66c..a42b448 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2202,6 +2202,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t
msg)
struct usb_hcd *hcd = container_of(rhdev-bus, struct usb_hcd, self);
int status;
int old_state = hcd-state;
+ int ret;
dev_dbg(rhdev-dev, usb %sresume\n,
(PMSG_IS_AUTO(msg) ? auto- : ));
@@ -2216,6 +2217,17 @@ int hcd_bus_resume(struct usb_device *rhdev,
pm_message_t msg)
hcd-state = HC_STATE_RESUMING;
status = hcd-driver-bus_resume(hcd);
+
+ /* calibrate the phy here */
+ if (!IS_ERR(hcd-gen_phy)) {
+ ret = phy_calibrate(hcd-gen_phy);
+ if (ret 0 ret != -ENOTSUPP) {
+ dev_err(hcd-self.controller,
+ failed to calibrate USB PHY\n);
+ return ret;
+ }
+ }
+
clear_bit(HCD_FLAG_WAKEUP_PENDING, hcd-flags);
if (status == 0) {
struct usb_device *udev;
@@ -2738,6 +2750,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
hcd-rh_pollable = 1;
+ /* calibrate the phy here */
+ if (!IS_ERR(hcd-gen_phy)) {
+ retval = phy_calibrate(hcd-gen_phy);
+ if (retval 0 retval != -ENOTSUPP) {
+ dev_err(hcd-self.controller,
+ failed to calibrate USB PHY\n);
+ return retval;
+ }
+ }
+
/* NOTE: root hub and controller capabilities may not be the same */
if (device_can_wakeup(hcd-self.controller)
device_can_wakeup(hcd-self.root_hub-dev))
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level as well as
Tx-Vboost-Level should be controlled for Super-Speed operations.
Additionally set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.
We are using CR_port for this purpose to send required data
to override the LOS values.
On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-exynos5-usbdrd.c | 169 ++
1 file changed, 169 insertions(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 47f47fe..fa13784 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -89,8 +89,20 @@
#define PHYCLKRST_COMMONONNBIT(0)
#define EXYNOS5_DRD_PHYREG00x14
+
+#define EXYNOS5_DRD_PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define EXYNOS5_DRD_PHYREG0_SSC_RANGE BIT(20)
+#define EXYNOS5_DRD_PHYREG0_CR_WRITE BIT(19)
+#define EXYNOS5_DRD_PHYREG0_CR_READBIT(18)
+#define EXYNOS5_DRD_PHYREG0_CR_DATA_IN(_x) ((_x) 2)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_DATABIT(1)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_ADDRBIT(0)
+
#define EXYNOS5_DRD_PHYREG10x18
+#define EXYNOS5_DRD_PHYREG1_CR_DATA_OUT(_x)((_x) 1)
+#define EXYNOS5_DRD_PHYREG1_CR_ACK BIT(0)
+
#define EXYNOS5_DRD_PHYPARAM0 0x1c
#define PHYPARAM0_REF_USE_PAD BIT(31)
@@ -118,6 +130,26 @@
#define EXYNOS5_DRD_PHYRESUME 0x34
#define EXYNOS5_DRD_LINKPORT 0x44
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN (0x15)
+
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420 (0x5 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT (0x0 13)
+#define LOSLEVEL_OVRD_IN_EN(0x1 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT (0x9 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN (0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420 (0x5 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT (0x4 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG (0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M(0x4 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M (0x8 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M (0x8 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M (0x20 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5(0x20 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M(0x40 4)
+
#define KHZ1000
#define MHZ(KHZ * KHZ)
@@ -135,12 +167,14 @@ struct exynos5_usbdrd_phy_config {
void (*phy_isol)(struct phy_usb_instance *inst, u32 on);
void (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
unsigned int (*set_refclk)(struct phy_usb_instance *inst);
+ int (*phy_calibrate)(struct phy_usb_instance *inst);
};
struct exynos5_usbdrd_phy_drvdata {
const struct exynos5_usbdrd_phy_config *phy_cfg;
u32 pmu_offset_usbdrd0_phy;
u32 pmu_offset_usbdrd1_phy;
+ void (*calibrate)(struct exynos5_usbdrd_phy *phy_drd);
};
/**
@@ -487,6 +521,138 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
return 0;
}
+static void crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+ u32 val, u32 cmd)
+{
+ u32 usec = 100;
+ u32 result;
+
+ writel(val | cmd, phy_drd-reg_phy + EXYNOS5_DRD_PHYREG0);
+
+ do {
+ result = readl(phy_drd-reg_phy + EXYNOS5_DRD_PHYREG1);
+ if (result EXYNOS5_DRD_PHYREG1_CR_ACK)
+ break;
+
+ udelay(1);
+ } while (usec-- 0);
+
+ if (!usec)
+ dev_err(phy_drd-dev,
+ CRPORT handshake timeout1 (0x%08x)\n, val);
+
+ usec = 100;
+
+ writel(val, phy_drd-reg_phy + EXYNOS5_DRD_PHYREG0);
+
+ do {
+ result = readl(phy_drd-reg_phy + EXYNOS5_DRD_PHYREG1);
+ if (!(result EXYNOS5_DRD_PHYREG1_CR_ACK))
+ break;
+
+ udelay(1);
+ } while (usec-- 0);
+
+ if (!usec)
+ dev_err(phy_drd-dev,
+
[PATCH v5 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/xhci-plat.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..56ef9cf 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -180,6 +181,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+ hcd-gen_phy = devm_phy_get(pdev-dev, usb2-phy);
+ if (IS_ERR(hcd-gen_phy)) {
+ ret = PTR_ERR(hcd-gen_phy);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ else if (ret != -ENOSYS ret != -ENODEV)
+ dev_warn(pdev-dev,
+Error retrieving usb2 phy: %d\n, ret);
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
@@ -209,6 +221,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci-hcc_params) = 4)
xhci-shared_hcd-can_do_streams = 1;
+ /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+ xhci-shared_hcd-gen_phy = devm_phy_get(pdev-dev, usb3-phy);
+ if (IS_ERR(xhci-shared_hcd-gen_phy)) {
+ ret = PTR_ERR(xhci-shared_hcd-gen_phy);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ else if (ret != -ENOSYS ret != -ENODEV)
+ dev_warn(pdev-dev,
+Error retrieving usb3 phy: %d\n, ret);
+ }
+
ret = usb_add_hcd(xhci-shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/4] phy: Add provision for calibrating phy.
Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.
Signed-off-by: vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-core.c | 36
include/linux/phy/phy.h |8
2 files changed, 44 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 834b337..c8cb3de 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -393,6 +393,42 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_calibrate - calibrate a phy post initialization
+ * @phy: Pointer to 'phy' from consumer
+ *
+ * For certain PHYs, it may be needed to calibrate few phy parameters
+ * post initialization. The need to calibrate may arise after the
+ * initialization of consumer itself, in order to prevent further any
+ * loss of phy settings post consumer-initialization.
+ * example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such
+ * phy which needs calibration after the host controller reset
+ * has happened.
+ */
+int phy_calibrate(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ if (!phy)
+ return 0;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-calibrate) {
+ ret = phy-ops-calibrate(phy);
+ if (ret 0) {
+ dev_err(phy-dev,
+ phy calibration failed -- %d\n, ret);
+ goto out;
+ }
+ }
+
+out:
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
+/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index d983051..c70a311 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @calibrate: calibrate the phy post init
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -35,6 +36,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*calibrate)(struct phy *phy);
struct module *owner;
};
@@ -126,6 +128,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_calibrate(struct phy *phy);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy-attrs.bus_width;
@@ -231,6 +234,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_calibrate(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/4] Fine tune USB 3.0 PHY on exynos5420
This series is based on Heikki's patches for simpliefied phy lookup table: [PATCHv3 0/6] phy: simplified phy lookup [1], applied against 'usb-next' branch alongwith Sergei's patch for adding generic phy support to usb hcd [2]. Changes since v4: - Rebased on latest patches by Heikki. - Took care of handling -EPROBE_DEFER error number while getting PHY in xhci plat. Changes from v3: - Modified error message as per review comments from Julius. Changes since v2: - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy, in order to make it more generic. - Moved the phy_calibration calls to core/hcd.c to enable a more generic solution for issues of calibrating the PHYs. Changes since v1: - Using 'gen_phy' member of 'hcd' instead of declaring more variables to hold phys. - Added a check for compatible match for 'Synopsys-dwc3' controller, since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that, instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs (main hcd and shared hcd). - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()' to use hcd-gen_phy directly. Also added the check for Synopsys's DWC3 controller while trying to calibrate the PHY. Explanation for the need of this patch-series: The DWC3-exynos eXtensible host controller present on Exynos5420/5800 SoCs is quirky. The PHY serving this controller operates at High-Speed by default, so it detects even Super-speed devices as high-speed ones. Certain PHY parameters like Tx LOS levels and Boost levels need to be calibrated further post initialization of xHCI controller, to get SuperSpeed operations working. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html [2] http://comments.gmane.org/gmane.linux.ports.sh.devel/35932 Vivek Gautam (4): phy: Add provision for calibrating phy. usb: host: xhci-plat: Get PHYs for xhci's hcds usb: hcd: Caibrate PHY post hcd reset phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800 drivers/phy/phy-core.c | 36 drivers/phy/phy-exynos5-usbdrd.c | 169 ++ drivers/usb/core/hcd.c | 22 + drivers/usb/host/xhci-plat.c | 23 ++ include/linux/phy/phy.h |8 ++ 5 files changed, 258 insertions(+) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: composite: dequeue cdev-req before free it in composite_dev_cleanup
On Wed, Aug 20, 2014 at 03:18:47PM -0400, Alan Stern wrote:
On Wed, 20 Aug 2014, Felipe Balbi wrote:
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct
usb_composite_dev *cdev)
}
if (cdev-req) {
kfree(cdev-req-buf);
+ usb_ep_dequeue(cdev-gadget-ep0, cdev-req);
it's best to dequeue the request before freeing its buffer.
In fact, it's best to wait for the request's completion routine
to be called before freeing the buffer. The hardware can access
the buffer's memory at any time before the completion routine
runs.
dequeue should cause the transfer to be cancelled and given back.
There's a slight possible race window because we release the
controller lock in order to call gadget driver's -complete().
The dp has already been pulled down and the flush pending FIFO buffer
has finished, so the controller should not try to access memory buffer
after that.
In that case, why does the patch add a call to usb_ep_dequeue()?
Shouldn't the request be unlinked already?
I mean the controller should not try to access memory buffer after flush
pending buffer which should be done at usb_ep_dequeue, so it is safe we free
the request buffer after usb_ep_dequeue
Other than that, it should be fine. No ?
Dequeue causes the transfer to be cancelled and given back, yes.
But
usb_ep_dequeue() is allowed to return before those things happen.
If usb_ep_dequeue is returned before doing any flush and cancel
transfer, it means there is no request on the queue, we don't need to
cancel any requests.
It can be different for different UDCs. The documentation doesn't say
that usb_ep_dequeue has to wait until the transfer has been cancelled and
flushed.
I think it should add this content, it is strange that we still need to
Wait the transfer has finished/cancelled after calling dequeue, we de-queue
the request, of cos we hope the request has finished, and its resource can be
re-used again.
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
[PATCH] usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps
Commit 30a70b026b4cd (usb: musb: fix obex in g_nokia.ko causing kernel
panic) attempted to fix runtime PM handling for PHYs that are on the
I2C bus. Commit 3063a12be2b0 (usb: musb: fix PHY power on/off) then
changed things around to enable of PHYs that rely on runtime PM.
These changes however broke idling of the PHY and causes at least
100 mW extra power consumption on omaps, which is a lot with
the idle power consumption being below 10 mW range on many devices.
As calling phy_power_on/off from runtime PM calls in the USB
causes complicated issues with I2C connected PHYs, let's just let
the PHY do it's own runtime PM as needed. This leaves out the
dependency between PHYs and USB controller drivers for runtime
PM.
Let's fix the regression for twl4030-usb by adding minimal runtime
PM support. This allows idling the PHY on disconnect.
Note that we are changing to use standard runtime PM handling
for twl4030_phy_init() as that function just checks the state
and does not initialize the PHY. The PHY won't get initialized
until in twl4030_phy_power_on().
Fixes: 30a70b026b4cd (usb: musb: fix obex in g_nokia.ko causing kernel panic)
Fixes: 3063a12be2b0 (usb: musb: fix PHY power on/off)
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Tony Lindgren t...@atomide.com
---
Kishon, this regression fix would be nice to get into the v3.17-rc
series if no objections. If you don't have other fixes, I can also
queue via arm-soc with proper acks.
It probably does not make sense to try to fix this without using
runtime PM without complicating the code further.
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -34,6 +34,7 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/phy/phy.h
+#include linux/pm_runtime.h
#include linux/usb/musb-omap.h
#include linux/usb/ulpi.h
#include linux/i2c/twl.h
@@ -422,37 +423,55 @@ static void twl4030_phy_power(struct twl4030_usb *twl,
int on)
}
}
-static int twl4030_phy_power_off(struct phy *phy)
+static int twl4030_usb_runtime_suspend(struct device *dev)
{
- struct twl4030_usb *twl = phy_get_drvdata(phy);
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ dev_dbg(twl-dev, %s\n, __func__);
if (twl-asleep)
return 0;
twl4030_phy_power(twl, 0);
twl-asleep = 1;
- dev_dbg(twl-dev, %s\n, __func__);
+
return 0;
}
-static void __twl4030_phy_power_on(struct twl4030_usb *twl)
+static int twl4030_usb_runtime_resume(struct device *dev)
{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+
+ dev_dbg(twl-dev, %s\n, __func__);
+ if (!twl-asleep)
+ return 0;
+
twl4030_phy_power(twl, 1);
- twl4030_i2c_access(twl, 1);
- twl4030_usb_set_mode(twl, twl-usb_mode);
- if (twl-usb_mode == T2_USB_MODE_ULPI)
- twl4030_i2c_access(twl, 0);
+ twl-asleep = 0;
+
+ return 0;
+}
+
+static int twl4030_phy_power_off(struct phy *phy)
+{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+ dev_dbg(twl-dev, %s\n, __func__);
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ return 0;
}
static int twl4030_phy_power_on(struct phy *phy)
{
struct twl4030_usb *twl = phy_get_drvdata(phy);
- if (!twl-asleep)
- return 0;
- __twl4030_phy_power_on(twl);
- twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+ pm_runtime_get_sync(twl-dev);
+ twl4030_i2c_access(twl, 1);
+ twl4030_usb_set_mode(twl, twl-usb_mode);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
/*
* XXX When VBUS gets driven after musb goes to A mode,
@@ -558,6 +577,16 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
* USB_LINK_VBUS state. musb_hdrc won't care until it
* starts to handle softconnect right.
*/
+ if ((status == OMAP_MUSB_VBUS_VALID) ||
+ (status == OMAP_MUSB_ID_GROUND)) {
+ if (twl-asleep)
+ pm_runtime_get_sync(twl-dev);
+ } else {
+ if (!twl-asleep) {
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
+ }
+ }
omap_musb_mailbox(status);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
@@ -599,22 +628,17 @@ static int twl4030_phy_init(struct phy *phy)
struct twl4030_usb *twl = phy_get_drvdata(phy);
enum omap_musb_vbus_id_status status;
- /*
-* Start in sleep state, we'll get called through set_suspend()
-* callback when musb is runtime resumed and it's time to start.
-*/
- __twl4030_phy_power(twl, 0);
- twl-asleep = 1;
-
+ pm_runtime_get_sync(twl-dev);
[PATCH] usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down
Commit 249751f22380 (usb: phy: twl4030-usb: poll for ID disconnect)
added twl4030_id_workaround_work() to deal with lost interrupts
after ID pin goes down. However, this currently only works for the
insertion. The PHY interrupts are not working after disconnecting
an USB-A device from the board, and the deeper idle states for
omap are blocked as the USB controller stays busy.
The issue can be solved by calling delayed work from twl4030_usb_irq()
when ID pin is down and the PHY is not asleep like we already do
in twl4030_id_workaround_work().
But as both twl4030_usb_irq() and twl4030_id_workaround_work()
already do pretty much the same thing, let's call twl4030_usb_irq()
from twl4030_id_workaround_work() instead of adding some more
duplicate code.
Fixes: 249751f22380 (usb: phy: twl4030-usb: poll for ID disconnect)
Cc: sta...@vger.kernel.org # v3.12+
Signed-off-by: Tony Lindgren t...@atomide.com
---
This too is intended for the v3.17-rc cycle if no objections.
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -589,6 +589,13 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
}
omap_musb_mailbox(status);
}
+
+ /* don't schedule during sleep - irq works right then */
+ if (status == OMAP_MUSB_ID_GROUND !twl-asleep) {
+ cancel_delayed_work(twl-id_workaround_work);
+ schedule_delayed_work(twl-id_workaround_work, HZ);
+ }
+
sysfs_notify(twl-dev-kobj, NULL, vbus);
return IRQ_HANDLED;
@@ -598,29 +605,8 @@ static void twl4030_id_workaround_work(struct work_struct
*work)
{
struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
id_workaround_work.work);
- enum omap_musb_vbus_id_status status;
- bool status_changed = false;
-
- status = twl4030_usb_linkstat(twl);
- spin_lock_irq(twl-lock);
- if (status = 0 status != twl-linkstat) {
- twl-linkstat = status;
- status_changed = true;
- }
- spin_unlock_irq(twl-lock);
-
- if (status_changed) {
- dev_dbg(twl-dev, handle missing status change to %d\n,
- status);
- omap_musb_mailbox(status);
- }
-
- /* don't schedule during sleep - irq works right then */
- if (status == OMAP_MUSB_ID_GROUND !twl-asleep) {
- cancel_delayed_work(twl-id_workaround_work);
- schedule_delayed_work(twl-id_workaround_work, HZ);
- }
+ twl4030_usb_irq(0, twl);
}
static int twl4030_phy_init(struct phy *phy)
--
To unsubscribe from this list: send the line unsubscribe 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: phy: twl4030-usb: Fix regressions to runtime PM on omaps
On Thu, Aug 21, 2014 at 09:43:46AM -0700, Tony Lindgren wrote:
Commit 30a70b026b4cd (usb: musb: fix obex in g_nokia.ko causing kernel
panic) attempted to fix runtime PM handling for PHYs that are on the
I2C bus. Commit 3063a12be2b0 (usb: musb: fix PHY power on/off) then
changed things around to enable of PHYs that rely on runtime PM.
These changes however broke idling of the PHY and causes at least
100 mW extra power consumption on omaps, which is a lot with
the idle power consumption being below 10 mW range on many devices.
As calling phy_power_on/off from runtime PM calls in the USB
causes complicated issues with I2C connected PHYs, let's just let
the PHY do it's own runtime PM as needed. This leaves out the
dependency between PHYs and USB controller drivers for runtime
PM.
Let's fix the regression for twl4030-usb by adding minimal runtime
PM support. This allows idling the PHY on disconnect.
Note that we are changing to use standard runtime PM handling
for twl4030_phy_init() as that function just checks the state
and does not initialize the PHY. The PHY won't get initialized
until in twl4030_phy_power_on().
Fixes: 30a70b026b4cd (usb: musb: fix obex in g_nokia.ko causing kernel
panic)
Fixes: 3063a12be2b0 (usb: musb: fix PHY power on/off)
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Tony Lindgren t...@atomide.com
---
Kishon, this regression fix would be nice to get into the v3.17-rc
series if no objections. If you don't have other fixes, I can also
queue via arm-soc with proper acks.
It probably does not make sense to try to fix this without using
runtime PM without complicating the code further.
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -34,6 +34,7 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/phy/phy.h
+#include linux/pm_runtime.h
#include linux/usb/musb-omap.h
#include linux/usb/ulpi.h
#include linux/i2c/twl.h
@@ -422,37 +423,55 @@ static void twl4030_phy_power(struct twl4030_usb *twl,
int on)
}
}
-static int twl4030_phy_power_off(struct phy *phy)
+static int twl4030_usb_runtime_suspend(struct device *dev)
{
- struct twl4030_usb *twl = phy_get_drvdata(phy);
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ dev_dbg(twl-dev, %s\n, __func__);
if (twl-asleep)
return 0;
twl4030_phy_power(twl, 0);
twl-asleep = 1;
- dev_dbg(twl-dev, %s\n, __func__);
+
return 0;
}
-static void __twl4030_phy_power_on(struct twl4030_usb *twl)
+static int twl4030_usb_runtime_resume(struct device *dev)
{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+
+ dev_dbg(twl-dev, %s\n, __func__);
+ if (!twl-asleep)
+ return 0;
+
twl4030_phy_power(twl, 1);
- twl4030_i2c_access(twl, 1);
- twl4030_usb_set_mode(twl, twl-usb_mode);
- if (twl-usb_mode == T2_USB_MODE_ULPI)
- twl4030_i2c_access(twl, 0);
+ twl-asleep = 0;
+
+ return 0;
+}
+
+static int twl4030_phy_power_off(struct phy *phy)
+{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+ dev_dbg(twl-dev, %s\n, __func__);
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ return 0;
}
static int twl4030_phy_power_on(struct phy *phy)
{
struct twl4030_usb *twl = phy_get_drvdata(phy);
- if (!twl-asleep)
- return 0;
- __twl4030_phy_power_on(twl);
- twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+ pm_runtime_get_sync(twl-dev);
+ twl4030_i2c_access(twl, 1);
+ twl4030_usb_set_mode(twl, twl-usb_mode);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
/*
* XXX When VBUS gets driven after musb goes to A mode,
@@ -558,6 +577,16 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
* USB_LINK_VBUS state. musb_hdrc won't care until it
* starts to handle softconnect right.
*/
+ if ((status == OMAP_MUSB_VBUS_VALID) ||
+ (status == OMAP_MUSB_ID_GROUND)) {
+ if (twl-asleep)
+ pm_runtime_get_sync(twl-dev);
+ } else {
+ if (!twl-asleep) {
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
+ }
+ }
omap_musb_mailbox(status);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
@@ -599,22 +628,17 @@ static int twl4030_phy_init(struct phy *phy)
struct twl4030_usb *twl = phy_get_drvdata(phy);
enum omap_musb_vbus_id_status status;
- /*
- * Start in sleep state, we'll get called through set_suspend()
- * callback when musb is runtime resumed and it's time to start.
- */
-
Re: [PATCH] usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down
On Thu, Aug 21, 2014 at 09:48:04AM -0700, Tony Lindgren wrote: Commit 249751f22380 (usb: phy: twl4030-usb: poll for ID disconnect) added twl4030_id_workaround_work() to deal with lost interrupts after ID pin goes down. However, this currently only works for the insertion. The PHY interrupts are not working after disconnecting an USB-A device from the board, and the deeper idle states for omap are blocked as the USB controller stays busy. The issue can be solved by calling delayed work from twl4030_usb_irq() when ID pin is down and the PHY is not asleep like we already do in twl4030_id_workaround_work(). But as both twl4030_usb_irq() and twl4030_id_workaround_work() already do pretty much the same thing, let's call twl4030_usb_irq() from twl4030_id_workaround_work() instead of adding some more duplicate code. Fixes: 249751f22380 (usb: phy: twl4030-usb: poll for ID disconnect) Cc: sta...@vger.kernel.org # v3.12+ Signed-off-by: Tony Lindgren t...@atomide.com looks ok to me: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps
* Felipe Balbi ba...@ti.com [140821 10:09]: On Thu, Aug 21, 2014 at 09:43:46AM -0700, Tony Lindgren wrote: @@ -744,6 +778,9 @@ static int twl4030_usb_probe(struct platform_device *pdev) return status; } + pm_runtime_mark_last_busy(pdev-dev); + pm_runtime_put(pdev-dev); don't you wanna do a put_autosuspend() here instead ? Sure yeah makes sense as the twl4030_phy_init() usually runs shortly after. Other than that Acked-by: Felipe Balbi ba...@ti.com Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Tegra xHCI support
On Thu, Aug 21, 2014 at 6:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 18 August 2014 19:08, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware from the ChromiumOS tree [2]. Hi Andrew, do you have any information regarding the port assignments for the Blaze board? Would like to test this there. Sure: - USB3 port 0 (using PCIe lane 0) and UTMI port 0 are connected to the USB A connector on the left side, - UTMI port 1 is connected to an internal hub, which is in turn connected to the camera, the LTE modem (if present), and one of the USB A connectors on the right side, and - UTMI port 2 is connected to the other USB A connector on the right side. The mapping of ports on the right side varies by SKU (i.e. the one on the internal hub may be the front or rear USB A port). The USB3 device tree bits for Venice2 should work just fine for Blaze; the only real difference is that USB3 port 1/PCIe lane 1 are unused. Also, because of the board design on Blaze, the fused HS_CURR_LEVEL values need to be adjusted before being programmed into USB2_OTG_PAD*_CTL0. This only affects UTMI ports 0 and 2, so ports connected to the internal hub should still work. I'll add a pinconfig property to address this in the likely event I need to re-spin this series. Or, if you like, I can send a follow-on patch to this set to add the property. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/4] r8152: remove clear_bp function
On 08/21/2014 06:12 AM, Hayes Wang wrote: [...] r8152b_disable_aldps(tp); - rtl_clear_bp(tp); Why leave 2 empty lines? One is enough. The next patch would use another fucntion at the same location. I skip removing the empty line and re-adding it again. Is that better to do so? I would resend the patches if the answer is yes. Sorry, I haven't looked at your next patch, too big for me. :-) Best Regards, Hayes 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: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Thu, 21 Aug 2014, Christoph Hellwig wrote:
On Thu, Aug 21, 2014 at 10:41:02AM -0400, Douglas Gilbert wrote:
Perhaps we could add another bit flag in struct
scsi_host_template such as:
unsigned int transport_says_dont_scsi2_lun_cmd:1;
then drivers/usb/storage/scsiglue.c could set that
bit in its usb_stor_host_template and
drivers/scsi/scsi.c could take heed (and not mask
cmd-cmnd[1] with the LUN).
Fully agreed.
(except that I'd shorten the flag name to .no_scsi2lun :))
Okay, here's a patch that implements the suggestion, except that I put
the flag in the Scsi_Host structure instead of the template. This was
to minimize the impact of the change. Among the various SCSI-over-USB
transports, only the Bulk-Only transport gives the LUN separately from
the CDB. I don't know if there are any multi-LUN USB devices that
don't use the Bulk-Only transport, but if there are then they won't
work if the LUN isn't stored in CDB[1].
Tiziano, does this do what you want?
Alan Stern
Index: usb-3.16/include/scsi/scsi_host.h
===
--- usb-3.16.orig/include/scsi/scsi_host.h
+++ usb-3.16/include/scsi/scsi_host.h
@@ -695,6 +695,9 @@ struct Scsi_Host {
/* The controller does not support WRITE SAME */
unsigned no_write_same:1;
+ /* The transport requires the LUN bits NOT to be stored in CDB[1] */
+ unsigned no_scsi2_lun:1;
+
/*
* Optional work queue to be utilized by the transport
*/
Index: usb-3.16/drivers/scsi/scsi.c
===
--- usb-3.16.orig/drivers/scsi/scsi.c
+++ usb-3.16/drivers/scsi/scsi.c
@@ -678,7 +678,8 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
* If SCSI-2 or lower, store the LUN value in cmnd.
*/
if (cmd-device-scsi_level = SCSI_2
- cmd-device-scsi_level != SCSI_UNKNOWN) {
+ cmd-device-scsi_level != SCSI_UNKNOWN
+ !host-no_scsi2_lun) {
cmd-cmnd[1] = (cmd-cmnd[1] 0x1f) |
(cmd-device-lun 5 0xe0);
}
Index: usb-3.16/drivers/usb/storage/usb.c
===
--- usb-3.16.orig/drivers/usb/storage/usb.c
+++ usb-3.16/drivers/usb/storage/usb.c
@@ -981,6 +981,14 @@ int usb_stor_probe2(struct us_data *us)
if (!(us-fflags US_FL_SCM_MULT_TARG))
us_to_host(us)-max_id = 1;
+ /*
+* Like Windows, we won't store the LUN bits in CDB[1] for SCSI-2
+* devices using the Bulk-Only transport (even though this violates
+* the SCSI spec).
+*/
+ if (us-transport == usb_stor_Bulk_transport)
+ us_to_host(us)-no_scsi2_lun = 1;
+
/* Find the endpoints and calculate pipe values */
result = get_pipes(us);
if (result)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB reset xhci_hcd for ELAN touchscreen
On Thu, 21 Aug 2014, Johan Hovold wrote:
It's not really super-nice, but if no other way around it has been found
to be possible in USB core, I am willing to take this.
Agreed, it's not that nice, but I'm not aware of any other way to
prevent the device firmware from disconnecting.
Autosuspend still seems to work, so it would not cause much overhead
for people not actually using the touchscreen (as long as autosuspend
is enabled) either.
Okay, good. Will be waiting for your polished patch for this.
[ ... snip ... ]
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 77632cf..13f81ae 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -286,6 +286,7 @@ struct hid_item {
#define HID_QUIRK_HIDINPUT_FORCE 0x0080
#define HID_QUIRK_NO_EMPTY_INPUT 0x0100
#define HID_QUIRK_NO_INIT_INPUT_REPORTS 0x0200
+#define HID_QUIRK_IN 0x0400
0x0400 has been removed before dynamic quirks started to be possible,
so there is no potential clash, that's fine.
I'd just propose some more descriptive name for the quirk ... how about
something like HID_QUIRK_EARLY_INTERRUPT?
Yeah, IN was just a working name. How about HID_QUIRK_ALWAYS_POLL or
similar as it is not just about disconnect before the device is opened,
but also if there's an event after the device has been closed (e.g.
stopping X)?
HID_QUIRK_ALWAYS_POLL sounds good.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: composite: dequeue cdev-req before free it in composite_dev_cleanup
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern Sent: Thursday, August 21, 2014 8:38 AM On Thu, 21 Aug 2014, Peter Chen wrote: dequeue should cause the transfer to be cancelled and given back. There's a slight possible race window because we release the controller lock in order to call gadget driver's -complete(). The dp has already been pulled down and the flush pending FIFO buffer has finished, so the controller should not try to access memory buffer after that. In that case, why does the patch add a call to usb_ep_dequeue()? Shouldn't the request be unlinked already? I mean the controller should not try to access memory buffer after flush pending buffer which should be done at usb_ep_dequeue, so it is safe we free the request buffer after usb_ep_dequeue Host controller hardware most definitely _does_ continue to access buffer memory after a dequeue, because the hardware caches the transfer descriptors. I don't know how similar device controller hardware is to host controller hardware, but it certainly seems possible that there could be similar caching going on. It can be different for different UDCs. The documentation doesn't say that usb_ep_dequeue has to wait until the transfer has been cancelled and flushed. I think it should add this content, it is strange that we still need to Wait the transfer has finished/cancelled after calling dequeue, we de-queue the request, of cos we hope the request has finished, and its resource can be re-used again. That is not true for usb_unlink_urb(). So why should it be true for usb_ep_dequeue()? Maybe what you want is something like usb_kill_urb(), for the gadget stack. AFAIK, it has always been a requirement that usb_ep_dequeue() release the data buffer and call the urb's completion routine before it returns. Quite a few of the function drivers depend on that, after the call to usb_ep_dequeue() they immediately free the data buffer. So if it's not explicitly documented like that, it should be. -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: composite: dequeue cdev-req before free it in composite_dev_cleanup
On Thu, 21 Aug 2014, Paul Zimmerman wrote: AFAIK, it has always been a requirement that usb_ep_dequeue() release the data buffer and call the urb's completion routine before it returns. Hmmm. I don't know if that really has been a requirement, but it does seem to be true in the UDC drivers I'm familiar with. Quite a few of the function drivers depend on that, after the call to usb_ep_dequeue() they immediately free the data buffer. So if it's not explicitly documented like that, it should be. Okay, would you like to write a documentation patch? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: composite: dequeue cdev-req before free it in composite_dev_cleanup
From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Thursday, August 21, 2014 12:16 PM On Thu, 21 Aug 2014, Paul Zimmerman wrote: AFAIK, it has always been a requirement that usb_ep_dequeue() release the data buffer and call the urb's completion routine before it returns. Hmmm. I don't know if that really has been a requirement, but it does seem to be true in the UDC drivers I'm familiar with. Quite a few of the function drivers depend on that, after the call to usb_ep_dequeue() they immediately free the data buffer. So if it's not explicitly documented like that, it should be. Okay, would you like to write a documentation patch? Something like this? I didn't find any references to usp_ep_dequeue() under Documentation/, so I guess the only place is the kerneldoc in the header. I also fixed up some strange capitalization in the existing text while I was there. If this looks OK to you I will send a proper patch submission to Felipe. [PATCH] usb: gadget: document a usb_ep_dequeue() requirement Document the requirement that the request be dequeued and its completion routine called before usb_ep_dequeue() returns. diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index c3a6185..c540557 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -345,12 +345,13 @@ static inline int usb_ep_queue(struct usb_ep *ep, * @ep:the endpoint associated with the request * @req:the request being canceled * - * if the request is still active on the endpoint, it is dequeued and its + * If the request is still active on the endpoint, it is dequeued and its * completion routine is called (with status -ECONNRESET); else a negative - * error code is returned. + * error code is returned. This is guaranteed to happen before the call to + * usb_ep_dequeue() returns. * - * note that some hardware can't clear out write fifos (to unlink the request - * at the head of the queue) except as part of disconnecting from usb. such + * Note that some hardware can't clear out write fifos (to unlink the request + * at the head of the queue) except as part of disconnecting from usb. Such * restrictions prevent drivers from supporting configuration changes, * even to configuration zero (a chapter 9 requirement). */ -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: composite: dequeue cdev-req before free it in composite_dev_cleanup
On Thu, 21 Aug 2014, Paul Zimmerman wrote: From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Thursday, August 21, 2014 12:16 PM On Thu, 21 Aug 2014, Paul Zimmerman wrote: AFAIK, it has always been a requirement that usb_ep_dequeue() release the data buffer and call the urb's completion routine before it returns. Hmmm. I don't know if that really has been a requirement, but it does seem to be true in the UDC drivers I'm familiar with. Quite a few of the function drivers depend on that, after the call to usb_ep_dequeue() they immediately free the data buffer. So if it's not explicitly documented like that, it should be. Okay, would you like to write a documentation patch? Something like this? I didn't find any references to usp_ep_dequeue() under Documentation/, so I guess the only place is the kerneldoc in the header. Yes, that's where it is. I also fixed up some strange capitalization in the existing text while I was there. If this looks OK to you I will send a proper patch submission to Felipe. [PATCH] usb: gadget: document a usb_ep_dequeue() requirement Document the requirement that the request be dequeued and its completion routine called before usb_ep_dequeue() returns. diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index c3a6185..c540557 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -345,12 +345,13 @@ static inline int usb_ep_queue(struct usb_ep *ep, * @ep:the endpoint associated with the request * @req:the request being canceled * - * if the request is still active on the endpoint, it is dequeued and its + * If the request is still active on the endpoint, it is dequeued and its * completion routine is called (with status -ECONNRESET); else a negative - * error code is returned. + * error code is returned. This is guaranteed to happen before the call to + * usb_ep_dequeue() returns. * - * note that some hardware can't clear out write fifos (to unlink the request - * at the head of the queue) except as part of disconnecting from usb. such + * Note that some hardware can't clear out write fifos (to unlink the request + * at the head of the queue) except as part of disconnecting from usb. Such * restrictions prevent drivers from supporting configuration changes, * even to configuration zero (a chapter 9 requirement). */ Looks good to me. Acked-by: Alan Stern st...@rowland.harvard.edu Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: composite: dequeue cdev-req before free it in composite_dev_cleanup
On Thu, Aug 21, 2014 at 03:55:13PM -0400, Alan Stern wrote: On Thu, 21 Aug 2014, Paul Zimmerman wrote: From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Thursday, August 21, 2014 12:16 PM On Thu, 21 Aug 2014, Paul Zimmerman wrote: AFAIK, it has always been a requirement that usb_ep_dequeue() release the data buffer and call the urb's completion routine before it returns. Hmmm. I don't know if that really has been a requirement, but it does seem to be true in the UDC drivers I'm familiar with. Quite a few of the function drivers depend on that, after the call to usb_ep_dequeue() they immediately free the data buffer. So if it's not explicitly documented like that, it should be. Okay, would you like to write a documentation patch? Something like this? I didn't find any references to usp_ep_dequeue() under Documentation/, so I guess the only place is the kerneldoc in the header. Yes, that's where it is. I also fixed up some strange capitalization in the existing text while I was there. If this looks OK to you I will send a proper patch submission to Felipe. [PATCH] usb: gadget: document a usb_ep_dequeue() requirement Document the requirement that the request be dequeued and its completion routine called before usb_ep_dequeue() returns. diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index c3a6185..c540557 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -345,12 +345,13 @@ static inline int usb_ep_queue(struct usb_ep *ep, * @ep:the endpoint associated with the request * @req:the request being canceled * - * if the request is still active on the endpoint, it is dequeued and its + * If the request is still active on the endpoint, it is dequeued and its * completion routine is called (with status -ECONNRESET); else a negative - * error code is returned. + * error code is returned. This is guaranteed to happen before the call to + * usb_ep_dequeue() returns. * - * note that some hardware can't clear out write fifos (to unlink the request - * at the head of the queue) except as part of disconnecting from usb. such + * Note that some hardware can't clear out write fifos (to unlink the request + * at the head of the queue) except as part of disconnecting from usb. Such * restrictions prevent drivers from supporting configuration changes, * even to configuration zero (a chapter 9 requirement). */ Looks good to me. Acked-by: Alan Stern st...@rowland.harvard.edu Thanks Alan and Paul :-) Paul, can you just send this as a formal patch with Alan's Acked-by ? Thank you -- balbi signature.asc Description: Digital signature
[PATCH] usb: gadget: document a usb_ep_dequeue() requirement
Document the requirement that the request be dequeued and its completion routine called before usb_ep_dequeue() returns. Also fix some capitalization issues in the existing text. Signed-off-by: Paul Zimmerman pa...@synopsys.com Acked-by: Alan Stern st...@rowland.harvard.edu --- include/linux/usb/gadget.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index c3a6185..c540557 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -345,12 +345,13 @@ static inline int usb_ep_queue(struct usb_ep *ep, * @ep:the endpoint associated with the request * @req:the request being canceled * - * if the request is still active on the endpoint, it is dequeued and its + * If the request is still active on the endpoint, it is dequeued and its * completion routine is called (with status -ECONNRESET); else a negative - * error code is returned. + * error code is returned. This is guaranteed to happen before the call to + * usb_ep_dequeue() returns. * - * note that some hardware can't clear out write fifos (to unlink the request - * at the head of the queue) except as part of disconnecting from usb. such + * Note that some hardware can't clear out write fifos (to unlink the request + * at the head of the queue) except as part of disconnecting from usb. Such * restrictions prevent drivers from supporting configuration changes, * even to configuration zero (a chapter 9 requirement). */ -- 2.0.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: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
Alan == Alan Stern st...@rowland.harvard.edu writes: Alan Okay, here's a patch that implements the suggestion, except that I Alan put the flag in the Scsi_Host structure instead of the template. Alan This was to minimize the impact of the change. Among the various Alan SCSI-over-USB transports, only the Bulk-Only transport gives the Alan LUN separately from the CDB. I don't know if there are any Alan multi-LUN USB devices that don't use the Bulk-Only transport, but Alan if there are then they won't work if the LUN isn't stored in Alan CDB[1]. I'm in agreement with this approach. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe 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: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Thu, Aug 21, 2014 at 05:43:41PM -0400, Martin K. Petersen wrote: Alan Okay, here's a patch that implements the suggestion, except that I Alan put the flag in the Scsi_Host structure instead of the template. Alan This was to minimize the impact of the change. Among the various Alan SCSI-over-USB transports, only the Bulk-Only transport gives the Alan LUN separately from the CDB. I don't know if there are any Alan multi-LUN USB devices that don't use the Bulk-Only transport, but Alan if there are then they won't work if the LUN isn't stored in Alan CDB[1]. I'm in agreement with this approach. I like it too. One idea to unclutter the fastpath would be to have a single flag that controls if the LUN is set which is based on the host(-template) flag and the scsi level, which would allow us to remove all the clutter around that area. -- To unsubscribe from this list: send the line unsubscribe 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: add support for Diolan DLN-2 devices
On Thu, Aug 21, 2014 at 11:07 AM, Johan Hovold jo...@kernel.org wrote: On Wed, Aug 20, 2014 at 02:24:45PM +0300, Daniel Baluta wrote: From: Octavian Purdila octavian.purd...@intel.com This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO Master Adapter DLN-2. Details about the device can be found here: snip I think you want to implement this driver as an MFD driver, rather than invent your own module registration. Hi Johan, Thank you for the detailed reviewed. We will rewrite the drivers to use the MFD interface and address the rest of your comments and we will resubmit them next week. Thanks, Tavi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next 3/4] r8152: remove clear_bp function
Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] [...] Why leave 2 empty lines? One is enough. The next patch would use another fucntion at the same location. I skip removing the empty line and re-adding it again. Is that better to do so? I would resend the patches if the answer is yes. Sorry, I haven't looked at your next patch, too big for me. :-) It's my mistake. I would avoid it next time. Thanks for your notice. Best Regards, Hayes -- To unsubscribe from this list: send the line unsubscribe 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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor
On 08/21/2014 04:24 PM, Sebastian Andrzej Siewior wrote:
On 08/20/2014 02:13 AM, Peter Chen wrote:
Thanks, so Xunbing, the imx6 hardware (chipidea core) have 8 endpoints,
and support all four transfer type, it should be no problem to support
RNDIS.
But you shouldn't use RNDIS on Windows 7 or 8. As far as I recall they
do not bring the RNDIS driver which is deprecated and only supported
by Windows XP which is EOL by now.
Windows 7 and 8 support CDC [0] and this is what you should look for.
[0]
http://msdn.microsoft.com/en-us/library/windows/hardware/ff538820%28v=vs.85%29.aspx
Sebastian
Sebastian, Peter, Andrzej,
Thank you for your help.
1) Are you aware of any devices (based on Freescale i.MX or ChipIdea USB
IP) with a gadget driver which uses .bAlternateSetting that support
Windows 7/8?
2) The reason I am asking this is that USB 1.1 Spec (section 9.2.6.4
Standard Device Requests) says: For standard device requests that
require no Data stage, a device *must* be able to complete the request
and be able to successfully complete the Status stage of the request
*within 50 ms* of receipt of the request. This limitation applies to
requests to the device, interface, or endpoint.
I am debugging this Windows support for UAC1, thus I am referring to USB
1.1 spec.
3) For any gadget which uses .bAlternateSetting, Host will send
USB_REQ_SET_INTERFACE Standard Device Request which requires no Data
State. I am not sure if Windows drivers strictly adhere to USB spec,
thus strictly require device to respond to USB_REQ_SET_INTERFACE within
50ms???
4) In gadget driver set_alt functions (to handle USB_REQ_SET_INTERFACE),
ep_enable/ep_disable will be called, and timing of this differs from
hardware platform to platform (and UDC drivers), does this explain why
below function exists???
4.1) /**
* gadget_supports_altsettings - return true if altsettings work
* @gadget: the gadget in question
*/
static inline bool gadget_supports_altsettings(struct usb_gadget *gadget)
{
/* PXA 21x/25x/26x has no altsettings at all */
if (gadget_is_pxa(gadget))
return false;
/* PXA 27x and 3xx have *broken* altsetting support */
if (gadget_is_pxa27x(gadget))
return false;
/* Everything else is *presumably* fine ... */
return true;
}
4.2) /* Some controllers can't support CDC Ethernet (ECM) ... */
static inline bool can_support_ecm(struct usb_gadget *gadget)
{
if (!gadget_supports_altsettings(gadget))
return false;
/* Everything else is *presumably* fine ... but this is a bit
* chancy, so be **CERTAIN** there are no hardware issues with
* your controller. Add it above if it can't handle CDC.
*/
return true;
}
Thanks again.
--
Thanks,
Xuebing Wang
--
To unsubscribe from this list: send the line unsubscribe 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 4/6] usb: common: add API to get if the platform supports TPL
On Thu, Aug 21, 2014 at 12:14:42AM +0800, Felipe Balbi wrote:
Hi,
On Tue, Aug 19, 2014 at 09:51:55AM +0800, Peter Chen wrote:
The TPL (Targeted Peripheral List) is used for targeted hosts
(non-PC hosts), and it can be used at USB OTG EH certification
and some specific products which need white list.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/common/usb-common.c | 15 +++
include/linux/usb/of.h |5 +
2 files changed, 20 insertions(+)
diff --git a/drivers/usb/common/usb-common.c
b/drivers/usb/common/usb-common.c
index 6dfd30a..b530fd4 100644
--- a/drivers/usb/common/usb-common.c
+++ b/drivers/usb/common/usb-common.c
@@ -139,6 +139,21 @@ enum usb_device_speed of_usb_get_maximum_speed(struct
device_node *np)
}
EXPORT_SYMBOL_GPL(of_usb_get_maximum_speed);
+/**
+ * of_usb_host_tpl_support - to get if Targeted Peripheral List is
supported
+ * for given targeted hosts (non-PC hosts)
+ * @np: Pointer to the given device_node
+ *
+ * The function gets if the targeted hosts support TPL or not
+ */
+bool of_usb_host_tpl_support(struct device_node *np)
+{
+ if (of_find_property(np, tpl-support, NULL))
+ return true;
+
+ return false;
please don't. Quite frankly, TPL support in Linux is quite braindead.
The way it's done it prevents USB from being used as an accessory port.
I talked to the USB-IF long ago and I was told that the spec is a bit
badly worded but preventing new drivers from being installed is wrong.
But the newest otg eh spec still has TPL definition, and the newest
compliance test still needs to support it.
I think we should have TPL support at Linux kernel, in that case,
The embedded linux box can pass the USB-IF certification test without
changing design code except define their TPL devices.
This patchset has no side effect, and can help embedded linux box
pass USB certification easier, why not accept it?
What we really need is a notification for when Linux can't bind any
driver to the new device. That would be an unsupported device.
This was my the first thought, but current usb device and usb driver
bind uses standard linux device model framework, we only know
if current device matches current driver or not. Maybe we can have a patchset
to support it, but it may change some code, since TPL framework has already
been existed, why not enhance it?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps
Hi,
On Thursday 21 August 2014 10:13 PM, Tony Lindgren wrote:
Commit 30a70b026b4cd (usb: musb: fix obex in g_nokia.ko causing kernel
panic) attempted to fix runtime PM handling for PHYs that are on the
I2C bus. Commit 3063a12be2b0 (usb: musb: fix PHY power on/off) then
changed things around to enable of PHYs that rely on runtime PM.
These changes however broke idling of the PHY and causes at least
100 mW extra power consumption on omaps, which is a lot with
the idle power consumption being below 10 mW range on many devices.
As calling phy_power_on/off from runtime PM calls in the USB
causes complicated issues with I2C connected PHYs, let's just let
the PHY do it's own runtime PM as needed. This leaves out the
dependency between PHYs and USB controller drivers for runtime
PM.
Let's fix the regression for twl4030-usb by adding minimal runtime
PM support. This allows idling the PHY on disconnect.
Note that we are changing to use standard runtime PM handling
for twl4030_phy_init() as that function just checks the state
and does not initialize the PHY. The PHY won't get initialized
until in twl4030_phy_power_on().
Fixes: 30a70b026b4cd (usb: musb: fix obex in g_nokia.ko causing kernel
panic)
Fixes: 3063a12be2b0 (usb: musb: fix PHY power on/off)
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Tony Lindgren t...@atomide.com
---
Kishon, this regression fix would be nice to get into the v3.17-rc
series if no objections. If you don't have other fixes, I can also
queue via arm-soc with proper acks.
I can queue this one up once put_autosuspend() is used.
Thanks
Kishon
It probably does not make sense to try to fix this without using
runtime PM without complicating the code further.
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -34,6 +34,7 @@
#include linux/delay.h
#include linux/usb/otg.h
#include linux/phy/phy.h
+#include linux/pm_runtime.h
#include linux/usb/musb-omap.h
#include linux/usb/ulpi.h
#include linux/i2c/twl.h
@@ -422,37 +423,55 @@ static void twl4030_phy_power(struct twl4030_usb *twl,
int on)
}
}
-static int twl4030_phy_power_off(struct phy *phy)
+static int twl4030_usb_runtime_suspend(struct device *dev)
{
- struct twl4030_usb *twl = phy_get_drvdata(phy);
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ dev_dbg(twl-dev, %s\n, __func__);
if (twl-asleep)
return 0;
twl4030_phy_power(twl, 0);
twl-asleep = 1;
- dev_dbg(twl-dev, %s\n, __func__);
+
return 0;
}
-static void __twl4030_phy_power_on(struct twl4030_usb *twl)
+static int twl4030_usb_runtime_resume(struct device *dev)
{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+
+ dev_dbg(twl-dev, %s\n, __func__);
+ if (!twl-asleep)
+ return 0;
+
twl4030_phy_power(twl, 1);
- twl4030_i2c_access(twl, 1);
- twl4030_usb_set_mode(twl, twl-usb_mode);
- if (twl-usb_mode == T2_USB_MODE_ULPI)
- twl4030_i2c_access(twl, 0);
+ twl-asleep = 0;
+
+ return 0;
+}
+
+static int twl4030_phy_power_off(struct phy *phy)
+{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+ dev_dbg(twl-dev, %s\n, __func__);
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ return 0;
}
static int twl4030_phy_power_on(struct phy *phy)
{
struct twl4030_usb *twl = phy_get_drvdata(phy);
- if (!twl-asleep)
- return 0;
- __twl4030_phy_power_on(twl);
- twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+ pm_runtime_get_sync(twl-dev);
+ twl4030_i2c_access(twl, 1);
+ twl4030_usb_set_mode(twl, twl-usb_mode);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
/*
* XXX When VBUS gets driven after musb goes to A mode,
@@ -558,6 +577,16 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
* USB_LINK_VBUS state. musb_hdrc won't care until it
* starts to handle softconnect right.
*/
+ if ((status == OMAP_MUSB_VBUS_VALID) ||
+ (status == OMAP_MUSB_ID_GROUND)) {
+ if (twl-asleep)
+ pm_runtime_get_sync(twl-dev);
+ } else {
+ if (!twl-asleep) {
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
+ }
+ }
omap_musb_mailbox(status);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
@@ -599,22 +628,17 @@ static int twl4030_phy_init(struct phy *phy)
struct twl4030_usb *twl = phy_get_drvdata(phy);
enum omap_musb_vbus_id_status status;
- /*
- * Start in sleep state, we'll get called through set_suspend()
- * callback when musb is
