10 Jul, 2020
1 commit
-
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/20200707195607.GA4198@embeddedor
Signed-off-by: Greg Kroah-Hartman
24 Jun, 2020
1 commit
-
This driver assumed that dmaengine_tx_status() could return
the residue even if the transfer was completed. However,
this was not correct usage [1] and this caused to break getting
the residue after the commit 24461d9792c2 ("dmaengine:
virt-dma: Fix access after free in vchan_complete()") actually.
So, this is possible to get wrong received size if the usb
controller gets a short packet. For example, g_zero driver
causes "bad OUT byte" errors.The usb-dmac driver will support the callback_result, so this
driver can use it to get residue correctly. Note that even if
the usb-dmac driver has not supported the callback_result yet,
this patch doesn't cause any side-effects.[1]
https://lore.kernel.org/dmaengine/20200616165550.GP2324254@vkoul-mobl/Reported-by: Hien Dang
Fixes: 24461d9792c2 ("dmaengine: virt-dma: Fix access after free in vchan_complete()")
Signed-off-by: Yoshihiro Shimoda
Link: https://lore.kernel.org/r/1592482277-19563-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman
23 Apr, 2020
1 commit
-
This patch corrects the SPDX License Identifier style in
header files related to Renesas USBHS Controller Drivers.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used).Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46.Suggested-by: Joe Perches
Signed-off-by: Nishad Kamdar
Reviewed-by: Yoshihiro Shimoda
Link: https://lore.kernel.org/r/20200419125705.GA5172@nishad
Signed-off-by: Greg Kroah-Hartman
17 Jan, 2020
1 commit
-
…on/linux-phy into usb-next
Kishon writes:
phy: for 5.6
*) Add support in PHY core to create link between PHY consumer and PHY
provider
*) Add DisplayPort PHY configuration set to be used for negotiating the
configurations to be used between DisplayPort controller and
DisplayPort PHY
*) Add PHY wrapper driver (configure inputs to Cadence Sierra PHY) for
TI's J721E SoC and adapt Cadence Sierra PHY driver to be used for
J721E SoC (Supports USB and PCIe)
*) Add PHY driver for eMMC PHY in Intel LGM SoC
*) Add PHY support for 7216 and 7211 Broadcom SoCs which uses the new
Synopsys USB Controller
*) Add support for 16nm SATA PHY present in Broadcom 7216 SoC
*) Fix lost packet issue, fix MDIO from getting inaccessible, fix
occasional transaction failures, fix USB driver from crashing in
Broadcom USB PHY driver
*) Fix missing PCS SW reset in UFS PHY of Qualcomm SM8150
*) Use "struct phy_configure_opts_mipi_dphy" to pass parameters from
display controller to rockchip-inno-dsidphy
*) Other cleanups including compile testing for some of the PHY drivers,
fixing Kconfig indentation, duplicate writes in drivers etc.,Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
* tag 'phy-for-5.6_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy: (54 commits)
dt-bindings: phy: Add PHY_TYPE_DP definition
phy: ti: j721e-wiz: Fix return value check in wiz_probe()
dt-bindings: usb: Convert Allwinner A80 USB PHY controller to a schema
phy: intel-lgm-emmc: Fix warning by adding missing MODULE_LICENSE
phy: ti: j721e-wiz: Manage typec-gpio-dir
dt-bindings: phy: ti,phy-j721e-wiz: Add Type-C dir GPIO
phy: cadence: Sierra: add phy_reset hook
phy: cadence: Sierra: remove redundant initialization of pointer regmap
phy: Add DisplayPort configuration options
phy: Enable compile testing for some of drivers
phy: mediatek: Fix Kconfig indentation
phy: intel-lgm-emmc: Add support for eMMC PHY
dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY
phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC
dt-bindings: phy: Document WIZ (SERDES wrapper) bindings
phy: cadence: Sierra: Use correct dev pointer in cdns_sierra_phy_remove()
phy: cadence: Sierra: Set cmn_refclk_dig_div/cmn_refclk1_dig_div frequency to 25MHz
phy: cadence: Sierra: Change MAX_LANES of Sierra to 16
phy: cadence: Sierra: Check for PLL lock during PHY power on
phy: cadence: Sierra: Get reset control "array" for each link
...
08 Jan, 2020
1 commit
-
In order to enforce suspend/resume ordering, this commit creates link
between phy consumers and phy devices. This link avoids to suspend phy
before phy consumers.Signed-off-by: Alexandre Torgue
[jonathanh@nvidia.com: Fix an abort when of_phy_get() returns error]
Signed-off-by: Jonathan Hunter
Signed-off-by: Kishon Vijay Abraham I
31 Dec, 2019
1 commit
-
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
Cc: Veeraiyan Chidambaram
Cc: Yoshihiro Shimoda
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20191217141241.57639-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman
14 Nov, 2019
1 commit
-
dma_request_slave_channel_reason() is:
#define dma_request_slave_channel_reason(dev, name) \
dma_request_chan(dev, name)Signed-off-by: Peter Ujfalusi
Link: https://lore.kernel.org/r/20191113094838.2141-1-peter.ujfalusi@ti.com
Signed-off-by: Greg Kroah-Hartman
04 Nov, 2019
1 commit
-
We need the USB fixes in here to build on top of.
Signed-off-by: Greg Kroah-Hartman
27 Oct, 2019
3 commits
-
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
Signed-off-by: Ben Dooks
Signed-off-by: Felipe Balbi -
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 __le16Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Felipe Balbi -
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] dataNote. I belive this to be correct, and should be a no-op on arm.
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Yoshihiro Shimoda
Signed-off-by: Ben Dooks
Signed-off-by: Felipe Balbi
16 Oct, 2019
2 commits
-
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
Link: https://lore.kernel.org/r/20191015153017.10858-1-ben.dooks@codethink.co.uk
Signed-off-by: Greg Kroah-Hartman -
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] dataNote. I belive this to be correct, and should be a no-op on arm.
Signed-off-by: Ben Dooks
Reviewed-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20191015155044.11858-1-ben.dooks@codethink.co.uk
Signed-off-by: Greg Kroah-Hartman
14 Oct, 2019
1 commit
-
we want the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
04 Oct, 2019
6 commits
-
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: # v3.0+
Signed-off-by: Yoshihiro Shimoda
Link: https://lore.kernel.org/r/1569924633-322-3-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman -
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: # v3.1+
Signed-off-by: Yoshihiro Shimoda
Link: https://lore.kernel.org/r/1569924633-322-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Eugeniu Rosca
Reviewed-by: Yoshihiro Shimoda
Tested-by: Yoshihiro Shimoda
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 -
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
Signed-off-by: Veeraiyan Chidambaram
Reviewed-by: Yoshihiro Shimoda
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 -
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
Signed-off-by: Veeraiyan Chidambaram
Reviewed-by: Yoshihiro Shimoda
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 -
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.Reported-by: Hulk Robot
Signed-off-by: YueHaibing
Link: https://lore.kernel.org/r/20190904085045.24204-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman
22 Aug, 2019
1 commit
-
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
Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2019
2 commits
-
…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 -
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: # v4.1+
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Felipe Balbi
26 Jun, 2019
13 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
Since this can remove over 80 charactors in a line, this patch adds
struct device * declaration in usbhs_probe().Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
This patch uses the dev_of_node macro instead of open coded
to be better.Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Greg Kroah-Hartman -
Now no one uses the type member so that this patch removes it.
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
20 Jun, 2019
1 commit
-
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
Reviewed-by: Simon Horman ---
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
05 Jun, 2019
2 commits
-
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
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
SUDMAC feature was supported in v3.10, but was never used by
any platform. So, this patch removes it.Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman
21 May, 2019
1 commit
-
The RZ/A2 is similar to the R-Car Gen3 with some small differences.
Signed-off-by: Chris Brandt
Reviewed-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman
