RE: [PATCH 18/28] usb: dwc3: ep0: fix Data Phase for transfer sizes aligned to wMaxPacketSize
From: Alan Stern From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of David Laight Sent: Monday, October 20, 2014 2:48 AM From: Felipe Balbi According to Section 8.5.3.2 of the USB 2.0 specification, a USB device must terminate a Data Phase with either a short packet or a ZLP (if the previous transfer was a multiple of wMaxPacketSize). For reference, here's what the USB 2.0 specification, section 8.5.3.2 says: 8.5.3.2 Variable-length Data Stage A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, the function should indicate that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage. If that is the same as my understanding of the USB3 spec then the requirement for a ZLP isn't unconditional. In particular if the data phase isn't variable length then a ZLP must not be added. Also, in the USB 3.0 spec, the corresponding section has been modified a bit. The last sentence has been changed to this: Note that if the amount of data in the data structure that is returned to the host *is less than the amount requested by the host* and is an exact multiple of maximum packet size then a control endpoint shall send a zero length DP to terminate the data stage. (emphasis mine) So I think you also need to take into account the wLength field of the request, and only send the ZLP if the amount of data returned is less than wLength. That's right, and it's true for USB-2 as well. A ZLP is needed only in cases where the host otherwise wouldn't know the transfer is over, i.e., when the transfer length is a nonzero multiple of the maxpacket size and is smaller than wLength. It's not clear what a variable length control transfer is supposed to be. I guess it means that sometimes the device will send back less than wLength bytes of data. I take it as being one where the amount of data returned isn't known by the host when it performs the 'read' request. So the response to a 'disk read' request is known and a ZLP isn't required (even though the transfer request is likely to be a multiple of the packet size). The length that matters is that of the buffer(s) supplied by the receiving driver. From the USB driver's point of view, only the 'application' (another driver) knows whether the next receive message is 'variable length', so the onus has to be on the 'application' sending the data to say whether it needs a ZLP. Has anyone fixed xhci to send ZLP yet ? David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] usb: gadget: composite: Provide a list of available functions
-Original Message- From: 'Sebastian Andrzej Siewior' [mailto:sebast...@breakpoint.cc] Sent: Monday, October 20, 2014 7:38 PM To: Krzysztof Opasiak Cc: 'Krzysztof Opasiak'; Andrzej Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-Hartman'; ba...@ti.com; 'Sebastian Andrzej Siewior'; matt.por...@linaro.org; linux-usb@vger.kernel.org Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of available functions On 2014-10-17 16:30:24 [+0200], Krzysztof Opasiak wrote: So you didn't answer my questions. Say you have a list of two functions says acm and ncm. Based on this information how do you know how to configure it? That's a good question but not directly related to current problem. The problem is that user ends up in empty functions directory in some gadget and has to write some magic strings which he may not know. He has just build in the usb_f_mass_storage module and usb_f_ss_lb and where should he get the information that he needs to use mass_storage, Loopback and SourceSink as function types? All those three are just magic strings hardcoded in kernel and not exported in any place to userspace but we enforce the user to know them and provide them to configfs. okay. I try it once again and I am close to give up: target uses configfs in a very similar fashion compared to what the gadget interface does. Similar to the gadget interface it provides different fabrics and back-ends. I doubt there is a list of available functionality exported somewhere in the target code. I believe very much that the userland hides all that information from you and simply assumes that the modules is available (and the kernel tries to load it if is not available but that is an implementation detail whether the kernel or that tool tries to load the module on failure). I don't know the target and it's configfs usage so I can only speak about composing gadget. Assuming that all usb functions are available in kernel is not a good idea. This hurts user experience because a tool or something may tell user that such function is available when really it's not. This means that creating it's instance will fail. Functions are kind of building blocks and gadget is simply some building which consist of that blocks. Those blocks are identified using some unique ID called function type which is just a string registered by kernel driver. Our assumption is that user know exactly how to configure RNDIS, Function FS and other functions. Problem is that user doesn't know which of those functions are available in his current kernel and what are the magic strings registered as a type name. Problem is on two levels: - bare command line interface level User doesn't have any additional tool and only know what is the convention and what is Remote Network Driver Interface Specification and what is Function FS and how to use them. So now I ask how user can discover that first of them is registered as rndis and not as RNDIS or Rndis or maybe RndiS? Moreover let's say that function fs has not been selected while building this kernel and it's not available. So how should we discover it? Just try to create the directory? This is good for one function but what if we have 10 or 15 of them? - tool or library level While creating such thing we may hardcode the strings for each currently mainlined function and information how to configure it. The case here is that usually currently running kernel will have only subset of those functions but not all of them. The question here is how user can ask such a tool what he can create? Showing user a full list of known function may be confusing because on one hand we show that this functions is available but on other hand we tell him that we cannot create such function because there is no suitable module. Of course tool can iterate over all known usb functions and try to create each of them to check if this function is available. Don't you thing that this is a little bit weird and confusing? It look really ugly, cause overhead and makes configfs dirty due to creating some test gadget to check available functions. Second scenario is that we have some running kernel and everything is compiled-in and we would like to create a gadget. Let's say that we have experience and we know all that magic strings but there still is a problem because we don't know what is available in current kernel. We need to try creating instance for all known for us functions type to learn what is available in this kernel. That is the wrong attempt. You have to have a config file in your userland tool which provides the information of all available functions and how / what is required to configure them. If the user decides to use the storage function the tool will offer the two storage functions we have _or_ display a list of all available functions including a hint/help text what the function what it is good for (or do
[PATCH] usb: hub: remove unused variable
the integer variable 'feature' was not being used anywhere in the function.
so it is safe to remove the variable.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/usb/core/hub.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 11e80ac..7eb45cd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3907,14 +3907,9 @@ static void usb_enable_link_state(struct usb_hcd *hcd,
struct usb_device *udev,
static int usb_disable_link_state(struct usb_hcd *hcd, struct usb_device *udev,
enum usb3_link_state state)
{
- int feature;
-
switch (state) {
case USB3_LPM_U1:
- feature = USB_PORT_FEAT_U1_TIMEOUT;
- break;
case USB3_LPM_U2:
- feature = USB_PORT_FEAT_U2_TIMEOUT;
break;
default:
dev_warn(udev-dev, %s: Can't disable non-U1 or U2 state.\n,
--
1.8.1.2
--
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: [resend PATCH 1/3] ACPI / platform: provide default DMA mask
On 24/09/14 16:49, Rafael J. Wysocki wrote: On Wednesday, September 24, 2014 11:00:37 AM Heikki Krogerus wrote: Most devices are configured for 32-bit DMA addresses. Setting the mask to 32-bit here removes the need for the drivers to do it separately. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com Cc: Rafael J. Wysocki r...@rjwysocki.net ACK Hi I need this for another driver. Did this patch go anywhere? Note Heikki is away at the moment. Regards Adrian --- drivers/acpi/acpi_platform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 2bf9082..8d099e6 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -16,6 +16,7 @@ #include linux/err.h #include linux/kernel.h #include linux/module.h +#include linux/dma-mapping.h #include linux/platform_device.h #include internal.h @@ -102,6 +103,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) pdevinfo.res = resources; pdevinfo.num_res = count; pdevinfo.acpi_node.companion = adev; +pdevinfo.dma_mask = DMA_BIT_MASK(32); pdev = platform_device_register_full(pdevinfo); if (IS_ERR(pdev)) dev_err(adev-dev, platform device creation failed: %ld\n, -- 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: [resend PATCH 1/3] ACPI / platform: provide default DMA mask
On Tuesday, October 21, 2014 03:27:45 PM Adrian Hunter wrote: On 24/09/14 16:49, Rafael J. Wysocki wrote: On Wednesday, September 24, 2014 11:00:37 AM Heikki Krogerus wrote: Most devices are configured for 32-bit DMA addresses. Setting the mask to 32-bit here removes the need for the drivers to do it separately. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com Cc: Rafael J. Wysocki r...@rjwysocki.net ACK Hi I need this for another driver. Did this patch go anywhere? It's not in 3.18-rc1 as far as I can say. Note Heikki is away at the moment. That's OK. I guess I can queue up this one for you. When do you need this to get into the Linus' tree? --- drivers/acpi/acpi_platform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 2bf9082..8d099e6 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -16,6 +16,7 @@ #include linux/err.h #include linux/kernel.h #include linux/module.h +#include linux/dma-mapping.h #include linux/platform_device.h #include internal.h @@ -102,6 +103,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) pdevinfo.res = resources; pdevinfo.num_res = count; pdevinfo.acpi_node.companion = adev; + pdevinfo.dma_mask = DMA_BIT_MASK(32); pdev = platform_device_register_full(pdevinfo); if (IS_ERR(pdev)) dev_err(adev-dev, platform device creation failed: %ld\n, -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: [resend PATCH 1/3] ACPI / platform: provide default DMA mask
On 21/10/14 16:08, Rafael J. Wysocki wrote: On Tuesday, October 21, 2014 03:27:45 PM Adrian Hunter wrote: On 24/09/14 16:49, Rafael J. Wysocki wrote: On Wednesday, September 24, 2014 11:00:37 AM Heikki Krogerus wrote: Most devices are configured for 32-bit DMA addresses. Setting the mask to 32-bit here removes the need for the drivers to do it separately. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com Cc: Rafael J. Wysocki r...@rjwysocki.net ACK Hi I need this for another driver. Did this patch go anywhere? It's not in 3.18-rc1 as far as I can say. Note Heikki is away at the moment. That's OK. I guess I can queue up this one for you. When do you need this to get into the Linus' tree? My patches are aiming for 3.19 --- drivers/acpi/acpi_platform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 2bf9082..8d099e6 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -16,6 +16,7 @@ #include linux/err.h #include linux/kernel.h #include linux/module.h +#include linux/dma-mapping.h #include linux/platform_device.h #include internal.h @@ -102,6 +103,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) pdevinfo.res = resources; pdevinfo.num_res = count; pdevinfo.acpi_node.companion = adev; + pdevinfo.dma_mask = DMA_BIT_MASK(32); pdev = platform_device_register_full(pdevinfo); if (IS_ERR(pdev)) dev_err(adev-dev, platform device creation failed: %ld\n, -- 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: dwc2: allow dwc2 to get built when USB_GADGET=m
From: Dinh Nguyen dingu...@opensource.altera.com This patch allows the gadget portion of the DWC2 driver to get built when (!USB USB_GADGET) condition is encountered. Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com --- drivers/usb/dwc2/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..4d02718 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,6 +1,6 @@ config USB_DWC2 bool DesignWare USB2 DRD Core Support - depends on USB + depends on USB || USB_GADGET help Say Y here if your system has a Dual Role Hi-Speed USB controller based on the DesignWare HSOTG IP Core. -- 2.0.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Sat, Oct 18, 2014 at 12:13:23AM +0300, Jani Nikula wrote: Documentation/kbuild/kconfig-language.txt warns to use select with care, and in general use select only for non-visible symbols and for symbols with no dependencies, because select will force a symbol to a value without visiting the dependencies. Select has become particularly problematic, interdependently, with the BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example: scripts/kconfig/conf --randconfig Kconfig KCONFIG_SEED=0x48312B00 warning: (DRM_RADEON DRM_NOUVEAU DRM_I915 DRM_GMA500 DRM_SHMOBILE DRM_TILCDC FB_BACKLIGHT FB_MX3 USB_APPLEDISPLAY FB_OLPC_DCON ASUS_LAPTOP SONY_LAPTOP THINKPAD_ACPI EEEPC_LAPTOP ACPI_CMPC SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM BACKLIGHT_LCD_SUPPORT) warning: (DRM_RADEON DRM_NOUVEAU DRM_I915 DRM_GMA500 DRM_SHMOBILE DRM_TILCDC FB_BACKLIGHT FB_MX3 USB_APPLEDISPLAY FB_OLPC_DCON ASUS_LAPTOP SONY_LAPTOP THINKPAD_ACPI EEEPC_LAPTOP ACPI_CMPC SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM BACKLIGHT_LCD_SUPPORT) With tristates it's possible to end up selecting FOO=y depending on BAR=m in the config, which gets discovered at build time, not config time, like reported in the thread referenced below. Do the following to fix the dependencies: * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of BACKLIGHT_CLASS_DEVICE. * Remove config FB_BACKLIGHT altogether, and replace it with a dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting FB_BACKLIGHT select or depend on FB anyway, so we can simplify. * Depend on (ACPI ACPI_VIDEO) || ACPI=n in several places instead of selecting ACPI_VIDEO and a number of its dependencies if ACPI is enabled. This is tied to backlight, as ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE. * Replace a couple of select INPUT/VT with depends as it seemed to be necessary. Reference: http://lkml.kernel.org/r/ca+r1zhhmt4drwtf6mbrqo5eqxwx+lxcqh15vsu_d9wpftlh...@mail.gmail.com Reported-by: Jim Davis jim.ep...@gmail.com Cc: Randy Dunlap rdun...@infradead.org Cc: David Airlie airl...@linux.ie Cc: Daniel Vetter daniel.vet...@intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Darren Hart dvh...@infradead.org Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Jens Frederich jfreder...@gmail.com Cc: Daniel Drake d...@laptop.org Cc: Jon Nettleton jon.nettle...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Jani Nikula jani.nik...@intel.com As for the drivers/platform/x86/Kconfig: Acked-by: Darren Hart dvh...@linux.intel.com Thanks, -- Darren Hart Intel Open Source Technology Center -- 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: [PATCHv5 7/7] usb: dwc2: Update Kconfig to support dual-role
On 10/20/2014 02:42 PM, Paul Bolle wrote: dingu...@opensource.altera.com schreef op ma 20-10-2014 om 13:52 [-0500]: From: Dinh Nguyen dingu...@opensource.altera.com Update DWC2 kconfig and makefile to support dual-role mode. The platform file will always get compiled for the case where the controller is directly connected to the CPU. So for loadable modules, dwc2.ko is built for host, peripheral, and dual-role mode. The PCI bus interface will be called dwc2_pci.ko and the platform interface module will be called dwc2_platform.ko. Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com Acked-by: Paul Zimmerman pa...@synopsys.com --- v5: dwc2.ko for all modes along with dwc2_platform.ko and dwc2_pci.ko will get built for kernel modules. v3: Add USB_GADGET=y and USB_GADGET=USB_DWC2 for peripheral and dual-role config options. v2: Remove reference to dwc2_gadget --- drivers/usb/dwc2/Kconfig | 61 --- drivers/usb/dwc2/Makefile | 32 - 2 files changed, 53 insertions(+), 40 deletions(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..1ea702e 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,5 +1,5 @@ config USB_DWC2 -bool DesignWare USB2 DRD Core Support +tristate DesignWare USB2 DRD Core Support depends on USB (Side note: drivers/usb/dwc2/Kconfig is sourced (in drivers/usb/Kconfig) even if USB is _not_ set. But USB_DCW2 still depends on USB. Why is that?) Because USB is for Host-Side support. DWC2 driver should only get built for when USB is enabled. I think you're getting USB and USB_SUPPORT mixed up. In addition, thanks to your comment, I realized that DWC2 should also be available to build when USB_GADGET is enabled. A patch has been sent: http://marc.info/?l=linux-usbm=141392377124818w=2 help Say Y here if your system has a Dual Role Hi-Speed USB @@ -10,31 +10,53 @@ config USB_DWC2 bus interface module (if you have a PCI bus system) will be called dwc2_pci.ko, and the platform interface module (for controllers directly connected to the CPU) will be called - dwc2_platform.ko. For gadget mode, there will be a single - module called dwc2_gadget.ko. - - NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. The - host and gadget drivers are still currently separate drivers. - There are plans to merge the dwc2_gadget driver with the dwc2 - host driver in the near future to create a dual-role driver. + dwc2_platform.ko. For all modes(host, gadget and dual-role), there + will be a single module called dwc2.ko. if USB_DWC2 +choice +bool DWC2 Mode Selection +default USB_DWC2_DUAL_ROLE if (USB USB_GADGET) +default USB_DWC2_HOST if (USB !USB_GADGET) +default USB_DWC2_PERIPHERAL if (!USB USB_GADGET) + Juggling kconfig tristate logic is still rather hard for me, but don't the above three if rules all evaluate to non-zero if both USB and USB_GADGET are 'm'? If that's correct perhaps USB_DWC2_DUAL_ROLE should be the last default (assuming the last default wins, that is). As the way it is, the functionality is correct. As this is the same as DWC3's Kconfig, perhaps Felipe can comment if something doesn't seem correct. Besides, will the default USB_DWC2_PERIPHERAL ever trigger as !USB can't be true at this point, can it? Yes it can. USB is for Host-side support, so you can have a condition where you just want to build for GADGET and !USB. config USB_DWC2_HOST -tristate Host only mode +bool Host only mode depends on USB help The Designware USB2.0 high-speed host controller - integrated into many SoCs. + integrated into many SoCs. Select this option if you want the + driver to operate in Host-only mode. + +comment Gadget/Dual-role mode requires USB Gadget support to be enabled + +config USB_DWC2_PERIPHERAL +bool Gadget only mode +depends on USB_GADGET=y || USB_GADGET=USB_DWC2 +help + The Designware USB2.0 high-speed gadget controller + integrated into many SoCs. Select this option if you want the + driver to operate in Peripheral-only mode. This option requires + USB_GADGET=y. + +config USB_DWC2_DUAL_ROLE +bool Dual Role mode +depends on (USB=y || USB=USB_DWC2) (USB_GADGET=y || USB_GADGET=USB_DWC2) +help + Select this option if you want the driver to work in a dual-role + mode. In this mode both host and gadget features are enabled, and + the role will be determined by the cable that gets plugged-in. This + option requires USB_GADGET=y. +endchoice (I wonder how the dependencies of these three config entries interact with the three defaults of this choice. Since we're dealing with three options here this requires a piece of paper, a pencil, and clear mind
usbutils 008 release
Here's the 008 release of usbutils. It's been over a year since the 007 release, and a bunch of small bugfixes have piled up, along with a much larger change of now using the hwdb instead of the old usb.ids file (a patch which almost all distros using systemd have been shipping for a while), so it's time for a new release. The short changelog can be found below. The package can be downladed from kernel.org: http://www.kernel.org/pub/linux/utils/usb/usbutils/ The source tree for usbutils can be found on both kernel.org and github.com if you want to fork it and send us changes easier: http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git http://github.com/gregkh/usbutils/tree/master thanks, greg k-h --- Alexandra Yates (2): lsusb: Reports if USB2.0 port is on L1 state lsusb: Reports devices that support BESL on USB2.0 Aurelien Jarno (1): dump_ccid_device: fix a typo Ben Chan (1): lsusb: decode CDC MBIM extended functional descriptor Greg Kroah-Hartman (10): lsusb: fix incorrect printf() for CAPS lsusb-t: handle problem if there is no usb bus list .gitignore: add compile to the list of things we need to ignore usbutils 008 release John Freed (1): Fix logic error Kurt Garloff (1): Update lsusb.py in usbutils Lukas Nykryn (2): update COPYING file lsusb-t: don't segfault when usbbuslist is empty Peter Wu (1): Ignore invalid string descriptors Raphaël Droz (1): usb-devices: hexadecimal bInterfaceNumber handling Tom Gundersen (2): lsusb: port to hwdb drop dependency on usb.ids Vadim Rutkovsky (1): New path for usbhid-dump submodule -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: gadget: Properly initialize LINK TRB
On ISOC endpoints the last trb_pool entry used as a LINK TRB is not getting zeroed out correctly due to memset being called incorrectly and in the wrong place. If pool allocated from DMA was not zero-initialized to begin with this will result in the size and ctrl values being random garbage. Call memset correctly after assignment of the trb_link pointer. Fixes: f6bafc6a1c (usb: dwc3: convert TRBs into bitshifts) Signed-off-by: Jack Pham ja...@codeaurora.org Cc: sta...@vger.kernel.org --- drivers/usb/dwc3/gadget.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 3818b26..f231b51 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -525,12 +525,11 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, if (!usb_endpoint_xfer_isoc(desc)) return 0; - memset(trb_link, 0, sizeof(trb_link)); - /* Link TRB for ISOC. The HWO bit is never reset */ trb_st_hw = dep-trb_pool[0]; trb_link = dep-trb_pool[DWC3_TRB_NUM - 1]; + memset(trb_link, 0, sizeof(*trb_link)); trb_link-bpl = lower_32_bits(dwc3_trb_dma_offset(dep, trb_st_hw)); trb_link-bph = upper_32_bits(dwc3_trb_dma_offset(dep, trb_st_hw)); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: dwc2: allow dwc2 to get built when USB_GADGET=m
On Wednesday, October 22, 2014 5:32 AM, Dinh Nguyen wrote: From: Dinh Nguyen dingu...@opensource.altera.com This patch allows the gadget portion of the DWC2 driver to get built when (!USB USB_GADGET) condition is encountered. Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com Reviewed-by: Jingoo Han jg1@samsung.com Best regards, Jingoo Han --- drivers/usb/dwc2/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..4d02718 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,6 +1,6 @@ config USB_DWC2 bool DesignWare USB2 DRD Core Support - depends on USB + depends on USB || USB_GADGET help Say Y here if your system has a Dual Role Hi-Speed USB controller based on the DesignWare HSOTG IP Core. -- 2.0.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: imx21-hcd: use %pad for dma_addr_t
Use %pad for dma_addr_t, because a dma_addr_t type can vary based on build options. So, it prevents the following build warnings in printks. drivers/usb/host/imx21-hcd.c:1175:2: warning: format '%X' expects argument of type 'unsigned int', but argument 8 has type 'dma_addr_t' [-Wformat] drivers/usb/host/imx21-hcd.c:1175:2: warning: format '%X' expects argument of type 'unsigned int', but argument 10 has type 'dma_addr_t' [-Wformat] Signed-off-by: Jingoo Han jg1@samsung.com --- drivers/usb/host/imx21-hcd.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/imx21-hcd.c b/drivers/usb/host/imx21-hcd.c index 207bad9..eb4efba 100644 --- a/drivers/usb/host/imx21-hcd.c +++ b/drivers/usb/host/imx21-hcd.c @@ -1174,11 +1174,11 @@ static int imx21_hc_urb_enqueue(struct usb_hcd *hcd, dev_vdbg(imx21-dev, enqueue urb=%p ep=%p len=%d - buffer=%p dma=%08X setupBuf=%p setupDma=%08X\n, + buffer=%p dma=%pad setupBuf=%p setupDma=%pad\n, urb, ep, urb-transfer_buffer_length, - urb-transfer_buffer, urb-transfer_dma, - urb-setup_packet, urb-setup_dma); + urb-transfer_buffer, urb-transfer_dma, + urb-setup_packet, urb-setup_dma); if (usb_pipeisoc(urb-pipe)) return imx21_hc_urb_enqueue_isoc(hcd, ep, urb, mem_flags); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 18/28] usb: dwc3: ep0: fix Data Phase for transfer sizes aligned to wMaxPacketSize
Hi, On Mon, 20 Oct 2014, Paul Zimmerman wrote: From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of David Laight Sent: Monday, October 20, 2014 2:48 AM From: Felipe Balbi According to Section 8.5.3.2 of the USB 2.0 specification, a USB device must terminate a Data Phase with either a short packet or a ZLP (if the previous transfer was a multiple of wMaxPacketSize). For reference, here's what the USB 2.0 specification, section 8.5.3.2 says: 8.5.3.2 Variable-length Data Stage A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, the function should indicate that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage. If that is the same as my understanding of the USB3 spec then the requirement for a ZLP isn't unconditional. In particular if the data phase isn't variable length then a ZLP must not be added. Also, in the USB 3.0 spec, the corresponding section has been modified a bit. The last sentence has been changed to this: Note that if the amount of data in the data structure that is returned to the host *is less than the amount requested by the host* and is an exact multiple of maximum packet size then a control endpoint shall send a zero length DP to terminate the data stage. (emphasis mine) So I think you also need to take into account the wLength field of the request, and only send the ZLP if the amount of data returned is less than wLength. That's right, and it's true for USB-2 as well. A ZLP is needed only in cases where the host otherwise wouldn't know the transfer is over, i.e., when the transfer length is a nonzero multiple of the maxpacket size and is smaller than wLength. Shall we use/check struct usb_request's zero flag for this? It's not clear what a variable length control transfer is supposed to be. I guess it means that sometimes the device will send back less than wLength bytes of data. 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 -- 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
