Sync serial (e.g. T1/T1/G.703) interfaces are obsolete, this driver
includes obfuscated source, and has reported potential security issues.
Differential Revision: https://reviews.freebsd.org/D33468
Sync serial (e.g. T1/T1/G.703) interfaces are obsolete, this driver
includes obfuscated source, and has reported potential security issues.
Differential Revision: https://reviews.freebsd.org/D33467
And the related sconfig utility. Sync serial (e.g. E1/T1) interfaces
are obsolete, and nobody responded to several inquires on the mailing
lists about use of these drivers.
Relnotes: Yes
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23928
* Add link-state change notifications by subscribing to ifnet_link_event.
In the Linux netlink model, link state is reported in 2 places: first is
the IFLA_OPERSTATE, which stores state per RFC2863.
The second is an IFF_LOWER_UP interface flag. As many applications rely
on the latter, reserve 1 bit from if_flags, named as IFF_NETLINK_1.
This flag is mapped to IFF_LOWER_UP in the netlink headers. This is done
to avoid making applications think this flag is actually
supported / presented in non-netlink outputs.
* Add flag change notifications, by hooking into rt_ifmsg().
In the netlink model, notification should include the bitmask for the
change flags. Update rt_ifmsg() to include such bitmask.
Differential Revision: https://reviews.freebsd.org/D37597
For the TCP protocol inpcb storage specify allocation size that would
provide space to most of the data a TCP connection needs, embedding
into struct tcpcb several structures, that previously were allocated
separately.
The most import one is the inpcb itself. With embedding we can provide
strong guarantee that with a valid TCP inpcb the tcpcb is always valid
and vice versa. Also we reduce number of allocs/frees per connection.
The embedded inpcb is placed in the beginning of the struct tcpcb,
since in_pcballoc() requires that. However, later we may want to move
it around for cache line efficiency, and this can be done with a little
effort. The new intotcpcb() macro is ready for such move.
The congestion algorithm data, the TCP timers and osd(9) data are
also embedded into tcpcb, and temprorary struct tcpcb_mem goes away.
There was no extra allocation here, but we went through extra pointer
every time we accessed this data.
One interesting side effect is that now TCP data is allocated from
SMR-protected zone. Potentially this allows the TCP stacks or other
TCP related modules to utilize that for their own synchronization.
Large part of the change was done with sed script:
s/tp->ccv->/tp->t_ccv./g
s/tp->ccv/\&tp->t_ccv/g
s/tp->cc_algo/tp->t_cc/g
s/tp->t_timers->tt_/tp->tt_/g
s/CCV\(ccv, osd\)/\&CCV(ccv, t_osd)/g
Dependency side effect is that code that needs to know struct tcpcb
should also know struct inpcb, that added several <netinet/in_pcb.h>.
Differential revision: https://reviews.freebsd.org/D37127
When PCI_IOV is not enabled, do not attempt to call
iflib_softirq_alloc_generic(...IFLIB_INTR_IOV), as it results
in boot-time warnings similar to:
taskqgroup_attach_cpu: qid not found for iov cpu=2
ixl2: taskqgroup_attach_cpu failed 22
Instead, make it conditional on PCI_IOV like the other
SR-IOV related code.
Reviewed by: erj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37609
Add a PNP macro in order to load this driver automatically.
While here check if the device is enabled in DT before probing it.
Reviewed by: wma
Sponsored by: Alstom
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D37579
Use correct resolution by compat table. If dtb is not defined use default 9 bit mode.
11 bit detection is called if 9 bit mode is used.
Sysctl resolution variable is added to change resolution in case.
Some sensors didn't pull ACK while reading from nonexistent registers and it caused I2C
read error and detect failure, so now detect failure does not cause driver break.
Obtained from: Semihalf
Sponsored by: Alstom
Differential revision: https://reviews.freebsd.org/D37497
Current Xen Processor driver will evaluate any Processor object on the
ACPI tables regardless of whether the processor is online or not.
Avoid doing so for processors that are not online, as evaluating
methods of processors that are not online could lead to accesses to
invalid memory, and in any case the data that the driver fetches from
the Processor ACPI object only makes sense for processors that are
online.
Note the CPU related data fetched from Xen using XENPF_get_cpuinfo
hypercall could be cached, I leave that as a future optimization.
Sponsored by: Citrix Systems R&D
Fixes: b93f47eaee ('xen/acpi: upload Cx and Px data to Xen')
BUS_PASS_SUPPORTDEV is semantically better than BUS_PASS_RESOURCE, since
it's a support device for dtsec, so only needs probed before dtsec, not
before interrupts.
Suggested by: manu
It's possible the MDIO device hasn't been and attached, or is incorrect
in the device tree so can't probe and attach. In this case,
ofw_bus_find_child_device_by_phandle() will fail, and return NULL.
Return an error from find_mdio() here to prevent the MAC from attaching,
rather than worry about a NULL pointer dereference later on when
accessing the PHY.
Along with _PSV, _HOT, and _CRT, ACPI supports the _CR3 threshold
which specifies a temperature above which a system should transition
to the S3 standby state.
On FreeBSD, this is more useful than _HOT, which specifies the S4
transition threshold temperature (since FreeBSD does not generally
support the S4 state), or, in many cases, _CRT, since after
transitioning to S3 the system can cool and then be resumed.
Reviewed by: jhb, bcr (manpages)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D35980
of various keyboard drivers.
EVIOCGRAB ioctl execution on /dev/input/event# device node gains
exclusive access to this device to caller. It is used mostly for
development purposes and remote control software. See e.g.
https://reviews.freebsd.org/D30020 which is the reason of creation
of this change.
Keyboard grabbing is disabled in KDB and during panics.
MFC with: 4a0db5e292
Tested by: corvink
Differential revision: https://reviews.freebsd.org/D30542
of psm(4), ums(4) and sysmouse(4) drivers.
EVIOCGRAB ioctl execution on /dev/input/event# device node gains
exclusive access to this device to caller. It is used mostly for
development purposes and remote control software. See e.g.
https://reviews.freebsd.org/D30020 which is the reason of creation
of this change.
MFC after: 2 weeks
Tested by: corvink
Differential revision: https://reviews.freebsd.org/D30542
We shouldn't force USB2 only based on if we have an external PHY.
The internal PHY register tell us what link speed we can acheive
and we need to force USB2 only if it cannot do USB3.
This is only available after revision 0x290A of the dwc3 IP.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37394
Fixed: 1331c0f44b ("Add support for RockChip RK356X to DWC3 driver.")
Sponsored by: Beckhoff Automation GmbH & Co. KG
We need to enable some quirks based on the version so read it.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37393
Sponsored by: Beckhoff Automation GmbH & Co. KG
Usually dwc3 needs a glue node that contain the SoC specific clocks/resets.
For some reason the RK3328 DTS doesn't have this glue node and the clocks
are specified in the dwc3 node directly.
The bindings says that it is allowed but doesn't specified some strict names
for them.
Add a specific case for RK3328 based on the compatible string.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37392
Sponsored by: Beckhoff Automation GmbH & Co. KG
Rather than requiring a socket to be created as a TLS socket from the
get go, switch a TOE socket from "plain" TOE to TLS mode when a
receive key is added to the socket.
The firmware is only able to switch a "plain" TOE connection to TLS
mode if the head of the pending socket data is the start of a TLS
record, so the connection is migrated to TLS mode as a multi-step
process.
When TOE TLS RX is enabled, the associated connection's receive side
is frozen via a flag in the TCB. The state of the socket buffer is
then examined to determine if the pending data in the socket buffer
ends on a TLS record boundary. If so, the connection is migrated to
TLS mode and unfrozen. Otherwise, the connection is unfrozen
temporarily until more data arrives. Once more data arrives, the
receive queue is frozen again and rechecked. This continues until the
connection is paused at a record boundary. Any records received
before TLS mode is enabled are decrypted as software records.
Note that this removes the 'rx_tls_ports' sysctl. TOE TLS offload for
receive is now enabled automatically on existing TOE connections when
using a KTLS-aware SSL library just as it was previously enabled
automatically for TLS transmit. This also enables TLS offload for TOE
connections which enable TLS after passing initial data in the clear
(e.g. STARTTLS with SMTP).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D37351
Currently bhyve's NVMe controller cannot save feature values cross
reboot. It should return a FEATURE_NOT_SAVEABLE error when the command
specifies a save flag.
Quote from NVMe specification, page 205:
https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf
If the Feature Identifier specified in the Set Features command is not
saveable by the controller and the controller receives a Set Features
command with the Save bit set to one, then the command shall be aborted
with a status of Feature Identifier Not Saveable.
Reviewed by: chuck (older version)
Approved by: manu (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32767
Intel 82599 has errata related to IPv4 UDP frames with zero checksum.
It reports such datagrams with L4 integrity errors in IXGBE_XEC
register. And after afb1aa4e6d commit such errors are reported
via IFCOUNTER_IERRORS. This confuses users, since actually all frames
are handled correctly by the system.
To workaround the problem, let's ignore the XEC register value for
82599 cards for now.
PR: 266048
Discussed with: erj
MFC after: 1 week
Sponsored by: Yandex LLC
The previous commit lost an implicit struct socket * cast. Use an
inline function instead as the macro is already rather long.
Fixes: e1401f7579 cxgbe: use standard sototcpcb() accessor macro to get socket's tcpcb
Sponsored by: Chelsio Communications
In addition to (*func) tasklet also seems to have a (*callback) with
a different argument. Add support for this and add tasklet_setup()
as well for support in more drivers.
The from_tasklet() definition is duplicated in the tree; hide it there
under #ifndef to avoid a re-definition. People should generally add
LinuxKPI bits to linuxkpi rather than private files if they also rely
on other LinuxKPI bits.
X-MFC: DO NOT MFC, space allocated by drivers not us.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37216
Polarity inversion register was mistekanly filled with the value of
the direction configuration register.
Correct that.
Reviewed by: kd
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D37262
These values come from section 7.7.11 ("ACS Extended Capability") of the
PCI Express Base Specification Revision 6.0, dated 16 Dec 2021.
MFC after: 1 week
Sponsored by: Chelsio Communications
Reviewed by: kib@
Differential Revision: https://reviews.freebsd.org/D37270
If fman_init() fails it can leave things in a state where it cannot
attach at all in the future, because it would simply exit without
tearing down everything that was already set up. Go to the exit point
to clean up on error instead, so that it can try again later.
MFC after: 1 week
Added support for application management interface. There are two types of commands supported:
1. Firmware IOCTLs: These ioctls are meant for firmware
consumption. Driver acts as a transport for these.
2. Driver only IOCTLs: These ioctls are meant for driver
consumption. Driver will serve these ioctls without sending them down
to firmware.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36448
Fixed the issue when kernel invokes _init() when it is already in
_init() state by invoking _stop() in such case.
Reviewed by: imp
Differential Revsion: https://reviews.freebsd.org/D36445
Removed sysctl node vlan_only which is not being used after migrating
from l2_set_rx_mask to l2_filter_alloc.
Reviewed by: imp
Differential Revsion: https://reviews.freebsd.org/D36444
Added support for Thor controller.
Below are the supported operations:
1. IPv4 ping (ICMP)
2. iperf / netperf (IPv4 TCP)
3. Promiscuous (tcpdump)
4. Can achieve 20 Gbps on a 25 G link (Uni-Di)
5. Can achieve 60 Gbps on a 100 G link (Uni-Di)
6. Port level and queue level driver stats.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36438
This is preparatory patch for making a base for Broadcom's Thor
controller support. It converts all doorbell writes into function
pointers.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36437
Updates the drivers to Broadcom's latest:
HWRM Version 1.10.2.34 using HSI definition version 1.8.4
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36436
There's been a report recently of mbufs with data that crosses a page
boundary. It seems those mbufs are generated by the iSCSI target
system:
https://lists.xenproject.org/archives/html/xen-devel/2021-12/msg01581.html
In order to handle those mbufs correctly on netfront use the bus_dma
interface and explicitly request that segments must not cross a page
boundary. No other requirements are necessary, so it's expected that
bus_dma won't need to bounce the data and hence it shouldn't
introduce a too big performance penalty.
Using bus_dma requires some changes to netfront, mainly in order to
accommodate for the fact that now ring slots no longer have a 1:1
match with mbufs, as a single mbuf can use two ring slots if the data
buffer crosses a page boundary. Store the first packet of the mbuf
chain in every ring slot that's used, and use a mbuf tag in order to
store the bus_dma related structures and a refcount to keep track of
the pending slots before the mbuf chain can be freed.
Reported by: G.R.
Tested by: G.R.
MFC: 1 week
Differential revision: https://reviews.freebsd.org/D33876
Now that vtblk uses busdma, it keeps important information inside its
request structures. The functions used for kernel dumps synthesize
their own request structures rather than using structures initialized
with the necessary bits for busdma.
Add busdma-bypass paths. Since dumping writes contiguous blocks of
physical memory, vtblk doesn't need busdma in that case.
Reported by: glebius
Tested by: glebius
Differential Revision: https://reviews.freebsd.org/D37243
vcpuHint has been expanded to 16 bit on host side to enable
interruptions to be routed to more CPUs. Guest side should align with
the change.
This change has been tested with hosts with 8-bit and 16-bit vcpuHint,
on both platforms host side can get correct value.
This driver is for ESXi product which only supports x86/x64. They are
little-endian. So there is no need to consider big-endian system.
PR: 264840
Reviewed by: imp@, Zhenlei Huang
The ipmi watchdog pretimeout action can trigger unintentionally in
certain rare, complicated situations. What we have seen at Netflix
is that the BMC can sometimes be sent a continuous stream of
writes to port 0x80, and due to what is a bug or misconfiguration
in the BMC software, this results in the BMC running out of memory,
becoming very slow to respond to KCS requests, and eventually being
rebooted by its own internal watchdog. While that is going on in
the BMC, back in the host OS, a number of requests are pending in
the ipmi request queue, and the kcs_loop thread is working on
processing these requests. All of the KCS accesses to process
those requests are timing out and eventually failing because the
BMC is responding very slowly or not at all, and the kcs_loop thread
is holding the IPMI_IO_LOCK the whole time that is going on.
Meanwhile the watchdogd process in the host is trying to pat the
BMC watchdog, and this process is sleeping waiting to get the
IPMI_IO_LOCK. It's not entirely clear why the watchdogd process
is sleeping for this lock, because the intention is that a thread
holding the IPMI_IO_LOCK should not sleep and thus any thread
that wants the lock should just spin to wait for it. My best guess
is that the kcs_loop thread is spinning waiting for the BMC to
respond for so long that it is eventually preempted, and during
the brief interval when the kcs_loop thread is not running,
the watchdogd thread notices that the lock holder is not running
and sleeps. When the kcs_loop thread eventually finishes processing
one request, it drops the IPMI_IO_LOCK and then immediately takes the
lock again so it can process the next request in the queue.
Because the watchdogd thread is sleeping at this point, the kcs_loop
always wins the race to acquire the IPMI_IO_LOCK, thus starving
the watchdogd thread. The callout for the watchdog pretimeout
would be reset by the watchdogd thread after its request to the BMC
watchdog completes, but since that request never processed, the
pretimeout callout eventually fires, even though there is nothing
actually wrong with the host.
To prevent this saga from unfolding:
- when kcs_driver_request() is called in a context where it can sleep,
queue the request and let the worker thread process it rather than
trying to process in the original thread.
- add a new high-priority queue for driver requests, so that the
watchdog patting requests will be processed as quickly as possible
even if lots of application requests have already been queued.
With these two changes, the watchdog pretimeout action does not trigger
even if the BMC is completely out to lunch for long periods of time
(as long as the watchdogd check command does not also get stuck).
Sponsored by: Netflix
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36555
In non-Hyper-V systems during Hyper-V initialization, system
initialization was getting hung, as hyperv_identify(),
was returning successful irrespective of the type of the platform.
Reviewed by: andrew, whu
Fixes: 9729f076e4
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37219
Assertions suggest that the loop in iommu_gas_fini_domain is executed
zero times, so remove it.
Reviewed by: alc, kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D37204
Maintain a pointer to an element in the domain map that is left of any
sufficiently large free gap in the tree and start the search for free
space there, rather than at the root of the tree. On find_space, move
that pointer to the leftmost leaf in the subtree of nodes with
free_down greater than or equal to the minimum allocation size before
starting the search for space from that pointer. On removal of a node
with address less than that pointer, update that pointer to point to
the predecessor or successor of the removed node.
In experiments with netperf streaming, this reduces by about 40% the
number of map entries examined in first-fit allocation.
Reviewed by: alc, kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36624
This commit brings back the driver from FreeBSD commit
f187d6dfbf plus subsequent fixes from
upstream.
Relative to upstream this commit includes a few other small fixes such
as additional INET and INET6 #ifdef's, #include cleanups, and updates
for recent API changes in main.
Reviewed by: pauamma, gbe, kevans, emaste
Obtained from: git@git.zx2c4.com:wireguard-freebsd @ 3cc22b2
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36909
When flushing the UART, we need to drain manually if LSR_TEMT is
*not* asserted, aka. if the transmit FIFO is not empty.
Reported by: void <void@f-m.fm>
Fixes: c4b68e7e53 "ns8250: Check if flush via FCR succeeded"
Differential Revision: https://reviews.freebsd.org/D37185
- We depend on header polution to include sys/malloc.h. Include it
directly.
- Only define FDT-specific fuctions when building a FDT kernel.
Sponsored by: Innovate UK
This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
guest on Hyper-V. With this patch, it should be able to build
the ARM64 image and install it on Hyper-V.
Reviewed by: emaste, andrew, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36744
psci_attach is way too late to provide the intended semantics for
psci_present. psci calls can be made immediately after psci_init(),
called way earlier at SI_SUB_CPU + SI_ORDER_FIRST, and we need it to
be valid as early as we can possibly call a psci function.
This fixes booting RPi3+4 with the in-review spintable patch;
rpi3-psci-monitor patches the FDT to add a PSCI node, but it doesn't
patch each cpus' enable-method. Because of this, we would stall the
boot while enabling CPU 1 as we saw a valid looking enable-method and
"no" functional PSCI and attempted to use the spintable rather than
simply not starting secondary APs.
Fixes: 2218070b2c ("psci: finish psci_present implementation")
Reported by: karels
Refactor the code to put split the MSR values for x86 and arm64
Hyper-V. Code not yet built. This is one of several patches for
the arm64 Hyper-V enablement.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37103
2782ed8f6c fixed the standalone module
build. REmove the now duplicate includes for opt_acpi.h and
opt_platform.h. Als remove the if_mdio.h again in both the Makefile
and the implementation file as it is not (currently) used.
X-MFC with: ba7319e909
MFC after: 70 days
New driver to ACPI generic event device, defined in ACPI spec.
Some ACPI power button may not work without this.
In qemu arm64 with "virt" machine, with ACPI firmware,
enable devd check devd message by
and invoke following command in qemu monitor
(qemu) system_powerdown
and make sure some power button input event appear.
(setting sysctl hw.acpi.power_button_state=S5 is not work,
because ACPI tree does not have \_S5 object.)
Reviewed by: andrew, hrs
Differential Revision: https://reviews.freebsd.org/D37032
This is the second part of the ARM64 Hyper-V enablement.
These changes here are mostly with Make, release changes and also
changes required in vmbus.c hyperv.c and common files in hyperv.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36467
In ARM64 gen2 Hyper-V, use IRQ resource from vmbus_res, which is owning
the IRQ for current device tree. It allows the MMIO resource to be
successfully allocated for vmbus from parent acpi_syscontainer.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37064
This add BUS_GET_DEVICE_PATH interface,
which shows device tree of openfirm/fdt.
In qemu-system-arm64 with "virt" machine with device-tree firmware,
% devctl getpath OFW cpu0
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37031
The emulated UART in the Firecracker VMM (aka the implementation in the
rust-vmm/vm-superio project) includes FIFOs but does not implement the
FCR register, which is used by ns8250_flush to flush the FIFOs.
Check the LSR to see if there is still data in the FIFOs and call
ns8250_drain if necessary.
Discussed with: emaste, imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36979
We assume that bus addresses from busdma are the same thing as
"physical" addresses in the Virtio specification; this seems to
be true for the platforms on which Virtio is currently supported.
For block devices which are limited to a single data segment per
I/O, we request PAGE_SIZE alignment from busdma; this is necessary
in order to support unaligned I/Os from userland, which may cross
a boundary between two non-physically-contiguous pages. On devices
which support more data segments per I/O, we retain the existing
behaviour of limiting I/Os to (max data segs - 1) * PAGE_SIZE.
Reviewed by: bryanv
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36667
Most virtio_blk requests are launched from vtblk_startio; prior to this
commit, if vtblk_request_execute failed (e.g. due to a lack of space on
the virtio queue) vtblk_startio would requeue the request to be
reattempted later.
Add a flag "vbr_requeue_on_error" to requests and perform the requeuing
from inside vtblk_request_execute instead.
No functional change intended.
Reviewed by: bryanv, imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36665
The error, if any, now gets stashed in the request structure. (Step 1
of reworking this driver to use busdma.)
No functional change intended.
Reviewed by: bryanv, imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36664
The Virtio MMIO bus driver was added in 2014 with support for devices
exposed via FDT; in 2018 support was added to discover Virtio MMIO
devices via ACPI tables, as in QEMU. The Firecracker VMM eschews both
FDT and ACPI, instead presenting device information via kernel command
line arguments of the form virtio_mmio.device=<parameters>.
These command line parameters get converted into kernel environment
variables; this adds support for parsing those variables and attaching
virtio_mmio children to nexus.
There is a case to be made that it would be cleaner to have a new
"cmdlinebus" attached to nexus and virtio_mmio children attached to
that. A future commit might do that.
Discussed with: imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36189
Issue Description:
The RequestCredits field of IOCFacts got changed between the Phase23
firmware to Phase24 firmware. So as part of firmware update operation,
driver has to free the resources & pools which are created with the Phase23
Firmware's IOCFacts data (i.e. during driver load time) and has to
reallocate the resources and pools using Phase24's IOCFacts data. Here
driver has freed the interrupts but missed to reallocate the interrupts and
hence config page read operation is getting timed out and controller is
going for recursive reinit (controller reset) operations and leading to
kernel panic.
Fix:
Reallocate the interrupts if the interrupts are disabled as part of
firmware update/downgrade operation.
Submitted by: Sreekanth Ready <sreekanth.reddy@broadcom.com>
Tested by: ken
MFC after: 3 days
DPAA2 is a hardware-level networking architecture found in some NXP
SoCs which contain hardware blocks including Management Complex
(MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O
processor (WRIOP, packets distribution, queuing, drop decisions),
Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer
pools) and the others.
The Management Complex runs NXP-supplied firmware which provides DPAA2
objects as an abstraction layer over those blocks to simplify an
access to the underlying hardware. Each DPAA2 object has its own
driver (to perform an initialization at least) and will be visible
as a separate device in the device tree.
Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses in
order to form a hierarchy of the DPAA2 devices:
acpiX (or simplebusX)
dpaa2_mcX
dpaa2_rcX
dpaa2_mcp0
...
dpaa2_mcpN
dpaa2_bpX
dpaa2_macX
dpaa2_io0
...
dpaa2_ioM
dpaa2_niX
dpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPI
and FDT flavours and implements helper interfaces to allocate and
assign bus resources, MSI and "managed" DPAA2 devices (NXP treats some
of the objects as resources for the other DPAA2 objects to let them
function properly). Almost all of the DPAA2 objects are assigned to
the resource containers (dpaa2_rc) to implement isolation.
The initial implementation focuses on the DPAA2 network interface
to be operational. It is the most complex object in terms of
dependencies which uses I/O objects to transmit/receive packets.
Approved by: bz (mentor)
Tested by: manu, bz
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36638
It can be static within uart_tty.c. It is an open question whether there
remains any real benefit to having uart instances share a swi thread.
Reviewed by: imp, markj, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36938
When a transaction is on the outstanding list, it needs to have a valid
timeout value, so set it to infinity before placing it on the
list. Place before we put it on the list, even though the list is
protected by the qpair lock.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D36920
Adapt 2796f7cab1 to igc(4)
* Don't reset the entire adapter for vlan changes, fix up the problems
* Remove the VFTA, this hardware doesn't seem to implement it
Approved by: grehan
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31979
Like many of the other encodings here, none of these are actually used
by our tables. However, defining the EVENT_xH names allows them to be
used by the user (e.g. when trying to use an implementation-defined
event that they know about from their core's documentation but we don't)
and allows us to define PMC_EV_ARMV8_LAST appropriately.
Some of these are also used downstream in CheriBSD on Morello.
Reviewed by: andrew, tsoome
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D36926
The documented encoding space for Armv8 was only 8 bits, but v8.0 has
always had a 10-bit encoding space for its events, and downstream in
CheriBSD we relied on this full space. This worked until the DMC-620 and
CMN-600 events were added, trampling on what should have been reserved
for Armv8.0 right from the start. Thus, renumber the DMC-620 and CMN-600
events to not do this before they make it into a stable release,
allowing for the full Armv8.0 encoding space to be used without having
to split it across two different regions.
Note that Armv8.1 grows the encoding space to 16 bits, which doesn't fit
well with our current approach. No attempt is made to allow for these
events in this change, only the ones that have always been valid (according to
the hardware) from the first commit of Armv8 support to hwpmc.
Reviewed by: arichardson, tsoome
Differential Revision: https://reviews.freebsd.org/D36925
Buggy SMM implementations can hang while processing CPPC notifications.
This leads to some laptops (notably Thinkpads) hanging when the
hwpstate_intel driver is loaded.
Tell the SMM that we will handle CPPC notifications as described in:
- Intel® Processor Vendor-Specific ACPI
- Intel® 64 and IA-32 Architectures Software Developer’s Manual
CPPC events default to masked (disabled) so while we do not do any
handling right now this does not seem to lead to any issues.
This approach was found via this Linux Kernel patch:
https://lkml.org/lkml/2016/3/17/563
PR: 253288
Reviewed by: imp, jhb
Sponsored by: Modirum
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D36699
I225 devices have only one PHY vendor. There is unnecessary to check
_I_PHY_ID during the link establishment and auto-negotiation process,
the checking also caused devices like i225-IT failed. This patch is to
remove the mentioned unnecessary checking.
Cc: stable@dpdk.org
Signed-off-by: Mah Yock Gen <yock.gen.mah@intel.com>
Signed-off-by: Taripin Samuel <samuel.taripin@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Approved by: grehan
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36923
This will resolve a reference and return the appropriate handle, a node
on the simplebus or an ACPI_HANDLE for ACPI. For now we do not try to
further abstract the return type.
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D36793
In virtual machines with virtual UARTs which have fictitious baud
rates, it may be possible to drain the receive queue very quickly,
without needing to DELAY after each character. Attempt to read
(and discard) the receive queue as fast as possible, stopping for
a DELAY only when LSR_RXRDY is no longer asserted; assume that we
have finished draining the queue when LSR_RXRDY is asserted both
before and after a DELAY.
This speeds up the boot process in FreeBSD/Firecracker by 27 ms.
Reviewed by: imp, jrtc27
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36184
Mechanically cleanup INP_TIMEWAIT from the kernel sources. After
0d7445193a, this commit shall not cause any functional changes.
Note: this flag was very often checked together with INP_DROPPED.
If we modify in_pcblookup*() not to return INP_DROPPED pcbs, we
will be able to remove most of this checks and turn them to
assertions. Some of them can be turned into assertions right now,
but that should be carefully done on a case by case basis.
Differential revision: https://reviews.freebsd.org/D36400
This was added in 7cba15b16e in 2016 and firmwares at that time were
already setting up the iSCSI tag mask properly. Since then it has also
become possible to split the iSCSI region between multiple PCIE PFs but
the driver's calculation takes only its own PF's allocation into account
and that means this code is incorrect and not just a harmless no-op.
MFC after: 1 week
Sponsored by: Chelsio Communications
By default all VMD devices remap children MSI/MSI-X interrupts into their
own. It creates additional isolation, but also complicates things due to
sharing, etc. Fortunately some VMD devices can bypass the remapping.
Add tunable to control it for remap testing or if something go wrong.
MFC after: 2 weeks
The "uart_bus_probe" function is used as a generic part of uart probe
logic. It returns a driver priority(negative number) if successful and
an error code otherwise.
Fix the error checking condition to account for that.
Also, while here return "BUS_PROBE_VENDOR", instead of "0".
This fixes uart on clearfog pro with recent DT.
PR: 266657
Reviewed by: mw
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D36880
Include sys/malloc.h directly in sdhci_xenon.c to get the malloc(9)
definition rather than depend on header pollution.
Sponsored by: The FreeBSD Foundation
To avoid data loss, make sure both the receive and transmit data toggles
get reset, before trying to read or write any data.
MFC after: 1 week
Sponsored by: NVIDIA Networking
Note that this required adding missing ()'s around the outermost level
of MSK_READ_MIB*. Otherwise, the void cast was only applied to the
first register read. This also meant that MSK_READ_MIB64 was pretty
broken as the uint64_t cast only applied to the first 16-bit register
read in each MSK_READ_MIB32 invocation and the 32-bit shift was only
applied to the second register read of the pair.
Reviewed by: imp, emaste
Reported by: GCC -Wunused-value
Differential Revision: https://reviews.freebsd.org/D36777
While at it optimise "case 3" into a default.
This way there is no need to initialize the "mark" variable in the beginning,
because all cases set it.
MFC after: 1 week
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D36042
