When the enable bits for controller / async schedule / periodic schedule
change just make sure we kick the frame timer and let
ehci_advance_periodic_state and ehci_advance_async_state handle the
controller state changes.

This will make ehci set USBSTS_HALT when the controller shutdown is
actually done, once both schedules are in inactive state and the
USBSTS_PSS and USBSTS_ASS bits are clear.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Update the status register in the ehci_set_state function, to make sure
the guest-visible register is in sync with our internal schedule state.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add helper functions to query whenever the async / periodic schedule
is enabled or not.  Put them into use too.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Check for the reset bit first when processing USBCMD register writes.
Also break out of the switch, there is no need to check the other bits.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Kick async schedule when we get a wakeup
notification from a usb device.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

When a packet completes which happens to be part of the async schedule
kick the async bottom half for processing,
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This way we can kick the async schedule independant from the
periodic frame timer.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Keep track whenever a EHCIQueue is part of the async or periodic
schedule.  This way we don't have to pass around the async flag
everywhere but can look it up from the EHCIQueue struct when needed.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Little tweak for the queue initialization, set the QH address in the
allocation function.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add packet queuing.  Follow the qTD chain to see if there are more
packets we can submit.  Improves performance on larger transfers,
especially with usb-host, as we don't have to wait for a packet to
finish before sending the next one to the host for processing.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Move ehci_flush_qh() function up in the source code.
No code change.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Keep a USBDevice pointer in EHCIQueue so we don't have to lookup the
device on each usb packet submission.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This way it is possible to use ehci_execute to submit others than the
first EHCIPacket of the EHCIQueue.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add a separate EHCIPacket struct and move fields over from EHCIQueue.
Preparing for supporting multiple packets per queue being in flight at
the same time.  No functional changes yet.

Fix some codestyle issues along the way.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

These were identified using: http://github.com/lyda/misspell-check
and run like this to create a bourne shell script using GNU sed's
-i option:

git ls-files|grep -vF .bin | misspellings -f - |grep -v '^ERROR:' |perl \
-pe 's/^(.*?)\[(\d+)\]: (\w+) -> "(.*?)"$/sed -i '\''${2}s!$3!$4!'\'' $1/'

Manually eliding the FP, "rela->real" and resolving "addres" to
address (not "adders") we get this:

  sed -i '450s!thru!through!' Changelog
  sed -i '260s!neccessary!necessary!' coroutine-sigaltstack.c
  sed -i '54s!miniscule!minuscule!' disas.c
  sed -i '1094s!thru!through!' hw/usb/hcd-ehci.c
  sed -i '1095s!thru!through!' hw/usb/hcd-ehci.c
  sed -i '21s!unecessary!unnecessary!' qapi-schema-guest.json
  sed -i '307s!explictly!explicitly!' qemu-ga.c
  sed -i '490s!preceeding!preceding!' qga/commands-posix.c
  sed -i '792s!addres!address!' qga/commands-posix.c
  sed -i '6s!beeing!being!' tests/tcg/test-mmap.c

Also, manually fix "arithmentic", spotted by Peter Maydell:

  sed -i 's!arithmentic!arithmetic!' coroutine-sigaltstack.c
Signed-off-by: NJim Meyering <meyering@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>

frindex is a 14 bits counter, so bits 31-14 should always be 0, and
after the commit titled "usb-ehci: frindex always is a 14 bits counter"
we rely on frindex always being a multiple of 8. I've not seen this in
practice, but theoretically a guest can write a value >= 0x4000 or a value
which is not a multiple of 8 value to frindex, this patch ensures that
things will still work when that happens.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

To answer the question in the comment removed by this patch:  I think
this was needed because several places in the ehci emulation did not
check the T bit of link entries correctly and thus might have followed
invalid references.  See commit 2a5ff735Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Not sure what the purpose of the assert() was, in any case it is bogous.
We can arrive there if transfer descriptors passed to us from the guest
failed to pass sanity checks, i.e. it is guest-triggerable.  We deal
with that case by resetting the host controller.  Everything is ok, no
need to throw a core dump here.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The sofv value only ever gets a value assigned and is never used (read)
anywhere, so we can just drop it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

frindex always is a 14 bits counter, and not a 13 bits one as we were
emulating. There are some subtle hints to this in the spec, first of all
"Table 2-12. FRINDEX - Frame Index Register" says:
"Bit 13:0 Frame Index. The value in this register increments at the end of
each time frame (e.g. micro-frame). Bits [N:3] are used for the Frame List
current index. This means that each location of the frame list is accessed
8 times (frames or micro-frames) before moving to the next index. The
following illustrates values of N based on the value of the Frame List
Size field in the USBCMD register.

USBCMD[Frame List Size]	Number Elements		 N
00b				1024		12
01b				 512		11
10b				 256		10
11b			    Reserved"

Notice how the text talks about "Bits [N:3]" are used ..., it does
NOT say that when N == 12 (our case) the counter will wrap from 8191 to 0,
or in otherwords that it is a 13 bits counter (bits 0 - 12).

The other hint is in "Table 2-10. USBSTS USB Status Register Bit Definitions":

"Bit 3 Frame List Rollover - R/WC. The Host Controller sets this bit to a one
when the Frame List Index (see Section 2.3.4) rolls over from its maximum value
to zero. The exact value at which the rollover occurs depends on the frame
list size. For example, if the frame list size (as programmed in the Frame
List Size field of the USBCMD register) is 1024, the Frame Index Register
rolls over every time FRINDEX[13] toggles. Similarly, if the size is 512,
the Host Controller sets this bit to a one every time FRINDEX[12] toggles."

Notice how this text talks about setting bit 3 when bit 13 of frindex toggles
(when there are 1024 entries, so our case), so this indicates that frindex
has a bit 13 making it a 14 bit counter.

Besides these clear hints the real proof is in the pudding. Before this
patch I could not stream data from a USB2 webcam under Windows XP, after
this cam using a USB2 webcam under Windows XP works fine, and no regressions
with other operating systems were seen.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Looks like a cut+paste bug from ehci_detach.  When the device itself is
detached from a ehci port (ehci_detach op) we have to clear the
device pointer for the companion port too.  When a device gets removed
from a downstream port of a usb hub (ehci_child_detach op) the ehci port
where the usb hub is plugged in is not affected.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Reorganize usb source files.  Create a new hw/usb/ directory and move
all usb source code to that place.  Also make filenames a bit more
descriptive.  Host adapters are prefixed with "hch-" now, usb device
emulations are prefixed with "dev-".  Fixup paths Makefile and include
paths to make it compile.  No code changes.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

We already have USB_RET_NAK, but that means that a device does not want
to send/receive right now. But with host / network redirection we can
actually have a transaction fail due to some io error, rather then ie
the device just not having any data atm.

This patch adds a new error code named USB_RET_IOERROR for this, and uses
it were appropriate.

Notes:
-Currently all usb-controllers handle this the same as NODEV, but that
 may change in the future, OHCI could indicate a CRC error instead for example.
-This patch does not touch hw/usb-musb.c, that is because the code in there
 handles STALL and NAK specially and has a if status < 0 generic catch all
 for all other errors
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

All error statuses except for NAK are handled in a switch case, move the
handling of NAK into the same switch case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The nakcnt code in ehci_execute_complete() marked transactions as finished
when a packet completed with a result of USB_RET_NAK, but USB_RET_NAK
means that the device cannot receive / send data at that time and that
the transaction should be retried later, which is also what the usb-uhci
and usb-ohci code does.

Note that there already was some special code in place to handle this
for interrupt endpoints in the form of doing a return from
ehci_execute_complete() when reload == 0, but that for bulk transactions
this was not handled correctly (where as for example the usb-ccid device does
return USB_RET_NAK for bulk packets).

Besides that the code in ehci_execute_complete() decrement nakcnt by 1
on a packet result of USB_RET_NAK, but
-since the transaction got marked as finished,
 nakcnt would never be decremented again
-there is no code checking for nakcnt becoming 0
-there is no use in re-trying the transaction within the same usb frame /
 usb-ehci frame-timer call, since the status of emulated devices won't change
 as long as the usb-ehci frame-timer is running
So we should simply set the nakcnt to 0 when we get a USB_RET_NAK, thus
claiming that we've tried reload times (or as many times as possible if
reload is 0).

Besides the code in ehci_execute_complete() handling USB_RET_NAK there
was also code handling it in ehci_state_executing(), which calls
ehci_execute_complete(), and then does its own handling on top of the handling
in ehci_execute_complete(), this code would decrement nakcnt *again* (if not
already 0), or restore the reload value (which was never changed) on success.

Since the double decrement was wrong to begin with, and is no longer needed
now that we set nakcnt directly to 0 on USB_RET_NAK, and the restore of reload
is not needed either, this patch simply removes all nakcnt handling from
ehci_state_executing().
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch removes 2 bits of dead nakcnt code:

1) usb_ehci_execute calls ehci_qh_do_overlay which does:
nakcnt = reload;
and then has a block of code which is conditional on:
if (reload && !nakcnt) {
which ofcourse is never true now as nakcnt == reload.

2) ehci_state_fetchqh does:
nakcnt = reload;
but before nakcnt is ever used ehci_state_fetchqh is always followed
by a ehci_qh_do_overlay call which also does:
nakcnt = reload;
So doing this from ehci_state_fetchqh is redundant.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

cerr should only be decremented on errors which cause XactErr to be set, and
when that happens the failing transaction should be retried until cerr reaches
0 and only then should USBSTS_ERRINT be set (and inactive cleared and
USBSTS_INT set if requested).

Since we don't have any hardware level errors (and in case of redirection
the real hardware has already retried), re-trying makes no sense, so
immediately set cerr to 0 on errors which set XactErr.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

As clearly stated in the 2.3.2 of the EHCI spec, any time USBERRINT get
sets then if the td has its IOC bit set USBINT should be set as well.

This means that for any status except for USB_RET_NAK we should set
USBINT if the IOC bit is set.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The purpose of the IAAD bit / the doorbell is to make the ehci controller
forget about cached qhs, this is mainly used when cancelling transactions,
the qh is unlinked from the async schedule and then the doorbell gets rung,
once the doorbell is acked by the controller the hcd knows that the qh is
no longer in use and that it can do something else with the memory, such
as re-use it for a new qh! But we keep our struct representing this qh around
for circa 250 ms. This allows for a (mightily large) race window where the
following could happen:
-hcd submits a qh at address 0xdeadbeef
-our ehci code sees the qh, sends a request to a usb-device, gets a result
 of USB_RET_ASYNC, sets the async_state of the qh to EHCI_ASYNC_INFLIGHT
-hcd unlinks the qh at address 0xdeadbeef
-hcd rings the doorbell, wait for us to ack it
-hcd re-uses the qh at address 0xdeadbeef
-our ehci code sees the qh, looks in the async_queue, sees there already is
 a qh at address 0xdeadbeef there with async_state of EHCI_ASYNC_INFLIGHT,
 does nothing
-the *original* (which the hcd thinks it has cancelled) transaction finishes
-our ehci code sees the qh on yet another pass through the async list,
 looks in the async_queue, sees there already is a qh at address 0xdeadbeef
 there with async_state of EHCI_ASYNC_COMPLETED, and finished the transaction
 with the results of the *original* transaction.

Not good (tm), this patch fixes this race by removing all qhs which have not
been seen during the last cycle through the async list immidiately when the
doorbell is rung.

Note this patch does not fix any actually observed problem, but upon
reading of the EHCI spec it became apparent to me that the above race could
happen and the usb-ehci behavior from before this patch is not good.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Before this patch USB 2 devices with interrupt endpoints were not working
properly. The problem is that to avoid loops we stop processing as soon
as we encounter a queue-head (qh) we've already seen since qhs can be linked
in a circular fashion, this is tracked by the seen flag in our qh struct.

The resetting of the seen flag is done from ehci_queues_rip_unused which
before this patch was only called when executing the statemachine for the
async schedule.

But packets for interrupt endpoints are part of the periodic schedule! So what
would happen is that when there were no ctrl or bulk packets for a USB 2
device with an interrupt endpoint, the async schedule would become non
active, then ehci_queues_rip_unused would no longer get called and when
processing the qhs for the interrupt endpoints from the periodic schedule
their seen bit would still be 1 and they would be skipped.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

qhs can be part of both the async and the periodic schedule, as is shown
in later patches in this series it is useful to keep track of the qhs on
a per schedule basis.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Before this patch the T-bit was not checked in 2 places, while it should be.

Once we properly check the T-bit everywhere we no longer need the weird
entry < 0x1000 and entry > 0x1000 checks, so this patch removes them.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Drop the "ehci under development" banner.
Drop unused & inactive (#if 0) code.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Before this patch the ehci code was not checking for any other errors other
then USB_RET_NAK. This causes 2 problems:
1) Other errors are not reported to the guest.
2) When transactions with the ITD_XACT_IOC bit set completing with another
   error would not result in USBSTS_INT getting set.

I hit this problem when unplugging devices while iso data was streaming from
the device to the guest. When this happens it takes a while for the guest to
process the unplugging and remove ISO transactions from the ehci schedule, in
the mean time these transactions would complete with a result of USB_RET_NODEV,
which was not handled. This lead to the Linux guest's usb subsystem "hanging",
that is it would no longer see new usb devices getting plugged in and running
for example lsusb would lead to a stuck (D state) lsusb process. This patch
fixes this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch adds a sanity check to itd processing to make sure the
endpoint addressed by the guest is actually an iso endpoint.  Also
verify that usb drivers don't return USB_RET_ASYNC which is illegal for
iso xfers.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Two reset fixes:
  * pick up s->usbcmd value after ehci_reset call to make sure it
    keeps the reset value and doesn't get rubbish filled in when
    val is written back to the mmio register array later on.
  * make sure the frame timer is zapped on reset.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Replace device_init() with generalized type_init().

While at it, unify naming convention: type_init([$prefix_]register_types)
Also, type_init() is a function, so add preceding blank line where
necessary and don't put a semicolon after the closing brace.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: malc <av1474@comtv.ru>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>