'BUS_PROBE_DEFAULT'. This allows bhyve's 'ppt' driver to claim ownership
of the device and pass it through to the guest.
In the common case where there are no competing drivers for USB controllers
this change is a no-op.
Reviewed by: hselasky
MFC after: 2 weeks
been done by U-Boot. This allows the USB to work when we load the kernel
directly.
No dma sync is performed after these operations as the data we read/write
is not used by the cpu after the calls to the maimbox driver.
Differential Revision: https://reviews.freebsd.org/D1940
Reviewed by: imp, Michal Meloun (meloun AT miracle.cz)
MFC after: 1 Week
Sponsored by: ABT Systems Ltd
when re-enumerating a FULL speed device. Else the wrong max packet
setting might be used when trying to re-enumerate a FULL speed device.
MFC after: 3 days
interrupt status bit. According to the UHCI controller specification
the host controller halted interrupt is non-maskable.
PR: 156596
Tested by: adrian @
MFC after: 1 week
that we should use a normal-TRB if there are more TRBs extending the
data-stage TRB. Add a dedicated state bit to the internal USB transfer
flags to handle this case.
Reported by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
MFC after: 1 week
every operation to retrieve the bs_cookie value almost nothing actually uses.
The bus_space struct contains a private data pointer (poorly named bs_cookie,
now renamed to bs_privdata) which is used only by a few old armv4 xscale
implementations. The bus_space functions were all defined to take this
value as the first parameter instead of the bus_space_tag_t, requiring all
the inline macro and function expansions to dereference the tag to pass it
to another function, which never uses it. Now all the functions take the tag
as the first parameter and retrieve the privdata if they need it.
Also fix a couple bus_space_unmap() implementations that were calling
kva_free() instead of pmap_unmapdev().
Discussed with: cognet
simultaneously detaching kernel drivers on the same USB device we can
get stuck in the "usb_wait_pending_ref_locked()" function because the
conditions needed for allowing detach are not met. The "destroy_dev()"
function waits for all system calls involving the given character
device to return. Character device system calls may lock the USB
enumeration lock, which is also held when "destroy_dev()" is
called. This can sometimes lead to a deadlock not noticed by
WITNESS. The current solution is to ensure the calling thread is the
only one holding the USB enumeration lock and prevent other threads
from getting refs while a USB device detach is ongoing. This turned
out not to be sufficient. To solve this deadlock we could use
"destroy_dev_sched()" to schedule the device destruction in the
background, but then we don't know when it is safe to free() the
private data of the character device. Instead a callback function is
executed by the USB explore process to kill off any leftover USB
character devices synchronously after the USB device explore code is
finished and the USB enumeration lock is no longer locked. This makes
porting easier and also ensures us that character devices must
eventually go away after a USB device detach.
While at it ensure that "flag_iserror" is only written when "priv_mtx"
is locked, which is protecting it.
MFC after: 5 days
scatter-gather XHCI TRB entries for its payload data. The XHCI
controller can handle at least 65536 bytes per scatter-gather list
entry.
MFC after: 1 week
Suggested by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
is called from "xhci_configure_reset_endpoint()". Ensure the 3-strikes
error feature is always enabled except for ISOCHRONOUS transfers.
MFC after: 1 week
Suggested by: marius@
- Simplify MSI allocation to what is actually needed for a single one.
- Release the MSI and the corresponding bus resource as appropriate when
either the interrupt resource cannot be allocated or setting up the
interrupt fails.
- Error out when interrupt allocation or setup fails and polling is
disabled.
- Release the MSI after the corresponding bus resource so the former is
not leaked on detach.
- Remove a redundant softc member.
MFC after: 3 days
re-using a hardware propritary transfer descriptor, PTD, in USB host
mode. If the PTD's are recycled too quickly, it has been observed that
the hardware simply fails to schedule the requested job or resets
completely disconnecting all devices.
SAF1761 OTG driver. Currently the driver logic is very simple and
double buffering the USB transactions is not done. Also you need to
use an external USB high speed USB HUB for reliable FULL speed
outgoing ISOCHRONOUS traffic, because the internal one chokes on
so-called split transfers above 188 bytes.
ports. The current bitmap array was too small to hold more than 16
bits and would at some point toggle the context size, which then would
trigger an enumeration fault and cause a fallback to the EHCI
companion controller, if any.
MFC after: 3 days
- Cleanup some register reads and writes to use existing register
access macros.
- Ensure code which only applies to the control endpoint is not run
for other endpoints in the data transfer path.
MFC after: 3 days
USB 2.0 port mask in addition to the USB 3.0 port mask. The hardware
does not always accept when writing -1U to the port switching
registers.
MFC after: 3 days
Tested by: Huang Wen Hui <huanghwh@gmail.com>
These changes prevent sysctl(8) from returning proper output,
such as:
1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.
Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
