Age | Commit message (Collapse) | Author |
|
Most of the resume work is already done in the audio(4) layer, so, to
fix suspend/resume we just need to reinitize the device.
ok kettenis@
|
|
The allocm() functions are supposed to allocate memory and it's bad
style to access the hardware there, so move the DMA base pointers
setup to the trigger_xxx().
ok kettenis@
|
|
Going by changes in FreeBSD and Linux it is almost identical to pch_spt
but doesn't need one of the workarounds for a pch_spt specific errata.
|
|
The maximum number of commands may be specified in outbound scratch register
3, should be limited to 1024, and should further be reduced by one to ensure
the reply queue doesn't overflow.
The maximum number of sges in a command should be the highest power of two
that fits in the space available in the io frame and in a chained sge frame.
The maximum size of a chained frame is specified in outbound scratch
register 2.
part of a diff from Naoki Fukaumi
ok dlg@
|
|
part of a diff from Naoki Fukaumi
ok dlg@
|
|
commands later.
part of a diff from Naoki Fukaumi
ok dlg@
|
|
|
|
feedback and ok jsg@
|
|
From Kai-Heng Feng
5b7ed414974320d7ebda71d18c85f505f3d959c0 in linux 4.4.y/4.4.119
06998a756a3865817b87a129a7e5d5bb66dc1ec3 in mainline linux
|
|
From Harry Wentland
c088f7bc3310bb57e0aaea297c7e2f467015d215 in linux 4.4.y/4.4.94
6cecdf7a161d2b909dc7c8979176bbc4f0669968 in mainline linux
|
|
(I've had this diff locally for a long time on port build machines to
avoid NFS stalls.)
|
|
|
|
|
|
From FreeBSD.
|
|
|
|
|
|
|
|
Kills "iwm0: unhandled firmware response 0xff/0xb8000010 rx ring" dmesg spam.
Patch by jes@posteo via tech@, who found the corresponding change in Linux:
https://patchwork.kernel.org/patch/9869017/
|
|
linux and add back struct members.
Avoids diffs in inteldrm, libdrm and Mesa >= 17.2.
ok kettenis@
|
|
|
|
(Bristol Ridge, aka tweaked Carrizo) not to be confused with
Carrizo-L (16h apu).
ok jsg@, mlarkin@
|
|
Apparently this can cause a firmware crash during a TX command on 7265 devices.
Why this happens is unclear.
Problem reported and workaround tested by trondd on bugs@
I have verified that hidden SSID APs still work, though we won't be able to
seamlessly roam between them anymore. Seems like a fair trade-off for now.
|
|
The problem happened if we didn't find an AP to connect to after one scan
iteration. The net80211 stack then performs a SCAN -> SCAN transition to
kick off another scan, but the driver treated this transition as a no-op
and remained in SCAN state doing nothing.
To fix this, introduce a flag which keeps track of whether a firmware
scan command is in progress, and start another scan during a SCAN->SCAN
transition if no scan is in progress. Matches what iwm(4) does.
Note that previously (i.e. in 6.2), iwn(4) would always try to start
a new scan regardless of what the firmware was currently doing.
Problem noticed by myself and also by deraadt@
test & ok tb@
|
|
|
|
|
|
|
|
|
|
in passthrough IO requests, which makes AEN processing work on SAS2208
controllers, and since AEN processing works now, enable it again.
tested on SAS2208 (PERC H710P) and SAS3108 (PERC H730), SAS3.5 parts
should work too.
ok dlg@
|
|
The account flag `ASU' will no longer be set but that makes suser()
mpsafe since it no longer mess with a per-process field.
No objection from millert@, ok tedu@, bluhm@
|
|
ifq dequeue semantics. This basically means we need to check for
available space before dequeuing a packet. As soon as we dequeue
a packet we commit to it. On the PCIe backend this check can not
be done easily since the flowring depends on the packet contents and
we cannot take a peek. When there is no flowring we cache the mbuf
and send it out as soon as the flowring opened up. Then the ifq can
be restarted and traffic can flow. Typically we usually run out of
packet ids, which can be checked without consulting the packet. The
flowring probably never becomes full as the bwfm(4) firmware takes
the packets off the ring without actually sending them out.
Discussed with dlg@
|
|
function so it can be shared with the SDIO attachment driver.
|
|
should resolve mapping error on SAS3508 encountered by claudio@
ok jmatthew@
|
|
requested by ifconfig while associated. For completeness, do the same
for RUN->{ASSOC,AUTH} and AUTH->ASSOC transitions. i.e. always keep
the firmware's association state in sync with the driver's state.
The firmware should only be associated in RUN state.
Fixes a problem where the driver remained in SCAN state forever after
running 'ifconfig iwn0 scan' in associated (i.e. RUN) state, presumably
because the firmware didn't like the driver's scan command and never
signaled completion of the scan.
ok kevlo@ phessler@
|
|
transitions, which means those state transition won't be shown in dmesg
in interface debug mode. Make drivers print these transitions themselves.
ok patrick@
|
|
avoids -Wincompatible-pointer-types-discards-qualifiers build errors
with radeon_ucode.c
|
|
|
|
|
|
|
|
|
|
|
|
pci_set_power_state()
|
|
|
|
|
|
|
|
vga_switcheroo_fini_domain_pm_ops() stub.
|
|
|
|
|
|
|
|
-Wformat includes -Wformat-zero-length with gcc 4.2 which breaks
building unmodified atom.c with the SDEBUG macro
"warning: zero-length kprintf format string"
|
|
|