The USB_FSL_MPH_DR_OF symbol is used to ensure the code that interprets
the DR device node is built whenever one of the two drivers (EHCI or
UDC) for the platform is enabled. However, if CONFIG_USB is disabled
and we only support gadget mode, this causes a Kconfig warning:
warning: (USB_FSL_USB2) selects USB_FSL_MPH_DR_OF which has unmet direct dependencies (USB_SUPPORT && USB)
We can avoid this warning by simply no longer using the symbol,
and making sure we enter the drivers/usb/host/ directory when
the UDC driver is enabled that needs the file, and then we use
Makefile syntax to ensure the file is built-in if needed.
There is currently a dependency on CONFIG_OF, but this is redundant,
as we already know that this is set unconditionally for the platforms
that use this driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
This converts the pxa25x udc driver to use readl/writel as normal
driver should do, rather than dereferencing __iomem pointers
themselves.
Based on the earlier preparation work, we can now also pass
the register start in the device pointer so we no longer need
the global variable.
The unclear part here is for IXP4xx, which supports both big-endian
and little-endian configurations. So far, the driver has done
no byteswap in either case. I suspect that is wrong and it would
actually need to swap in one or the other case, but I don't know
which. It's also possible that there is some magic setting in
the chip that makes the endianess of the MMIO register match the
CPU, and in that case, the code actually does the right thing
for all configurations, both before and after this patch.
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
This removes the dependency on the mach/hardware.h header file
from the pxa25x_udc driver after the register definitions were
already unified in the previous patch.
Following the model of pxa27x_udc (and basically all other drivers
in the kernel), we define the register numbers as offsets from
the register base address and use accessor functions to read/write
them.
For the moment, this still leaves the direct pointer dereference
in place, instead of using readl/writel, so this patch should
not be changing the behavior of the driver, other than using
ioremap() on the platform resource to replace the hardcoded
virtual address pointers.
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
ixp4xx and pxa25x both use this driver and provide a slightly
different set of register definitions for it. Aside from that,
the definition in the ixp4xx-regs.h header conflicts with the
on in the pxa27x device driver when compile-testing that:
In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0:
../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined
#define UDCCR 0x0000 /* UDC Control Register */
^
In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0,
from ../arch/arm/mach-ixp4xx/include/mach/io.h:18,
from ../arch/arm/include/asm/io.h:194,
from ../include/linux/io.h:25,
from ../include/linux/irq.h:24,
from ../drivers/usb/gadget/udc/pxa27x_udc.c:23:
../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition
#define UDCCR IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000)
This addresses both issues by moving all the definitions into the
pxa25x_udc driver itself. It turns out the only difference between
them was 'UDCCS_IO_ROF', and that could well be a mistake when it
was incorrectly copied from pxa25x to ixp4xx.
Acked-by: Krzysztof Halasa <khalasa@piap.pl>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Since Some SoCs (e.g. R-Car Gen2) don't have the CSSTS bit in the
pipectrl registers ({DCP,PIPEn}CTR) because such SoCs have peripheral
mode only. So, this driver should not check the CSSTS bit if peripheral
mode is running.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Since the usb2 phy driver for gen3 (phy-rcar-gen3-usb2) cannot access
LPSTS and UGCTRL2 registers in the HSUSB module, this driver have to
initialize the registers. So, this patch adds such handling code into
rcar3.c.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Enable SuperSpeedPlus by programming the DCFG.speed and after
enumerating, set gadget->speed appropriately.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
If the maximum_speed is not set, set it to a known value, either
SuperSpeed or SuperSpeedPlus based on the type of controller we are
using. If we are on DWC_usb31 controller, check the PHY interface to see
if it is capable of SuperSpeedPlus.
Also this check is moved after dwc3_core_init() so that we can check
dwc->revision.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Update various places where the speed is checked so that it takes into
account SuperSpeedPlus properly.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Update various registers fields definitions for the DWC_usb31 controller
for SuperSpeedPlus support.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Add a convenience function to check if the controller is DWC_usb31.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Enable superspeed plus configuration for the mass storage gadget.
The mass storage function doesn't do anything special for
SuperSpeedPlus. Just pass in the same SuperSpeed descriptors for
SuperSpeedPlus.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Update the debug message reporting the speeds that a configuration
supports for SuperSpeedPlus.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Configure the usb_ep using the SuperSpeedPlus descriptors if connected
in SuperSpeedPlus.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Enable writing of SuperSpeedPlus descriptors for any SuperSpeedPlus
capable configuration when connected in SuperSpeedPlus.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
There are a couple places in the code that get the function descriptors
based on the speed. Move this lookup into a function call and add
support to handle the SuperSpeedPlus descriptors as well.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
If enumerated in SuperSpeedPlus, count the configurations that support
it.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
When a function is added to a configuration with usb_add_function(), the
configuration speed flags are updated. These flags indicate for which
speeds the configuration is valid for.
This patch adds a flag in the configuration for SuperSpeedPlus and
also updates this based on the existence of ssp_descriptors.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Add a ssp_descriptors member to struct usb_function and handle the
initialization and cleanup of it. This holds the SuperSpeedPlus
descriptors for a function that supports SuperSpeedPlus. This is added
by usb_assign_descriptors().
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Add the 'ssp_descriptors' parameter to the usb_assign_descriptors()
function. This allows a function driver to add descriptors for
SuperSpeedPlus speeds if it supports it.
Also update all uses of this function in the gadget subsystem so that
they pass NULL for the ssp_descriptors parameters.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
If a gadget supports SuperSpeedPlus or higher speeds, return a
SuperSpeedPlus USB Device Capability descriptor.
Currently this implementation returns a fixed descriptor with typical
values set.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
The USB 3.1 specification replaces the USB 3.0 specification and all new
devices that are running at SuperSpeed or higher speeds must report a
bcdUSB of 0x0310.
Refer to USB 3.1 Specification, Revision 1.0, Section 9.6.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Avoid printing an error if adding the device failes with return
value EPROBE_DEFFER. This may happen e.g. due to missing GPIO for
the vbus-supply regulator.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
In chipidea IP RTL, there is a very limited design for siTD, the detail
like below:
There is no Max Packet Size at siTD, so it uses one constant for both
Max Packet Size for packet and the packet size for the last transaction
when considering schedule.
If the ttctrl.ttha does not match against Hub Address field in siTD,
this constant is 188 bytes, else this constant is 1023 bytes.
If the ttctrl.ttha is non-zero value, RTL will use 188 as this constant,
so it will lose the data if the packet size is larger than 188 bytes, eg,
if we playback a wav which format is 48khz, 16 bits, 2 channels, the
packet size will be 192bytes, but the controller will only send 188 bytes
for this packet, the noise will be heared using USB audio card.
The use case is single transaction, but higher frame rate.
If the ttctr.ttha is zero value, we can send 1023 bytes within one
transaction, but the controller will not accept the coming tranaction
if it considers the schedule time is less than 1023 bytes. So the
limitation is we can't schedule as many as transactions within frame.
If the total bytes is already 256 bytes for previous transactions within
frame, it can't accept another transaction. The use case is multiple
transactions, but less frame rate.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
retval is assigned to be -EOVERFLOW but is overwritten later before
it's used, remove this unused value assignment.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Until now the imx23 uses the imx27 platform flag. But the
imx23 needs the flag CI_HDRC_TURN_VBUS_EARLY_ON, too. So
fix this by adding a separate platform flag.
Suggested-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The most important fixes here are:
a) yet another fix to dwc3's EP transfer resource
assignment logic. This time around we will be
pre-allocating transfer resources to avoid any
future issues;
b) two DMA fixes for the old MUSB driver.
c) dwc2's data toggle fix for FS
Other than these, we have a few other minor fixes
elsewhere.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWzAM4AAoJEIaOsuA1yqREBCUP+QGgS85vE3L4pdVsvIg92j5l
9kgSyhJvJEbWlxPQlft08gvYlazD1993IP1UW3aFVDVpJt/yxf1rd7zqMrnh1jSM
c0SWYrlXVpkPuH15o4JaNjSajsJ9CM7kOg32WcleOmqugWiY4et98wrOkxIYtm1Y
5cR34O12WL+XcdgluxNz0CF3UQTvnI3EurwJzLMRvEqG/QmUCoN6Ie3nRxKOglhn
/UIHVT2kv/qN1L3QgdNPZzn3n3fX7ZdSg6sTMjdM7VWGNOrziK6658KBx9q64XeG
G3HQyOtxzXhAMHFHNxjh0RCkg+KJL+vkfouZJHtEZtX8JialnGwGIVnnyCbqZTwn
VVQcR8Jwh5Ph2oBIAyefqjFPIiKrvZ+Xq34j912W03KGertIoAW+8uOWM4Y6i8Ey
CU/kvUPjyI6I7znddJaeLvik3AL4G9YIi2rMdLs33ayWFhU3A0Lyg5mIdZox5w+Z
sMBe8OOfr5DnbgzzHyRW2yoTQrGSy11q8ZJom88jXreH3afM1naMduhnDAaYGN9/
X2WmIu+NyyxbK/VeDsr4RiZtgmAp/8udfkootPkbAcH68mPlQo5/tztdYAFOrcNa
gUmvL4j4yukagBG1XiKyS2eevnRqGq4bRwMkCzQ4PutZUQr67Wk+LxllUEvhSIFp
7puDKjAIKHHd6lQZykmp
=5QjC
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.5-rc6' of http://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v4.5-rc6
The most important fixes here are:
a) yet another fix to dwc3's EP transfer resource
assignment logic. This time around we will be
pre-allocating transfer resources to avoid any
future issues;
b) two DMA fixes for the old MUSB driver.
c) dwc2's data toggle fix for FS
Other than these, we have a few other minor fixes
elsewhere.
Commit ac33cdb166 ("usb: musb: Remove ifdefs for musb_host_rx in
musb_host.c part5") introduces a problem setting DMA host mode.
The musb_advance_schedule() is called immediately after receiving an
endpoint RX interrupt without waiting for the DMA transfer to complete.
As a consequence when the dma complete interrupt arrives the in_qh
member of hw_ep is already null an the musb_host_rx() exits on !urb
error case. Fix the done condition that advances the musb schedule.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: Joshua Henderson <joshua.henderson@microchip.com>
Tested-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
When working in Dual Role Device mode, USB state machine is not kicked,
when host or gadget drivers are loaded. Fix this be explicitly triggering
state detection on client driver load.
Issue is that if the board is booted without micro usb cable and usb
device attached, kernel fails to populate the usb host and device.
The reason for this is that the state machine worker logic only checks
for USB_DR_MODE_PERIPHERAL and USB_DR_MODE_HOST modes to run worker
thread. However if the phy is configured in OTG mode it would fail
to run the state machine, resulting in failure to detect for very
first time.
This patch fixes the issue by removing the explicit checks.
Issue is noticed on Qualcomm Dragon board DB410C.
[srinivas.kandagatla@linaro.org: Added more details to log]
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
This patch fixes the register offset used for super-speed connection's
max packet size. Without it using the 338x series of devices in enhanced
mode will only allow full or high speed operation to function correctly.
Signed-off-by: Simon Appleby <simon.appleby@pickeringtest.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even
if it didn't register it earlier due to other failures. This patch fixes
this.
Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Retry gadget probe only if the probe result is -EPROBE_DEFER, not on
every probe error.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Some platforms don't have DMA, but we should still be able to build USB
drivers for these platforms. They could still be used through vhci_hcd,
usbip_host, or maybe something like USB passthrough in UML from a
capable host.
If NO_DMA=y:
ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "dma_pool_free" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "dma_pool_create" [drivers/usb/core/usbcore.ko] undefined!
Add a few checks for CONFIG_HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The US_DEBUGPX macro uses printk without specifying a kernel log level, so
the default kernel log level is used, which may not match LOGLEVEL_DEBUG
used in usb_stor_dbg. Remove the macro and use usb_store_dbg instead.
Signed-off-by: Victor Dodon <printesoi@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the device is disconnected poll waiters were not being woken.
Changes for v2:
- add commit summary
- add Fixes and Reported-by tags
Fixes: eb6b92ecc0 ("Add support for receiving USBTMC USB488 SRQ notifications via poll/select")
Reported-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Dave Penkler <dpenkler@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The write value is 8bit, but currently writing a larger number (eg a doubled
digit) is not errored but instead gets cast and sets off an action probably
undesired.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To allow for and clean handling of signals an URB is introduced.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shares the cleanup code between all probe failure paths, instead of
having per-failure cleanup at each point in the function.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 4b61b4f205.
As reported by Oliver, this change was unnecessary.
Reported-by: Oliver Neukum <oneukum@suse.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit d8f00cd685.
Tony writes:
This upstream commit is causing an oops:
d8f00cd685 ("usb: hub: do not clear BOS field during reset device")
This patch has already been included in several -stable kernels. Here
are the affected kernels:
4.5.0-rc4 (current git)
4.4.2
4.3.6 (currently in review)
4.1.18
3.18.27
3.14.61
How to reproduce the problem:
Boot kernel with slub debugging enabled (otherwise memory corruption
will cause random oopses later instead of immediately)
Plug in USB 3.0 disk to xhci USB 3.0 port
dd if=/dev/sdc of=/dev/null bs=65536
(where /dev/sdc is the USB 3.0 disk)
Unplug USB cable while dd is still going
Oops is immediate:
Reported-by: Tony Battersby <tonyb@cybernetics.com>
Cc: Du, Changbin <changbin.du@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are some new device ids.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWx3i4AAoJEEEN5E/e4bSVUncP/Rm5vy+8YJ8u2NzvXOtzXdoe
2+Ef8yE402DQl9d4SJNg5mL8nNcdUDaZGRoLKDlnws/iX1PcQf6RxrR4fhYbR8xk
kd6+BT+rUzICI7xD5Q190GPV4InFUXDJ9lH89LPb75A9aMLdffy+WpEFoXoKlDaw
O01b/OZClAsxqNmMO0UKr8Xbki2hMPlP5AM6rOVn5eJqZv4FB9mD/C9pwxxloW75
8iBq5pRHrJpHw3AiWOz9npW5RUxOag0HRln4Lx9b7gOHeMY/JH440LVufjQB0/4Y
cJ/G3w94rJqAuJ+87fYXJ8zDmAHTOfCVqSuloC7o4GqNXjV1PayRj3MMxOLjusHg
DLuCkZquCEQ8+X2+j09A/0+k4XFw6he+a8n7dmzJzfMYH5DAd+WU1oMn9c8p/zG6
Vf9t0C9m4DtCMh+lO1cz5M3q8133cePf282ogCkK8meGISBZH2ZUMSJWqkn9+RYd
/rytj1UVq5UH8wVqNPu2fVlIqEk3AaG8VrM7iLHGsEE4BsYJ3fYyEvu1NeVXqMEa
thZZQBrvBCkObZsJzkZIfKhjisvN+Pg1Wo4X3OzsFuXxt56zZYh52ysFl43GEyWp
Jyw+8ggpiWd5nrvps3uVMvDVLwaIhhCgMUW2XgVnnrtxBtFfguJRAjWjO513esuy
C0EfegNX9Qzx2MSTrtSH
=eFQw
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.5-rc5
Here are some new device ids.
Signed-off-by: Johan Hovold <johan@kernel.org>
In case of error, the function usb_phy_generic_register()
returns ERR_PTR() and never returns NULL. The NULL test in
the return value check should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
The write value is 8bit, but currently writing a larger number
(eg a doubled digit) is not errored but instead gets cast and
sets off an action probably undesired.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
(Change the style of commit log to fix checkpatch.pl warning)
