aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/gadget
Commit message (Collapse)AuthorAge
...
| * | usb: gadget: loopback: fix: Don't share qlen and buflen between instancesKrzysztof Opasiak2015-10-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each instance of loopback function may have different qlen and buflen attributes values. When linking function to configuration those values had been assigned to global variables. Linking other instance to config overwrites those values. This commit moves those values to f_loopback structure to avoid overwriting. Now each function has its own instance of those values. Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Reviewed-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_sourcesink: fix function params handlingRobert Baldyga2015-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move function parameters to struct f_sourcesink to make them per instance instead of having them as global variables. Since we can have multiple instances of USB function we also want to have separate set of parameters for each instance. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: composite: fill bcdUSB for any gadget max speedIgor Kotrasinski2015-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When handling device GET_DESCRIPTOR, composite gadget driver fills the bcdUSB field only if the gadget supports USB 3.0. Otherwise the field is left unfilled. For consistency, set bcdUSB to 0x0200 for gadgets that don't support superspeed. It's correct to use 0x0200 for any setting that doesn't use superspeed, since USB 2.0 devices can restrict themselves to full speed only. It is NOT correct to use 0x0210, since BOS descriptors are handled only if gadget_is_superspeed() is satisfied, otherwise it results in a stall. Signed-off-by: Igor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: SourceSink: Fix show methods for attributesKrzysztof Opasiak2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | Most of USB functions place new line after attribute value. Let's follow this convention also in source sink function as it improves readability. Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: loopback: Fix show methods for attributesKrzysztof Opasiak2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | Most of USB functions place new line after attribute value. Let's follow this convention also in loopback function as it improves readability. Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: at91_udc: mention proper dependencySudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While building allmodconfig on avr32 the build failed with the error: "at91_pmc_base" [drivers/usb/gadget/udc/atmel_usba_udc.ko] undefined! On checking the code it turned out that if CONFIG_OF is defined then it is using at91_pmc_read() which is using at91_pmc_base. And unless COMMON_CLK_AT91 is defined we donot have at91_pmc_base. And COMMON_CLK_AT91 is available with AT91 architecture. Mention the dependency such that this driver builds with avr32 only if OF is not enabled. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: NULL comparisonSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | A NULL comparison can be written as if (var) or if (!var). Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove forward declaration of udc_basic_initSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | Rearrange the udc_basic_init function to remove the forward declaration. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove forward declaration of udc_pci_*Sudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | Remove the forward declarations of udc_pci_probe and udc_pci_remove. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove forward declaration of udc_free_dma_chainSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | Rearrange udc_free_dma_chain to remove the forward declaration. While at it fixed all the relevant checkpatch warnings. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove forward declaration of udc_create_dma_chainSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | Rearrange udc_create_dma_chain to remove the forward declaration. While rearranging fixed the relevant checkpatch warnings. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove forward declaration of udc_remote_wakeupSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | Rearrange the udc_remote_wakeup function to remove the forward declaration. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove forward declaration of udc_probeSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | Rearrange the udc_probe function to remove the forward declarations. While rearranging also fixed the relevant checkpatch warnings. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: remove unnecessary conditionsSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The condition checking for irq_registered, regs, mem_region and active are not required as this is the remove function. And we are in the remove means that probe was successful and they can never be NULL at this point of code. It was required in the original code as the remove function was part of the error handler of probe function. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: use free_dma_poolsSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have the function free_dma_pools() which frees all the dma pools. Use it instead of calling all the functions separately. The if conditions for data_requests and stp_requests are also not required here as this is the remove function and we are here means probe has succeeded and dma has been successfully allocated, so they cannot be NULL here. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: use WARN_ONSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | | | | Use WARN_ON() instead of halting the kernel with BUG_ON() and also fix the checkpatch warning. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: fix error pathSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | Handle the error properly instead of calling the pci remove function. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: amd5536udc: rewrite init_dma_poolsSudip Mukherjee2015-10-01
| | | | | | | | | | | | | | | | | | | | | A rewrite of init_dma_pools() with proper error handling. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: pch-udc: fix lockFelipe Balbi2015-09-28
| | | | | | | | | | | | | | | | | | | | | | | | gadget methods should be called without spinlocks held. Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: legacy: tcm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of tcm, ep->driver_data was used only for endpoint claiming so we can simplify code by reducing it. We also remove give_back_ep() function which is not needed after all - when error code is returned from bind() function, composite will release all endpoints anyway. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: legacy: dbgp: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of dbgp, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: u_serial: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of u_serial ep->driver_data stores pointer to struct gs_port, which is referenced in many places in code. Code using ep->driver_data to mark endpoint as enabled/disabled has been removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: u_ether: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of u_ether we only need to store in ep->driver_data pointer to struct eth_dev, as it's used in rx_complete() and tx_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_uvc: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uvc, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_uac2: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uac2, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_uac1: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uac1, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_subset: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_subset, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_sourcesink: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_sourcesink we only need to store in ep->driver_data pointer to struct f_sourcesink, as it's used in source_sink_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_serial: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_serial, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_rndis: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_rndis, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_printer: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_printer we only need to store in ep->driver_data pointer to struct printer_dev, as it's used in rx_complete() and tx_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_phonet: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_phonet we only need to store in ep->driver_data pointer to struct f_phonet, as it's used in pn_tx_complete() and pn_rx_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_obex: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_obex, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_ncm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ncm, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_midi: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_midi we only need to store in ep->driver_data pointer to struct f_midi, as it's used in f_midi_complete() callback and related functions. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_mass_storage: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_mass_storage we only need to store in ep->driver_data pointer to struct fsg_common, which is used in bulk_in_complete() and bulk_out_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_loopback: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_hid we only need to store in ep->driver_data pointer to struct f_loopback, as it's used in loopback_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_hid: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_hid we only need to store in ep->driver_data pointer to struct f_hidg, as it's used in f_hidg_req_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_eem: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ecm, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_acm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_acm we only need to store in ep->driver_data pointer to struct f_acm, as it's used in acm_complete_set_line_coding() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_ecm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ecm, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: epautoconf: add usb_ep_autoconfig_release() functionRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces usb_ep_autoconfig_release() function which allows to release endpoint previously obtained from usb_ep_autoconfig() during USB function bind. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_ncm: obtain cdev from function instead of driver_dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | The 'driver_data' field in ep0 is never set to pointer to cdev, so we have to obtain it from another source as in this context ep->driver_data contains invalid data. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: fix few outdated commentsRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix comments in code to make them up to date. composite: claiming endpoint is now done by setting ep->claimed flag, not ep->driver_data. epautoconf: usb_ep_autoconfig() and usb_ep_autoconfig_ss() return claimed endpoint with ep->claimed flag already set. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: dummy_hcd: replace timeval with timespec64WEN Pingbo2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The millisecond of the last second will be normal if tv_sec is overflowed. But for y2038 consistency and demonstration purpose, and avoiding further risks, we need to remove 'timeval' in this driver, to avoid similair problems. Signed-off-by: Pingbo Wen <pingbo.wen@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_sourcesink: format data pattern according to max packet sizePeter Chen2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the host and gadget can't agree with transfer length before each transfer, but they agree with max packet size for each endpoint, we use max packet size to format data pattern. Acked-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: ether: Allow jumbo framesMike Looijmans2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB network adapters support Jumbo frames. The only thing blocking that feature is the code in the gadget driver that disposes of packets larger than 1518 bytes, and the limit on the ioctl to set the mtu. This patch relaxes these limits, and allows up to 15k frames sizes. The 15k value was chosen because 16k does not work on all platforms, and usingclose to 16k will result in allocating 5 or 8 4k pages to store the skb, wasting pages at no measurable performance gain. On a topic-miami board (Zynq-7000), iperf3 performance reports: MTU= 1500, PC-to-gadget: 139 Mbps, Gadget-to-PC: 116 Mbps MTU=15000, PC-to-gadget: 239 Mbps, Gadget-to-PC: 361 Mbps On boards with slower CPUs the performance improvement will be relatively much larger, e.g. an OMAP-L138 increased from 40 to 220 Mbps using a similar patch on an 2.6.37 kernel. Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: at91_udc: move at91_udc_data in at91_udc.hAlexandre Belloni2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | struct at91_udc_data is now only used inside the driver, move it to its include. Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: f_midi: check for error on usb_ep_queueFelipe F. Tonello2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | f_midi is not checking whether there is an error on usb_ep_queue request, ignoring potential problems, such as memory leaks. Signed-off-by: Felipe F. Tonello <eu@felipetonello.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * | usb: gadget: mass_storage: allow for deeper queue lengthsFelipe Balbi2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of allowing a range of 2 to 4 requests, let's allow the user choose up to 32 requests as that will give us a better chance of keeping controller busy. We still maintain default of 2 so users shouldn't be affected. Signed-off-by: Felipe Balbi <balbi@ti.com>