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
