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
[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 --- 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] 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 > > 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 Reviewed-by: Jingoo Han 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: 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
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
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
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 >> >> 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 >> Acked-by: Paul Zimmerman >> --- >> 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-usb&m=141392377124818&w=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 >
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 > Cc: Randy Dunlap > Cc: David Airlie > Cc: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Darren Hart > Cc: Laurent Pinchart > Cc: Benjamin Herrenschmidt > Cc: Jens Frederich > Cc: Daniel Drake > Cc: Jon Nettleton > Cc: Jean-Christophe Plagniol-Villard > Cc: Tomi Valkeinen > Signed-off-by: Jani Nikula As for the drivers/platform/x86/Kconfig: Acked-by: Darren Hart 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
[PATCH] usb: dwc2: allow dwc2 to get built when USB_GADGET=m
From: Dinh Nguyen 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 --- 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: [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 Cc: "Rafael J. Wysocki" >>> >>> 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 #include #include +#include #include #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 > >> Cc: "Rafael J. Wysocki" > > > > 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 > >> #include > >> #include > >> +#include > >> #include > >> > >> #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 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 >> Cc: "Rafael J. Wysocki" > > 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 >> #include >> #include >> +#include >> #include >> >> #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: 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
---
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: [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
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
