Change the range test in iommu_gas_match_one from '< ubound' to '<=
ubound', and pass a smaller-by-one ubound parameter to it, to avoid
overflow in ubound calculation.
Reported by: andrew
Reviewed by: andrew (previous version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37764
Historically the ACPI _HID for both the Arm PL011 and Generic UARTs
was ARMH0011. In the Arm Base Boot Requirements 2.0 the Generic UART
_HID is changed to ARMHB000. Use this new value in the PL011 driver
where we support both UART types.
This has been observed in some recent EDK2 builds.
Sponsored by: Arm Ltd
The SPDX-License-Identifier was wrong in the Arm CoreLink DMC-620
driver files. It used the incorrect FreeBSD variant of the BSD-2-Clause
identifier. According to [1] all files should use BSD-2-Clause.
[1] https://tools.spdx.org/app/check_license/
Reported by: emaste
Sponsored by: Arm Ltd
The SPDX-License-Identifier was wrong in the Arm CoreLink CMN-600
driver files. It used the incorrect FreeBSD variant of the BSD-2-Clause
identifier. According to [1] all files should use BSD-2-Clause.
[1] https://tools.spdx.org/app/check_license/
Reported by: emaste
Sponsored by: Arm Ltd
In 0a9a4d2cd6 a check for OPT_ACPI was added to the hwpmc Makefile
to fix loading the module in a kernel where ACPI has been disabled.
This broke loading the module when ACPI was enabled in the build as
OPT_ACPI isn't a Makefile macro so was always disabled.
Move this check to the C files where the DEV_ACPI macro does exist.
Reviewed by: gnn
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D37773
This is to upgrade current irdma driver version (in support of RDMA on
Intel(R) Ethernet Controller E810) to 1.1.5-k
change summary:
- refactor defines for hardware registers
- rereg_mr verb added in libirdma
- fix print warning during compilation
- rt_ros2priority macro fix
- irdma.4 validated with mandoc
- fixing nd6_resolve usage
- added libirdma_query_device
- sysctl for irdma version
- aeq_alloc_db fix
- dwork_flush protected with qp refcount
- PFC fixes
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
Sponsored by: Intel Corporation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36944
mrsas_issue_blocked_cmd stores a pointer to an on-stack variable
in its softc so that the driver can call wakeup() on the correct
pointer. Once the loop around tsleep() has finished however, the
pointer is no longer needed and any further use would be invalid.
Clear sc->chan to NULL after the loop.
Reported by: GCC -Wdangling-pointer
Differential Revision: https://reviews.freebsd.org/D37628
In some drivers we need to assert and deassert a group of hardware
resets in any order. To support this add a new hwreset_array that
manages all hwresets defined for a device.
Reviewed by: bz, manu, mmel
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37357
The SCMI specification describes a set of standard interfaces for power,
performance and system management.
SCMI is extensible and provides interfaces to access functions which are
often implemented in firmwares in the System Control Processor (SCP).
This implements Shared Memory-based transfer, which is one of the ways on
how messages are exchanged between agents and the platform.
This includes a driver for ARM Message Handling Unit (MHU) Doorbell, which
is a mechanism that the caller can use to alert the callee of the presence
of a message.
The support implements clock management interface. For instance this allows
us to control HDMI pixel clock on ARM Morello Board.
Tested on ARM Morello Board.
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D37316
Reviewed by: manu
Sponsored by: UKRI
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
