| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
ok sthen@
|
|
|
|
|
|
|
|
|
| |
The report descriptors specify an invalid button count for models
with 6 or 8 buttons.
Thanks to Sivaram Gowkanapal, who provided the core of this patch.
ok mpi@
|
|
|
|
|
|
|
|
| |
The node here is always ic_bss, for which the reference count isn't
actually used (it's always freed when the interface detaches), so
not releasing it in this case wasn't really a problem.
ok stsp@
|
|
|
|
|
|
|
| |
To maintain the correct refs count, blocking calls to uaudio are
wrapped in usbd_ref_incr() and usbd_ref_decr() calls.
suggested by mpi@ and ok visa@
|
|
|
|
|
|
|
|
| |
dormant in the driver for years, we just needed to insert the IV before
transmission and do packet number checks on received frames.
tested by kevlo@ solene@ benno@ and me on a variety of hardware
ok kevlo@ stsp@
|
|
|
|
|
|
| |
sleep in the stop routine in case of errors.
Fix proposed by mpi@, ok patrick@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include sys/proc.h to address following errors:
/usr/src/sys/dev/usb/uvideo.c:2901:31: error: incomplete definition of type 'struct proc'
vn_close(nd.ni_vp, FWRITE, p->p_ucred, p);
~^
/usr/src/sys/sys/types.h:223:8: note: forward declaration of 'struct proc'
struct proc;
^
/usr/src/sys/dev/usb/uvideo.c:2925:40: error: incomplete definition of type 'struct proc'
UIO_SYSSPACE, IO_APPEND|IO_UNIT, p->p_ucred, NULL, p);
~^
/usr/src/sys/sys/types.h:223:8: note: forward declaration of 'struct proc'
struct proc;
^
2 errors generated.
ok mpi@
|
|
|
|
|
|
| |
conversion steps). it only contains kernel prototypes for 4 interfaces,
all of which legitimately belong in sys/systm.h, which are already included
by all enqueue_randomness() users.
|
|
|
|
| |
from Tero Koskinen
|
| |
|
|
|
|
| |
from Tero Koskinen
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
miod explained it was initially a long as it was thought drivers may
need to allocate storage but in practice they don't need more than
32 bits for an attribute.
suggested and reviewed by miod@
|
|
|
|
|
|
|
|
| |
Suggested by John Carmack. miod agrees a rename would make sense and
explained it was initially thought drivers may need to allocate storage
but in practice they don't need more than 32 bits for an attribute.
ok mpi@
|
|
|
|
| |
ok visa@
|
|
|
|
|
|
| |
Fixes coverity CID 1492830.
ok sthen, deraadt
|
|
|
|
| |
go for it deraadt@
|
|
|
|
|
|
| |
Besides making things simpler, this allows libsndio to figure out that
this is a control affecting all inputs (outputs) that needs to be
exposed.
|
|
|
|
|
|
|
| |
There's no reliable way to decide whether a control must belong
to "inputs" or to "record". In other words both classes were
used for the same thing. Furthermore we've no "play" class which
tends to make things more confusing.
|
|
|
|
|
| |
All other drivers use "dac" and libsndio needs the control name to
be "dac" for the control to be exposed.
|
|
|
|
|
| |
Makes the code simpler and more flexible as the naming is done in a
single place where the full units list is available.
|
|
|
|
| |
No object change.
|
|
|
|
| |
Input from sthen@, ok claudio@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces CPU load during traffic bursts, which is especially noticeable
on boards with relatively slow CPUs such as Alix and APU. For reference,
my rcc-ve boards (Intel Atom C2558) now forward ~2000pps between Ethernet
and wifi with <= 1% CPU interrupt time according to systat. Beforehand, these
boards became noticeably less responsive with fairly high interrupt and spin %.
CCMP offload is used on both PCI and USB devices (thanks kevlo@ for catching
my omission of USB devices in the first iteration of this change!)
Tested by (at least) Kevin Chadwick, tracey@, kevlo@, kili@, Ted Patterson,
David Dahlberg, and Scott Bennett.
ok tracey@ kevlo@
|
|
|
|
|
|
| |
Hardware may expose per-channel controls and equivalent ones affecting
all channels, which is redundant. In this case expose only the
per-channel ones as they are more flexible.
|
|
|
|
|
|
|
|
|
| |
The audio(9) mixer API can't represent such per-channel controls with
a single entry, so we've to expose one mixer entry (with an unique
name) per control.
Fixes name clashes on usb audio devices with per-channel mute
controls.
|
|
|
|
|
|
|
|
| |
ethernet aliase paths in the new omap device trees are longer than 64
characters. Fixes the MAC address on Pandaboard-ES with the new
device tree.
ok jsg@
|
|
|
|
|
|
| |
for example, with locking assertions.
OK mpi@, anton@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stack into the USB controller driver, since not all of the xfers
actually use DMA and some invalidations might even be harmful.
The important part is to sync before handing the buffer to the
controller, and to sync on a successful transfer before handing
it back to the USB stack. For isoc transfers it's easier to sync
the complete length of the transfer, since the buffer to flush is
not filled in a contiguous fashion.
For dwc2 there's a common point which takes care of the start
of transfers from or to devices, where we can make sure that our
buffers are synced. On completion, there's a common point before
handing it off to the USB stack.
For ehci there are three places which take care of the start
of transfers from or to devices, where one already does the sync,
while the two other places still need the sync. There are two
completion handler (isoc and non-isoc), where one already has a
comment asking for the need of a sync. The done handler for intr
xfers does a sync that is not needed anymore after adding the sync
in the completion handler.
For ohci there are three places which take care of the start
of transfers from or to devices, where all of them were still in
need of the sync. For completion, there is one place for isoc
xfers and two places for handling successful generic xfers.
For uhci there are two places which take care of the start
of transfers from or to device, where all of them were still in
need of the sync. For completion, there is one handler for both
isoc and non-isoc xfers where syncs need to occur.
For xhci there are three places which take care of the start
of transfers from or to device, where all of them were still in
need of the sync. For completion, there is one handler for isoc
and one for non-isoc xfers where syncs need to occur.
With this we can revert the workaround that implicitly allocated
buffers are COHERENT, since now control transfers fulfilled by the
driver code (instead of the controller doing DMA) are not flushed
into oblivion anymore.
Tested by Janne Johansson with dwc2 (octeon)
Tested by kettenis@ with xhci(4) (octeon)
Tested by patrick@ with ehci(4) on a Cubox-i (armv7)
Tested by patrick@ with xhci(4) on an i.MX8MQ (arm64)
Tested by tobhe@ with dwc2 on a rPi 3b (arm64)
ok kettenis@
|
|
|
|
|
|
|
|
| |
EOPNOTSUPP is returned when there's no "filterops" for a given fd.
EINVAL when the requested filter isn't supported by the "filterops".
ENXIO means the underlying device is no longer valid/present.
ok visa@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a transmit error occurs in zyd_tx() we must reset tx data's ni pointer
to NULL since the node reference will be released in zyd_start().
A stale node pointer could potentially be released again which would mess
up the node's reference count and potentially result in a use-after-free.
Upon detach, ic->ic_bss was freed in ieee80211_ifdetach(), and afterwards
ic->ic_bss->ni_refcnt was decremented in zyd_free_tx_list(). Change the
order of operations during detach to prevent this use-after-free.
Reported on bugs@ by Raf Czlonka
ok mpi@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices we have proper DMA transfers, so that the DMA syncs before and
after transfers are necessary. For the root hub, we seem to fulfill
those requests ourselves, e.g. by using memcpy. The POSTREAD DMA sync
on a read will invalidate the caches for the buffer, and unless our root
hub code explicitly flushed the data to memory, it's possible that our
memcpy got removed from history.
Until a better solution is implemented, like moving the DMA syncs from
the USB subsystem into the controller driver, allocate all buffers that
are not explicitly allocated using USB_DMA_COHERENT. The IO buffers
continue to be allocated as non-coherent.
Regression found by jsg@
ok kettenis@
|
|
|
|
| |
CID 980279
|
|
|
|
|
|
|
| |
fail early in uaudio(4). This prevents negative safe_blksz and
integer overflow in nframes_max in case of a bad call to
uaudio_stream_open() or a hardware bug.
OK ratchov@
|
|
|
|
|
|
|
|
| |
playing, the uaudio(4) driver selected a wrong rate. Then recording
failed with "block size too large". The v1_rates field of the
parameters contains the correct intersection of valid rates. Use
it for v1 devices.
OK ratchov@
|
|
|
|
|
|
|
| |
filled by the callee, change the usb_allocmem() API to take another
argument for the flags.
ok mpi@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the import in '99 all buffers allocated using usb_allocmem() have
been mapped COHERENT. On some ARM SoCs, where the USB controller
is not coherent with the caches, this means the buffers were mapped
uncached. This drastically reduces the performance, especially on
reads.
We already added cache syncs before and after USB transfers, but so
far those have essentially been no-ops. Since other drivers make
use of the same allocation code, and those haven't been proven to
have correct syncs, we can't just remove the COHERENT flag.
This splits the allocation into coherent and non-coherent blocks.
All drivers who call usb_allocmem() themselves now pass a flag to
show they require coherent blocks. Onced verified that they also
work fine without coherent, or once they have been refactored, we
can remove this again.
On a ure(4) connected to an i.MX8MQ, the receive performance is
10x as fast as before. The Raspberry Pi's ethernet receive speed
doubled.
Debugged using dt(4)
Original diff from Marius Strobl
Feedback from kettenis@
Tested on an i.MX8MQ (arm64) by patrick@
Tested on a Raspberry Pi (arm64) by tobhe@
Tested on an ERL (octeon) by Janne Johansson
ok mpi@ gerhard@ tobhe@
|
|
|
|
|
|
| |
CID 1453258
ok kettenis@
|
|
|
|
|
|
|
|
|
|
| |
when no IO endpoints were found. Coverity CID 1453263, 1453156
Check return value of usbd_interface2endpoint_descriptor() in
alloc_all_endpoints_yamaha() as it may return NULL which ends up being
dereferenced by the UE_GET_XFERTYPE() macro. Coverity CID 271356
ok ratchov@
|
|
|
|
| |
CID 1453335.
|
|
|
|
|
|
|
|
| |
right after err is set.
Coverity CID 975917
ok kettenis@ kn@
|
| |
|
|
|
|
| |
Tested by David Demelier
|
|
|
|
|
|
|
|
| |
when the port is initialized (with a tcsetattr() call) but not on every
changed of DTR (especially those caused by other tty ioctls).
Fixes firmware upload on various microcontroller boards that use DTR and
RTS as signaling lines to reset the device and enter the bootloader.
Tested by tracey@, OK deraadt@
|
|
|
|
|
|
|
|
| |
USB audio devices with empty AC descriptor (i.e. emtpy devices) don't
exist as they would be of no use. So this fix is mostly to properly
skip broken hardware.
Found by coverity.
|
|
|
|
|
|
|
|
|
| |
This corrects computation of xfer->actlen, allowing xhci(4) to work
again on octeon and other big endian architectures.
Reported by Allen Smith
OK patrick@
|