Due to how the old control request API worked, the request
pointer (and the pointed-to contents) passed by the driver
must remain valid for the lifetime of the request.
The buffered copy wasn't used consistently anyway, so it
should be safe to just get rid of it.
(This only affects the old API compatibility layer.)
Change-Id: I00294c718a7515a91b84f7c7cae5220c73aa5960
In the old API, usb_core_transfer_complete() would ignore
any completions on EP0. The legacy control API will also
ignore most completions on EP0, but it only did so after
filling in the completion event.
If the driver submits a spurious completion on EP0, then
this could clobber a previously queued completion event.
Fix this by deciding whether to ignore the completion
*before* modifying the event data.
Change-Id: I68526898a96efa594ada4e94bb6851aaaf12e92a
The address from the packet needs to be saved before sending
the response -- after the response the request being pointed
to could get overwritten. This used to be done correctly but
I unintentionally broke it when updating the handler to the
new control request API.
Change-Id: I9b11548baf20dce44a82301731405dc8e8f1cef3
Because usb_core_legacy_control_request() is called by an
interrupt handler the global variables used to track the
current control request at the very least need to be volatile.
It might also be necessary to disable IRQs but I'm not sure
of that.
Change-Id: I0f0bb86d0ad63734e8d3c73cb1c52fedf5a98120
All existing USB drivers now define USB_LEGACY_CONTROL_API to
enable the emulation layer.
Control request handlers will be ported in follow-up commits.
Change-Id: I4be1ce7c372f2f6fee5978a4858c841b72e77405
This makes it possible for macros of conditionally included string
descriptors to get a correct index no matter what other usb drivers
are enabled or disabled due to the nature behavior of enums.
Change-Id: I8ccebbd316605bed0f5d90b6b73fab4a333c02fa
Upon getting a USB reset, the USB core will update charging
current by calling usb_charging_maxcurrent_change(). On all
current X1000 targets this may cause a hang, since changing
the charge current involves a blocking I2C transaction.
Eg. if the host issues a reset when we're already configured
as part of error recovery, the change from 500 mA -> 100 mA
will cause a hang.
Change-Id: I5b45272c01fa16b179ae3d16bbc50c7fab9a416b
IMHO the current name is somewhat misleading:
- usb_drv_send() is blocking and we have usb_drv_send_nonblocking()
for the non-blocking case. This inconsistent naming can only
promote confusion. (And what would we call a blocking receive?)
- Other hardware abstraction APIs in Rockbox are usually blocking:
storage, LCD, backlight, audio... in other words, blocking is the
default expected behavior, with non-blocking calls being a rarity.
Change-Id: I05b41088d09eab582697674f4f06fdca0c8950af
Atmel AT88SC6416C CryptoMemory is almost I2C compatible. The device
is connected to bitbanged I2C bus shared with compliant I2C devices.
Change-Id: Iec54702db1bdfb93c01291eef18ec60391c63b16
This uses the new unicode string literal feature that is available
now to greatly simplify the initialization of these special string
types. This makes them much more readable at a quick glance.
Change-Id: Iad8b49aa763486608e3bb7e83fb8abfb48ce0a7b
Windows will try to retrieve such a descriptor on first connect.
If the device returns STALL or a regular string descriptor (i.e.
not one that follows the Microsoft OS Descriptor spec), things
will continue normally.
Unfortunately some of our low-level USB drivers have issues with
STALL so any other valid descriptor is the next best solution.
Change-Id: I59eb09eea157e4e14bec0197a898be378a5559f2
Reviewed-on: http://gerrit.rockbox.org/680
Reviewed-by: Frank Gevaerts <frank@gevaerts.be>
Tested: Frank Gevaerts <frank@gevaerts.be>
disconnect() needs to be called exactly once per call to init_connection().
In case of bus resets, disconnect() was not called, which led to leaking
alloc_maximum() allocated buflib handles, which led to buflib running out
of memory to allocate.
Change-Id: I03025da578dc54e48b6de6bd3e3f40feae7220a6
Currently we don't know where the serial number is stored on the
stmp3600. It is probably using the laser fuses but this needs to
be investigated
Change-Id: I1ac25e38b8f65635abb68788ceb65df0a740dabd
Some USB controllers like the one of the Rockchip 27xx handle some
requests in pure hardware. This is especially a problem for two
of them:
- SET ADDR which is used by our core to track the DEFAULT/ADDRESS
state and is required for the drivers to work properly
- SET CONFIG which is used by our core to initialise the drivers
by calling init_connection()
In these cases we need a way to notify the core that such requests
happened.
We do this by exporting two functions which directly notify the
core about these requests and perform the necessary init steps
required without doing the actual USB transfers. Special care is
needed because these functions could be called from an interrupt
handler. For this reason we still use the usb_queue and introduce
new IDs so that they are processed in order and safely.
No functional change is intended, both in the usbstack and on
targets without such quirks.
Change-Id: Ie42feffd4584e88bf37cff018b627f333dca1140
Compute a serial number using the ocotp OPS bits like the OF.
Also add a comment about the first character of serial number
being a indicator of the enabled interfaces.
Change-Id: I9b90aed4e3b803f12fec003c9bc8ee8a046f4e42
FreeBSD apparently sends a SET_ADDRESS first, which confused our code.
This patch fixes that, and also simplifies the connection handling a bit.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31582 a1c6a512-1295-4272-9138-f99709370657
Enable support for the "force" mode of USB charging. This should work on Gigabeat S and Nano2g (and any other future target which has a RB usb stack and supports charging) - if a host connection is not detected within 10 seconds of USB insertion, assume that the connected device is an AC charger and charge anyway, if the user has specified "force" as the mode.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26594 a1c6a512-1295-4272-9138-f99709370657
1) "Charge during USB connection" option is now tristate: off/on/force. Currently "force" behaves just like "on", but in future it will allow charging even when it was not possible to positively identify a charger.
2) The H300 code has been adjusted to use the new system but there should be no functional differences, it already had the USB charging option and its USB/charging support is hardware controlled.
3) The Gigabeat S code has been adjusted to use the new system: the player now has the USB charging option, which wasn't previously available. The player will only charge at full speed when allowed to do so by a working USB host, so USB AC adapters won't work very well; however, they didn't work before either, so this is not a change in functionality.
4) The iPod Nano 2G code has been adjusted to use the new system: it already had the USB charging option. Using a USB AC adapter won't charge at full speed any more (it did before) - the old implementation was equivalent to the not-yet-implemented "force" option in the new system.
No other target should be affected. Support for the "force" mode and support for at least some other iPod models will come in a future commit :)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26570 a1c6a512-1295-4272-9138-f99709370657
- Interface number is in lower half of wIndex for interface control requests. Upper half is reserved and used in other protocols.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@25618 a1c6a512-1295-4272-9138-f99709370657
- Only interpret standard endpoint requests (previous code didn't check the request type) and pass all others to usb drivers.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@25069 a1c6a512-1295-4272-9138-f99709370657
Also enable HID, and use that as the dummy class instead of charging-only for controllers that have working interrupt transfers.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21053 a1c6a512-1295-4272-9138-f99709370657
This needs support for usb interrupt transfers, so there are some changes in various USB drivers as well (only usb-drv-arc supports it at this point, others won't have working HID yet).
HID is disabled for now, as the apps/ part is not included yet.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@20962 a1c6a512-1295-4272-9138-f99709370657
