splclock is used in one driver (spkr) to control access to
timer_spkr_* routines. However, nothing else does. So it shows no
useful locking info to someone that would want to lock spkr.
NOTE: I think there's races with timer_spkr_{acquire,release} since
there's no interlock in those routines, despite there being a spin
lock to protect the clock. Current other users appear to use no extra
locking protocol, though they themselves appear to be at least
attempting to make sure that only a single thread calls these
routines. I suspect the right answer is to update these routines to
take/release the clock spin lock since they are short and to the
point, but that's beyond the scope of this commit.
ich_init() returns an errno value or 0, but ich_pci_resume() was
comparing the return value with -1 to determine whether an error had
occurred.
PR: 248941
Submitted by: Tong Zhang <ztong0001@gmail.com>
MFC after: 1 week
fdc_in() returns only 0 and 1, some callers were checking incorrectly
for failure.
PR: 248940
Submitted by: Tong Zhang <ztong0001@gmail.com>
MFC after: 1 week
asmc_key_read() returns only 0 and 1, some callers were checking
incorrectly for failure.
PR: 248939
Submitted by: Tong Zhang <ztong0001@gmail.com>
MFC after: 1 week
crypto(9) functions can now be used on buffers composed of an array of
vm_page_t structures, such as those stored in an unmapped struct bio. It
requires the running to kernel to support the direct memory map, so not all
architectures can use it.
Reviewed by: markj, kib, jhb, mjg, mat, bcr (manpages)
MFC after: 1 week
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D25671
Update the deprecation message in the drm2 (aka legacy drm) drivers to point
towards the graphics/drm-kmod ports for all architectures, not just amd64.
drm-kmod has support for more architectures these days, and the
graphics/drm-legacy-kmod port is being deprecated.
Approved by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26174
For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.
Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.
Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.
Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.
ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.
Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.
MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091
Rx is more efficient within the chip when the receive buffer size
matches the TLS PDU size.
MFC after: 3 days
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D26127
Coverity flagged this condition: The condition
offset == 0 && offset == 65535
can never be true because offset cannot be equal
to two different values at the same time.
Submitted by: bret_ketchum@dell.com
Reported by: Coverity
Reviewed by: tsoome, cem
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D26144
The AMD's Ryzen 3 3200g XHCI controllers apparently need the evaluate
control endpoint context command, but we don't need to issue this
command when the bMaxPacketSize is received after the read of the USB
device descriptor, because this part should be handled automatically.
PR: 248784
Tested by: emaste, hselasky
MFC after: 1 week
Sponsored by: Mellanox Technologies
It was a driver for a USB FM tuner that was available in the market in 2002. I
wrote the driver in 2003. I've not used it since 2005 or so, so it's time to
retire this driver. No userland code ever interfaced to the special device it
created. There's no user base: the last bug I received on this driver was in
2004.
Relnotes: Yes
The XHCI specification says that the XHCI controller should detect
reception of the USB device descriptors, and automatically update
the max packet size in the control endpoint context.
Differential Revision: https://reviews.freebsd.org/D26104
Reviewed by: kp@
MFC after: 1 week
Sponsored by: Mellanox Technologies
Because pcell_t is unsigned both sides of the comparison were treated as
such.
Because of that error iicmux created all possible sub-buses even if only
a subset was defined in the device tree.
MFC after: 1 week
Code was checking for NETMAP_{SW,HW}_RING in req->nr_ringid which
had already been masked by NETMAP_RING_MASK. Therefore, the comparisons
always failed and set NR_REG_ALL_NIC. Check against the original nmr
structure.
Submitted by: bpoole@packetforensics.com
Reported by: bpoole@packetforensics.com
Reviewed by: giuseppe.lettieri@unipi.it
Approved by: vmaffione
MFC after: 1 week
This was discussed in arch@ a while ago. Most of the 16-bit drivers that it
relied on have been removed. There's only a few other drivers remaining that
support it, and those are very rare the days (even the once ubiquitious wi(1)
is now quite rare).
Indvidual drivers will be handled separately before pccard itself is removed.
Remove two debugging printfs, even if hidden under boot -v.
They seemed to be of debug nature and always spit onto the
console when running camcontrol devlist -v.
Reviewed by: manu
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25962
Reviewed by: Jacob Keller <jacob.e.keller@intel.com>
Suggested editing from: Krzysztof Galazka <krzysztof.galazka@intel.com>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25954
This adds support for the Cortex-A76 and Neoverse-N1 PMU counters to pmc.
While here add more PMCR_IDCODE values and check the implementers code is
correct before setting the PMU type.
Reviewed by: bz, emaste (looks reasonable to me)
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25959
Only linux,code is supported as it maps 1:1 to evdev key codes.
No reverse mapping for freebsd,code yet.
Reviewed by: wulf
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D25940
- hoist all request / response structures from function level to top level
- replace magic numeric literals with constants
- regroup types, data and functions
- remove setting of the id field in responses as they are completely
overwritten with data from the device
- centralize setting of the id field as it is always set to the value of
request type
- fix setting and querying of open-drain vs push-pull configuration of
an output pin -- it's always in one of those configurations
- detect special pin configurations: a pin in a special configuration is
neither general purpose input or output
- there is still no support for setting special configurations
MFC after: 2 weeks
- Do not rely on U-Boot for clocks configuration, enable and set frequencies
in the driver's attach method.
- Adjust MAC settings according to detected linespeed on RK3399 and RK3328.
- Add support for RMII PHY mode on RK3328.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D26006
The FreeBSD em driver fails to properly reset the VME flag
in the e1000 CTRL register oneg the following ifconfig command
ifconfig em1 -vlanhwtag
Tested on the e1000 device emulated by QEMU, and on a real
NIC (chip=0x10d38086).
PR: 236584
Submitted by: murat@sunnyvalley.io
Reported by: murat@sunnyvalley.io
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D25286
so we don't ifdef for every arch in busdma_iommu.c;
o No need to include specialreg.h for x86, remove it.
Requested by: andrew
Reviewed by: kib
Sponsored by: DARPA/AFRL
Differential Revision: https://reviews.freebsd.org/D25957
