summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove AMRR/MiRA support from iwx(4). Tx rate selection happens in firmware.stsp2020-06-222-146/+13
|
* Remove unused code for parsing non-volatile memory (NVM) from iwx(4).stsp2020-06-223-465/+5
|
* Some connectors attach late when the drm driver is registers. Forkettenis2020-06-221-17/+37
| | | | | | | | | | | | that reason we have to delay attaching Backlight properties to those connectors until after drm driver registration. However the drm midlayer code now warns about attaching new properties to connectors after driver registration. So add some workarounds to suppress these warning messages. Figured out by jcs@ ok jsg@, jcs@
* apart from the lock wait_queue_head struct is unused so replace itjsg2020-06-221-25/+25
|
* don't try to decrement if completion flag is UINT_MAXjsg2020-06-221-6/+11
|
* drm/amdgpu: Sync with VM root BO when switching VM to CPU update modejsg2020-06-221-2/+9
| | | | | | From Felix Kuehling 8db9696c1fdfa3d80e29ee80d002f315e4e344a9 in linux 5.7.y/5.7.5 90ca78deb004abe75b5024968a199acb96bb70f9 in mainline linux
* drm/amd/powerpay: Disable gfxoff when setting manual mode on picasso and ravenjsg2020-06-221-0/+9
| | | | | | From chen gong 4e88ff94dd359871f609da9f430712fcf7025164 in linux 5.7.y/5.7.5 cbd2d08c7463e78d625a69e9db27ad3004cbbd99 in mainline linux
* drm/amd/display: Do not disable pipe split if mode is not supportedjsg2020-06-221-2/+7
| | | | | | From Sung Lee dbf0a8fce6a9c867c315a400176f9f0e3a963d1e in linux 5.7.y/5.7.5 1dfedb39d38f813357885e19badd1971c17f79a7 in mainline linux
* drm/amd/display: dmcu wait loop calculation is incorrect in RVjsg2020-06-221-3/+0
| | | | | | From Paul Hsieh 11bce5915166fd50a395716755db8c6a3d3f2eb0 in linux 5.7.y/5.7.5 7fc5c319efceaed1a23b7ef35c333553ce39fecf in mainline linux
* drm/amd/display: Correct updating logic of dcn21's pipe VM flagsjsg2020-06-221-5/+1
| | | | | | From Dale Zhao 21b7c6033823d3888a195a24271cbea34279dd62 in linux 5.7.y/5.7.5 2a28fe92220a116735ef45939b7edcfee83cc6b0 in mainline linux
* drm/amd/display: Revert to old formula in set_vtg_paramsjsg2020-06-221-2/+4
| | | | | | From Alvin Lee 719bdc4363637fa45b67c80259c6a72967cb4947 in linux 5.7.y/5.7.5 a1a0e61f3c43c610f0a3c109348c14ce930c1977 in mainline linux
* drm/dp: Lenovo X13 Yoga OLED panel brightness fixjsg2020-06-221-0/+1
| | | | | | From Mark Pearson b846c5c78cf6365adf3b32645db39009c4710a2c in linux 5.7.y/5.7.5 0df3ff451287d71c620384eb7bb2cd3a8106412c in mainline linux
* drm/amdgpu: Init data to avoid oops while reading pp_num_states.jsg2020-06-221-1/+4
| | | | | | From limingyu 4ceae1cf8ca686b64a68822677ef0fb69a917c4e in linux 5.7.y/5.7.5 6f81b2d047c59eb77cd04795a44245d6a52cdaec in mainline linux
* drm/amd/display: fix virtual signal dsc setupjsg2020-06-221-1/+1
| | | | | | From Dmytro Laktyushkin b5d74af308d373668ec2d8f0f0a490207fcc5eda in linux 5.7.y/5.7.5 d5bef51f084fccafa984b114ff74a01a64a0e2e3 in mainline linux
* drm/amd/display: Force watermark value propagationjsg2020-06-222-1/+6
| | | | | | From Joshua Aberback 3a16e9862faff68edb43c1ec3112d62f6a391037 in linux 5.7.y/5.7.5 868149c9a072cbdc22a73ce25a487f9fbfa171ef in mainline linux
* drm/amdgpu: fix and cleanup amdgpu_gem_object_close v4jsg2020-06-221-18/+25
| | | | | | From Christian Koenig ba90bed3ea632a6cff527dea080336666f36ab2b in linux 5.7.y/5.7.5 82c416b13cb7d22b96ec0888b296a48dff8a09eb in mainline linux
* gup: document and work around "COW can break either way" issuejsg2020-06-221-0/+8
| | | | | | From Linus Torvalds 8e45fdafdecc8436c5b6e1620c30726056e6b29c in linux 5.7.y/5.7.3 17839856fd588f4ab6b789f482ed3ffd7c403e1f in mainline linux
* Fix two iwx(4) TX_CMD_OFFLD macros.stsp2020-06-221-3/+3
| | | | | | | | | | | | | The IP_HDR and MH_SIZE fields represent byte offsets into the frame, rather than flags. Make these macros require a parameter to prevent them from being misunderstood as flag bits. In iwlwifi these are defined via an enum, with most values being used as parameters to BIT(). Yet these IP and MH ones are actually used to shift length values to particular positions within the offloading parameters of the Tx command. Fortunately, these macros aren't used yet in our version of the driver.
* Prepare for newer iwx(4) firmware scan command versions.stsp2020-06-222-9/+72
| | | | | | | | | Add declarations of "version 2" scan flags from iwlwifi and prepare the iwx_scan_channel_cfg_umac struct for life beyond version 1. None of this is needed yet. But we will need this at some point and I've already written the diff, hoping it would prevent firmware errors (which of course it didn't).
* Update definition of the iwx_ac_to_tx_fifo map.stsp2020-06-221-5/+5
| | | | | | Compared to iwm(4) devices the BE and BK fifo numbers have been swapped in iwx(4) hardware. This has no real consequences for us since we send all frames at the same access category, but I'm fixing the mapping anyway.
* Enable critical temperature detection in iwx(4) firmware.stsp2020-06-222-2/+71
| | | | | | The driver will turn the device off and print a message to dmesg if the firmware signals critical temperature. It looks like the firmware will also make use of a Tx-backoff mechanism to regulate device temperature.
* Do not copy an SSID into the iwx(4) probe request template.stsp2020-06-221-2/+4
| | | | | | | | Firmware will add SSIDs specified via the scan command to its probe requests. There is no need to copy an SSID into the template. This code path is not used yet because active scanning mode is still disabled in this driver.
* Fix unconditional write to v1.scan_priority in iwx(4) scan command.stsp2020-06-221-2/+3
| | | | | | | | | | The data structure for the scan command contains a union which represents various versions of the scan command. The driver wrote to the scan_priority field in version 1 data regardless of the scan command version actually expected by firmware. Perform that write only for scan command version 1, as intended. Testing suggests that this prevents occasional firmware errors during scans.
* Fix length specification for 2GHz band IE data in iwx(4) probe requeststsp2020-06-221-2/+2
| | | | | | | | | template. This code path is not used yet because active scanning mode is still disabled in this driver. ok kn@
* in wait_for_completion_* return 0 on timeout -ERESTARTSYS on signaljsg2020-06-221-14/+11
| | | | matches how the interfaces are documented
* let userland read vpd info from a pci device.dlg2020-06-221-4/+35
| | | | | | | | | | | | | | | | | | | reading vpd stuff is useful when you're trying to get support information about a pci device, eg, if you want a serial number, or firmware versions, or specific part name or number, it's likely available via vpd. also, im sick of having the diff in my tree. the vpd info is not accessed as bytes read from a capability, but is read via a register in the capability. the same register also supports updating or writing vpd info, which sounds like a bad idea to let userland have raw access to. this adds an ioctl so that userland can ask the kernel to read via the vpd register on its behalf. this ensures that the only access is read access, and it's sanity checked. tested by hrvoje popovski on many devices. ok jmatthew@
* use ifiq_input and use it's return value to apply backpressure to rxrs.dlg2020-06-2211-26/+46
| | | | this is a step toward deprecating softclock based livelock detection.
* correct mutex_lock_interruptible()jsg2020-06-211-2/+9
| | | | | | | | | | | | Linux kernel code often passes errors around as negative numbers cast to pointers. As rw_enter() returns a errno on failure mutex_lock_interruptible() negated the return value. But this did not account for ERESTART being -1 which would return 1 to the caller. sthen@ periodically hit a uvm_fault() in i915_request_create() which was caused by attempting to use 1 as a pointer. ok kettenis@
* The onboard interfaces on T7/S7 machines don't provide a valid MAC addressjmatthew2020-06-211-1/+11
| | | | | | | for themselves, so use the "local-mac-address" Open Firmware property instead, as done in ix(4). ok dlg@
* Make FUNCTION()/UNIT() return valid major/minor device numbers ratherkrw2020-06-201-3/+4
| | | | | | | | | | | | than always returning 0. bktr0..bktr15 should now 'work'. COVERITY 1452865 COVERITY 1452956 COVERITY 1453025 COVERITY 1453186 COVERITY 1453231 ian@'s bktr still works as well as it did before.
* make zeroing fb mem conditional matching linux pathjsg2020-06-201-1/+2
| | | | ok kettenis@
* Make iwx(4) reset Tx byte count table slots for frames that are done.stsp2020-06-191-5/+11
| | | | | | | | | | | This fixes a "fatal firmware error" at run-time. Thanks again to Sara Sharon who provided the hint that the error trace I was looking at indicated that the firmware was running into a problem while trying to flush its Tx queues, and that this could be related to the Tx byte count table not being maintained properly. Tested by sven falempin and myself.
* Add WPA2 (CCMP) crypto offload support to iwx(4).stsp2020-06-192-25/+216
| | | | | | | | | | | | | | | | | | | | | | | | Much thanks to Sara Sharon who helped me by providing hints about new firmware behaviour. Contrary to older iwn(4) and iwm(4) devices, key material is no longer part of the Tx command. Instead, firmware will encrypt outgoing traffic as soon as the station associated with a Tx queue has an encryption key configured. Each Tx queue is created with an associated station ID (which in our case is a constant and represents the AP) and a traffic identifier (TID). The driver was configuring data Tx queues with the "management TID". This magic TID value bypasses hardware encryption and resulted in plaintext frames being sent while received frames were decrypted as expected since the station had a key. This behaviour looked rather strange and was difficult for me to debug. The clues which Sara provided led to the solution: iwx(4) must configure data Tx queues with the "non-QOS TID" in order to allow for encryption in the firmware's data Tx path. The rest of the offload mechanism works as it did on iwn(4) and iwm(4). Tested by sven falempin and myself.
* reduce the diff to linuxjsg2020-06-192-4/+2
|
* BCM5719 A1 seen in the wild.kettenis2020-06-182-2/+4
| | | | dlg@, deraadt@, mpi@
* Remove the bus specific sc_ih (interrup handle) variable and use the commonclaudio2020-06-171-7/+6
| | | | | | sc_ih value of struct rl_softc. This fixes a crash in re(4) because intr_barrier(9) is called with the rl_softc sc_ih which was NULL. OK kettenis@
* Let iwx(4) firmware decide which Tx rate to use.stsp2020-06-172-7/+309
| | | | | | | | | | | | The firmware will notify the driver when it decides to change Tx rate. Based on those notifications the driver updates the value displayed by ifconfig. This is similar to how bwfm(4) and urtwn(4) handle this. Offloading Tx rate selection should allow us to eventually delete AMRR/MiRA support code from iwx(4). That code is disabled for now, not yet deleted. For now, the driver restricts firmware Tx rate selection to 11n/20MHz mode because that's what net80211 can support.
* if the chip did rss, use the hash from the chip as an mbuf flowid.dlg2020-06-172-2/+8
| | | | another sniped commit from jmatthew@
* make ph_flowid in mbufs 16bits by storing whether it's set in csum_flags.dlg2020-06-171-3/+3
| | | | | i've been wanting to do this for a while, and now that we've got stoeplitz and it gives us 16 bits, it seems like the right time.
* enable multiple queues (and interrupts on multiple cpus) on vmx(4).dlg2020-06-172-33/+53
| | | | | | | | | | | | | | | | | | | | | im doing this with vmx(4) because it only exists on two archs (well, one and a half archs really) so any impact is localised. most other drivers i'm working on are enabled on 3 or 4 archs, and we're still working on the interrupt code on those archs. in the meantime vmx(4) can be used as a reference driver on how to implement multiq. it shows the use of rss, toeplitz, intrmap, and interrupts on multiple cpus. it's also a relatively simple device, which makes it easier to understand the above features. note that vmx(4) seems to advertise 25 msi-x vectors. it appears that the intention is that 16 of these vectors are supposed to be used for rx, 8 for tx, and 1 for events (eg, link up and down). we're keeping things simple for now and using a maximum of 8 vectors for both tx and rx, and one for events. this is mostly based on work that jmatthew@ did, but it's simplified now cos intrmap makes things easier.
* use atomic_set() in kref_init()jsg2020-06-171-2/+2
|
* kref_sub() interface was removed from linux and is unusedjsg2020-06-171-8/+1
|
* add pci_intr_msix_count(), to get the msi-x table size for a device.dlg2020-06-172-3/+22
| | | | | | | | | | | | this basically tells us the number of interrupt vectors a pci device is able to support. it relies on the arch having __HAVE_PCI_MSIX defined. without that define it always returns 0. i think this originally came from haesbart via patrick@ as amd64 md code in the middle of a diff from 2018(!), but i've tweaked it to make it MI. tested on sparc64 and amd64 with various drivers.
* use WRITE_ONCE and READ_ONCE for set and readjsg2020-06-171-6/+6
| | | | ok kettenis@
* Do not do logical negation of a bitshifted field.mortimer2020-06-171-2/+2
| | | | | | Prompted by warning from clang 10. ok patrick@
* remove some unused definesjsg2020-06-161-14/+6
|
* implement atomic_inc_not_zero() by way of atomic_add_unless()jsg2020-06-161-11/+3
|
* remove a dead storejsg2020-06-161-2/+2
|
* configure toeplitz using the kernel stoeplitz key if needed.dlg2020-06-162-3/+32
| | | | | | | | "if needed" basically means if more than 1 queue is set up, then set up rss. again, i think jmatthew@ wrote most of this, but im sniping it cos of the stoeplitz integration.
* show the structure for the rss configuration.dlg2020-06-161-1/+20
| | | | | i can't remember writing this, i think jmatthew@ did it, but im sniping the commit. sorry jmatthew@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.