IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
fix the coding style of a few switches on the
gadget framework.
[ balbi@ti.com : add a commit log ]
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
MAINTAINERS: add myself as maintainer of USB/IP
usb: r8a66597-hcd: fix cannot detect low/full speed device
USB: ehci-ath79: fix a NULL pointer dereference
USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c
usb/isp1760: Fix bug preventing the unlinking of control urbs
USB: Fix up URB error codes to reflect implementation.
xhci: Always set urb->status to zero for isoc endpoints.
xhci: Add reset on resume quirk for asrock p67 host
xHCI 1.0: Incompatible Device Error
USB: don't let errors prevent system sleep
USB: don't let the hub driver prevent system sleep
USB: change maintainership of ohci-hcd and ehci-hcd
xHCI 1.0: Force Stopped Event(FSE)
xhci: Don't warn about zeroed bMaxBurst descriptor field.
USB: Free bandwidth when usb_disable_device is called.
xhci: Reject double add of active endpoints.
USB: TI 3410/5052 USB Serial Driver: Fix mem leak when firmware is too big.
usb: musb: gadget: clear TXPKTRDY flag when set FLUSHFIFO
usb: musb: host: compare status for negative error values
Add config_ep_by_speed() to configure the endpoint
according to the gadget speed.
Using this function will spare the FDs from handling
the endpoint chosen descriptor.
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change usb_ep_enable() prototype to use endpoint
descriptor from usb_ep.
This optimization spares the FDs from saving the
endpoint chosen descriptor. This optimization is
not full though. To fully exploit this change, one
needs to update all the UDCs as well since in the
current implementation each of them saves the
endpoint descriptor in it's internal (and extended)
endpoint structure.
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
peripheral drivers are using usb_add_gadget()/usb_del_gadget() to
register/unregister to the udc-core.
The udc-core will take the first available gadget driver and attach
function driver which is calling usb_gadget_register_driver(). This is
the same behaviour we have right now.
Only dummy_hcd was tested, the others were compiled tested.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Anton Tikhomirov <av.tikhomirov@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
Cc: Roy Huang <roy.huang@analog.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Cc: Xiaochen Shen <xiaochen.shen@intel.com>
Cc: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com>
Cc: cxie4 <cxie4@marvell.com>
Cc: linux-geode@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
this class will be used to abstract away several of the duplicated
operations scattered among the USB gadget controller drivers.
Later, we can add an atomic notifier to tell interested drivers about
what's happening with the controller. Notifications such as suspend,
resume, enumerated, etc. will be useful, at a minimum, for implementing
usb charger detection.
As part of the converting process usb_gadget_probe_driver() is no longer
part of each udc but pushed into the ->stap() callback. The same for his
couterpart.
The core is currently set explicit to 'n'. It will be changed to 'y' once
all users are converted since it provides functions which clash with
other drivers.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This controller can control "Transaction Translators", but
the hcd->has_tt is not set.
Since the commit d199c96d41d80a567493e12b8e96ea056a1350c1
("USB: prevent buggy from crashing the USB stack") has checked it,
the driver could not work the low/full speed device.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Loading the ehci-hcd module on the ath79 platform causes
a NULL pointer dereference:
CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == c0252928, ra == c00de968
Oops[#1]:
Cpu 0
$ 0 : 00000000 00000070 00000001 00000000
$ 4 : 802cf870 0000117e ffffffff 8019c7bc
$ 8 : 0000000a 00000002 00000001 fffffffb
$12 : 8026ef20 0000000f ffffff80 802dad3c
$16 : 8077a2d4 8077a200 c00f3484 8019ed84
$20 : c00f0000 00000003 000000a0 80262c2c
$24 : 00000002 80079da0
$28 : 80788000 80789c80 80262b14 c00de968
Hi : 00000000
Lo : b61f0000
epc : c0252928 __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd]
Not tainted
ra : c00de968 usb_add_hcd+0x2a4/0x858 [usbcore]
Status: 1000c003 KERNEL EXL IE
Cause : 00800008
BadVA : 00000000
PrId : 00019374 (MIPS 24Kc)
Modules linked in: ehci_hcd(+) pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG
xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filte
r ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc ath mac80211
usbcore nls_base input_polldev crc_ccitt cfg80211 compat input_core a
rc4 aes_generic crypto_algapi
Process insmod (pid: 379, threadinfo=80788000, task=80ca2180,
tls=77fe52d0)
Stack : c0253184 80c57d80 80789cac 8077a200 00000001 8019edc0 807fa800 8077a200
8077a290 c00f3484 8019ed84 c00f0000 00000003 000000a0 80262c2c c00de968
802d0000 800878cc c0253228 c02528e4 c0253184 80c57d80 80bf6800 80ca2180
8007b75c 00000000 8077a200 802cf830 802d0000 00000003 fffffff4 00000015
00000348 00000124 800b189c c024bb4c c0255000 801a27e8 c0253228 c02528e4
...
Call Trace:
[<c0252928>] __mod_vermagic5+0xc260/0xc7e8 [ehci_hcd]
It is caused by:
commit c430131a02d677aa708f56342c1565edfdacb3c0
Author: Jan Andersson <jan@gaisler.com>
Date: Tue May 3 20:11:57 2011 +0200
USB: EHCI: Support controllers with big endian capability regs
The two first HC capability registers (CAPLENGTH and HCIVERSION)
are defined as one 8-bit and one 16-bit register. Most HC
implementations have selected to treat these registers as part
of a 32-bit register, giving the same layout for both big and
small endian systems.
This patch adds a new quirk, big_endian_capbase, to support
controllers with big endian register interfaces that treat
HCIVERSION and CAPLENGTH as individual registers.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The reading of the HC capability register has been moved by that
commit to a place where the ehci->caps field is not initialized
yet. This patch moves the reading of the register back to the
original place.
Acked-by: Jan Andersson <jan@gaisler.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
appended patch adds support for the new FTDI FT232H chip. This chip is a
single channel version of the dual FT2232H/quad FT4232H, coming with it's
own default PID 0x6014 (FT2232H uses the same PID 0x6010 like FT2232C,
FT4232H has also it's own PID).
The patch was checked on an UM232H module and a terminal program with TX/RX
shorted to that typing in the terminal reproduced the characters.
Signed-off-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Both control and bulk transfers use isp1760 slots of type ATL, but the
driver unlink code for ATL slots only acts on urbs describing a bulk
transfer, letting the code for INT slots take care of the unlink instead,
which often ended up removing the interrupt transfer for root hub events
instead. That's not good, and gets fixed by this patch.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
USB: Fix up URB error codes to reflect implementation.
xhci: Always set urb->status to zero for isoc endpoints.
xhci: Add reset on resume quirk for asrock p67 host
xHCI 1.0: Incompatible Device Error
xHCI 1.0: Force Stopped Event(FSE)
xhci: Don't warn about zeroed bMaxBurst descriptor field.
USB: Free bandwidth when usb_disable_device is called.
xhci: Reject double add of active endpoints.
Remove linux/mm.h inclusion from netdevice.h -- it's unused (I've checked manually).
To prevent mm.h inclusion via other channels also extract "enum dma_data_direction"
definition into separate header. This tiny piece is what gluing netdevice.h with mm.h
via "netdevice.h => dmaengine.h => dma-mapping.h => scatterlist.h => mm.h".
Removal of mm.h from scatterlist.h was tried and was found not feasible
on most archs, so the link was cutoff earlier.
Hope people are OK with tiny include file.
Note, that mm_types.h is still dragged in, but it is a separate story.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch (as1473) renames the "in_suspend" field in struct
dev_pm_info to "is_prepared", in preparation for an upcoming change.
The new name is more descriptive of what the field really means.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
Many stupid corrections of duplicated includes based on the output of
scripts/checkincludes.pl.
Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.
This should be backported to stable kernels as old as 2.6.37.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
It is one new TRB Completion Code for the xHCI spec v1.0.
Asserted if the xHC detects a problem with a device that does not allow it to
be successfully accessed, e.g. due to a device compliance or compatibility
problem. This error may be returned by any command or transfer, and is fatal
as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
of ISOC for transfer case. And return -ENODEV for configure endpoint command,
evaluate context command and address device command if there is an incompatible
Device Error. The error codes will be sent back to the USB core to decide how
to do. It's unnecessary for other commands because after the three commands run
successfully means that the device has been accepted.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch (as1471) deprecates the File-backed Storage Driver and
schedules its replacement for the 3.8 kernel release (about two years
from now). Users are advised to switch to the Mass Storage Gadget
instead.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep. In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:
Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets. (This might be less true for USB-3.0 devices, but let's not
worry about them now.)
Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.
In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error. There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.
Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended. This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Following the loss of David Brownell, I volunteer to maintain the
ohci-hcd and ehci-hcd drivers. This patch (as1472) makes it official.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
FSE shall occur on the TD natural boundary. The software ep_ring dequeue pointer
exceed the hardware ep_ring dequeue pointer in these cases of Table-3. As a
result, the event_trb(pointed by hardware dequeue pointer) of the FSE can't be
found in the current TD(pointed by software dequeue pointer). What should we do
is to figured out the FSE case and skip over it.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed
Endpoint Companion descriptor is supposed to indicate how many packets a
SS device can handle before it needs to wait for an explicit handshake
from the host controller. A zero value means the device can only handle
one packet before it needs a handshake. Remove a warning in the xHCI
driver that implies this is an invalid value.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tanya ran into an issue when trying to switch a UAS device from the BOT
configuration to the UAS configuration via the bConfigurationValue sysfs
file. Before installing the UAS configuration, set_bConfigurationValue()
calls usb_disable_device(). That function is supposed to remove all host
controller resources associated with that device, but it leaves some state
in the xHCI host controller.
Commit 0791971ba8fbc44e4f476079f856335ed45e6324
usb: allow drivers to use allocated bandwidth until unbound
added a call to usb_disable_device() in usb_set_configuration(), before
the xHCI bandwidth functions were invoked. That commit fixed a bug, but
also introduced a bug that is triggered when a configured device is
switched to a new configuration.
usb_disable_device() goes through all the motions of unbinding the drivers
attached to active interfaces and removing the USB core structures
associated with those interfaces, but it doesn't actually remove the
endpoints from the internal xHCI host controller bandwidth structures.
When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
set to true, the entries in udev->ep_out and udev->ep_in will be set to
NULL. Usually, when the USB core installs a new configuration,
usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
and udev->ep_in before adding any new endpoints. However, when the new
UAS configuration was added, all those entries were null, so none of the
old endpoints in the BOT configuration were dropped.
The xHCI driver blindly added the UAS configuration endpoints, and some of
the endpoint addresses overlapped with the old BOT configuration
endpoints. This caused the xHCI host to reject the Configure Endpoint
command. Now that the xHCI driver code is cleaned up to reject a
double-add of active endpoints, we need to fix the USB core to properly
drop old endpoints in usb_disable_device().
If the host controller driver needs bandwidth checking support, make
usb_disable_device() call usb_disable_endpoint() with
reset_hardware set to false, drop the endpoints from the xHCI host
controller, and then call usb_disable_endpoint() again with
reset_hardware set to true.
The first call to usb_disable_endpoint() will cancel any pending URBs and
wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
pointers in udev->ep_out and udev->ep in intact. Then
usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
to drop.
The final call to usb_disable_endpoint() will do two things:
1. It will call usb_hcd_disable_endpoint() again, which should be harmless
since the ep->urb_list should be empty after the first call to
usb_disable_endpoint() returns.
2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
usb_hcd_disable_endpoint(). That call will have no effect, since the xHCI
driver doesn't set the endpoint_disable function pointer.
Note that usb_disable_device() will now need to be called with
hcd->bandwidth_mutex held.
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Cc: ablay@codeaurora.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org
While trying to switch a UAS device from the BOT configuration to the UAS
configuration via the bConfigurationValue file, Tanya ran into an issue in
the USB core. usb_disable_device() sets entries in udev->ep_out and
udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
functions to remove the BOT configuration endpoints from the xHCI host's
internal structures.
The USB core would then attempt to add endpoints for the UAS
configuration, and some of the endpoints had the same address as endpoints
in the BOT configuration. The xHCI driver blindly added the endpoints
again, but the xHCI host controller rejected the Configure Endpoint
command because active endpoints were added without being dropped.
Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
add active endpoints without first calling xhci_drop_endpoint().
This should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Cc: stable@kernel.org
Sometimes the connection fail happen on renesas_usbhs.
This patch fix it up.
Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the size of the firmware exceeds TI_FIRMWARE_BUF_SIZE we'll leak 'fw_p'
by failing to call release_firmware().
This patch fixes the leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Several fixes as well where the +1 was missing.
Done via coccinelle scripts like:
@@
struct resource *ptr;
@@
- ptr->end - ptr->start + 1
+ resource_size(ptr)
and some grep and typing.
Mostly uncompiled, no cross-compilers.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fixes mis-use of MUSB's hardware feature where it won't
flush FIFOs when TXPKTRDY flag was set before and we are
flushing setting both FLUSHFIFO and TXPKTRDY.
In other words, we need to ensure that when we try to
flush FIFOs, we don't accidentaly set TXPKTRDY bit too
due to a read-back of the register.
The MUSB Programming Guide says "May be set simultaneously
with TxPktRdy to abort the packet that is currently being
loaded into the FIFO". This is a situation where TXPKTRDY
hasn't been set yet, but some data already loaded into the
fifo. It looks, that if TXPKTRDY has been set before, and
there is no loading in progress, but we set FLUSHFIFO with
the TXPKTRDY, controller tries to use the same logic to
abort loading and as the result just does nothing (because
there is no packet been loaded currently)
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@nokia.com>
[ balbi@ti.com : fixed one whitespace git complained about
improved the commit log slightly ]
Signed-off-by: Felipe Balbi <balbi@ti.com>
Variable d is a struct usb_iso_packet_descriptor. The status filed is usually
negative when an error happens.
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8.
Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc
when the option driver tries to bind to it.
So revert this as it doesn't seem to be needed at all.
Thanks to Michael Tokarev and Paweł Drobek for working on resolving this
issue.
Cc: Paweł Drobek <pawel.drobek@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB DMA was installed on "normal DMAC" when SH7724 or older SuperH,
but the "USB-DMAC" was prepared on recent SuperH.
These 2 DMAC have a little bit different behavior.
This patch add DMAEngine code for "normal DMAC",
but it is still using PIO fifo.
The DMA fifo will be formally supported in the future.
You can enable DMA fifo by local fixup
usbhs_fifo_pio_push_handler -> usbhs_fifo_dma_push_handler
usbhs_fifo_pio_pop_handler -> usbhs_fifo_dma_pop_handler
on usbhsg_ep_enable.
This DMAEngine was tested by g_file_storage on SH7724 Ecovec board
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch tidyup PIO packet handler name.
This is a preparation for DMAEngine support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
packet transfer timing are controlled in mod_gadget on current renesas_usbhs,
and this style will be imitated on mod_host.
But it need not be managed with host/gadget if it is general transfer.
By this patch, the packet transfer timing is managed in fifo.c
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
renesas_usbhs has CFIFO which is for PIO transfer,
and D0FIFO/D1FIFO which are for DMA transfer.
The pipe selects one of these fifo when it send/recv data.
But fifo must not be selected to different pipe in same time.
This patch add pipe/fifo link for each other,
and fifo is not selected by another pipe until it is unselected.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
renesas_usbhs has CFIFO/D0FIFO/D1FIFO.
But current renesas_usbhs is using CFIFO (for PIO) only for now.
The fifo selection method is needed for DMAEngine support.
This is a preparation for DMAEngine support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
spin lock was very effective while doing 1 packet send/recv on
current renesas_usbhs driver.
But this lock is enough only
- modify packet/pipe link
- modify interrpt mask
- modify fifo access
This patch shrink spin lock area
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On current driver, overall data transfer method was implemented in fifo.c,
but its interrupt which is member of packet queue control
was still in mod_gadget.c.
This patch move it into fifo.c.
By this patch, the packet/fifo control is independent from mod_gadget.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On current driver, main data transfer function was implemented in fifo.c,
but the overall controlling was implementing in mod_gadget.c.
This style is not useful to support host and DMAEngine in the future.
But the interrupt for data transfer cannot separate easily for now,
because it is deeply related to mod_gadget.
This patch move the overall data transfer method
into fifo.c except interrupt.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current renesas_usbhs driver is controlling packet queue on mod_gadget.c.
But it has relationship with pipe/fifo, not host/gadget.
So, controlling USB packet queue in pipe.c/fifo.c is
more convenient than in mod_gadget.c.
This patch modify it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
DMAEngine will be supported to this driver in the future.
Then, both PIO and DMA data transfer method should be supported.
But, the transfer function can returns the result immediately
in PIO version, but it can't in DMA version.
This patch divides data transfer functions into top/bottom half
in preparation for DMAEngine support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current renesas_usbhs has PIO data transfer mode which controls CFIFO.
And it was implemented in pipe.c.
But, fifo control method needs more flexible implementation
to support DMAEngine.
This patch create fifo.c, and it became independent from pipe.c.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current driver had pipe direction flag
which came from usb_endpoint_dir_in().
It means "input direction" for HOST,
and "out direction" for Gadget.
But driver needs "input direction for pipe".
This patch adds IS_DIR_HOST flags and care
both "input direction for HOST" and "input direction for pipe"
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There is no need to have a "\n" on a MODULE_PARM_DESC, remove it
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
