- 19 10月, 2015 1 次提交
-
-
由 Geliang Tang 提交于
s/regsiter/register/ Signed-off-by: NGeliang Tang <geliangtang@163.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 15 10月, 2015 2 次提交
-
-
由 Krzysztof Opasiak 提交于
Since commit e0857ce5 ("usb: gadget: loopback: don't queue requests to bogus endpoints") Loopback function is not realy working as that commit removed all looping back logic. After that commit ep-out works like /dev/null and ep-in works like /dev/zero. This commit fix this issue by allocating set of out requests and set of in requests but each out req shares buffer with one in req: out_req->buf ---> buf <--- in_req.buf out_req->context <---> in_req.context The completion routine simply enqueue the suitable req in an oposite direction. Cc: <stable@vger.kernel.org> # 3.18+ Fixes: e0857ce5 ("usb: gadget: loopback: don't queue requests to bogus endpoints") Signed-off-by: NKrzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Krzysztof Opasiak 提交于
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: NKrzysztof Opasiak <k.opasiak@samsung.com> Reviewed-by: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 14 10月, 2015 1 次提交
-
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 10 10月, 2015 1 次提交
-
-
由 Igor Kotrasinski 提交于
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: NIgor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 02 10月, 2015 15 次提交
-
-
由 Krzysztof Opasiak 提交于
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: NKrzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Krzysztof Opasiak 提交于
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: NKrzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
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: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
A NULL comparison can be written as if (var) or if (!var). Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Rearrange the udc_basic_init function to remove the forward declaration. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Remove the forward declarations of udc_pci_probe and udc_pci_remove. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Rearrange udc_free_dma_chain to remove the forward declaration. While at it fixed all the relevant checkpatch warnings. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Rearrange udc_create_dma_chain to remove the forward declaration. While rearranging fixed the relevant checkpatch warnings. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Rearrange the udc_remote_wakeup function to remove the forward declaration. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Rearrange the udc_probe function to remove the forward declarations. While rearranging also fixed the relevant checkpatch warnings. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
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: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
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: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Use WARN_ON() instead of halting the kernel with BUG_ON() and also fix the checkpatch warning. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
Handle the error properly instead of calling the pci remove function. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudip Mukherjee 提交于
A rewrite of init_dma_pools() with proper error handling. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 29 9月, 2015 1 次提交
-
-
由 Felipe Balbi 提交于
gadget methods should be called without spinlocks held. Reported-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 27 9月, 2015 19 次提交
-
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Robert Baldyga 提交于
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: NRobert Baldyga <r.baldyga@samsung.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-