These includes were for __FBSD_RCSID() macro. They weren't formatted
like the rest of the tree so weren't trimmed automatically when that
script was run. Trim them now.
MFC After: 1 week
Sponsored by: Netflix
(cherry picked from commit ca48e43ba9ee73a07cdbad8365117793b01273bb)
This method is often used to process GPIO "Power on" button press on
modern x86 laptops with S0ix sleep mode.
Tested with patch from https://reviews.freebsd.org/D26407
Sponsored by: Future Crew LLC
MFC after: 2 month
(cherry picked from commit adc2c156acb50bac6e8ec66b72cadc8910ce4975)
Different drivers respond differently to having neither GPIO_PIN_INPUT
or GPIO_PIN_OUTPUT set, this stops the unpredictable results.
(cherry picked from commit 6aab381a498f1a43ba372f4ae9f57ef88b4767b5)
Currently, for DQO QPL our MPASS assertion on qpl_buf_head for available
pending_pkts (i.e. not holding a packet) fails due to incorrect
initialization. The MPASS fails on the first run of packets through the
ring when INVARIANTS is on, and when INVARIANTS is off, things work
without a bug.
The MPASS guards against improper reaping of "pending_pkt" objects,
and thus was failing for the first run through the ring. By correctly
initializing the objects in this patch we make the MPASS not fail on the
first run too.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48968
(cherry picked from commit 73c3fe4db3ebc2bd6cb732aae77ea017fd376d22)
This commit fixes several minor issues:
- Removes an unnecessary function pointer parameter on gve_start_tx_ring
- Adds a presubmit check against style(9)
- Replaces mb() and rmb() macros with native
atomic_thread_fence_seq_cst() and atomic_thread_fence_acq()
respectively
- Fixes various typos throughout
- Increments the version number to 1.3.2
Co-authored-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48969
(cherry picked from commit 031800c786823a9ad4c4d2f79f217d42dad3f5d1)
Before this change, during reset we were allocating new memory for
priv->ptype_lut_dqo, irq_db_array and the counter_array over the old
memory. This change ensures we do not allocate new memory during reset
and avoid memory leaks.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48970
(cherry picked from commit 62b2d0c3f4add3bb87081a96412056e17eed31ea)
If hardware LRO is enabled with GVE, then setting the driver's MTU to a
range of values around 8000 will cause dropped packets and drastically
degraded performance. While this issue is being investigated, we need
to prohibit the driver's MTU being set to a value within this range.
Signed-off-by: Jasper Tran O'Leary <jtranoleary@google.com>
Reviewed by: delphij, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48971
(cherry picked from commit 909e2d7b691f7418a78b1289a51d3b6c46860a9b)
The comment and rationale behind choosing CHN_INSERT_SORT_DESCEND()
instead of CHN_INSERT_SORT_ASCEND() are no longer relevant as of FILLME
("sound: Allocate vchans on-demand").
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48962
(cherry picked from commit 2868776c9c6f5313a5676786f642b766f103d780)
The mechanism of acquiring SD_F_BUSY in pcm_init() and releasing it in
pcm_register() is a leftover from the previous device creation scheme,
where pcm_init() (previously pcm_register()) would create the sysctl
nodes, as well as the device node. In this scenario, acquiring SD_F_BUSY
was necessary, in order to avoid races in case the device was accessed
before it was ready for use. Commit 66f3eb14e955 ("sound: Move sysctl
and /dev/dspX creation to pcm_setstatus()") fixed this issue, so we can
simplify things now. Only acquire SD_F_BUSY in pcm_addchan(), because
chn_init() expects to be called with SD_F_BUSY acquired.
While here, move the sndstat_register() call further down to be more
robust.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D48482
(cherry picked from commit fd906e47b18f53b09524647bf8431dc6170b8dfd)
This gives us a slight performance boost since we do not have to go
through chn_setparam() and the driver functions.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D48012
(cherry picked from commit 40616b7e41ff96b6d7522445b00f27f26d593a85)
It's a no-op. There is no lock associated with the buffer.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D48008
(cherry picked from commit 6524d2a5affd02623e6909fff0ca03ba21882a0c)
vchan_getparentchannel() is used by various vchan sysctl functions to
fetch the first primary channel. However, this assumes that all devices
have only one primary channel per direction. If a device does not meet
this assumption, then the sysctl functions will be applying the
configurations on the first primary channel only.
Since we now have the "primary" channel sublist, we can retire
vchan_getparentchannel() and iterate through the "primary" list in each
sysctl function and apply the settings to all primary channels.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48336
(cherry picked from commit 1cbafcd13796934a7896064cdb23fd4e37d58821)
Refactor pcm_chnalloc() and merge with parts of vchan_setnew() (now
removed) and dsp_open()’s channel creation into a new dsp_chn_alloc()
function. The function is responsible for either using a free HW channel
(if vchans are disabled), or allocating a new vchan.
Clean up allocated vchans associated with a given dsp_cdevpriv on
dsp_close() instead of leaving them unused.
hw.snd.vchans_enable (previously hw.snd.maxautovchans) and
dev.pcm.X.{play|rec}.vchans now work as tunables to only enable/disable
vchans, as opposed to setting their number and/or (de-)allocating
vchans. Since these sysctls do not trigger any (de-)allocations anymore,
their effect is instantaneous, whereas before we could have frozen the
machine (when trying to allocate new vchans) when setting
dev.pcm.X.{play|rec}.vchans to a very large value.
Create a new "primary" channel sublist so that we do not waste time
looping through all channels in dsp_chn_alloc(), since we are only
looking for a parent channel to either use, or add a new vchan to. This
guarantees a steady traversal speed, as the parent channels are most
likely going to be just a handful (2). What was currently in place was a
loop through the whole channel list, which meant that the traversal
would take longer the more channels were added to that list.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47917
(cherry picked from commit 02d4eeabfd73e6a827f5d42601e99aad92060b04)
There is no good reason to initialize with AFMT_U8 at 8000Hz.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48434
(cherry picked from commit e89ee05b7cf1a54d0d6ed56e4d451fdd9a10db43)
vchan_destroy() should be able to call chn_kill() regardless of whether
the channel has been added to the children list yet or not. Also remove
the CHN_F_BUSY check. There is no reason we shouldn't execute the code
below if the parent is not busy.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48185
(cherry picked from commit 405b1e50926d4162fb9503644073c0184a8b37d9)
An empty children list does not mean that there is an error.
Reported by: Florian Walpen <dev@submerge.ch>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48156
(cherry picked from commit 164651f16c860049a4ad2098206def8ca7a39b4a)
This function is not used outside of this file.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47760
(cherry picked from commit c2cd12b7ae28a34e551d1b96906620249a860bc0)
- Only two of these tunables are used for RATELIMIT without
TCP_OFFLOAD.
- Mark t4_tmr_idx_ofld and t4_pktc_idx_ofld static.
- Move hw.cxgbe.cop_managed_offloading under hw.cxgbe.toe since it is
specific to TOE.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47765
(cherry picked from commit 90652188232458891a2922fb5a542971aa58055d)
These drivers do not add child devices, so there's no need to try to
detach children.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47390
(cherry picked from commit 8b54d874c70d9fb3ed2e059f65c91b3e0eaadbd7)
This removes the need for the second call.
Reviewed by: dsl
Differential Revision: https://reviews.freebsd.org/D47388
(cherry picked from commit 24d5a8e6eec2b9eed9591971f223d79b8d7044c9)
These detach routines in these drivers all ended with 'return
(bus_generic_detach())' meaning that if any child device failed to
detach, the parent driver was left in a mostly destroyed state, but
still marked attached. Instead, bus drivers should detach child
drivers first and return errors before destroying driver state in the
parent.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47387
(cherry picked from commit d412c07617eb35435668b024bc2cecda05f57f1f)
Note that hdsp and hdspe were just leaking the ivars on detach
previously.
While here, use M_WAITOK to allocate ivars since attach routines are
sleepable. hdsp and hdspe were using M_NOWAIT without checking the
return value.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47366
(cherry picked from commit a17a41ffde0d1c579dcd7cef7900c3b44be0ec81)
hsdp(4) doesn't exist in stable/14 so is not patched
When GPIOBUS_PIN_SETFLAGS fails we called gpiobus_free_ivars to clean
up the contents of the ivar, then would free the ivar. This lead to a
use-after-free as the ivar had already been set on the child so
gpiobus_child_deleted would try to free it again.
Fix this by removing the early cleanup and letting
gpiobus_child_deleted handle it.
Fixes: c9e880c0ceef ("gpiobus: Use a bus_child_deleted method to free ivars for children")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47670
(cherry picked from commit bb8c68b25333638a20838500ccffee23b4291427)
Push the #ifdefs down into the function body instead of defining
functions conditionally for ease of readability. These aren't
critical paths, so one extra branch in the !PCI_IOV case is not a big
deal.
Requested by: jrtc27
Differential Revision: https://reviews.freebsd.org/D45877
(cherry picked from commit 971c9f57d7e6b55161fecc008e19f00ccaba8060)
For activate/deactivate resource, use a more standard check at the
start of the function since the addition of the PCI_IOV code made this
more complex. For the three recently added methods, just add the
typical check at the beginning that I missed.
This wasn't always fatal as if your system only had PCI device_t's as
children of PCI bus devices it would happen to work ok, but if you
have a non-PCI child device (e.g. an ATA channel) then dereferencing
ivars for non-direct-children could fault.
Reported by: Cirrus-CI (via emaste)
Reviewed by: emaste
Fixes: 871b33ad65ba pci: Consistently use pci_vf_* for suballocated VF memory resources
Differential Revision: https://reviews.freebsd.org/D45499
(cherry picked from commit 56b822a17cde5940909633c50623d463191a7852)
Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.
Reported by: kp
Reviewed by: imp
Tested by: kp (earlier version)
Differential Revision: https://reviews.freebsd.org/D45406
(cherry picked from commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b)
`argsp` is not defined in `generic_pcie_unmap_resource(..)`. Remove the
parameter passed to `bus_generic_unmap_resource(..)` as this parameter
is never passed to `generic_pcie_unmap_resource(..)`.
Fixes: 98056127ddfa ("acpi/pci/vmd: Fix a nit with nested resource mapping requests")
Reported by: Jenkins (aarch64, armv6, armv7, etc)
Differential Revision: https://reviews.freebsd.org/D45493
(cherry picked from commit 637ee1391957acb3ae0f68aef3e2fad76a5ae338)
Some bus drivers use rmans to suballocate resources to child devices.
When the driver for a child device requests a mapping for a
suballocated resource, the bus driver translates this into a mapping
request for a suitable subrange of the original resource the bus
driver allocated from its parent. This nested mapping request should
look like any other resource mapping request being made by the bus
device (i.e. as if the bus device had called bus_map_resource() or
bus_alloc_resource() with RF_ACTIVE).
I had slightly flubbed this last bit though since the direct use of
bus_generic_map/unmap_resource passed up the original child device
(second argument to the underlying kobj interface). While this is
currently harmless, it is not strictly correct as the resource being
mapped is owned by the bus device, not the child and can break for
other bus drivers in the future.
Instead, use bus_map/unmap_resource for the nested request where the
requesting device is now the bus device that owns the parent resource.
Reviewed by: imp
Fixes: 0e1246e33461 acpi: Cleanup handling of suballocated resources
Fixes: b377ff8110e3 pcib: Refine handling of resources allocated from bridge windows
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Fixes: d714e73f7895 vmd: Use bus_generic_rman_* for PCI bus and memory resources
Differential Revision: https://reviews.freebsd.org/D45433
(cherry picked from commit 98056127ddfa36720bcf46edc09843c867784bcb)
This was only connected to the build for MIPS and has been
disconnected from the build since MIPS was removed.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D45432
(cherry picked from commit c7c037fad1862c18e3e9635b06194a4ca00ac3c1)
QEMU for armv7 includes a PCI memory range whose CPU address is
greater than 4GB. This falls outside the range of armv7's global
mem_rman used by the nexus driver. As a result, pcib0 fails to
attach blocking all PCI devices.
Instead, change the driver to be a bit more tolerant. If allocating a
resource for a range fails, don't fail attaching the entire driver,
but do skip adding the associated PCI range to the relevant rman in
the pcib driver. This will prevent child devices from using BARs that
allocate from this range. In the case of QEMU on armv7 devices can
still allocate from an earlier PCI memory range that is within the
32-bit address space (and in fact none of the firmware-assigned memory
BARs use addresses from the upper range).
While here, reorder the operations on I/O ranges a bit: 1) print the
range under bootverbose first (rather than last) so that the range is
printed before any relevant errors for the range, 2) move
rman_manage_region last after the parent resource has been set and
allocated.
Reported by: markj, Jenkins
Reviewed by: markj
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44698
(cherry picked from commit 03713f805a91749eabcfb2e23e86489b2d4034df)
Use rman_set_type to set the type of allocated resources everywhere
rman_set_rid is currently called.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44123
(cherry picked from commit 1b9bcffff39a817b77401d1b975f374781adfaf8)
Inline generic_pcie_translate_resource_common into its sole caller.
No functional change.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D44206
(cherry picked from commit 291079d0ebdd078840ccb27aaa5d286e03e2e7e6)
The generic_pcie_containing_range helper added in commit d79b6b8ec267
assumed that the passed in (start, end) range used to locate the
containing mapping range was a valid address range (with end >=
start). The previous version of
generic_pcie_translate_resource_common only used the start address to
locate a mapping range, so the end address of 0 did not matter, but an
end of 0 now causes the first range to match and an incorrect
translation for resources using a later range.
PR: 277211
Reported by: dch, tuexen
Reviewed by: tuexen
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44205
(cherry picked from commit 332dbd3a2f08a887014a425d2532af93503588ce)
Previously ranges were only enumerated for the FDT attachment but not
ACPI. This commit moves the enumeration to the shared attach routine
so it is done for both. While here, don't list empty ranges but do
include the resource type for each range.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44132
(cherry picked from commit b28670018dbcc7d6ebc0d05584189d6d04aa079f)
This uses bus_generic_rman_alloc/release_resource to reduce some code
duplication. However, I've left the custom activate/deactivate
methods as-is.
Differential Revision: https://reviews.freebsd.org/D43939
(cherry picked from commit 3a48dfe115f35abac6c2d9ec03a6a574baeaf0bc)
