Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c
Hi, On Fri, Mar 08, 2013 at 10:26:45AM -0700, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). Venu, please comment on what conflicts, if any, this will cause with the patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. BTW, let's stop with the whole dependency between PHY driver cleanup and arch/arm/mach-tegra/, too many patches have gone upstream bypassing my tree. What we should be doing is figuring out how to remove arch/ dependencies so that patches can go upstream and not cause conflicts. Unfortunately, there's no way to actually avoid the dependencies themselves. The DT bindings and EHCI/PHY controller split are wrong, and need work on both the DT and drivers to fix. but those changes don't need to come together, right ? I mean, for the DT part you could add the bindings to driver A without removing from driver B and span the changes accross 2 merge windows. I guess I could apply all the initial DT changes to a topic branch in the Tegra tree (item 1 below), and have you merge that branch into yours, and then you could take all the USB-related patches (item 2 below) through your tree. Would that work better? I'm not merging, taking everything as patches, sorry. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c
Hi, On Fri, Mar 08, 2013 at 11:33:48AM -0700, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). On other thought here: The Tegra PHY in question here very specifically is a USB PHY. There's no way it could be used as e.g. a SATA PHY, either as a HW block or given the driver code that program is. Is sharing a PHY IP block or driver ever possible for any HW? yes it is possible, and OMAP5 shares the same IP for USB3 and SATA. PHYs don't know about USB, SATA, Ethernet and whatnot. PHYs know solely about the physical layer. Their work is just to generate the proper electrical signals. Hence, I don't think removing USB from the filename makes sense, nor even moving it into a generic PHY directory. fair enough, I have now renamed tegra to phy-tegra-usb.c -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] usb: phy: isp1301: implement PHY API
On Fri, Mar 08, 2013 at 11:53:21PM +0400, Sergei Shtylyov wrote:
Hello.
On 08-03-2013 15:30, Felipe Balbi wrote:
this patch implements -init() and -set_vbus()
methods for isp1301 transceiver driver.
Later patches can now come in order to remove
the hackery from ohci-nxp and lpc32xx udc drivers.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/phy/phy-isp1301.c | 59
+++
1 file changed, 59 insertions(+)
diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 36c4d98..af8f9da 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
[...]
@@ -31,6 +34,60 @@ static const struct i2c_device_id isp1301_id[] = {
[...]
+static int isp1301_phy_init(struct usb_phy *phy)
+{
+struct isp1301 *isp = phy_to_isp(phy);
+
+/* Disable transparent UART mode first */
+isp1301_clear(isp,ISP1301_I2C_MODE_CONTROL_1, MC1_UART_EN);
You misssed space after comma here.
fixed, thanks.
+isp1301_clear(isp, ISP1301_I2C_MODE_CONTROL_1, ~MC1_SPEED_REG);
+isp1301_write(isp, ISP1301_I2C_MODE_CONTROL_1, MC1_SPEED_REG);
+isp1301_clear(isp, ISP1301_I2C_MODE_CONTROL_2, ~0);
+isp1301_write(isp, ISP1301_I2C_MODE_CONTROL_2, (MC2_BI_DI | MC2_PSW_EN
+| MC2_SPD_SUSP_CTRL));
+
+isp1301_clear(isp, ISP1301_I2C_OTG_CONTROL_1, ~0);
+isp1301_write(isp, ISP1301_I2C_MODE_CONTROL_1, MC1_DAT_SE0);
+isp1301_write(isp, ISP1301_I2C_OTG_CONTROL_1, (OTG1_DM_PULLDOWN
+| OTG1_DP_PULLDOWN));
+isp1301_clear(isp, ISP1301_I2C_OTG_CONTROL_1, (OTG1_DM_PULLUP
+| OTG1_DP_PULLUP));
() around | not necessary.
this one I'll keep as it aids readability.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] usb: phy: isp1301: give it a context structure
On Fri, Mar 08, 2013 at 11:47:13PM +0400, Sergei Shtylyov wrote:
Hello.
On 08-03-2013 15:30, Felipe Balbi wrote:
this patch is a small preparation to fix
isp1301 driver so that other platforms can
use it.
We're defining our private data structure
to represent this device and adding the
PHY to the PHY list.
Later patches will come implementing proper
PHY API and removing bogus code from ohci_nxp
and lpc32xx_udc drivers.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/phy/phy-isp1301.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 18dbf7e..36c4d98 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
[...]
@@ -23,14 +32,37 @@ static const struct i2c_device_id isp1301_id[] = {
static struct i2c_client *isp1301_i2c_client;
static int isp1301_probe(struct i2c_client *client,
- const struct i2c_device_id *i2c_id)
+const struct i2c_device_id *i2c_id)
Is this change necessary?
yes.
hehe, seriously now. I'll revert it.
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 00/12] UVC gadget patches for v3.10
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Saturday, March 02, 2013 1:16 AM To: linux-usb@vger.kernel.org Cc: Bhupesh SHARMA; Cyril Roelandt; Chen Gang; Felipe Balbi Subject: [PATCH 00/12] UVC gadget patches for v3.10 Hello, Here are the miscellaneous fixes and enhacements for the UVC gadget driver that I would like to push for v3.10. All the patches have already been sent to the list, some of them in an older form. I've done my best to consolidate everything and take all comments into account. The USB 2.0 enumeration issue should be fixed. Bhupesh, would you be able to test the set (without any additional patch) ? I will then send a pull request with your Tested-by lines. I will then wait for the V4 of your UVC webcam gadget related changes patch set, rebased on top of this. You can get all the patches from git://linuxtv.org/pinchartl/uvcvideo.git uvc-gadget I tested the enumeration and basic class specific USB request transfer with this patchset both for: - Super-Speed case: Using a PCIe(Gen2)-based-USB3 card from TI connected on a Fedora 17 Linux PC. - High-Speed case: Using standard EHCI based card on a Fedora 17 Linux PC. You can add my tested-by to the patchset for basic enumeration and class-specific request handling. Note that the detailed data path checking will be possible after I add V4 of my UVC webcam gadget related changes. Tested-by: Bhupesh Sharma bhupesh.sha...@st.com I will send the V4 shortly. Regards, Bhupesh Bhupesh Sharma (4): usb: gadget/uvc: Add fix for UVC compliance test suite assertion 6.3.90 failure usb: gadget/uvc: Add fix for UVC compliance test suite's assertion 6.1.25 failure usb: gadget/uvc: Delay the status stage when setting alternate setting 1 usb: gadget/uvc: Make video streaming buffer size comply with USB3.0 SS Chen Gang (1): usb: gadget/uvc: Use strlcpy instead of strncpy Cyril Roelandt (1): usb: gadget/uvc: Use GFP_ATOMIC under spin lock Laurent Pinchart (6): usb: gadget/uvc: Clarify comment about string descriptors usb: gadget/uvc: Rename STATUS_BYTECOUNT to UVC_STATUS_MAX_PACKET_SIZE usb: gadget/uvc: Fix coding style issues introduced by SS support usb: gadget/uvc: Merge the SS/HS/FS control endpoint descriptors usb: gadget/uvc: Merge the streaming maxpacket and mult parameters usb: gadget/uvc: Configure the streaming endpoint based on the speed drivers/usb/gadget/f_uvc.c | 262 -- --- drivers/usb/gadget/f_uvc.h | 12 +- drivers/usb/gadget/uvc.h | 1 + drivers/usb/gadget/uvc_v4l2.c | 20 +++- drivers/usb/gadget/uvc_video.c | 13 +- 5 files changed, 162 insertions(+), 146 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
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 03/08/2013 05:45 PM, Marc Kleine-Budde wrote:
On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
On 02/04/2013 04:58 PM, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
drivers/usb/otg/nop-usb-xceiv.c| 31
++
2 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 000..d7e2726
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+ /bindings/clock/clock-bindings.txt
+ This property is required if clock-frequency is specified.
+
+- clock-names: Should be main_clk
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+ be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+ hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ clock-frequency = 1920;
Why do you hardcode the clock frequency here? You should use
clk_get_rate() to get the frequency from the clock tree.
What about declaring a fixed-clock node in the device tree? Then it
should be possible to keep the driver free of any omap specific code.
The current implementation is not OMAP specific and is not limited to a
fixed frequency clock. The PHY driver is using standard clock APIs to set
the clock rate 'only' if the 'clock-frequency' property is present in the
device tree node.
What is the benefit of declaring it as a fixed-clock?
FYI. The clock may not necessarily be a fixed frequency clock and someone
needs to program the rate.
cheers,
-roger
--
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] vers/usb/gadget: beautify code, delete useless comments
since parameter driver has been deleted, also need delete relative comments. relative commit number is d93e2600d80fc41ccf339b4a2843a3007d479907 Signed-off-by: Chen Gang gang.c...@asianux.com --- drivers/usb/gadget/s3c-hsudc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c index 458965a..7da26cf 100644 --- a/drivers/usb/gadget/s3c-hsudc.c +++ b/drivers/usb/gadget/s3c-hsudc.c @@ -283,7 +283,6 @@ static void s3c_hsudc_nuke_ep(struct s3c_hsudc_ep *hsep, int status) /** * s3c_hsudc_stop_activity - Stop activity on all endpoints. * @hsudc: Device controller for which EP activity is to be stopped. - * @driver: Reference to the gadget driver which is currently active. * * All the endpoints are stopped and any pending transfer requests if any on * the endpoint are terminated. -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code
于 2013年03月04日 22:35, Felipe Balbi 写道: since stop_activity() also gets called from RESET interrupt, and in that case we need to call driver-disconnect(). Can you make a simple test that would take current code and issue a device reset to see if that would break, then apply my suggestion above and run the same test again? after reference the commit: d93e2600d80fc41ccf339b4a2843a3007d479907 it seems udc_start and udc_stop will have effect, so not need call driver-disconnect() is it correct ? thanks. -- Chen Gang Asianux Corporation -- 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] drivers/usb/gadget: beautify code, delete unused code
On Mon, Mar 11, 2013 at 06:17:10PM +0800, Chen Gang wrote: 于 2013年03月04日 22:35, Felipe Balbi 写道: since stop_activity() also gets called from RESET interrupt, and in that case we need to call driver-disconnect(). Can you make a simple test that would take current code and issue a device reset to see if that would break, then apply my suggestion above and run the same test again? after reference the commit: d93e2600d80fc41ccf339b4a2843a3007d479907 it seems udc_start and udc_stop will have effect, so not need call driver-disconnect() is it correct ? in case of net2272.c and net2280.c, they call stop_activity() also from disconnect and reset interrupt handlers, in that case the gadget driver needs to know about the disconnect. -- balbi signature.asc Description: Digital signature
Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code
于 2013年03月11日 18:17, Chen Gang 写道: 于 2013年03月04日 22:35, Felipe Balbi 写道: since stop_activity() also gets called from RESET interrupt, and in that case we need to call driver-disconnect(). Can you make a simple test that would take current code and issue a device reset to see if that would break, then apply my suggestion above and run the same test again? after reference the commit: d93e2600d80fc41ccf339b4a2843a3007d479907 it seems udc_start and udc_stop will have effect, so not need call driver-disconnect() is it correct ? thanks. another reference commit: 6166c24669678662547bb4e5dbd6a810268b8b7b also seems udc_start and udc_stop will have effect. -- Chen Gang Asianux Corporation -- 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] vers/usb/gadget: beautify code, delete useless comments
On Mon, Mar 11, 2013 at 06:14:19PM +0800, Chen Gang wrote: since parameter driver has been deleted, also need delete relative comments. relative commit number is d93e2600d80fc41ccf339b4a2843a3007d479907 Signed-off-by: Chen Gang gang.c...@asianux.com please come up with a better Subject and commit log. Something along the lines of: usb: gadget: s3c-hsudc: delete outdated comment since commit d93e260 (usb: gadget: s3c-hsudc: use udc_start and udc_stop functions) the 'driver' parameter has been deleted from s3c_hsudc_stop_activity() but its documentation was left outdated. This patch deletes the comment since it makes no sense anymore. -- balbi signature.asc Description: Digital signature
[PATCH] usb: gadget: s3c-hsudc: delete outdated comment
since commit d93e260 (usb: gadget: s3c-hsudc: use udc_start and udc_stop functions) the 'driver' parameter has been deleted from s3c_hsudc_stop_activity() but its documentation was left outdated. This patch deletes the comment since it makes no sense anymore. Signed-off-by: Chen Gang gang.c...@asianux.com --- drivers/usb/gadget/s3c-hsudc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c index 458965a..7da26cf 100644 --- a/drivers/usb/gadget/s3c-hsudc.c +++ b/drivers/usb/gadget/s3c-hsudc.c @@ -283,7 +283,6 @@ static void s3c_hsudc_nuke_ep(struct s3c_hsudc_ep *hsep, int status) /** * s3c_hsudc_stop_activity - Stop activity on all endpoints. * @hsudc: Device controller for which EP activity is to be stopped. - * @driver: Reference to the gadget driver which is currently active. * * All the endpoints are stopped and any pending transfer requests if any on * the endpoint are terminated. -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: pxa25x: fix disconnect reporting
when commit 6166c24 (usb: gadget: pxa25x_udc: convert to udc_start/udc_stop) converted this driver to udc_start/udc_stop, it failed to consider the fact that stop_activity() is called from disconnect interrupt. Fix the problem so that gadget drivers know about proper disconnect sequences. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/gadget/pxa25x_udc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index 9aa9dd5..d0f3748 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -1303,6 +1303,10 @@ stop_activity(struct pxa25x_udc *dev, struct usb_gadget_driver *driver) } del_timer_sync(dev-timer); + /* report disconnect; the driver is already quiesced */ + if (driver) + driver-disconnect(dev-gadget); + /* re-init driver-visible data structures */ udc_reinit(dev); } -- 1.8.1.rc1.5.g7e0651a -- 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] drivers/usb/gadget: beautify code, delete unused code
On Mon, Mar 11, 2013 at 06:42:25PM +0800, Chen Gang wrote: if I can not find other members to help us, I will try to find another ways. code inspection works most of the time. all together: I beleive ways is always more than issues. BTW: I also add comments for your test program, please check whether it is ok, thanks. sure, it's alright. -- balbi signature.asc Description: Digital signature
Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code
于 2013年03月11日 18:50, Felipe Balbi 写道: On Mon, Mar 11, 2013 at 06:42:25PM +0800, Chen Gang wrote: if I can not find other members to help us, I will try to find another ways. code inspection works most of the time. excuse me, my English is not quite well, could you describe it with more details ? thanks. -- Chen Gang Asianux Corporation -- 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] drivers/usb/gadget: beautify code, delete unused code
On Mon, Mar 11, 2013 at 07:03:02PM +0800, Chen Gang wrote: 于 2013年03月11日 18:50, Felipe Balbi 写道: On Mon, Mar 11, 2013 at 06:42:25PM +0800, Chen Gang wrote: if I can not find other members to help us, I will try to find another ways. code inspection works most of the time. excuse me, my English is not quite well, could you describe it with more details ? I mean just reading the code and understanding what it does. When you don't have HW to test, it's the only way to patch the driver. -- balbi signature.asc Description: Digital signature
Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code
于 2013年03月11日 19:07, Felipe Balbi 写道: I mean just reading the code and understanding what it does. When you don't have HW to test, it's the only way to patch the driver. ok, thanks. and I still try to find another ways, at least within this week (before 2013-03-15). thanks again. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB patches
Hi Greg, Here's my second set of fixes for this -rc cycle. Since my previous pull request didn't reach v3.9-rc2, this one is based out of the previous. Surprised to see that git gracefully found a common commit by just running: $ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3 (usb is my remote to kernel.org) Anyway, let me know if you have any issues. I have merged this tag on top of your greg/usb-linus branch just to make sure there'd be no conflicts and it merges just fine. cheers The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec: usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.9-rc3 for you to fetch changes up to 66e4afc77f76653460d7eb31ec793506ada1ad33: usb: gadget: pxa25x: fix disconnect reporting (2013-03-11 12:40:31 +0200) usb: fixes for v3.9-rc3 Most fixes are on 'musb' driver. There's a sparse warning fix which marks omap2430_glue as static, a build warning fix which was found with randconfig, a fix for omap_musb_mailbox check and removal of 'select' from musb's Kconfig to prevent Kconfig warnings. Other than that, pxa25x got a fix which was introduced by the latest conversion to udc_start/udc_stop patchset, kernel-doc warnings for composite layer and dwc3 got a build fix on sparc64. Aaro Koskinen (2): usb: musb: omap2430: fix omap_musb_mailbox glue check again usb: musb: omap2430: fix sparse warning Andrew Morton (1): usb: dwc3: ep0: fix sparc64 build Felipe Balbi (3): usb: musb: remove all 'select' from Kconfig usb: musb: fix compile warning usb: gadget: pxa25x: fix disconnect reporting Nishanth Menon (1): usb: gadget: composite: fix kernel-doc warnings drivers/usb/dwc3/ep0.c | 7 --- drivers/usb/gadget/composite.c | 5 + drivers/usb/gadget/pxa25x_udc.c | 4 drivers/usb/musb/Kconfig| 5 - drivers/usb/musb/musb_core.c| 2 -- drivers/usb/musb/omap2430.c | 12 include/linux/usb/composite.h | 3 ++- 7 files changed, 19 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vers/usb/gadget: beautify code, delete useless comments
Hello. On 11-03-2013 14:14, Chen Gang wrote: since parameter driver has been deleted, also need delete relative comments. relative You probably meant related in both cases? commit number is d93e2600d80fc41ccf339b4a2843a3007d479907 Please also specify that commit's summary line in parens (or however you like). Signed-off-by: Chen Gang gang.c...@asianux.com 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: About USBADRA bit at DEVICEADDR for chipidea driver
Peter Chen peter.c...@freescale.com writes: On Fri, Mar 08, 2013 at 04:06:30PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: On Fri, Mar 08, 2013 at 12:39:04PM +0200, Alexander Shishkin wrote: Peter Chen peter.c...@freescale.com writes: Hi David Hi, I notice at your code for hw_usb_set_address, there is a comment for it /** * This function explicitly sets the address, without the USBADRA (advance) * feature, which is not supported by older versions of the controller. */ That's mine. David's original driver did use USBADRA. I removed it because it's not supported by some versions of chipidea, for example the one that Marvell integrated in their kirkwood SoCs. If we use USB3.0 host for CV test, we must use this bit, or the host may send GET_DESCRIPTOR before the controller set address. That's because we don't have the state machine for ep0 currently, USBADRA has nothing to do with it. Can you explain more? As far as I know, it is the completion of set_address cost too much time that the host sends next command before device sets address. USBADRA doesn't magically speed up anything. It's a convenience thing that lets you set the controller's address register value straight away instead of deferring it till after status phase of SET_ADDRESS. The status phase won't happen any sooner than normally. Correct, but the problem is after the status phase finished, when the software can set address without using USBADRA? Assuming the busy system, the interrupt latecy, etc? For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the status phase of SetAddress is 2ms. That should be enough to process the transfer completion interrupt, shouldn't it? Why is USB 3 CV violating this and why should we care? I guess, if we really want to, we can make USBADRA usage conditional, BUT something tells me that there will be more arbitrary timing expectations then that we won't necessarily be able to meet. Regards, -- Alex -- 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: About USBADRA bit at DEVICEADDR for chipidea driver
For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the status phase of SetAddress is 2ms. That should be enough to process the transfer completion interrupt, shouldn't it? Why is USB 3 CV violating this and why should we care? I guess, if we really want to, we can make USBADRA usage conditional, BUT something tells me that there will be more arbitrary timing expectations then that we won't necessarily be able to meet. I will investigate it more after finishing several chipidea related patches. Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device
On Sat, Mar 9, 2013 at 12:50 AM, Alexey Khoroshilov khoroshi...@ispras.ru wrote: As it was described by Oliver Neukum in commit acbe2fe USB: Don't use GFP_KERNEL while we cannot reset a storage device: Memory allocations with GFP_KERNEL can cause IO to a storage device which can fail resulting in a need to reset the device. Therefore GFP_KERNEL cannot be safely used between usb_lock_device() and usb_unlock_device(). Replace by GFP_NOIO. The patch fixes the same issue in usb/core/devio.c. All the allocations fixed are under usb_lock_device() from usbdev_do_ioctl(). I am wondering why the device lock is needed for usbdev_do_ioctl()? Looks device lock isn't required for USB transfer of kernel driver. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: fsl_udc_core: set address request aren't handled like expected. usb30cv test suite fails.
On Fri, Mar 08, 2013 at 11:54:41AM +0200, Felipe Balbi wrote:
On Fri, Mar 08, 2013 at 05:38:53PM +0800, Peter Chen wrote:
On Thu, Mar 07, 2013 at 09:58:52AM +0100, Peter Bestler wrote:
Hi,
We try to get our device (based on p2020rdb) usb 2.0 compliant. We ran
the usb30cv test suite (version 1.0.1.2, chapter 9 tests for usb 2.0
devices) on win7 with g_zero and g_serial. We access the device via an
usb 3.0 hcd from intel. Our device runs the 3.2.35-rt52 kernel. I spotted
the following problem with ch9setaddress in fsl_udc_core.c.
All tests passed on single execution. At running it in batch mode the
first test after switching from default to adressed state failed. The
subsequent tests passed. It doesn't depend on the selected tests, only on
the switch over from default to adressed. It fails with our custom
gadgetfs driver too. Another device with Intel PXA25x and the same setup
passes all tests.
With the total phase usbsniffer i spotted the following behavior:
The test issues a setAddress and receives an ACK, 125 us afterwards the
host issues a getDescriptor (setuptx) request, which fails at setuptx.
The USB sniffer reports invalid PID sequence.
For debugging purpose I delayed the dma_map_single in ep0_prime_status
(which does the ACK, right?) by 2 milliseconds. And all tests are passing
in batch mode. It's quite the same sequence on the bus, but between
setAdress and its ACK is a delay of 3 ms.
I think delaying the ACK in set request isn't the way to go. I think we
set the address too early; we have to wait until the status phase of the
set address has finished. My understanding is that the device has to
respond to address 0 until the complete status phase of setAddress is
passed (is this correct).
Has anybody ran the usb30cv on fsl_udc recently?
After applying the patch f79a60b8785 none of the tests run anymore. Did I
miss anything here? How can we fix this issue?
Best regards
Peter
--- Patch for debugging ---
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 55abfb6..fdbfd25 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1285,6 +1285,7 @@ static int ep0_prime_status(struct fsl_udc *udc,
int direction)
req-req.complete = NULL;
req-dtd_count = 0;
+ udelay(2000);
req-req.dma = dma_map_single(ep-udc-gadget.dev.parent,
req-req.buf, req-req.length,
ep_is_in(ep) ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
Please check your datasheet if your controller has USBADRA bit
at DEVICEADDR, if it exists, it means your controller supports
advance store device address function. Please have a try for
below change, if it fixes your problem, please give a tested-by,
then, I can make change for chipidea and fsl-core driver.
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 04d5fef..a75c884 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1335,10 +1335,14 @@ static void udc_reset_ep_queue(struct fsl_udc *udc,
u8 pipe)
*/
static void ch9setaddress(struct fsl_udc *udc, u16 value, u16 index, u16
length)
{
- /* Save the new address to device struct */
udc-device_address = (u8) value;
+ /* Set the new address */
+ fsl_writel(((u32)value USB_DEVICE_ADDRESS_BIT_POS)|
+ (1 USB_DEVICE_ADDRESS_BIT_POS),
do you mean:
(u32) ((value USB_DEVICE_ADDRESS_BIT_POS) |
(1 USB_DEVICE_ADDRESS_BIT_POS))
??
Also, why do you need the extra (1 USB_DEVICE_ADDRESS_BIT_POS) ?
You'd be making all addresses odd, no ?
Sorry, my wrong, should be below:
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 04d5fef..b0e78e6 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -1335,10 +1335,14 @@ static void udc_reset_ep_queue(struct fsl_udc *udc, u8
pipe)
*/
static void ch9setaddress(struct fsl_udc *udc, u16 value, u16 index, u16
length)
{
- /* Save the new address to device struct */
udc-device_address = (u8) value;
+ /* Set the new address */
+ fsl_writel(((u32)value USB_DEVICE_ADDRESS_BIT_POS)|
+ (1 USB_DEVICE_ADDRESS_ADV_BIT_POS),
+ dr_regs-deviceaddr);
/* Update usb state */
udc-usb_state = USB_STATE_ADDRESS;
+
/* Status phase */
if (ep0_prime_status(udc, EP_DIR_IN))
ep0stall(udc);
@@ -1539,13 +1543,6 @@ static void setup_received_irq(struct fsl_udc *udc,
static void ep0_req_complete(struct fsl_udc *udc, struct fsl_ep *ep0,
struct fsl_req *req)
{
- if (udc-usb_state ==
Re: [PATCH 00/12] UVC gadget patches for v3.10
Hi Bhupesh, On Monday 11 March 2013 15:07:05 Bhupesh SHARMA wrote: On Saturday, March 02, 2013 1:16 AM Laurent Pinchart wrote: Hello, Here are the miscellaneous fixes and enhacements for the UVC gadget driver that I would like to push for v3.10. All the patches have already been sent to the list, some of them in an older form. I've done my best to consolidate everything and take all comments into account. The USB 2.0 enumeration issue should be fixed. Bhupesh, would you be able to test the set (without any additional patch) ? I will then send a pull request with your Tested-by lines. I will then wait for the V4 of your UVC webcam gadget related changes patch set, rebased on top of this. You can get all the patches from git://linuxtv.org/pinchartl/uvcvideo.git uvc-gadget I tested the enumeration and basic class specific USB request transfer with this patchset both for: - Super-Speed case: Using a PCIe(Gen2)-based-USB3 card from TI connected on a Fedora 17 Linux PC. - High-Speed case: Using standard EHCI based card on a Fedora 17 Linux PC. You can add my tested-by to the patchset for basic enumeration and class-specific request handling. Note that the detailed data path checking will be possible after I add V4 of my UVC webcam gadget related changes. Tested-by: Bhupesh Sharma bhupesh.sha...@st.com Thanks a lot. Felipe, I've added the Tested-by line to the patches and pushed the result to git://linuxtv.org/pinchartl/uvcvideo.git uvc-gadget You can also pick the patches from the list if that's easier for you. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About USBADRA bit at DEVICEADDR for chipidea driver
On Mon, 11 Mar 2013, Alexander Shishkin wrote: For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the status phase of SetAddress is 2ms. That should be enough to process the transfer completion interrupt, shouldn't it? Why is USB 3 CV violating this and why should we care? I guess, if we Probably because the recovery period, being in the USB 2.0 spec, applies to USB-2 devices -- whereas the USB-3 CV tries to test USB-3 devices. Do they have the same recovery period? 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: Use resource_size function
On Sun, 10 Mar 2013, Paul Vlase wrote: Signed-off-by: Paul Vlase vlase.p...@gmail.com --- drivers/usb/host/ehci-mv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c index 3065809..5cd9f96 100644 --- a/drivers/usb/host/ehci-mv.c +++ b/drivers/usb/host/ehci-mv.c @@ -225,7 +225,7 @@ static int mv_ehci_probe(struct platform_device *pdev) (void __iomem *) ((unsigned long) ehci_mv-cap_regs + offset); hcd-rsrc_start = r-start; - hcd-rsrc_len = r-end - r-start + 1; + hcd-rsrc_len = resource_size(r); hcd-regs = ehci_mv-op_regs; hcd-irq = platform_get_irq(pdev, 0); Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.
On Mon, 11 Mar 2013, Jenya Y wrote: // Update Alan, I'm happy to say that the errors disappeared. I recompiled the latest master from torvalds with USB_CONFIG=Y instead of 'm' and the errors are gone. I'm not sure it was this particular config flag + the settings you suggested earlier or simply the changes that were incorporated into the latest master but everything is working perfectly now. Thank you very very much for you patience with me and I'll be glad to assist if you need any help figuring out what went right :) Well, I'd like to take the credit for this but I don't really deserve it. :-) The problem you had is a valid one and it deserves to be fixed. People should not have to select particular combinations of config options in order to avoid a ton of error messages. I'll try to work out a patch in the next few days. Can you recreate the arrangement where all the errors occurred, in order to test the patch when it is ready? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] USB: misc: usb3503: use module_i2c_driver to simplify the code
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/usb/misc/usb3503.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index f713f6a..d3a1cce 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -307,18 +307,7 @@ static struct i2c_driver usb3503_driver = {
.id_table = usb3503_id,
};
-static int __init usb3503_init(void)
-{
- return i2c_add_driver(usb3503_driver);
-}
-
-static void __exit usb3503_exit(void)
-{
- i2c_del_driver(usb3503_driver);
-}
-
-module_init(usb3503_init);
-module_exit(usb3503_exit);
+module_i2c_driver(usb3503_driver);
MODULE_AUTHOR(Dongjin Kim tobet...@gmail.com);
MODULE_DESCRIPTION(USB3503 USB HUB driver);
--
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: REQUEST : Some help to write a new driver for LEAP motion device
On Sun, Mar 10, 2013 at 07:52:55PM +0100, LECOQ Vincent wrote: Hello Dears, I have near me 2 piece of the Leap Motion device released as developpers release kits. (http://www.leapmotion.com/) The constructor give me only drivers for Microsoft ans Apple environements, and of course closed source. I ve have install a virtualbox with an windows environement and initialize the device, play some minute with. During this time I ve record the usbmon output that You can found here : http://oktail.org/download/dump_usb http://oktail.org/download/dump_usb Somebody can help me to understand this trace and start the linux driver ? Why not try asking the company if they will provide the specs for how to talk to the device, so that we can make a USB driver for Linux in a much easier manner? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB patches
On Mon, Mar 11, 2013 at 01:14:36PM +0200, Felipe Balbi wrote: Hi Greg, Here's my second set of fixes for this -rc cycle. Since my previous pull request didn't reach v3.9-rc2, this one is based out of the previous. That is fine, due to my travels last week, I didn't get a chance to get stuff to Linus. I should catch up this week. Surprised to see that git gracefully found a common commit by just running: $ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3 (usb is my remote to kernel.org) Anyway, let me know if you have any issues. I have merged this tag on top of your greg/usb-linus branch just to make sure there'd be no conflicts and it merges just fine. cheers The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec: usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.9-rc3 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb/gadget: FunctionFS: Fix enable multiple instances
This patch fixes an off-by-one bug found in
581791f5c7a480b2cc3431af9a6e799ffd51eb5e.
During gfs_bind/gfs_unbind the functionfs_bind/functionfs_unbind should be
called for every functionfs instance. With the i pre-decremented they
were not called for the zeroth instance.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/usb/gadget/g_ffs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index d3ace90..919177b 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -358,7 +358,7 @@ static int gfs_bind(struct usb_composite_dev *cdev)
if (unlikely(ret 0))
goto error;
- for (i = func_num; --i; ) {
+ for (i = func_num; i--; ) {
ret = functionfs_bind(ffs_tab[i].ffs_data, cdev);
if (unlikely(ret 0)) {
while (++i func_num)
@@ -413,7 +413,7 @@ static int gfs_unbind(struct usb_composite_dev *cdev)
gether_cleanup();
gfs_ether_setup = false;
- for (i = func_num; --i; )
+ for (i = func_num; i--; )
if (ffs_tab[i].ffs_data)
functionfs_unbind(ffs_tab[i].ffs_data);
--
1.7.0.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/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device
On Mon, 11 Mar 2013, Ming Lei wrote: On Sat, Mar 9, 2013 at 12:50 AM, Alexey Khoroshilov khoroshi...@ispras.ru wrote: As it was described by Oliver Neukum in commit acbe2fe USB: Don't use GFP_KERNEL while we cannot reset a storage device: Memory allocations with GFP_KERNEL can cause IO to a storage device which can fail resulting in a need to reset the device. Therefore GFP_KERNEL cannot be safely used between usb_lock_device() and usb_unlock_device(). Replace by GFP_NOIO. The patch fixes the same issue in usb/core/devio.c. All the allocations fixed are under usb_lock_device() from usbdev_do_ioctl(). I am wondering why the device lock is needed for usbdev_do_ioctl()? Looks device lock isn't required for USB transfer of kernel driver. Of course you have to lock the device before changing its driver. What would happen if two different threads tried to change a device's driver at the same time? usbdev_do_ioctl() needs to acquire the device lock in order to prevent races with driver_disconnect() and usbdev_remove(). 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/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device
On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern st...@rowland.harvard.edu wrote: Of course you have to lock the device before changing its driver. What would happen if two different threads tried to change a device's driver at the same time? Yes, claim/release interface need device lock, but the patch doesn't touch claim/release command handling. usbdev_do_ioctl() needs to acquire the device lock in order to prevent races with driver_disconnect() and usbdev_remove(). Looks the patch basically converts the allocation inside URB submit path, and actually I mean why we need to hold device lock in submitting URB path? Device lock isn't required before submitting URBs in kernel driver. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 02/05/2013 08:26 AM, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
drivers/usb/otg/nop-usb-xceiv.c| 31 ++
2 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 000..d7e2726
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+ /bindings/clock/clock-bindings.txt
+ This property is required if clock-frequency is specified.
+
+- clock-names: Should be main_clk
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+ be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+hsusb1_phy {
+compatible = usb-nop-xceiv;
+clock-frequency = 1920;
+clocks = osc 0;
+clock-names = main_clk;
+vcc-supply = hsusb1_vcc_regulator;
+reset-supply = hsusb1_reset_regulator;
+};
+
+hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
+and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
+controls RESET.
diff --git a/drivers/usb/otg/nop-usb-xceiv.c
b/drivers/usb/otg/nop-usb-xceiv.c
index ac027a1..adbb7ab 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -34,6 +34,7 @@
#include linux/slab.h
#include linux/clk.h
#include linux/regulator/consumer.h
+#include linux/of.h
struct nop_usb_xceiv {
struct usb_phy phy;
@@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static void nop_xeiv_get_dt_pdata(struct device *dev,
asking to remove, but xeiv != xceiv :-)
+struct nop_usb_xceiv_platform_data *pdata)
+{
+struct device_node *node = dev-of_node;
+u32 clk_rate;
+
+if (!of_property_read_u32(node, clock-frequency, clk_rate))
+pdata-clk_rate = clk_rate;
+}
+
static int nop_usb_xceiv_probe(struct platform_device *pdev)
{
+struct device *dev = pdev-dev;
struct nop_usb_xceiv_platform_data *pdata = pdev-dev.platform_data;
struct nop_usb_xceiv*nop;
enum usb_phy_type type = USB_PHY_TYPE_USB2;
@@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
if (!nop-phy.otg)
return -ENOMEM;
+if (dev-of_node) {
+pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+if (!pdata) {
+dev_err(dev, Memory allocation failure\n);
+return -ENOMEM;
+}
+nop_xeiv_get_dt_pdata(dev, pdata);
actually, I would prefer to not create pdata at all. I mean, ideally
pdata would be used to initialize fields in your own structure, so first
move clk_rate to your own private structure, copy pdata's clk_rate value
to that, then you don't need this hackery when using DT.
As far as I can see, clk_rate is never used, but in the probe function.
Why should it be saved into the private data structure at all?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET
On 02/05/2013 10:43 AM, Roger Quadros wrote:
On 02/05/2013 11:09 AM, Felipe Balbi wrote:
On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 3265b61..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -6,6 +6,10 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
unsigned long clk_rate;
+
+/* if set fails with -EPROBE_DEFER if can't get regulator */
+unsigned int needs_vcc:1;
+unsigned int needs_reset:1;
how about u8 here?
Not sure. Bitfields are usually defined as unsigned int.
IIRC the benefit is that compiler can try to optimize those flags. I
mean, if you have 32 1-bit flags, compiler will combine those in a
single u32. Someone correct me if I'm wrong.
Yes you are right. Kishon was asking me to use u8 instead of unsigned int,
which
I don't think is necessary. AFAIK, it is a norm to use unsigned int when
defining
a bitfield. Compilers are known to behave funny with bitfields. I don't mind
using bool for each.
In the current version (rogerq/v3.8-usbhost17-dt) of this patch you've
put both needs_* into the private data struct and the pdata, but it's
only used inside the probe function.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device
On Mon, 11 Mar 2013, Ming Lei wrote: On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern st...@rowland.harvard.edu wrote: Of course you have to lock the device before changing its driver. What would happen if two different threads tried to change a device's driver at the same time? Yes, claim/release interface need device lock, but the patch doesn't touch claim/release command handling. Then why did you ask? You wrote: Looks device lock isn't required for USB transfer of kernel driver. usbdev_do_ioctl() needs to acquire the device lock in order to prevent races with driver_disconnect() and usbdev_remove(). Looks the patch basically converts the allocation inside URB submit path, and actually I mean why we need to hold device lock in submitting URB path? Device lock isn't required before submitting URBs in kernel driver. In general it isn't, no. But usbfs uses the lock to prevent races with driver_disconnect() -- it is invalid to submit URBs after the disconnect routine has returned. 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: FunctionFS: Fix enable multiple instances
On Mon, Mar 11 2013, Andrzej Pietrasiewicz wrote:
This patch fixes an off-by-one bug found in
581791f5c7a480b2cc3431af9a6e799ffd51eb5e.
During gfs_bind/gfs_unbind the functionfs_bind/functionfs_unbind should be
called for every functionfs instance. With the i pre-decremented they
were not called for the zeroth instance.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: sta...@vger.kernel.org
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/g_ffs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index d3ace90..919177b 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -358,7 +358,7 @@ static int gfs_bind(struct usb_composite_dev *cdev)
if (unlikely(ret 0))
goto error;
- for (i = func_num; --i; ) {
+ for (i = func_num; i--; ) {
ret = functionfs_bind(ffs_tab[i].ffs_data, cdev);
if (unlikely(ret 0)) {
while (++i func_num)
@@ -413,7 +413,7 @@ static int gfs_unbind(struct usb_composite_dev *cdev)
gether_cleanup();
gfs_ether_setup = false;
- for (i = func_num; --i; )
+ for (i = func_num; i--; )
if (ffs_tab[i].ffs_data)
functionfs_unbind(ffs_tab[i].ffs_data);
--
1.7.0.4
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
pgpIczGey7PeN.pgp
Description: PGP signature
Re: [PATCH] usb: musb: log VBUS error
* Grazvydas Ignotas nota...@gmail.com [130309 16:53]:
VBUS_ERROR is a serious error that the driver often doesn't recover from
in my tests, so we should at least inform the user about it.
Patch makes sens to me, just a related question..
Do you get this when trying to enable the host mode, right? Or have you seen
this in other situations too?
If the error happens when enabling the host mode, my experience is that
the VBUS_ERROR is caused by the musb trying to be too smart and doing the
timeouts automatically. If the VBUS on the hardware does not raise fast
enough to the right range for whatever reason, musb can produce this
error.
Regards,
Tony
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/musb/musb_core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f95404e..df6a54e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
break;
}
- dev_dbg(musb-controller, VBUS_ERROR in %s (%02x, %s), retry
#%d, port1 %08x\n,
+ dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb-controller,
+VBUS_ERROR in %s (%02x, %s), retry #%d, port1
%08x\n,
otg_state_string(musb-xceiv-state),
devctl,
({ char *s;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Problem with linux-3.7.7 (Stern - d01875f11f05f76fc471cec94d701201c1b34389)
On Mon, 11 Mar 2013, Adrian Bassett wrote:
You know, the 6e0c3339a6 commit consists of two hunks, and they are
pretty much independent of one another. You could try reverting each
of the hunks separately to narrow things down. Maybe only one of them
is responsible for your problem.
Have now been able to do this.
Using a vanilla 3.8.2 as base but with the following commit reverted
as it's scheduled for removal in 3.8.3 anyway:
55bcdce8a8228223ec4d17d8ded8134ed265d2c5 - 'USB: EHCI: remove ASS/PSS polling
timeout'
Then 6e0c3339a6f19d748f16091d0a05adeb1e1f822b - 'USB: EHCI: unlink
one async QH at a time' - was also reverted and two kernels were
built. The first, 'A', incorporated the first part of 6e0c3339
(changes to drivers/usb/host/ehci-q.c starting at line 1197) while
the second, 'B', had that code reverted in favour of the remainder of
the original composite patch.
What I found was that 'A' was entirely un-problematic in that I could
not trigger the problem behaviour at all. On the other hand, 'B'
could be made to trigger at first suspend/resume attempt. Moreover,
whilst previously the system with the composite patch in would always
return after a few minutes, with 'B' I eventually gave up waiting and
forced a re-boot. Perhaps the first half of the original patch in
some way mitigates the effects of the second.
Ah, that explains a lot. Indeed, there does appear to be a bug.
I haven't tried out this patch myself, but I think it will fix your
problem. It is based on 3.8 and should apply to 3.8.2. Let me know
what happens.
Alan Stern
Index: 3.8/drivers/usb/host/ehci-hcd.c
===
--- 3.8.orig/drivers/usb/host/ehci-hcd.c
+++ 3.8/drivers/usb/host/ehci-hcd.c
@@ -302,6 +302,7 @@ static void ehci_quiesce (struct ehci_hc
static void end_unlink_async(struct ehci_hcd *ehci);
static void unlink_empty_async(struct ehci_hcd *ehci);
+static void unlink_empty_async_suspended(struct ehci_hcd *ehci);
static void ehci_work(struct ehci_hcd *ehci);
static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
static void end_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
Index: 3.8/drivers/usb/host/ehci-hub.c
===
--- 3.8.orig/drivers/usb/host/ehci-hub.c
+++ 3.8/drivers/usb/host/ehci-hub.c
@@ -328,7 +328,7 @@ static int ehci_bus_suspend (struct usb_
ehci-rh_state = EHCI_RH_SUSPENDED;
end_unlink_async(ehci);
- unlink_empty_async(ehci);
+ unlink_empty_async_suspended(ehci);
ehci_handle_intr_unlinks(ehci);
end_free_itds(ehci);
Index: 3.8/drivers/usb/host/ehci-q.c
===
--- 3.8.orig/drivers/usb/host/ehci-q.c
+++ 3.8/drivers/usb/host/ehci-q.c
@@ -1316,6 +1316,20 @@ static void unlink_empty_async(struct eh
}
}
+/* The root hub is suspended; unlink all the async QHs */
+static void unlink_empty_async_suspended(struct ehci_hcd *ehci)
+{
+ struct ehci_qh *qh, *qh_to_unlink;
+
+ qh = ehci-async-qh_next.qh;
+ while (qh) {
+ qh_to_unlink = qh;
+ qh = qh-qh_next.qh;
+ WARN_ON(!list_empty(qh_to_unlink-qtd_list));
+ start_unlink_async(ehci, qh_to_unlink);
+ }
+}
+
/* makes sure the async qh will become idle */
/* caller must own ehci-lock */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device
On Tue, Mar 12, 2013 at 12:08 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 11 Mar 2013, Ming Lei wrote: On Mon, Mar 11, 2013 at 11:32 PM, Alan Stern st...@rowland.harvard.edu wrote: Of course you have to lock the device before changing its driver. What would happen if two different threads tried to change a device's driver at the same time? Yes, claim/release interface need device lock, but the patch doesn't touch claim/release command handling. Then why did you ask? You wrote: Looks device lock isn't required for USB transfer of kernel driver. Maybe I didn't expressed clearly, sorry. Here the USB transfer means URBs submitting. usbdev_do_ioctl() needs to acquire the device lock in order to prevent races with driver_disconnect() and usbdev_remove(). Looks the patch basically converts the allocation inside URB submit path, and actually I mean why we need to hold device lock in submitting URB path? Device lock isn't required before submitting URBs in kernel driver. In general it isn't, no. But usbfs uses the lock to prevent races with driver_disconnect() -- it is invalid to submit URBs after the disconnect routine has returned. If so, we may introduce another lock to avoid the race. So I think we may figure out to decrease the device lock scope in devio.c, and most of ioctl commands might not require it at all, then the problem addressed by the patch can be fixed too. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: rename all phy drivers to phy-$name.c
On 03/11/2013 12:59 AM, Felipe Balbi wrote: Hi, On Fri, Mar 08, 2013 at 10:26:45AM -0700, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). Venu, please comment on what conflicts, if any, this will cause with the patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. BTW, let's stop with the whole dependency between PHY driver cleanup and arch/arm/mach-tegra/, too many patches have gone upstream bypassing my tree. What we should be doing is figuring out how to remove arch/ dependencies so that patches can go upstream and not cause conflicts. Unfortunately, there's no way to actually avoid the dependencies themselves. The DT bindings and EHCI/PHY controller split are wrong, and need work on both the DT and drivers to fix. but those changes don't need to come together, right ? I mean, for the DT part you could add the bindings to driver A without removing from driver B and span the changes accross 2 merge windows. There is only a single driver. It's being reworked to support the new binding. I guess I could apply all the initial DT changes to a topic branch in the Tegra tree (item 1 below), and have you merge that branch into yours, and then you could take all the USB-related patches (item 2 below) through your tree. Would that work better? I'm not merging, taking everything as patches, sorry. In that case, the Tegra USB driver changes have to go through the Tegra tree this kernel cycle. The only way to avoid this, as you said above, would be to break the patches into n kernel cycles, which will introduce another 2-3 months delay, and I really don't see any point at all in doing that just to avoid a git pull, or taking the patches through the Tegra tree. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: log VBUS error
On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren t...@atomide.com wrote: * Grazvydas Ignotas nota...@gmail.com [130309 16:53]: VBUS_ERROR is a serious error that the driver often doesn't recover from in my tests, so we should at least inform the user about it. Patch makes sens to me, just a related question.. Do you get this when trying to enable the host mode, right? Or have you seen this in other situations too? I sometimes see it when booting with cable connected to PC or connecting cable to PC after using a host adapter. In those cases OTG port dies completely until a powercycle :( If the error happens when enabling the host mode, my experience is that the VBUS_ERROR is caused by the musb trying to be too smart and doing the timeouts automatically. If the VBUS on the hardware does not raise fast enough to the right range for whatever reason, musb can produce this error. Yeah the driver seems to expect that and has a ignore variable, I use KERN_DEBUG level in case it's set. Regards, Tony -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: log VBUS error
* Grazvydas Ignotas nota...@gmail.com [130311 10:12]: On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren t...@atomide.com wrote: * Grazvydas Ignotas nota...@gmail.com [130309 16:53]: VBUS_ERROR is a serious error that the driver often doesn't recover from in my tests, so we should at least inform the user about it. Patch makes sens to me, just a related question.. Do you get this when trying to enable the host mode, right? Or have you seen this in other situations too? I sometimes see it when booting with cable connected to PC or connecting cable to PC after using a host adapter. In those cases OTG port dies completely until a powercycle :( Hmm OK. I suspect there's some kernel bug currently with the OTG id pin detection where it's initial state during the boot is ignored. But replugging the cable should fix that, and in your case it sounds like that's not the case. If the error happens when enabling the host mode, my experience is that the VBUS_ERROR is caused by the musb trying to be too smart and doing the timeouts automatically. If the VBUS on the hardware does not raise fast enough to the right range for whatever reason, musb can produce this error. Yeah the driver seems to expect that and has a ignore variable, I use KERN_DEBUG level in case it's set. Yes in the host case I think we then just retry enabling the session bit and don't have anything in place to check that the VBUS regulator is ready or not. Have not looked at that code for a while though. Regards, 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 v4] xhci - correct comp_mode_recovery_timer on return from hibernate
Hi Sarah,
Sorry for my delayed response, I was investigating this. By 'Inactive' state
you mean the Compliance mode? since SS.Inactive and Compliance are not the same.
When in D3hot or D3cold, the host must be able to transmit a PME whenever a
device is plugged into the DS port. If a SS device is plugged into DS port and
fails to make it to U0, the Port will land in Compliance or SS.Disabled. If
Compliance, then there will be no PME notification. If it lands in
SS.Disabled, the USB2 will be enabled and then a PME notification will be sent
for USB2 connection. I just realized this.
Hope this helps.
Best Regards,
Alexis Cortes.
-Original Message-
From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
Sent: Wednesday, March 06, 2013 3:32 PM
To: Alan Stern; Cortes, Alexis
Cc: Tony Camuso; linux-usb@vger.kernel.org; r...@sisk.pl; dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from
hibernate
On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg) { ...
for (i = 0; i xhci-num_usb3_ports; i++) {
temp = xhci_readl(xhci, xhci-usb3_ports[i]);
if ((temp PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
/*
* Compliance Mode Detected. Letting USB Core
* handle the Warm Reset
*/
What happens when the xHCI host controller goes into D3cold due to
runtime PM? The port status registers will read as all f's, so we
will miss any transitions to the compliance mode that happened
before or during the transition to D3cold.
This code probably needs to wake up the host controller and keep it
from suspending until all the ports can be read.
Alan, would the right way to do that be a get/put call into the
runtime PM core?
If xhci_suspend deletes the Compliance Mode Recovery timer then the
timer will never fire while the controller is in D3cold. The problem
won't arise.
Alex,
Can the USB 3.0 port go into the Inactive sate while the host is in D3hot or
D3cold? If so, will we see a PME that will cause the USB core resume the host?
I'm concerned that if we don't get a port status change event when the port
goes into the Inactive state, then we won't get an interrupt if the port
transitions to the Inactive state while the host is in D3.
If the ports can't go into the Inactive state while the host is in D3, then I
agree with Alan that it's fine to delete the timer in xhci_suspend.
However, if the ports can to into the Inactive state and we won't get a PME,
then we have to keep the timer running while the xHCI host is runtime suspended.
Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: cdc-wdm: fix read buffer overflow
On Fri, Feb 15, 2013 at 12:30:11PM +0100, Bjørn Mork wrote: Oliver Neukum oli...@neukum.org writes: On Friday 15 February 2013 08:53:28 Bjørn Mork wrote: Oliver Neukum oli...@neukum.org writes: We have to let user space recover. To do so we need to indicate when exactly we dropped data. The problem with that is that this is likely to happen when a client just doesn't care. It will just continue happily ignoring the read data, writing new commands or whatever. Then the *next* client opening the file for reading will see this error. Well, this may be a separate bug. Should the buffer be cleared when we run out of openers? No. A valid use case, currently working just fine, is using e.g. shell commands to sequentially write and read, closing the file inbetween. I don't see any reason to suddenly break that. It is a userspace visible ABI. snip What ever was decided here? Can someone please send me the patch that you two agreed would solve this problem? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB patches
Hi,
On Mon, Mar 11, 2013 at 08:29:00AM -0700, Greg KH wrote:
On Mon, Mar 11, 2013 at 01:14:36PM +0200, Felipe Balbi wrote:
Hi Greg,
Here's my second set of fixes for this -rc cycle. Since my previous pull
request didn't reach v3.9-rc2, this one is based out of the previous.
That is fine, due to my travels last week, I didn't get a chance to get
stuff to Linus. I should catch up this week.
Surprised to see that git gracefully found a common commit by just running:
$ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3
(usb is my remote to kernel.org)
Anyway, let me know if you have any issues. I have merged this tag on top of
your greg/usb-linus branch just to make sure there'd be no conflicts and it
merges just fine.
cheers
The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec:
usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45
+0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
tags/fixes-for-v3.9-rc3
Pulled and pushed out, thanks.
hmm... and of course I made a mistake. Forgot to git add one hunk of one
patch, can you take it in patch form ? It's below, but I'll send as a
proper patch as a reply to this mail as well.
8 - cut here --
From 1e7bd9f5130d33a9bd6c005138030ac9ce8bbe7c Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Mon, 11 Mar 2013 19:58:06 +0200
Subject: [PATCH] usb: musb: core: fix possible build error with randconfig
when making commit e574d57 (usb: musb: fix
compile warning) I forgot to git add this
part of the patch which ended up introducing
a possible build error.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 13382e0..daec6e0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1624,8 +1624,6 @@ EXPORT_SYMBOL_GPL(musb_dma_completion);
/*-*/
-#ifdef CONFIG_SYSFS
-
static ssize_t
musb_mode_show(struct device *dev, struct device_attribute *attr, char *buf)
{
@@ -1742,8 +1740,6 @@ static const struct attribute_group musb_attr_group = {
.attrs = musb_attributes,
};
-#endif /* sysfs */
-
/* Only used to provide driver mode change events */
static void musb_irq_work(struct work_struct *data)
{
--
1.8.1.rc1.5.g7e0651a
--
balbi
signature.asc
Description: Digital signature
[PATCH] usb: musb: core: fix possible build error with randconfig
when making commit e574d57 (usb: musb: fix
compile warning) I forgot to git add this
part of the patch which ended up introducing
a possible build error.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 13382e0..daec6e0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1624,8 +1624,6 @@ EXPORT_SYMBOL_GPL(musb_dma_completion);
/*-*/
-#ifdef CONFIG_SYSFS
-
static ssize_t
musb_mode_show(struct device *dev, struct device_attribute *attr, char *buf)
{
@@ -1742,8 +1740,6 @@ static const struct attribute_group musb_attr_group = {
.attrs = musb_attributes,
};
-#endif /* sysfs */
-
/* Only used to provide driver mode change events */
static void musb_irq_work(struct work_struct *data)
{
--
1.8.1.rc1.5.g7e0651a
--
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: rename all phy drivers to phy-$name.c
Hi, On Mon, Mar 11, 2013 at 11:05:15AM -0600, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). On other thought here: The Tegra PHY in question here very specifically is a USB PHY. There's no way it could be used as e.g. a SATA PHY, either as a HW block or given the driver code that program is. Is sharing a PHY IP block or driver ever possible for any HW? yes it is possible, and OMAP5 shares the same IP for USB3 and SATA. PHYs don't know about USB, SATA, Ethernet and whatnot. PHYs know solely about the physical layer. Their work is just to generate the proper electrical signals. Hmm. Is the current code in drivers/usb/phy/tegra_usb_phy.c not really a PHY driver, then? Tegra's USB PHY HW module definitely does know that it's specifically a USB PHY. It has direct knowledge of knowledge of UTMI/ULPI doesn't mean it knows it's a USB PHY. SATA and USB3 use the PIPE3 interface, which was designed, originally, for PCIe. It's just that UTMI/ULPI only got used in USB scenario. UTMI/ULPI/... Instead, should the code be part of the EHCI driver, no way, no. EHCI-core should be taught about PHYs instead. since the concept of a PHY known to drivers/usb/phy doesn't seem related to what the Tegra PHY HW actually is? I disagree a PHY is a PHY, no matter if it's attached to a Host IP, Device IP or DRD IP. -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] USB patches
On Mon, Mar 11, 2013 at 08:00:29PM +0200, Felipe Balbi wrote: Hi, On Mon, Mar 11, 2013 at 08:29:00AM -0700, Greg KH wrote: On Mon, Mar 11, 2013 at 01:14:36PM +0200, Felipe Balbi wrote: Hi Greg, Here's my second set of fixes for this -rc cycle. Since my previous pull request didn't reach v3.9-rc2, this one is based out of the previous. That is fine, due to my travels last week, I didn't get a chance to get stuff to Linus. I should catch up this week. Surprised to see that git gracefully found a common commit by just running: $ git request-pull greg/usb-linus usb fixes-for-v3.9-rc3 (usb is my remote to kernel.org) Anyway, let me know if you have any issues. I have merged this tag on top of your greg/usb-linus branch just to make sure there'd be no conflicts and it merges just fine. cheers The following changes since commit 29240e2392786c39007df2f4162f3dc4680f3dec: usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.9-rc3 Pulled and pushed out, thanks. hmm... and of course I made a mistake. Forgot to git add one hunk of one patch, can you take it in patch form ? It's below, but I'll send as a proper patch as a reply to this mail as well. Applied, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: USB device registered on OHCI instead of EHCI at boot
On Fri, Mar 08, 2013 at 09:35:50PM -0500, Alan Stern wrote: The dmesg log shows the card reader attached to the EHCI controller at timestamp 2.569228 (which should be the boot-time detection) -- not to the OHCI controller. And it doesn't show any devices on bus 5. Why not? I have no idea. I'm sure there was a slow down on this boot (I posted right after unplugging the reader and plugging it back in) and the lsusb contents were accurate. However, I can no longer reproduce it with either this 3.8.2 kernel or 3.7.10, so I don't know. Maybe there is something after boot that is messing things up. Sorry for the noise. -- Bruce Guenter br...@untroubled.orghttp://untroubled.org/ signature.asc Description: Digital signature
Re: PROBLEM: USB device registered on OHCI instead of EHCI at boot
On Mon, 11 Mar 2013, Bruce Guenter wrote: On Fri, Mar 08, 2013 at 09:35:50PM -0500, Alan Stern wrote: The dmesg log shows the card reader attached to the EHCI controller at timestamp 2.569228 (which should be the boot-time detection) -- not to the OHCI controller. And it doesn't show any devices on bus 5. Why not? I have no idea. I'm sure there was a slow down on this boot (I posted right after unplugging the reader and plugging it back in) and the lsusb contents were accurate. However, I can no longer reproduce it with either this 3.8.2 kernel or 3.7.10, so I don't know. Maybe there is something after boot that is messing things up. Okay; if it happens again, collect the information and we'll go on from there. 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: phy: rename all phy drivers to phy-$name.c
Hi, On Mon, Mar 11, 2013 at 11:02:43AM -0600, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). Venu, please comment on what conflicts, if any, this will cause with the patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. BTW, let's stop with the whole dependency between PHY driver cleanup and arch/arm/mach-tegra/, too many patches have gone upstream bypassing my tree. What we should be doing is figuring out how to remove arch/ dependencies so that patches can go upstream and not cause conflicts. Unfortunately, there's no way to actually avoid the dependencies themselves. The DT bindings and EHCI/PHY controller split are wrong, and need work on both the DT and drivers to fix. but those changes don't need to come together, right ? I mean, for the DT part you could add the bindings to driver A without removing from driver B and span the changes accross 2 merge windows. There is only a single driver. It's being reworked to support the new binding. alright, so what's the problem of adding new binding without removing old one for v3.10 and remove old on v3.11 ? It gives a 3 month grace period for all boards to be converted, at least. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb/core/devio.c: Don't use GFP_KERNEL while we cannot reset a storage device
On Tue, 12 Mar 2013, Ming Lei wrote: In general it isn't, no. But usbfs uses the lock to prevent races with driver_disconnect() -- it is invalid to submit URBs after the disconnect routine has returned. If so, we may introduce another lock to avoid the race. So I think we may figure out to decrease the device lock scope in devio.c, and most of ioctl commands might not require it at all, then the problem addressed by the patch can be fixed too. That might work. A mutex could be added to the dev_state structure. The mutex would be locked whenever an URB was being submitted and during driver_disconnect, and perhaps a few other places too, but not when memory was being allocated. The device itself would remain unlocked most of the time. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: chipidea: core: switch over to devm_ioremap_resource
switch over to the newly added devm_ioremap_resource
which provides more consistent error messages.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/chipidea/core.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 57cae1f..7f3a9e1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -410,11 +410,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
- base = devm_request_and_ioremap(dev, res);
- if (!base) {
- dev_err(dev, can't request and ioremap resource\n);
- return -ENOMEM;
- }
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
ci = devm_kzalloc(dev, sizeof(*ci), GFP_KERNEL);
if (!ci) {
--
1.8.1.rc1.5.g7e0651a
--
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: rename all phy drivers to phy-$name.c
On 03/11/2013 12:49 PM, Felipe Balbi wrote: Hi, On Mon, Mar 11, 2013 at 11:02:43AM -0600, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). Venu, please comment on what conflicts, if any, this will cause with the patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. BTW, let's stop with the whole dependency between PHY driver cleanup and arch/arm/mach-tegra/, too many patches have gone upstream bypassing my tree. What we should be doing is figuring out how to remove arch/ dependencies so that patches can go upstream and not cause conflicts. Unfortunately, there's no way to actually avoid the dependencies themselves. The DT bindings and EHCI/PHY controller split are wrong, and need work on both the DT and drivers to fix. but those changes don't need to come together, right ? I mean, for the DT part you could add the bindings to driver A without removing from driver B and span the changes accross 2 merge windows. There is only a single driver. It's being reworked to support the new binding. alright, so what's the problem of adding new binding without removing old one for v3.10 and remove old on v3.11 ? It gives a 3 month grace period for all boards to be converted, at least. By binding, I assume you mean the driver code that implements the binding, so you want the driver to support both the old and new bindings at once? I don't think that's practical in this case. Currently the EHCI driver parses a single EHCI DT node, and passes some information down to the PHY driver. The PHY driver is in fact just a set of functions and not actually any kind of driver. The patches will split the single EHCI DT node into a separate EHCI and PHY DT nodes, convert the PHY driver to an actual (platform) driver, move the parsing of the PHY DT node into the new PHY DT driver, and remove the parsing of the PHY-related properties from the EHCI driver. Supporting both sets of DT content across that transition would be rather difficult I think. The patches will convert all in-tree boards, and I'm pretty confident that there aren't actually any out-of-tree boards for Tegra (that use a mainline kernel; there are plenty that don't use DT and are based on much older kernels). Hence, I don't see any need for a grace period here. Even if there are out-of-tree boards, the conversion of the DT content would take about 30 seconds. I'll volunteer to even do it (without testing!) for any out-of-tree boards if there are any. One reason that I really care about moving this forward quickly, is that you had indicated the driver cleanup was a pre-requisite to continuing to extend the code. Right now, the Tegra USB drivers only support Tegra20. We'd really like to get Tegra30 and now Tegra114 USB support into mainline ASAP. -- 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: remove MACH_OMAP_H4_OTG
The Kconfig option MACH_OMAP_H4_OTG was already considered dead as of v2.6.36, as can be seen in commit 267ecec95f7d215d2da38252640b06198515acc3 (Removing dead MACH_OMAP_H4_OTG). Remove its last trace now. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) Tested with make ARCH=arm menuconfig (specifically whether setting either MACH_OMAP_H2 or MACH_OMAP_H3 still selected ISP1301_OMAP). 1) By the way if ARCH_OMAP on the next line seems superfluous, as ARCH_OMAP1 already selects ARCH_OMAP. Minor nit, actually. drivers/usb/gadget/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 5a0c541..c65b5e2 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -194,7 +194,7 @@ config USB_FUSB300 config USB_OMAP tristate OMAP USB Device Controller depends on ARCH_OMAP1 - select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG + select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 select USB_OTG_UTILS if ARCH_OMAP help Many Texas Instruments OMAP processors have flexible full -- 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: [PATCH] usb: phy: rename all phy drivers to phy-$name.c
Hi, On Mon, Mar 11, 2013 at 01:54:54PM -0600, Stephen Warren wrote: On Mon, Mar 11, 2013 at 11:02:43AM -0600, Stephen Warren wrote: On 03/08/2013 12:08 AM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 01:37:17PM -0700, Stephen Warren wrote: On 03/07/2013 08:45 AM, Felipe Balbi wrote: this will make sure that we have sensible names for all phy drivers. Current situation was already quite bad with too generic names being used. Is phy-$name specific enough? There are other types of PHY such as Ethernet, etc. What about phy-usb-$name? we will be creating a generic (kernel-wide) phy layer, so I guess that matters very little. Specially since we don't want to be differentiating PHYs by their subsystem and rather by the IP name (which means phy-tegra, phy-samsung, phy-omap, are all 'wrong', but there were no better names). Venu, please comment on what conflicts, if any, this will cause with the patches you'll be sending to clean up the Tegra USB/PHY drivers. Thanks. BTW, let's stop with the whole dependency between PHY driver cleanup and arch/arm/mach-tegra/, too many patches have gone upstream bypassing my tree. What we should be doing is figuring out how to remove arch/ dependencies so that patches can go upstream and not cause conflicts. Unfortunately, there's no way to actually avoid the dependencies themselves. The DT bindings and EHCI/PHY controller split are wrong, and need work on both the DT and drivers to fix. but those changes don't need to come together, right ? I mean, for the DT part you could add the bindings to driver A without removing from driver B and span the changes accross 2 merge windows. There is only a single driver. It's being reworked to support the new binding. alright, so what's the problem of adding new binding without removing old one for v3.10 and remove old on v3.11 ? It gives a 3 month grace period for all boards to be converted, at least. By binding, I assume you mean the driver code that implements the binding, so you want the driver to support both the old and new bindings at once? I don't think that's practical in this case. Currently the EHCI driver parses a single EHCI DT node, and passes some information down to the PHY driver. The PHY driver is in fact just a set of functions and not actually any kind of driver. that's quite wrong :-) The patches will split the single EHCI DT node into a separate EHCI and PHY DT nodes, convert the PHY driver to an actual (platform) driver, move the parsing of the PHY DT node into the new PHY DT driver, and remove the parsing of the PHY-related properties from the EHCI driver. Supporting both sets of DT content across that transition would be rather difficult I think. ok, now I get the full picture. The patches will convert all in-tree boards, and I'm pretty confident that there aren't actually any out-of-tree boards for Tegra (that use a mainline kernel; there are plenty that don't use DT and are based on much older kernels). Hence, I don't see any need for a grace period here. Even if there are out-of-tree boards, the conversion of the DT content would take about 30 seconds. I'll volunteer to even do it (without testing!) for any out-of-tree boards if there are any. I guess we can't delete this from archives anymore :-p One reason that I really care about moving this forward quickly, is that you had indicated the driver cleanup was a pre-requisite to continuing to extend the code. Right now, the Tegra USB drivers only support Tegra20. We'd really like to get Tegra30 and now Tegra114 USB support into mainline ASAP. Alright, now that I have the full picture it makes it a lot easier to ack patches, thanks. Sorry for somewhat wasting time, please carry on. -- balbi signature.asc Description: Digital signature
Re: RFC: [PATCH 1/3] usb: cdc_ncm: patch for VMware
On Sun, 2013-03-10 at 22:12 +0100, Loic Domaigne wrote: On Fri, Mar 08, 2013 at 04:28:59PM -0600, Dan Williams wrote: On Fri, 2013-03-08 at 22:03 +0100, Loic Domaigne wrote: +/* maximum Rx URB size */ +/* + * in the original Linux driver, the rx urb size can be up to + * CDC_NCM_NTB_MAX_SIZE_RX. + * + * Under VMware (as of wks9), URB size greater than 16kB is a problem, + * so simply adjust this define when the driver is compiled for a VMware + * environment. + * + */ +#ifdef VMWARE_BUG +#warning Compiling for VMware +#define CDC_NCM_MAX_RX_URB_SIZE 16384 +#else +#define CDC_NCM_MAX_RX_URB_SIZE CDC_NCM_NTB_MAX_SIZE_RX +#endif I can't see how that is going to get past any sort of review. Either there's some other way of detecting that the CPU is the VMWare emulated one or you're stuck with the bug until VMWare fixes it. Yeah, I know. The kludge consists to (re)compile the kernel module on the VMWare guest with the VMWARE_BUG compiler flag set. We have a helper script for that task, but it's distros specific. We can detect automatically a VMWare emulated CPU in some cases, but not always. As a result, we end up sometimes asking the user. I am aware that it's not suitable as a generic solution. But waiting a fix from VMWare might not be practical for you either. Any better ideas? Example from drivers/misc/vmw_balloon.c: #include asm/hypervisor.h ... /* * Check if we are running on VMware's hypervisor and bail out * if we are not. */ if (x86_hyper != x86_hyper_vmware) return -ENODEV; Obviously for a non-x86-specific driver this needs to be conditional on #ifdef CONFIG_X86. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: REQUEST : Some help to write a new driver for LEAP motion device
On 03/11/2013 04:24 PM, Greg KH wrote: On Sun, Mar 10, 2013 at 07:52:55PM +0100, LECOQ Vincent wrote: Hello Dears, I have near me 2 piece of the Leap Motion device released as developpers release kits. (http://www.leapmotion.com/) The constructor give me only drivers for Microsoft ans Apple environements, and of course closed source. I ve have install a virtualbox with an windows environement and initialize the device, play some minute with. During this time I ve record the usbmon output that You can found here : http://oktail.org/download/dump_usb http://oktail.org/download/dump_usb Somebody can help me to understand this trace and start the linux driver ? Why not try asking the company if they will provide the specs for how to talk to the device, so that we can make a USB driver for Linux in a much easier manner? thanks, greg k-h The manufacturer have planed to release a linux drivers too in some week, but surely in closed source only. I preffer to have an open source. I have already manage this kind of technology for human detections before, i just need to understand the initialization of the device to do the nexts steps (driver, userland library and API). Thanks Vincent. -- 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: REQUEST : Some help to write a new driver for LEAP motion device
On Mon, Mar 11, 2013 at 09:41:47PM +0100, LECOQ Vincent wrote: On 03/11/2013 04:24 PM, Greg KH wrote: On Sun, Mar 10, 2013 at 07:52:55PM +0100, LECOQ Vincent wrote: Hello Dears, I have near me 2 piece of the Leap Motion device released as developpers release kits. (http://www.leapmotion.com/) The constructor give me only drivers for Microsoft ans Apple environements, and of course closed source. I ve have install a virtualbox with an windows environement and initialize the device, play some minute with. During this time I ve record the usbmon output that You can found here : http://oktail.org/download/dump_usb http://oktail.org/download/dump_usb Somebody can help me to understand this trace and start the linux driver ? Why not try asking the company if they will provide the specs for how to talk to the device, so that we can make a USB driver for Linux in a much easier manner? thanks, greg k-h The manufacturer have planed to release a linux drivers too in some week, but surely in closed source only. Why do you think this? USB Linux drivers can not be closed source. If they are planning on releasing Linux drivers, great, all should be fine. I preffer to have an open source. I have already manage this kind of technology for human detections before, i just need to understand the initialization of the device to do the nexts steps (driver, userland library and API). just can be an understatement :) Good luck, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND
Userspace applications need to know the maximum supported message
size.
Using a character device as interface to USB control messages hides
the fact that these messages have a strict size limit. The userspace
application must in most cases still be aware of this limit. It must
allocate sufficiently large read buffers, and it must prevent the
driver from splitting messages if the protocol requires more
advanced fragmentation like e.g. CDC MBIM does.
The limit could be read from CDC functional descriptors for CDC WDM
and CDC MBIM devices, duplicating the parsing already done by the
driver probe. For other devices, where the limit is based on a
hardcoded default, the application will need hardcode this default
as well. Such hidden and implicit kernel dependencies are bad and
makes it impossible to ever change the defaults.
All this is unnecessarily complex and likely to make drivers and
applications end up using different limits, causing errors which
are hard to debug and replicate.
Exporting the maximum message size from the driver simplifies
the task for the userspace application, and creates a unified
information source independent of device and function class.
Signed-off-by: Bjørn Mork bj...@mork.no
---
Oliver Neukum oli...@neukum.org writes:
On Saturday 09 February 2013 20:16:20 Bjørn Mork wrote:
Oliver Neukum oli...@neukum.org writes:
On Saturday 09 February 2013 18:41:52 Bjørn Mork wrote:
Well, OK..., generic then. In the sense that the attribute stays the
same regardless of whether the value is hardcoded in the driver (QMI),
or parsed from wMaxCommand (CDC WDM) or wMaxControlMessage (CDC MBIM)
Not sure I understand what you want here... I am trying to avoid having
three different attributes for the three drivers currently needing this
number.
I would say that the most generic solution would be an ioctl()
I am not exactly sure how to do this, but does this look like something
that could be submitted?
The issue just came up again, after I tried to get a user with an
Ericsson H5521gw modem to run mbimcli. It failed because the hard coded
message size is too big. We need a simple way for userspace applications
to check the message size.
Bjørn
Documentation/ioctl/ioctl-number.txt |1 +
drivers/usb/class/cdc-wdm.c | 19 +++
include/linux/usb/cdc-wdm.h |2 ++
include/uapi/linux/usb/cdc-wdm.h | 21 +
4 files changed, 43 insertions(+)
create mode 100644 include/uapi/linux/usb/cdc-wdm.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 3210540..237acab 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -131,6 +131,7 @@ Code Seq#(hex) Include FileComments
'H'40-4F sound/hdspm.h conflict!
'H'40-4F sound/hdsp.hconflict!
'H'90 sound/usb/usx2y/usb_stream.h
+'H'A0 uapi/linux/usb/cdc-wdm.h
'H'C0-F0 net/bluetooth/hci.h conflict!
'H'C0-DF net/bluetooth/hidp/hidp.h conflict!
'H'C0-DF net/bluetooth/cmtp/cmtp.h conflict!
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 5f0cb41..6463d8c 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -13,6 +13,7 @@
*/
#include linux/kernel.h
#include linux/errno.h
+#include linux/ioctl.h
#include linux/slab.h
#include linux/module.h
#include linux/mutex.h
@@ -628,6 +629,22 @@ static int wdm_release(struct inode *inode, struct file
*file)
return 0;
}
+static long wdm_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ struct wdm_device *desc = file-private_data;
+ int rv = 0;
+
+ switch (cmd) {
+ case IOCTL_WDM_MAX_COMMAND:
+ if (copy_to_user((void __user *)arg, desc-wMaxCommand,
sizeof(desc-wMaxCommand)))
+ rv = -EFAULT;
+ break;
+ default:
+ rv = -ENOTTY;
+ }
+ return rv;
+}
+
static const struct file_operations wdm_fops = {
.owner =THIS_MODULE,
.read = wdm_read,
@@ -636,6 +653,8 @@ static const struct file_operations wdm_fops = {
.flush =wdm_flush,
.release = wdm_release,
.poll = wdm_poll,
+ .unlocked_ioctl = wdm_ioctl,
+ .compat_ioctl = wdm_ioctl,
.llseek = noop_llseek,
};
diff --git a/include/linux/usb/cdc-wdm.h b/include/linux/usb/cdc-wdm.h
index 719c332..0b3f429 100644
--- a/include/linux/usb/cdc-wdm.h
+++ b/include/linux/usb/cdc-wdm.h
@@ -11,6 +11,8 @@
#ifndef __LINUX_USB_CDC_WDM_H
#define __LINUX_USB_CDC_WDM_H
+#include uapi/linux/usb/cdc-wdm.h
+
extern struct usb_driver *usb_cdc_wdm_register(struct usb_interface *intf,
struct usb_endpoint_descriptor *ep,
int bufsize,
diff --git
Re: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND
On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote: Userspace applications need to know the maximum supported message size. Can't they get that from sysfs from the USB field that defines this? Adding a new ioctl is usually not a good idea, who is going to change the userspace tools to properly call this ioctl? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: cdc-wdm: fix read buffer overflow
Greg Kroah-Hartman gre...@linuxfoundation.org writes: On Fri, Feb 15, 2013 at 12:30:11PM +0100, Bjørn Mork wrote: Oliver Neukum oli...@neukum.org writes: On Friday 15 February 2013 08:53:28 Bjørn Mork wrote: Oliver Neukum oli...@neukum.org writes: We have to let user space recover. To do so we need to indicate when exactly we dropped data. The problem with that is that this is likely to happen when a client just doesn't care. It will just continue happily ignoring the read data, writing new commands or whatever. Then the *next* client opening the file for reading will see this error. Well, this may be a separate bug. Should the buffer be cleared when we run out of openers? No. A valid use case, currently working just fine, is using e.g. shell commands to sequentially write and read, closing the file inbetween. I don't see any reason to suddenly break that. It is a userspace visible ABI. snip What ever was decided here? Can someone please send me the patch that you two agreed would solve this problem? I believe Oliver's patch titled cdc-wdm: fix buffer overflow dated Wed, 27 Feb 2013 10:29:02 +0100 was the conclusion to all this. I'll leave it to Oliver to resend it if this is correct. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND
Greg KH gre...@linuxfoundation.org writes: On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote: Userspace applications need to know the maximum supported message size. Can't they get that from sysfs from the USB field that defines this? Not at the moment since we don't export it. But that is of course easy to fix. This was how I started. The next problem was that this message size property is common to all drivers using the cdc-wdm code (cdc-wdm, cdc_mbim and qmi_wwan), and they all have different USB descriptors defining it. So you would have 3 different fields (if you decided to add a pseudo field for qmi_wwan, which hard codes a sane value) for the same property. This made me create the first patch, which added a common sysfs propery to the cdc-wdm device instead. The response to that was I would say that the most generic solution would be an ioctl() Adding a new ioctl is usually not a good idea, who is going to change the userspace tools to properly call this ioctl? That will be Aleksander's job :) No, being serious I do realize the problem and I don't know if it is such a good idea either. But I do know that we need some way for the driver to let userspace know this value without having to guess too much. Currently, when a userspace application sees a /dev/cdc-wdmX device, it will have to - check which USB interface it belongs to, - parse the DMM descriptor if it is CDC WDM, - parse the MBIM descriptor if it is CDC MBIM - check if the driver is qmi_wwan if none of the above - know which value qmi_wwan has hard coded No application does this. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND
On Mon, Mar 11, 2013 at 10:28:21PM +0100, Bjørn Mork wrote: Greg KH gre...@linuxfoundation.org writes: On Mon, Mar 11, 2013 at 10:00:21PM +0100, Bjørn Mork wrote: Userspace applications need to know the maximum supported message size. Can't they get that from sysfs from the USB field that defines this? Not at the moment since we don't export it. But that is of course easy to fix. This was how I started. The next problem was that this message size property is common to all drivers using the cdc-wdm code (cdc-wdm, cdc_mbim and qmi_wwan), and they all have different USB descriptors defining it. So you would have 3 different fields (if you decided to add a pseudo field for qmi_wwan, which hard codes a sane value) for the same property. This made me create the first patch, which added a common sysfs propery to the cdc-wdm device instead. The response to that was I would say that the most generic solution would be an ioctl() Adding a new ioctl is usually not a good idea, who is going to change the userspace tools to properly call this ioctl? That will be Aleksander's job :) No, being serious I do realize the problem and I don't know if it is such a good idea either. But I do know that we need some way for the driver to let userspace know this value without having to guess too much. Currently, when a userspace application sees a /dev/cdc-wdmX device, it will have to - check which USB interface it belongs to, - parse the DMM descriptor if it is CDC WDM, - parse the MBIM descriptor if it is CDC MBIM - check if the driver is qmi_wwan if none of the above - know which value qmi_wwan has hard coded No application does this. Hm, I hate to ask, but what does other OSes do (OS-X, Windows, etc.) about this? And what happens today that causes us to need this size? How have we lived so long without it? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flood of xhci warnings with 3.9.0-rc1
On Sun, Mar 10, 2013 at 12:04:40PM -0700, Stephen Hemminger wrote: My test kernel is screaming with xHCI messages into kernel log. [ 76.117016] xhci_hcd :00:14.0: WARN Event TRB for slot 1 ep 0 with no TDs queued? This is using kernel based on net-next which is based on 3.9.0-rc1. Please send `sudo lspci -vvv -n` output as well. Do you have any USB devices that have auto-suspend turned on? I'm aware that the message above gets printed when a device auto-suspends, and it really shouldn't in that case. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Isochronous transfer error on USB3
On Mon, Mar 11, 2013 at 01:21:48PM +0100, jean-philippe francois wrote: Hi, The company I work for is doing USB cameras, for which I wrote the drivers (out of tree). Kernel driver or userspace driver? Raw camera data are transferred using isochronous transfer, which work fine when used on USB2 EHCI. However when plugging the camera on an USB3 port, xhci spits the following messages on URB submission : [ 1704.989785] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Does the device work properly, despite the error messages? I see that there are transfer errors in the log file, along with those messages. Are those expected? USB3 host is an asmedia ASM1042. Do you know if this is a 1.0 xHCI host? E.g. when you enable CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING, do you see lines like this during driver initialization: CAPLENGTH AND HCIVERSION 0x180: If you see that line start with 0x100, it's a 1.0 xHCI host. If starts with 0x096, it's a 0.96 host; 0x095 would be a 0.95 host. I ask because I have a todo list entry to fix short packet handling on xHCI 1.0 hosts: On Intel Lynx Point xHCI, when you plug in a HS USB webcam, the log will fill with the error message: ERROR Transfer event TRB DMA ptr not part of current TD However, the video looks fine, and there is no impact on the driver behavior. This is caused by a change between the xHCI 0.96 and the xHCI 1.0 spec. The change describes in section 4.10.1.1 how the xHCI host controller should handle short transfers that happen on a TD comprised of more than one TRB chained together. The 0.96 spec says that the host will only send one event with a short completion code for the TD. The 1.0 spec says if the short packet happened on a TRB that wasn't the last TRB in the TD, then we will get two events with short completions (one for the short TRB and one for the last TRB with the IOC flag set). The 1.0 spec says that the xHCI driver shall not consider the TD to be done until the second event is received. The current xHCI driver behavior finishes the TD when it receives the first short event. Then when it receives the second event, it prints the warning message. This also appeared under the xHCI 1.0 host in Intel Panther Point xHCI, but it was mistaken for a known hardware bug, the spurious successful event bug. The work-around that was put into the driver masks this xHCI driver bug. Impact on the driver is minimal for this bug. The easy fix is just to change the XHCI_SPURIOUS_SUCCESS quirk to be applied for all 1.0 xHCI hosts. However, that doesn't solve the race condition that exists when the endpoint is stopped before the second event TRB is received. The harder fix is to either add an event data TRB after the chained TD (and stop using ISP and IOC flags), or make the xHCI ring handling code wait for the second event completion for xHCI 1.0 hosts. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from hibernate
On Mon, Mar 11, 2013 at 05:33:26PM +, Cortes, Alexis wrote:
Hi Sarah,
Sorry for my delayed response, I was investigating this. By 'Inactive' state
you mean the Compliance mode? since SS.Inactive and Compliance are not the
same.
Yes, I mean Compliance mode.
When in D3hot or D3cold, the host must be able to transmit a PME whenever a
device is plugged into the DS port. If a SS device is plugged into DS port
and fails to make it to U0, the Port will land in Compliance or SS.Disabled.
If Compliance, then there will be no PME notification. If it lands in
SS.Disabled, the USB2 will be enabled and then a PME notification will be
sent for USB2 connection. I just realized this.
Then we definitely need to poll during runtime suspend, or disable
runtime PM for the PCI device all together.
Does this mean wake from S3 (system suspend) on device connect will be
broken as well, if the port fails to make it to U0 and goes into
Compliance mode?
Sarah Sharp
-Original Message-
From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
Sent: Wednesday, March 06, 2013 3:32 PM
To: Alan Stern; Cortes, Alexis
Cc: Tony Camuso; linux-usb@vger.kernel.org; r...@sisk.pl; dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return
from hibernate
On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg) { ...
for (i = 0; i xhci-num_usb3_ports; i++) {
temp = xhci_readl(xhci, xhci-usb3_ports[i]);
if ((temp PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
/*
* Compliance Mode Detected. Letting USB Core
* handle the Warm Reset
*/
What happens when the xHCI host controller goes into D3cold due to
runtime PM? The port status registers will read as all f's, so we
will miss any transitions to the compliance mode that happened
before or during the transition to D3cold.
This code probably needs to wake up the host controller and keep it
from suspending until all the ports can be read.
Alan, would the right way to do that be a get/put call into the
runtime PM core?
If xhci_suspend deletes the Compliance Mode Recovery timer then the
timer will never fire while the controller is in D3cold. The problem
won't arise.
Alex,
Can the USB 3.0 port go into the Inactive sate while the host is in D3hot or
D3cold? If so, will we see a PME that will cause the USB core resume the
host? I'm concerned that if we don't get a port status change event when the
port goes into the Inactive state, then we won't get an interrupt if the port
transitions to the Inactive state while the host is in D3.
If the ports can't go into the Inactive state while the host is in D3, then I
agree with Alan that it's fine to delete the timer in xhci_suspend.
However, if the ports can to into the Inactive state and we won't get a PME,
then we have to keep the timer running while the xHCI host is runtime
suspended.
Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flood of xhci warnings with 3.9.0-rc1
On Mon, 11 Mar 2013 14:48:01 -0700 Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Sun, Mar 10, 2013 at 12:04:40PM -0700, Stephen Hemminger wrote: My test kernel is screaming with xHCI messages into kernel log. [ 76.117016] xhci_hcd :00:14.0: WARN Event TRB for slot 1 ep 0 with no TDs queued? This is using kernel based on net-next which is based on 3.9.0-rc1. Please send `sudo lspci -vvv -n` output as well. Do you have any USB devices that have auto-suspend turned on? I'm aware that the message above gets printed when a device auto-suspends, and it really shouldn't in that case. Sarah Sharp I don't explicitly turn on auto-suspend, but maybe some sysctl is doing it (powertop?). 00:00.0 0600: 8086:0150 (rev 09) Subsystem: 1043:84ca Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? 00:01.0 0604: 8086:0151 (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: f000-0fff Memory behind bridge: df30-df5f Prefetchable memory behind bridge: f000-f02f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: 1043:84ca Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00298 Data: Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 256 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #2, Speed 8GT/s, Width x16, ASPM L0s L1, Latency L0 256ns, L1 8us ClockPM- Surprise- LLActRep- BwNot+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt+ SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #1, PowerLimit 75.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd- LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -3.5dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress-
Re: [PATCH] vers/usb/gadget: beautify code, delete useless comments
Felipe Balbi also pointed my subject and comments issue. and I have sent the related new patch for it. the new patch subject is [PATCH] usb: gadget: s3c-hsudc: delete outdated comment please help checking the new patch, thanks. :-) 于 2013年03月11日 19:28, Sergei Shtylyov 写道: Hello. On 11-03-2013 14:14, Chen Gang wrote: since parameter driver has been deleted, also need delete relative comments. relative You probably meant related in both cases? ok, thanks, I need notice, next time. commit number is d93e2600d80fc41ccf339b4a2843a3007d479907 Please also specify that commit's summary line in parens (or however you like). ok, thanks. I need notice, next time. Signed-off-by: Chen Gang gang.c...@asianux.com WBR, Sergei -- Chen Gang Asianux Corporation -- 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 v7 0/6] staging: DWC2 DesignWare USB HS OTG driver
Hi Greg, Here is the latest version of the DWC2 patch set. This version includes changes suggested by Felipe in his review of the HCD code. Only patch #2 has had any substantial changes since last time. I have also moved the driver to the staging tree, since it doesn't look like it's ready for mainline yet. -- Paul This is a host-mode driver for the Synopsys DesignWare HS OTG controller. This is the same controller whose peripheral mode is implemented by the existing s3c-hsotg driver. This controller is also used in host mode in the Raspberry Pi via a very ugly out-of-tree driver, so merging this would be a step toward bringing USB support for that platform into mainline. The idea is to add a dwc2/ directory alongside the existing dwc3/ directory, initially to contain just this host-mode driver. Once that has been accepted we would then like to move the s3c-hsotg driver into this directory and integrate it to make a dual-role driver. Finally we will implement support for the OTG features of the controller. This driver is still a work in progress, to wit: - Only a PCI bus interface has been implemented so far. However the core code and the PCI bus glue code are contained in separate modules, so it will be easy to add platform driver interfaces in the future. I have already done that with a platform driver for the Raspberry Pi, but it is not included here since USB support for that platform is out of tree. - There is no power-management support yet. - There is quite a bit of debug code included. We would like to keep that until the integration with s3c-hsotg is complete, then most of it can be stripped out. Changes since v6 - Made a fix to the dwc2_hcd_endpoint_disable() function to close a race that Felipe spotted. Refactored some of the HCD code per Felipe's suggestions. Moved driver to the staging tree. Changes since v5 - Made a few minor tweaks in response to Felipe's last review. Also, use usb_calc_bus_time() in place of a private version, and implement the .clear_tt_buffer_complete callback, both at the suggestion of Alan Stern. Fixed a couple of driver crashes that were exposed by those changes. Changes since v4 - Changes in response to Felipe's third review. Also removed the module parameters. Plus made a few more cleanups and simplifications. Changes since v3 - Numerous changes in response to Felipe's second review. Changes since v2 - Fixed a problem with periodic transfers, so hubs, mice and keyboards work reliably now. Fixed a spurious channel halted interrupt by disabling the interrupt if the channel is idle. Changes since v1 - Numerous changes in response to Felipe's review. Paul Zimmerman (6): Core files for the DWC2 driver HCD files for the DWC2 driver HCD descriptor DMA support for the DWC2 driver PCI bus interface for the DWC2 driver Hook the DWC2 driver into the build system Add a MAINTAINERS entry for the DWC2 driver MAINTAINERS |6 + drivers/staging/Kconfig |2 + drivers/staging/Makefile |1 + drivers/staging/dwc2/Kconfig | 41 + drivers/staging/dwc2/Makefile| 23 + drivers/staging/dwc2/core.c | 2678 ++ drivers/staging/dwc2/core.h | 658 + drivers/staging/dwc2/core_intr.c | 505 +++ drivers/staging/dwc2/hcd.c | 2951 ++ drivers/staging/dwc2/hcd.h | 737 ++ drivers/staging/dwc2/hcd_ddma.c | 1196 +++ drivers/staging/dwc2/hcd_intr.c | 2079 +++ drivers/staging/dwc2/hcd_queue.c | 675 + drivers/staging/dwc2/hw.h| 811 +++ drivers/staging/dwc2/pci.c | 198 +++ 15 files changed, 12561 insertions(+) create mode 100644 drivers/staging/dwc2/Kconfig create mode 100644 drivers/staging/dwc2/Makefile create mode 100644 drivers/staging/dwc2/core.c create mode 100644 drivers/staging/dwc2/core.h create mode 100644 drivers/staging/dwc2/core_intr.c create mode 100644 drivers/staging/dwc2/hcd.c create mode 100644 drivers/staging/dwc2/hcd.h create mode 100644 drivers/staging/dwc2/hcd_ddma.c create mode 100644 drivers/staging/dwc2/hcd_intr.c create mode 100644 drivers/staging/dwc2/hcd_queue.c create mode 100644 drivers/staging/dwc2/hw.h create mode 100644 drivers/staging/dwc2/pci.c -- 1.8.2.rc0.16.g20a599e -- 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 v7 3/6] staging: HCD descriptor DMA support for the DWC2 driver
This file contains code to support the HCD descriptor DMA mode of
the controller
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/staging/dwc2/hcd_ddma.c | 1196 +++
1 file changed, 1196 insertions(+)
create mode 100644 drivers/staging/dwc2/hcd_ddma.c
diff --git a/drivers/staging/dwc2/hcd_ddma.c b/drivers/staging/dwc2/hcd_ddma.c
new file mode 100644
index 000..ab88f50
--- /dev/null
+++ b/drivers/staging/dwc2/hcd_ddma.c
@@ -0,0 +1,1196 @@
+/*
+ * hcd_ddma.c - DesignWare HS OTG Controller descriptor DMA routines
+ *
+ * Copyright (C) 2004-2013 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
+ * IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file contains the Descriptor DMA implementation for Host mode
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/usb.h
+
+#include linux/usb/hcd.h
+#include linux/usb/ch11.h
+
+#include core.h
+#include hcd.h
+
+static u16 dwc2_frame_list_idx(u16 frame)
+{
+ return frame (FRLISTEN_64_SIZE - 1);
+}
+
+static u16 dwc2_desclist_idx_inc(u16 idx, u16 inc, u8 speed)
+{
+ return (idx + inc)
+ ((speed == USB_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 dwc2_desclist_idx_dec(u16 idx, u16 inc, u8 speed)
+{
+ return (idx - inc)
+ ((speed == USB_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 dwc2_max_desc_num(struct dwc2_qh *qh)
+{
+ return (qh-ep_type == USB_ENDPOINT_XFER_ISOC
+ qh-dev_speed == USB_SPEED_HIGH) ?
+ MAX_DMA_DESC_NUM_HS_ISOC : MAX_DMA_DESC_NUM_GENERIC;
+}
+
+static u16 dwc2_frame_incr_val(struct dwc2_qh *qh)
+{
+ return qh-dev_speed == USB_SPEED_HIGH ?
+ (qh-interval + 8 - 1) / 8 : qh-interval;
+}
+
+static int dwc2_desc_list_alloc(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh,
+ gfp_t flags)
+{
+ qh-desc_list = dma_alloc_coherent(hsotg-dev,
+ sizeof(struct dwc2_hcd_dma_desc) *
+ dwc2_max_desc_num(qh), qh-desc_list_dma,
+ flags);
+
+ if (!qh-desc_list)
+ return -ENOMEM;
+
+ memset(qh-desc_list, 0,
+ sizeof(struct dwc2_hcd_dma_desc) * dwc2_max_desc_num(qh));
+
+ qh-n_bytes = kzalloc(sizeof(u32) * dwc2_max_desc_num(qh), flags);
+ if (!qh-n_bytes) {
+ dma_free_coherent(hsotg-dev, sizeof(struct dwc2_hcd_dma_desc)
+ * dwc2_max_desc_num(qh), qh-desc_list,
+ qh-desc_list_dma);
+ qh-desc_list = NULL;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void dwc2_desc_list_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
+{
+ if (qh-desc_list) {
+ dma_free_coherent(hsotg-dev, sizeof(struct dwc2_hcd_dma_desc)
+ * dwc2_max_desc_num(qh), qh-desc_list,
+
[PATCH v7 4/6] staging: PCI bus interface for the DWC2 driver
This file contains the PCI bus interface glue for the DWC2 driver
Signed-off-by: Paul Zimmerman pa...@synopsys.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/staging/dwc2/pci.c | 198 +
1 file changed, 198 insertions(+)
create mode 100644 drivers/staging/dwc2/pci.c
diff --git a/drivers/staging/dwc2/pci.c b/drivers/staging/dwc2/pci.c
new file mode 100644
index 000..117d3ce
--- /dev/null
+++ b/drivers/staging/dwc2/pci.c
@@ -0,0 +1,198 @@
+/*
+ * pci.c - DesignWare HS OTG Controller PCI driver
+ *
+ * Copyright (C) 2004-2013 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
+ * IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * Provides the initialization and cleanup entry points for the DWC_otg PCI
+ * driver
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pci.h
+#include linux/usb.h
+
+#include linux/usb/hcd.h
+#include linux/usb/ch11.h
+
+#include core.h
+#include hcd.h
+
+#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_PRODUCT_ID_HAPS_HSOTG 0xabc0
+
+static const char dwc2_driver_name[] = dwc_otg;
+
+static struct dwc2_core_params dwc2_module_params = {
+ .otg_cap= -1,
+ .otg_ver= -1,
+ .dma_enable = -1,
+ .dma_desc_enable= 0,
+ .speed = -1,
+ .enable_dynamic_fifo= -1,
+ .en_multiple_tx_fifo= -1,
+ .host_rx_fifo_size = 1024,
+ .host_nperio_tx_fifo_size = 256,
+ .host_perio_tx_fifo_size= 1024,
+ .max_transfer_size = 65535,
+ .max_packet_count = 511,
+ .host_channels = -1,
+ .phy_type = -1,
+ .phy_utmi_width = 16, /* 16 bits - NOT DETECTABLE */
+ .phy_ulpi_ddr = -1,
+ .phy_ulpi_ext_vbus = -1,
+ .i2c_enable = -1,
+ .ulpi_fs_ls = -1,
+ .host_support_fs_ls_low_power = -1,
+ .host_ls_low_power_phy_clk = -1,
+ .ts_dline = -1,
+ .reload_ctl = -1,
+ .ahb_single = -1,
+};
+
+/**
+ * dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
+ * DWC_otg driver
+ *
+ * @dev: Bus device
+ *
+ * This routine is called, for example, when the rmmod command is executed. The
+ * device may or may not be electrically present. If it is present, the driver
+ * stops device processing. Any resources used on behalf of this device are
+ * freed.
+ */
+static void dwc2_driver_remove(struct pci_dev *dev)
+{
+ struct dwc2_hsotg *hsotg = pci_get_drvdata(dev);
+
+ dev_dbg(dev-dev, %s(%p)\n, __func__, dev);
+
+ dwc2_hcd_remove(dev-dev, hsotg);
+ pci_disable_device(dev);
+}
+
+/**
+ * dwc2_driver_probe() - Called when the DWC_otg core is bound to the DWC_otg
+ * driver
+ *
+ * @dev: Bus device
+ *
+ * This routine creates the driver components required to control the device
+ *
[PATCH v7 5/6] staging: Hook the DWC2 driver into the build system
Add the DWC2 Kconfig and Makefile, and modify the USB Kconfig and Makefile to include them Signed-off-by: Paul Zimmerman pa...@synopsys.com --- drivers/staging/Kconfig | 2 ++ drivers/staging/Makefile | 1 + drivers/staging/dwc2/Kconfig | 41 + drivers/staging/dwc2/Makefile | 23 +++ 4 files changed, 67 insertions(+) create mode 100644 drivers/staging/dwc2/Kconfig create mode 100644 drivers/staging/dwc2/Makefile diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 093f10c..1df401a 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -140,4 +140,6 @@ source drivers/staging/zcache/Kconfig source drivers/staging/goldfish/Kconfig +source drivers/staging/dwc2/Kconfig + endif # STAGING diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index fa41b04..2a6a607 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -62,3 +62,4 @@ obj-$(CONFIG_SB105X) += sb105x/ obj-$(CONFIG_FIREWIRE_SERIAL) += fwserial/ obj-$(CONFIG_ZCACHE) += zcache/ obj-$(CONFIG_GOLDFISH) += goldfish/ +obj-$(CONFIG_USB_DWC2) += dwc2/ diff --git a/drivers/staging/dwc2/Kconfig b/drivers/staging/dwc2/Kconfig new file mode 100644 index 000..610418a --- /dev/null +++ b/drivers/staging/dwc2/Kconfig @@ -0,0 +1,41 @@ +config USB_DWC2 + tristate DesignWare USB2 DRD Core Support + depends on USB + select USB_OTG_UTILS + help + Say Y or M here if your system has a Dual Role HighSpeed + USB controller based on the DesignWare HSOTG IP Core. + + If you choose to build this driver as dynamically linked + modules, the core module will be called dwc2.ko, and the + PCI bus interface module (if you have a PCI bus system) + will be called dwc2_pci.ko. + + NOTE: This driver at present only implements the Host mode + of the controller. The existing s3c-hsotg driver supports + Peripheral mode, but only for the Samsung S3C platforms. + There are plans to merge the s3c-hsotg driver with this + driver in the near future to create a dual-role driver. + +if USB_DWC2 + +config USB_DWC2_DEBUG + bool Enable Debugging Messages + help + Say Y here to enable debugging messages in the DWC2 Driver. + +config USB_DWC2_VERBOSE + bool Enable Verbose Debugging Messages + depends on USB_DWC2_DEBUG + help + Say Y here to enable verbose debugging messages in the DWC2 Driver. + WARNING: Enabling this will quickly fill your message log. + If in doubt, say N. + +config USB_DWC2_TRACK_MISSED_SOFS + bool Enable Missed SOF Tracking + help + Say Y here to enable logging of missed SOF events to the dmesg log. + If in doubt, say N. + +endif diff --git a/drivers/staging/dwc2/Makefile b/drivers/staging/dwc2/Makefile new file mode 100644 index 000..6dccf46 --- /dev/null +++ b/drivers/staging/dwc2/Makefile @@ -0,0 +1,23 @@ +ccflags-$(CONFIG_USB_DWC2_DEBUG) += -DDEBUG +ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE_DEBUG + +obj-$(CONFIG_USB_DWC2) += dwc2.o + +dwc2-y += core.o core_intr.o + +# NOTE: This driver at present only implements the Host mode +# of the controller. The existing s3c-hsotg driver supports +# Peripheral mode, but only for the Samsung S3C platforms. +# There are plans to merge the s3c-hsotg driver with this +# driver in the near future to create a dual-role driver. Once +# that is done, Host mode will become an optional feature that +# is selected with a config option. + +dwc2-y += hcd.o hcd_intr.o +dwc2-y += hcd_queue.o hcd_ddma.o + +ifneq ($(CONFIG_PCI),) + obj-$(CONFIG_USB_DWC2) += dwc2_pci.o +endif + +dwc2_pci-y += pci.o -- 1.8.2.rc0.16.g20a599e -- 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 v7 6/6] staging: Add a MAINTAINERS entry for the DWC2 driver
Add myself as maintainer of the DWC2 driver Signed-off-by: Paul Zimmerman pa...@synopsys.com --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e95b1e9..6672165 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2470,6 +2470,12 @@ M: Matthew Garrett mj...@srcf.ucam.org S: Maintained F: drivers/platform/x86/dell-wmi.c +DESIGNWARE USB2 DRD IP DRIVER +M: Paul Zimmerman pa...@synopsys.com +L: linux-usb@vger.kernel.org +S: Maintained +F: drivers/staging/dwc2/ + DESIGNWARE USB3 DRD IP DRIVER M: Felipe Balbi ba...@ti.com L: linux-usb@vger.kernel.org -- 1.8.2.rc0.16.g20a599e -- 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: fsl_udc_core: set address request aren't handled like expected. usb30cv test suite fails.
Hi, I tested your patch, Peter and it works fine. All tests of the usbcv30 are passing with my setup. Thank you so far. So you get a tested-by: peter.best...@omicron.at In my opinion we do it in the wrong order; we set the address before the status stage completes. But isn't the setAddress request specified that we should set it after the status stage completes, like it was before (http://www.beyondlogic.org/usbnutshell/usb6.shtml) We set address at the ep0_req_complete, it is called after the status stage is completed. -- 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: PROBLEM: since linux kernel 3.8 Apple Cinema Display's usb hub spits errors randomly at boot.
On 03/11/2013 04:06 PM, Alan Stern wrote: On Mon, 11 Mar 2013, Jenya Y wrote: // Update Alan, I'm happy to say that the errors disappeared. I recompiled the latest master from torvalds with USB_CONFIG=Y instead of 'm' and the errors are gone. I'm not sure it was this particular config flag + the settings you suggested earlier or simply the changes that were incorporated into the latest master but everything is working perfectly now. Thank you very very much for you patience with me and I'll be glad to assist if you need any help figuring out what went right :) Well, I'd like to take the credit for this but I don't really deserve it. :-) The problem you had is a valid one and it deserves to be fixed. People should not have to select particular combinations of config options in order to avoid a ton of error messages. I'll try to work out a patch in the next few days. Can you recreate the arrangement where all the errors occurred, in order to test the patch when it is ready? Alan Stern Absolutely, I'd be glad to help. Just tell me what kernel should I use to apply your patch and I'll prepare the env to test it. -- 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: Flood of xhci warnings with 3.9.0-rc1
On Mon, 11 Mar 2013 17:55:42 -0700 Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Well, let's find out. Can you please run the following command as root? for f in /sys/bus/usb/devices/*; do if [ -e $f/power/control ]; then echo Filename: $f; cat $f/power/control; fi done All are marked auto Filename: /sys/bus/usb/devices/1-1 auto Filename: /sys/bus/usb/devices/2-1 auto Filename: /sys/bus/usb/devices/2-1.5 auto Filename: /sys/bus/usb/devices/2-1.5.1 on Filename: /sys/bus/usb/devices/2-1.5.3 on Filename: /sys/bus/usb/devices/2-1.5.4 on Filename: /sys/bus/usb/devices/2-1.6 auto Filename: /sys/bus/usb/devices/3-4 auto Filename: /sys/bus/usb/devices/usb1 auto Filename: /sys/bus/usb/devices/usb2 auto Filename: /sys/bus/usb/devices/usb3 auto Filename: /sys/bus/usb/devices/usb4 auto -- 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: Flood of xhci warnings with 3.9.0-rc1
On Mon, 11 Mar 2013 17:55:42 -0700 Sarah Sharp sarah.a.sh...@linux.intel.com wrote: All right. You've got a Intel Panther Point xHCI host then. Did you notice these messages on older kernels, or just with the 3.9-rc1 kernel? It seems to be new in 3.9, haven't bisected it down. -- 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: Fwd: a usb regression in kernel 2.6.37 and upper
On Mon, 11 Mar 2013, Sarah Sharp wrote: On Mon, Mar 11, 2013 at 02:50:57PM +0800, Joshua wrote: ... Recently, I read the EHCI 1.1 addendum specification. I noticed there are some implementations in kernel for that spec by intel engineers, but i didn't find the Hardware Prefetching support . Did the kernel support that feature? I doubt there have such a EHCI that supports the EHCI 1.1. What would an EHCI addendum have to do with your particular bug? Or is this a different question? Alan Stern would probably be the best person to ask this question, since he's the EHCI maintainer. ehci-hcd does not support Hardware Prefetching. Since Intel played a big role in designing the EHCI 1.1 addendum, it seems likely that they made some EHCI controllers supporting those extensions. But I don't know the details, and I don't know if the controllers in the current chipsets support EHCI-1.1. 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: About USBADRA bit at DEVICEADDR for chipidea driver
On Mon, Mar 11, 2013 at 10:58:05AM -0400, Alan Stern wrote: On Mon, 11 Mar 2013, Alexander Shishkin wrote: For USB 3.0 host CV test, the host sends GET_DESCRIPTOR very quick (500us) once it accept the status of SET_ADDRESS The USB 2.0 spec says the recovery period after the status phase of SetAddress is 2ms. That should be enough to process the transfer completion interrupt, shouldn't it? Why is USB 3 CV violating this and why should we care? I guess, if we Probably because the recovery period, being in the USB 2.0 spec, applies to USB-2 devices -- whereas the USB-3 CV tries to test USB-3 devices. Do they have the same recovery period? Alex Alan, I checked the USB 3.0 spec, there is no requirement for recovery time. So, for this problem, it is USB3 CV suite's problem, When it detects 2.0 device, it should follow 2.0 recovery time. -- 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
[PATCH 15/18] driver: usb: storage: remove cast for kmalloc return value
remove cast for kmalloc return value.
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Matthew Dharm mdharm-...@one-eyed-alien.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: linux-usb@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
---
drivers/usb/storage/isd200.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index ecea478..06a3d22 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -1457,8 +1457,7 @@ static int isd200_init_info(struct us_data *us)
retStatus = ISD200_ERROR;
else {
info-id = kzalloc(ATA_ID_WORDS * 2, GFP_KERNEL);
- info-RegsBuf = (unsigned char *)
- kmalloc(sizeof(info-ATARegs), GFP_KERNEL);
+ info-RegsBuf = kmalloc(sizeof(info-ATARegs), GFP_KERNEL);
info-srb.sense_buffer =
kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
if (!info-id || !info-RegsBuf || !info-srb.sense_buffer) {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
