summaryrefslogtreecommitdiff
path: root/drivers/usb/renesas_usbhs
AgeCommit message (Collapse)AuthorFilesLines
2019-12-30usb: renesas_usbhs: Switch to GPIO descriptorLinus Walleij2-15/+9
The Renesas USBHS driver includes a bit of surplus headers and uses the old GPIO API so let's switch it to use the GPIO descriptor. I noticed that the enable_gpio inside renesas_usbhs_driver_param isn't really referenced anywhere, and it is also the wrong type (u32) so let's just delete it and use a local variable instead. Cc: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: Veeraiyan Chidambaram <veeraiyan.chidambaram@in.bosch.com> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191217141241.57639-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-14usb: renesas_usbhs: Use dma_request_chan() directly for channel requestPeter Ujfalusi1-2/+2
dma_request_slave_channel_reason() is: #define dma_request_slave_channel_reason(dev, name) \ dma_request_chan(dev, name) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191113094838.2141-1-peter.ujfalusi@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-04Merge 5.4-rc6 into usb-nextGreg Kroah-Hartman1-1/+1
We need the USB fixes in here to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-27usb: renesas_usbhs: fix type of bufBen Dooks (Codethink)1-1/+1
Fix the type of buf in __usbhsg_recip_send_status to be __le16 to avoid the following sparse warning: drivers/usb/renesas_usbhs/mod_gadget.c:335:14: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/mod_gadget.c:335:14: expected unsigned short drivers/usb/renesas_usbhs/mod_gadget.c:335:14: got restricted __le16 [usertype] Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-10-27usb: renesas_usbhs: Fix warnings in usbhsg_recip_handler_std_set_device()Yoshihiro Shimoda1-1/+1
This patch fixes the following sparse warnings by shifting 8-bits after le16_to_cpu(). drivers/usb/renesas_usbhs/mod_gadget.c:268:47: warning: restricted __le16 degrades to integer drivers/usb/renesas_usbhs/mod_gadget.c:268:47: warning: cast to restricted __le16 Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-10-27usb: renesas_usbhs: fix __le16 warningsBen Dooks (Codethink)1-6/+6
Fix the warnings generated by casting to/from __le16 without using the correct functions. Fixes the following sparse warnings: drivers/usb/renesas_usbhs/common.c:165:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:165:25: expected restricted __le16 [usertype] wValue drivers/usb/renesas_usbhs/common.c:165:25: got unsigned short drivers/usb/renesas_usbhs/common.c:166:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:166:25: expected restricted __le16 [usertype] wIndex drivers/usb/renesas_usbhs/common.c:166:25: got unsigned short drivers/usb/renesas_usbhs/common.c:167:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:167:25: expected restricted __le16 [usertype] wLength drivers/usb/renesas_usbhs/common.c:167:25: got unsigned short drivers/usb/renesas_usbhs/common.c:173:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:173:39: expected unsigned short [usertype] data drivers/usb/renesas_usbhs/common.c:173:39: got restricted __le16 [usertype] wValue drivers/usb/renesas_usbhs/common.c:174:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:174:39: expected unsigned short [usertype] data drivers/usb/renesas_usbhs/common.c:174:39: got restricted __le16 [usertype] wIndex drivers/usb/renesas_usbhs/common.c:175:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:175:39: expected unsigned short [usertype] data Note. I belive this to be correct, and should be a no-op on arm. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-10-15usb: renesas_usbhs: fix type of bufBen Dooks (Codethink)1-1/+1
Fix the type of buf in __usbhsg_recip_send_status to be __le16 to avoid the following sparse warning: drivers/usb/renesas_usbhs/mod_gadget.c:335:14: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/mod_gadget.c:335:14: expected unsigned short drivers/usb/renesas_usbhs/mod_gadget.c:335:14: got restricted __le16 [usertype] Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://lore.kernel.org/r/20191015153017.10858-1-ben.dooks@codethink.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-15usb: renesas_usbhs: fix __le16 warningsBen Dooks (Codethink)1-6/+6
Fix the warnings generated by casting to/from __le16 without using the correct functions. Fixes the following sparse warnings: drivers/usb/renesas_usbhs/common.c:165:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:165:25: expected restricted __le16 [usertype] wValue drivers/usb/renesas_usbhs/common.c:165:25: got unsigned short drivers/usb/renesas_usbhs/common.c:166:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:166:25: expected restricted __le16 [usertype] wIndex drivers/usb/renesas_usbhs/common.c:166:25: got unsigned short drivers/usb/renesas_usbhs/common.c:167:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:167:25: expected restricted __le16 [usertype] wLength drivers/usb/renesas_usbhs/common.c:167:25: got unsigned short drivers/usb/renesas_usbhs/common.c:173:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:173:39: expected unsigned short [usertype] data drivers/usb/renesas_usbhs/common.c:173:39: got restricted __le16 [usertype] wValue drivers/usb/renesas_usbhs/common.c:174:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:174:39: expected unsigned short [usertype] data drivers/usb/renesas_usbhs/common.c:174:39: got restricted __le16 [usertype] wIndex drivers/usb/renesas_usbhs/common.c:175:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:175:39: expected unsigned short [usertype] data Note. I belive this to be correct, and should be a no-op on arm. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191015155044.11858-1-ben.dooks@codethink.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-14Merge 5.4-rc3 into usb-nextGreg Kroah-Hartman6-4/+34
we want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: renesas_usbhs: gadget: Fix usb_ep_set_{halt,wedge}() behaviorYoshihiro Shimoda6-2/+34
According to usb_ep_set_halt()'s description, __usbhsg_ep_set_halt_wedge() should return -EAGAIN if the IN endpoint has any queue or data. Otherwise, this driver is possible to cause just STALL without sending a short packet data on g_mass_storage driver, and then a few resetting a device happens on a host side during a usb enumaration. Fixes: 2f98382dcdfe ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Cc: <stable@vger.kernel.org> # v3.0+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1569924633-322-3-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: renesas_usbhs: gadget: Do not discard queues in usb_ep_set_{halt,wedge}()Yoshihiro Shimoda1-2/+0
The commit 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area") had added a usbhsg_pipe_disable() calling into __usbhsg_ep_set_halt_wedge() accidentally. But, this driver should not call the usbhsg_pipe_disable() because the function discards all queues. So, this patch removes it. Fixes: 97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area") Cc: <stable@vger.kernel.org> # v3.1+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1569924633-322-2-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: renesas_usbhs: add suspend event support in gadget modeVeeraiyan Chidambaram2-4/+11
When R-Car Gen3 USB 2.0 is in Gadget mode, if host is detached an interrupt will be generated and Suspended state bit is set in interrupt status register. Interrupt handler will call driver->suspend(composite_suspend) if suspended state bit is set. composite_suspend will call ffs_func_suspend which will post FUNCTIONFS_SUSPEND and will be consumed by user space application via /dev/ep0. To be able to detect host detach, extend the DVSQ_MASK to cover the Suspended bit of the DVSQ[2:0] bitfield from the Interrupt Status Register 0 (INTSTS0) register and perform appropriate action in the DVST interrupt handler (usbhsg_irq_dev_state). Without this commit, disconnection of the phone from R-Car-H3 ES2.0 Salvator-X CN9 port is not recognized and reverse role switch does not happen. If phone is connected again it does not enumerate. With this commit, disconnection will be recognized and reverse role switch will happen by a user space application. If phone is connected again it will enumerate properly and will become visible in the output of 'lsusb'. Signed-off-by: Veeraiyan Chidambaram <veeraiyan.chidambaram@in.bosch.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1568207756-22325-3-git-send-email-external.veeraiyan.c@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: renesas_usbhs: enable DVSE interruptEugeniu Rosca1-4/+3
Commit [1] enabled the possibility of checking the DVST (Device State Transition) bit of INTSTS0 (Interrupt Status Register 0) and calling the irq_dev_state() handler if the DVST bit is set. But neither commit [1] nor commit [2] actually enabled the DVSE (Device State Transition Interrupt Enable) bit in the INTENB0 (Interrupt Enable Register 0). As a consequence, irq_dev_state() handler is getting called as a side effect of other (non-DVSE) interrupts being fired, which definitely can't be relied upon, if DVST notifications are of any value. Why this doesn't hurt is because usbhsg_irq_dev_state() currently doesn't do much except of a dev_dbg(). Once more work is added to the handler (e.g. detecting device "Suspended" state and notifying other USB gadget components about it), enabling DVSE becomes a hard requirement. Do it in a standalone commit for better visibility and clear explanation. [1] commit f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") [2] commit 2f98382dcdfe ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Veeraiyan Chidambaram <veeraiyan.chidambaram@in.bosch.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1568207756-22325-2-git-send-email-external.veeraiyan.c@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: renesas_usbhs: simplify usbhs_status_get_device_state()Eugeniu Rosca1-11/+1
Similar to usbhs_status_get_ctrl_stage(), *_get_device_state() is not supposed to return any error code since its return value is the DVSQ bitfield of the INTSTS0 register. According to SoC HW manual rev1.00, every single value of DVSQ[2:0] is valid and none is an error: ----8<---- Device State 000: Powered state 001: Default state 010: Address state 011: Configuration state 1xx: Suspended state ----8<---- Hence, simplify the function body. The motivation behind dropping the switch/case construct is being able to implement reading the suspended state. The latter (based on the above DVSQ[2:0] description) doesn't have a unique value, but is rather a list of states (which makes switch/case less suitable for reading/validating it): 100: (Suspended) Powered state 101: (Suspended) Default state 110: (Suspended) Address state 111: (Suspended) Configuration state Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Veeraiyan Chidambaram <veeraiyan.chidambaram@in.bosch.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1568207756-22325-1-git-send-email-external.veeraiyan.c@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-04usb: renesas_usbhs: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+2
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904085045.24204-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-21usb: add a HCD_DMA flag instead of guestimating DMA capabilitiesChristoph Hellwig1-1/+1
The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03Merge tag 'usb-for-v5.3-part2' of ↵Greg Kroah-Hartman1-12/+22
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Felipe writes: USB: more changes for v5.3 merge window Turns out a few more important changes came about. We have the new Cadence DRD Driver being added here and that's the biggest, most important part. Together with that we have suport for new imx7ulp phy. Support for TigerLake Devices on dwc3. Also a couple important fixes which weren't completed in time for the -rc cycle. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> * tag 'usb-for-v5.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: usb: renesas_usbhs: add a workaround for a race condition of workqueue usb: gadget: udc: renesas_usb3: remove redundant assignment to ret usb: dwc2: use a longer AHB idle timeout in dwc2_core_reset() USB: gadget: function: fix issue Unneeded variable: "value" usb: phy: phy-mxs-usb: add imx7ulp support doc: dt-binding: mxs-usb-phy: add compatible for 7ulp usb:cdns3 Fix for stuck packets in on-chip OUT buffer. usb:cdns3 Add Cadence USB3 DRD Driver usb:gadget Simplify usb_decode_get_set_descriptor function. usb:gadget Patch simplify usb_decode_set_clear_feature function. usb:gadget Separated decoding functions from dwc3 driver. dt-bindings: add binding for USBSS-DRD controller. usb: dwc3: pci: add support for TigerLake Devices
2019-07-03usb: renesas_usbhs: add a workaround for a race condition of workqueueYoshihiro Shimoda1-12/+22
The old commit 6e4b74e4690d ("usb: renesas: fix scheduling in atomic context bug") fixed an atomic issue by using workqueue for the shdmac dmaengine driver. However, this has a potential race condition issue between the work pending and usbhsg_ep_free_request() in gadget mode. When usbhsg_ep_free_request() is called while pending the queue, since the work_struct will be freed and then the work handler is called, kernel panic happens on process_one_work(). To fix the issue, if we could call cancel_work_sync() at somewhere before the free request, it could be easy. However, the usbhsg_ep_free_request() is called on atomic (e.g. f_ncm driver calls free request via gether_disconnect()). For now, almost all users are having "USB-DMAC" and the DMAengine driver can be used on atomic. So, this patch adds a workaround for a race condition to call the DMAengine APIs without the workqueue. This means we still have TODO on shdmac environment (SH7724), but since it doesn't have SMP, the race condition might not happen. Fixes: ab330cf3888d ("usb: renesas_usbhs: add support for USB-DMAC") Cc: <stable@vger.kernel.org> # v4.1+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-06-26usb: renesas_usbhs: Use struct platform_callback pointerYoshihiro Shimoda3-6/+6
Now the driver fixes the issue of the commit 482982062f1b ("usb: gadget: renesas_usbhs: bugfix: don't modify platform data") by using usbhs_mod_info.get_vbus, this patches uses the pointer instead of copied value to avoid redundancy. Note that struct renesas_usbhs_driver_param has to use copied value because the driver has to set some members (e.g. buswait_bwait). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Use renesas_usbhs_platform_info on of_device_id.dataYoshihiro Shimoda9-107/+73
In device tree environment, the previous code allocates renesas_usbhs_platform_info by using devm_kzalloc() and then copies usbhs_of_data to the allocated memory. This reason is some values (e.g. .platform_callback.get_vbus) are overwritten by the driver, but the of_device_id.data is "const". Now the driver doesn't have such a code, so this patch uses renesas_usbhs_platform_info on of_device_id.data. Note that the previous code set the pdev->dev.platform_data pointer even if device tree environment, but the value is not used. So, this patch also remove such a code. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Add a common function for the .get_idYoshihiro Shimoda6-27/+15
All platform related codes (rcar[23].c and rza{2}.c) has its own .get_id function as "USBHS_GADGET". So, we can use a common function for it. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: move device tree properties parsingYoshihiro Shimoda1-10/+8
In the future, each struct renesas_usbhs_driver_param is stored on the each platform related source code (e.g. rcar3.c) to remove usbhs_parse_dt(). So, this patch moves device tree properties parsing to usbhs_probe(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Add struct device * declaration in usbhs_probe()Yoshihiro Shimoda1-15/+15
Since this can remove over 80 charactors in a line, this patch adds struct device * declaration in usbhs_probe(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Add has_new_pipe_configs flagYoshihiro Shimoda1-11/+9
In the future, each struct renesas_usbhs_driver_param is stored on the each platform related source code (e.g. rcar3.c). So, to simplify the source code, this patch adds a new flag has_new_pipe_configs. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Use dev_of_node macro instead of open codedYoshihiro Shimoda2-8/+9
This patch uses the dev_of_node macro instead of open coded to be better. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Remove type member from renesas_usbhs_driver_paramYoshihiro Shimoda1-5/+0
Now no one uses the type member so that this patch removes it. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Use a specific flag instead of type for multi_clksYoshihiro Shimoda1-5/+3
To remove the type of renesas_usbhs_driver_param in the future, this patch uses a specific flag "multi_clks". Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: Avoid to write platform_data's valueYoshihiro Shimoda4-5/+21
The very old commit 482982062f1b ("usb: gadget: renesas_usbhs: bugfix: don't modify platform data") changed to use copied whole structures values to fix the "hung-up" issue. However, we also can fix the issue if the driver copies the get_vbus function pointer to the driver's value. So, this patch adds get_vbus member into struct usbhs_mod_info and use the pointer instead of struct renesas_usbhs_platform_callback. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: move macros from mod.c to the mod.hYoshihiro Shimoda2-9/+9
In the future, since other source code of this driver will use these macros, this patch moves it to the header file. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: remove notify_hotplug callbackYoshihiro Shimoda4-14/+10
The notify_hotplug callback was supported in v3.10, but the last user (armadillo800eva) was removed by the commit 1fa59bda21c7 ("ARM: shmobile: Remove legacy board code for Armadillo-800 EVA"). So, this patch removes it. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26usb: renesas_usbhs: revise the irq_vbus commentsYoshihiro Shimoda1-5/+5
Since the irq_vbus comments doesn't match with the current implementation, this patch revises it. This patch also changes new lines to reduce the source code lines. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-20usb: renesas_usbhs: Use struct assignment instead of memcpy()Yoshihiro Shimoda1-9/+4
To avoid the error-proneness of calls to sizeof() in the memcpy, this patch uses struct assignment instead of memcpy. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>--- This patch is based on Greg's linux-usb.git / usb-next branch. Note that mod_host.c also has memcpy but we cannot use struct assignment for it because the type of urb->setup_patcket is just "unsigned char *". drivers/usb/renesas_usbhs/common.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05usb: renesas_usbhs: remove controlling PWEN/EXTLP supportYoshihiro Shimoda1-4/+0
Controlling PWMEN/EXTLP (named as "has_otg") was supported in v3.2, but the last user (kzm9g) was removed by the commit 30f8925a57d8ad49 ("ARM: shmobile: Remove legacy board code for KZM-A9-GT"). So, this patch remove it. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05usb: renesas_usbhs: remove sudmac supportYoshihiro Shimoda1-5/+1
SUDMAC feature was supported in v3.10, but was never used by any platform. So, this patch removes it. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: renesas_usbhs: Add support for RZ/A2Chris Brandt4-1/+89
The RZ/A2 is similar to the R-Car Gen3 with some small differences. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: renesas_usbhs: support byte addressable CFIFOChris Brandt1-2/+7
Some SoC have a CFIFO register that is byte addressable. This means when the CFIFO access is set to 32-bit, you can write 8-bit values to addresses CFIFO+0, CFIFO+1, CFIFO+2, CFIFO+3. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: renesas_usbhs: add support for CNEN bitChris Brandt2-0/+7
For some SoC, CNEN must be set for USB Device mode operation. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: renesas_usbhs: move flags to paramChris Brandt2-18/+7
Move options from 'flags' field in private structure to param structure where other options are already being kept. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: remove redundant 'default n' from Kconfig-sBartlomiej Zolnierkiewicz1-1/+0
'default n' is the default value for any bool or tristate Kconfig setting so there is no need to write it explicitly. Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO is not set' for visible symbols") the Kconfig behavior is the same regardless of 'default n' being present or not: ... One side effect of (and the main motivation for) this change is making the following two definitions behave exactly the same: config FOO bool config FOO bool default n With this change, neither of these will generate a '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied). That might make it clearer to people that a bare 'default n' is redundant. ... Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: renesas_usbhs: Use specific struct instead of USBHS_TYPE_* enumsYoshihiro Shimoda2-47/+70
This patch adds a specific struct "usbhs_of_data" to add a new SoC data easily instead of code basis in the future. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-19USB: renesas_usbhs: fix spelling mistake "doens't" -> "doesn't"Colin Ian King1-1/+1
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18usb: renesas_usbhs: replace udelay() with usleep_range()Yoshihiro Shimoda2-2/+2
According to Documentation/timers/timers-howto.txt, a driver should use usleep_range() instead of udelay() on NON-ATOMIC CONTEXT if "SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms)". Since the .hardware_init() and .power_ctrl() will run on NON-ATOMIC CONTEXT, this patch replaces udelay() with usleep_range(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-17usb: renesas_usbhs: add support for RZ/G2EFabrizio Castro1-0/+4
HS-USB found in RZ/G2E (a.k.a. r8a774c0) is very similar to the one found in R-Car E3 (a.k.a. r8a77990), as it needs to release the PLL reset by the UGCTRL register like R-Car E3, therefore add r8a774c0 support in a similar fashion to what was done for the r8a77990. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-12usb: renesas_usbhs: mark PM functions as __maybe_unusedArnd Bergmann1-2/+2
Without CONFIG_PM, we get a new build warning here: drivers/usb/renesas_usbhs/common.c:860:12: error: 'usbhsc_resume' defined but not used [-Werror=unused-function] static int usbhsc_resume(struct device *dev) ^~~~~~~~~~~~~ drivers/usb/renesas_usbhs/common.c:844:12: error: 'usbhsc_suspend' defined but not used [-Werror=unused-function] static int usbhsc_suspend(struct device *dev) ^~~~~~~~~~~~~~ Fixes: d54d334e75b9 ("usb: renesas_usbhs: Use SIMPLE_DEV_PM_OPS macro") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05usb: renesas_usbhs: Use SIMPLE_DEV_PM_OPS macroYoshihiro Shimoda1-4/+1
This patch uses SIMPLE_DEV_PM_OPS macro instead of struct dev_pm_ops directly. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-12-05usb: renesas_usbhs: Remove dummy runtime PM callbacksJarkko Nikula1-14/+0
Platform drivers don't need dummy runtime PM callbacks that just return success in order to have runtime PM happening. This has changed since following commits: commit 05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks") commit 543f2503a956 ("PM / platform_bus: Allow runtime PM by default") commit 8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly") Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> [shimoda: revise git commit description style] Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-09-28usb: renesas_usbhs: add support for R-Car E3Yoshihiro Shimoda1-0/+4
This patch adds support for R-Car E3. This SoC needs to release the PLL reset by the UGCTRL register like R-Car D3. So, this patch adds a usbhs_of_match entry for this SoC with "USBHS_TYPE_RCAR_GEN3_WITH_PLL". Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-28usb: renesas_usbhs: rcar3: Use OTG mode for R-Car D3Yoshihiro Shimoda1-1/+2
Since R-Car D3 can use OTG mode, this patch changes the UGCTRL2 value to UGCTRL2_USB0SEL_OTG and UGCTRL2_VBUSSEL like other R-Car Gen3 SoCs. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-28Revert "usb: renesas_usbhs: set the mode by using extcon state for non-otg ↵Yoshihiro Shimoda1-14/+1
channel" This reverts commit cd14247d5c14b9b20bb3d3dfcaa899ca22c8dccc. R-Car D3 can use OTG mode in fact. So, the commit doesn't need anymore. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-28Revert "usb: renesas_usbhs: add extcon notifier to set mode for non-otg channel"Yoshihiro Shimoda3-21/+0
This reverts commit 8ada211d0383b72878582bd312b984a9eae62b30. R-Car D3 can use OTG mode in fact. So, the commit doesn't need anymore. In other words, like other R-Car Gen3 SoCs, R-Car D3 can change the mode by using the phy-rcar-gen3-usb2 driver. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>