Age | Commit message (Collapse) | Author |
|
From Zheyu Ma
5c3d753b872a706af9317fef4edfb6b640d8a71e in linux 5.10.y/5.10.55
9e5c772954406829e928dbe59891d08938ead04b in mainline linux
|
|
framebuffer when Backspace is typed.
Reading data from LUNA framebuffer's 'common write plane' is not
valid. But on 1bpp framebuffer routine attempts to read from common
write plane in macro. That causes displaying incorrect patterns.
This bug was found on nono's LUNA-88K emulation first, then inspected
on the real hardware after I fortunately got 1bpp framebuffer.
Spotted and investigated by Isaki and Sugahara of nono procject.
Tested on my LUNA-88K2.
|
|
|
|
e.g. uvideo(4) with lower resolutions.
In general we might need to re-write parts of the nframes handling in the
driver, since the NetBSD nframes transfer allocation doesn't match with our
USB stack.
With this we can at least start further testing and improvement for ISOC
support.
|
|
Starting with major version 35 the Linux driver prints the minor version
number in hexadecimal.
Same change was made for iwm(4) in CVS commit LCM6R5u9jeF8bcXB
|
|
This allocation was left over from code inherited from iwm(4) where
it is used for transferring firmware code to the device. Devices
supported by iwx(4) use an entirely different mechanism for loading
firmware and don't need this allocation at all.
Based on a patch by zxystd from the OpenIntelWireless project.
|
|
clobber in the inline assembly.
|
|
|
|
recently updated code. There, sync the hardware specific parts with the
NetBSD driver.
|
|
|
|
|
|
These images contain fixes which address fragattacks vulnerabilities:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
Running fw_update(1) may be required before rebooting into a new kernel.
sysupgrade(8) will take care of this.
When reporting issues, please enable 'ifconfig iwx0 debug', reproduce the
error once more, and include the full dmesg in your bug report.
Tested:
ax200: stsp, kevlo, hrvoje, jmc, Mark Patruck, Ashton Fagg
ax201: kettenis, Fredrik Engberg, Eric Auge
ok kevlo@
|
|
New firmware will generate this notification when a block ack request is
received. Older firmware passed the block ack request frame to the driver.
ok kevlo@
|
|
ADD_STA command version >= 12 implies that firmware uses an internal AUX
station for scanning. We do not configure an AUX Tx queue in this case
and data queue indices assigned by firmware shift upwards accordingly.
ok kevlo@
|
|
This command was expanded by a 4 byte max_tx_op field. As far as I can tell
the Linux driver makes no use of this field, so just initialize it to zero.
New firmware panics when we try to initialize Tx rate scaling otherwise.
ok kevlo@
|
|
Required for having associations succeed with new firmware.
ok kevlo@
|
|
ok kevlo@
|
|
ok kevlo@
|
|
ok kevlo@
|
|
ADD_STA command version >= 12 implies that firmware uses an internal
AUX station for scanning, and firmware panics if we try to add one.
ok kevlo@
|
|
This is related to the previous commit which fixed "BAD COMMAND" firmware
errors. We can no longer use old-style "narrow" commands on the command
queue with new firmware, and our current -48 firmware images don't seem
to care either way. We can simplify this code and align it with iwlwifi.
ok kevlo@
|
|
Firmware API versions >= 50 reject old-style commands in group 0 with a
"BAD_COMMAND" firmware error. We must pretend that such commands were in
the LONG_GROUP instead in order for firmware to accept them.
ok kevlo@
|
|
ok kevlo@
|
|
firmware images. For now, we can simply ignore them while loading firmware.
ok kevlo@
|
|
ok kevlo@
|
|
and microcode sections. Required for loading new firmware images.
ok kevlo@
|
|
ok kevlo@
|
|
as boot interface when doing netboot. This makes auto install/upgrade work.
ok kettenis@ visa@
|
|
From Colin Xu
1df4fe5a8871f49d34d681ff5b7f93a84d50af4b in linux 5.10.y/5.10.54
c90b4503ccf42d9d367e843c223df44aa550e82a in mainline linux
|
|
From Likun Gao
fc31b5be1383e31ca046fdd6e11e0a9a0b3a01d5 in linux 5.10.y/5.10.54
3e94b5965e624f7e6d8dd18eb8f3bf2bb99ba30d in mainline linux
|
|
From Charles Baylis
69a603aa170e1c145b93d5d7efcca83a8b1268fe in linux 5.10.y/5.10.54
3abab27c322e0f2acf981595aa8040c9164dc9fb in mainline linux
|
|
earlier. So far we haven't noticed this, as we had the assumption that
all clocks are enabled anyway. On the NanoPi R4S this does not seem to
be the case, so we need to bring the clock enable code closer to the
other bringup code.
ok kettenis@
|
|
some of those clocks to be enabled.
Noticed on the NanoPi R4S, where the Ethernet controller clocks were
surprisingly turned off.
ok kettenis@
|
|
kmap_atomic_prot(). Use this to unstub ttm_copy_io_ttm_page()
and ttm_copy_ttm_io_page(). This fixes suspend/resume of machines
with certain radeondrm(4) hardware.
Based on a diff from jsg@. Tested by Edd Barrett and Alf Schlichting.
ok jsg@
|
|
ok kettenis@
|
|
ok kettenis@
|
|
of battery levels the device can report.
|
|
connected. Allows sensorsd(8) to pick up hotplugged devices.
Thanks to Laurence Tratt <laurie at tratt dot net> for the report.
|
|
I should have used Byte (unsigned char) which led to passing twice the
correct size to free.
Found & tested by bluhm with the sys/netinet/ipsec tests on i386.
|
|
Panic reported by Hrvoje Popovski.
|
|
* Introduce split transaction order queues.
* Improve the NAK interrupt handler routine.
* Mostly move from list_move() to list_move_tail().
Those changes fix an attachment problem seen for certain devices which
are issuing NAK interrupts during split transactions, which don't get
handled correctly by the driver today. This could result in unexpected
channel halting, printing "ChHltd set, but reason is unknown", which
finally leaves the device back on a disabled USB port.
ok kettenis@
|
|
With bluhm@'s diff for parallel forwarding pipex(4) could be accessed in
parallel through (*ifp->if_input)() -> ether_input() ->
pipex_pppoe_input(). PPPOE pipex(4) sessions are mostly immutable except
MPPE crypt.
The new per-session `pxs_mtx' mutex(9) used to protect session's
`ccp-id' which is incremented each time we send CCP reset-request.
The new `pxm_mtx' mutex(9) used to protect MPPE context. Each pipex(4)
session has two of them: one for the input and one for output path.
Where is no lock order limitations because those new mutex(9)'es never
held together.
ok bluhm@
|
|
tested on armv7 arm64 and amd64 (bootx64)
ok kettenis@ mpi@
|
|
This matches what Linux and FreeBSD do.
ok jmatthew@
|
|
'tdb_data' struct became unused and was removed.
ok bluhm@
|
|
|
|
task queues were unlimited and could overflow during havy traffic.
Even if we still use hardware drivers that sleep, softnet task
instead of soft interrupt can handle this now. Without queues net
lock is inherited and kernel lock is only needed once per packet.
This results in less lock contention and faster IPsec.
Also protect tdb drop counters with net lock and avoid a leak in
crypto dispatch error handling.
intense testing Hrvoje Popovski; OK mpi@
|
|
strict. ICMP error packets generated by pf were not passed
immediately, but could be blocked. Preserve PF_TAG_GENERATED flag
in icmp_reflect() and icmp6_reflect().
reported by sf@; OK patrick@ kn@
|
|
|
|
Stop decrementing ring->queued inside the if-statement which guards
maintenance of the OACTIVE flag. This is wrong and resulted in a negative
counter value (visible in firmware error traces). The counter is already
decremented in the loop above where frames are taken off the ring.
|