summaryrefslogtreecommitdiffstats
path: root/sys/dev (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Clean up nonexistent/unused properties handlingkn2021-04-011-12/+1
| | | | | | | | | | Never used since import and probably just ported over from NetBSD as-is; "design-capacity" does not exist in the device tree binding. "monitor-interval-ms" defaults to 250ms as per binding and could be used in the sensor_task_register() call, but our framework only supports whole seconds and there's no advantage over our current fixed poll interval of 5s. OK patrick
* Hardcode meaningful alert level, track apm's battery state betterkn2021-04-011-23/+7
| | | | | | | | | | | | | | | | | | | | The current code looks for the nonexistent "cellwise,alert-level" property and falls back to zero as threshold (like the original NetBSD code). It also updates the CONFIG register with that very threshold to let the hardware set a bit and thus alert us when it has been reached. Since our sensor framework is designed to poll every N seconds and this driver does not actually look at whether the hardware alerted, neither using a default threshold of zero nor updating the hardware with it makes sense. Remove the alert level code and simply map >50%, >25% and <=25% of remaining battery life to apm(4)'s "high", "low" and "critical" battery state respectively; this matches exactly what acpibat(4) does and provides more meaningful sensor readings without relying on nonexistent device tree bindings. Feedback OK patrick
* Push kernel lock down to umb_rtrequest().mvs2021-04-011-1/+3
| | | | | | | | | | | | | | | We are going to unlock PF_ROUTE sockets. This means `if_rtrequest' handler will be performed without kernel lock. umb_rtrequest() calls umb_send_inet_proposal() which touches kernel lock protected `ipv{4,6}dns' array. Also umb_rtrequest() is the only handler which requires kernel lock to be held. So push the lock down to umb_rtrequest() instead of grab it around `if_rtrequest' call. This hunk was commited separately for decreases PF_ROUTE sockets unlocking diff. ok gerhard@ deraadt@
* syncsthen2021-03-312-54/+54
|
* Remove redundant "HUAWEI Mobile" in usbdevs strings, mention radiosthen2021-03-311-26/+26
| | | | technology where known. ok deraadt
* fix typos in commentssthen2021-03-301-3/+3
|
* Handle systems, such as the Dell Precision 3640, that accesskettenis2021-03-301-19/+87
| | | | | | | | | | GenericSerialBus operating regions witout checking whether they're really available. This needs to work on RAMDISK kernels as well. Since we don't want to pull in the i2c subsystem on those, provide a separate and much simpler dummy implementation of the GenericSerialBus access code when SMALL_KERNEL is defined. ok tb@
* Register the PCI variant of dwiic(4) with acpi(4).kettenis2021-03-301-2/+7
| | | | ok tb@
* Some cards announce support for the NTB16 format, but that support does notpatrick2021-03-303-41/+167
| | | | | | | | | | work. Hence, add support for NTB32 in the transmit path. We already have support for NTB32 in the receive path. We detect the supported format on boot and can then decide on transmit which format to use. From ehrhardt@ with gerhard@ Tested by jan@ ok sthen@
* Some umb(4) devices require the NDP pointer behind the NDP datagram.patrick2021-03-302-36/+59
| | | | | From gerhard@ "broadly OK" sthen@
* Move tx/rx descriptors into their own structs.kevlo2021-03-302-188/+509
| | | | | | | | | This is a first step toward making rge work with multiple queues and interrupts. Only one queue is currently used. While here, update the RTL8125B microcode. ok jmatthew@
* combine umb_products and umb_fccauth_devs into one umb_quirks tablesthen2021-03-291-36/+51
| | | | ok gerhard@
* Since ipw(4) doesn't call into net80211_newstate() the interface link statestsp2021-03-281-1/+13
| | | | | | | | | must be updated by the driver in order to get packets to flow. In case of WPA the link state was updated as a side-effect of a successful WPA handshake. This commit fixes the WEP and plaintext cases. Problem reported and fix tested by Riccardo Mottola.
* Add vid/pid table to umb(4) allowing matching to alternate configsthen2021-03-281-3/+64
| | | | | | | | | Some devices present multiple configurations and the one chosen by default is not always usable - for example, some have an CDC ECM config that does not work with our cdce(4) - allow overriding to a specific config in those cases. From gerhard@ with tweaks to comments by me, ok patrick@
* syncsthen2021-03-282-4/+14
|
* add pid for Dell DW5821e and HUAWEI ME906s LTE, ok patrick@sthen2021-03-281-1/+3
|
* Fix SDMMC_DEBUG buildkn2021-03-272-8/+8
| | | | | - Replace undefined SDMMCDEVNAME macro with usual DEVNAME from sdmmcvar.h - typofix struct member name
* trim the FCS off Ethernet packets before sending them up the stack.dlg2021-03-271-1/+8
| | | | | | | | | | | | | | | | | | Jurjen Oskam on tech@ found that ure in a veb caused these extra fcs bytes to be transmitted by other veb members. the extra bytes aren't a problem usually because our network stack ignores them if they're present, eg, the ip stack reads an ip packet length and trims bytes in an mbuf if there's more. bridge(4) masked this problem because it always parses IP packets going over the bridge and trims them like the IP stack before pushing them out another port. veb(4) generally just moves packets around based on the Ethernet header, by default it doesn't look too deeply into packets, which is why this issue popped out. it is more correct for ure to just not pass the fcs bytes up. ok jmatthew@ kevlo@
* Flag sensors as invalid on bogus readskn2021-03-261-3/+7
| | | | | | | | | | | | | | | | | Follow-up to the previous commit: This driver continues to report stale hw.sensors values when reading them fails, which can easily be observed on a Pinebook Pro after plugging in the AC cable, causing the hw.sensors.cwfg0.raw0 (battery remaining minutes) value to jump considerably one or two times before stalling and becoming incoherent with the rest. Flag sensors invalid upfront in apm's fashion and mark them OK iff they yield valid values; this is what other drivers such as rktemp(4) do, but the consequence/intention of SENSOR_FINVALID is sysctl(8) and systat(8) skipping such sensors (until AC gets plugged off again). OK patrick
* Initialize error variable in dtread().bluhm2021-03-261-2/+2
| | | | OK mpi@
* regenjan2021-03-261-1/+5
|
* Add PCI ID for Intel X710 10G SFP+ NICjan2021-03-261-1/+2
| | | | ok patrick@
* regenjan2021-03-261-1/+2
|
* Add missing PCI ID for Intel X710 SFP+ NICjan2021-03-261-1/+2
| | | | ok patrick@
* Provide apm(4/arm64) with battery informationkn2021-03-251-1/+41
| | | | | | | | | | | | | | | | | | | | | | apm merely provides an all zero/unknown stub for those values, e.g. apm(8) output is useless. Hardware sensors however provide this information: hw.sensors.cwfg0.volt0=3.76 VDC (battery voltage) hw.sensors.cwfg0.raw0=259 (battery remaining minutes) hw.sensors.cwfg0.percent0=58.00% (battery percent) Make cwfg(4) copy those over using apm_setinfohook() for apm to show it: Battery state: high, 58% remaining, 259 minutes life estimate A/C adapter state: not known Performance adjustment mode: auto (408 MHz) In cwfg's update routine, to keep values coherent, always reset them to zero/unknown and only set those that came from a valid reading. Input OK jca
* syncsthen2021-03-242-6/+6
|
* remove vendor name (Dell) repeated in product namesthen2021-03-241-2/+2
|
* Improve the tap detection mechanism.bru2021-03-241-12/+21
| | | | | | | | | Revision 1.29 of wstpad.c has removed the 'maxdist' checks for multi-finger taps. While this change makes tap detection more reliable, and does not affect inputs intended for pointer movement, it might interfere with short scroll gestures. This version reorganizes the filtering code, and reintroduces a weaker version of those checks for MT touchpads.
* Make tap detection less restrictive for multi-finger taps.bru2021-03-241-9/+3
| | | | | | | | | In order to distinguish tap gestures from short movements, the mechanism checks whether the distance between the first and the last position of a touch exceeds the 'maxdist' limit. Some touchpads provide unreliable coordinates when more than one contact is being made simultaneously, and in this case the filter may be too strong - and superfluous, because only one-finger contacts should trigger pointer movement.
* Define a USB quirk for devices that need to keep their pipes open atjcs2021-03-244-14/+63
| | | | | | | | | | | | | | | all times, before the device is enabled and after the device is disabled by wscons. This was originally needed by umt for the Microsoft Surface Type Cover to avoid it resetting (or at least detaching and reattaching) when the touchpad was touched while at the console. A similar problem occurs with the Pinebook Pro's keyboard when switching from X to the console due to the touchpad getting disabled, so add it to ums as well. with and ok kurt
* regenjcs2021-03-242-4/+16
|
* add HAILUCK Keyboardjcs2021-03-241-1/+5
| | | | from kurt
* Pack the SPCR struct definition since the struct isn't naturally alignedpatrick2021-03-231-2/+2
| | | | | | | or padded, and hence e. g. the access to the PCI vendor/device id would be broken. The structs for the other tables all seem to be packed as well. ok kettenis@
* Load MSI pages through bus_dma(9). Our interrupt controllers for MSIspatrick2021-03-221-4/+53
| | | | | | | | | | | | | | | | | | | | | | | | | typically pass the physical address, however retrieved, to our PCIe controller code. This physical address can in practise be directly given to the PCIe, but it is not a given that the CPU and the PCIe controller are able to use the same physical addresses. This is even more obvious with an smmu(4) inbetween, which can change the world view by introducing I/O virtual addresses. Hence for this it is indeed necessary to map those pages, which thanks to integration with bus_dma(9) works easily. For this we remember the PCI devices' DMA tag in the interrupt handle during the MSI map, so that we can use the smmu(4)-hooked DMA tag to load the physical address. While some systems might prefer to implement "trapping" pages for MSIs, to make sure devices cannot trigger other devices' interrupts, we only make sure the whole page is mapped. Having the IOMMU create a mapping for each MSI is a bit wasteful, but for now it's the simplest way to implement it. Discussed with and ok kettenis@
* Update device-tree bindingskn2021-03-221-6/+6
| | | | | | | | | | | | | | | | | Using the DTB from our dtb package this driver no longer attaches (on a Pinebook Pro)due to renamed bindings: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml Thanks to kettenis and patrick for pointing this out. Follow upstream's rename and acccount for the monitor interval now being milliseconds not seconds anymore. This makes cwfg(4) export values under hw.sensors as expected when using /usr/local/share/dtb/arm64/rockchip/rk3399-pinebook-pro.dtb . Input patrick kettenis OK kettenis
* Let iwn(4) simply clear frames before the firmware's BA window, insteadstsp2021-03-221-29/+17
| | | | | | | | | | | | | | | | of trying to be smart and clearing already acknowledged frames which are still within the firmware's BA window. This matches what the Linux driver does and makes our driver code simpler. Also, Tx rate control code relies on sequence numbers falling into the BA window so let's skip Tx rate control for frames before this window. Tested by: myself on 6205 and 6300 afresh1, bluhm, and paco on 6300 jmatthew on 5100 Balder Oddson on 6205
* Include wstpad allocations when cleaning up wsmouse resources.bru2021-03-213-3/+20
| | | | ok gnezdo@
* In revision 1.91 of uhidev.c, jcs@ made sure to only detach devicesanton2021-03-183-22/+3
| | | | | claiming multiple report ids once. This allows uhidpp to piggy back on the same functionality making uhidev_unset_report_dev() redundant.
* Fix previous (1.258). It breaks if localX itself is an object reference.yasuoka2021-03-181-2/+5
| | | | | | found and test by Rafael Avila de Espindola ok kettenis
* When devices have claimed multiple report ids, only detach and sendjcs2021-03-171-17/+34
| | | | | | | | DVACT_DEACTIVATE to them once when walking sc_subdevs. Fixes a regression reported and tested by Edd Barrett. Input from and previous version ok anton.
* Make iwx(4) attach to AX201 devices with PCI ID 0x34f0.stsp2021-03-171-1/+14
| | | | | | Requires Qu-c0-hr-b0-48 firmware which is available via fw_update(1). Patch by Fredrik Engberg
* regenstsp2021-03-172-2/+7
|
* Add another iwx(4) PCI device ID.stsp2021-03-171-1/+2
| | | | Based on a patch by Fredrik Engberg
* Make iwn(4) send block ack request frames with the firmware nodestsp2021-03-171-2/+5
| | | | | | | | | | | which represents the AP, rather than the firmware's broadcast node. Fixes a problem where firmware would generate bogus block ack requests with a wrong starting sequence number, shifting the receiver's block ack window out of sync with that of the firmware. Traffic would stall until enough frames were sent to wrap sequence numbers of the block ack window. ok chris@ kmos@
* Add acpi_iommu_device_map(), which replaces the DMA tag with one thatpatrick2021-03-152-2/+6
| | | | | | | | | is blessed with IOMMU magic, if available. This is mainly for arm64, since on amd64 and i386 the IOMMU only captures PCIe devices, as far as I know, which uses the pci_probe_device_hook(). This though is for non-PCI devices attached through ACPI. ok kettenis@
* Add the IORT structure for named components. These give us the stream idspatrick2021-03-151-5/+13
| | | | | | | used towards an smmu(4) for non-PCI devices. The references are provided as ASCII printable paths. ok kettenis@
* msi-map-mask is a pasto and should be iommu-map-mask.patrick2021-03-141-2/+2
| | | | | From Jared McNeill at NetBSD ok kettenis@
* regenjan2021-03-142-2/+7
|
* Add ID for Intel SSD DCjan2021-03-141-1/+2
| | | | ok jsg@
* Advertise 30-bit color support.kettenis2021-03-131-2/+5
| | | | ok matthieu@, jsg@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.