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
On arm64 with per-thread stack canaries enabled (the PERTHREAD_SSP
option), the compiler may load curthread->td_md.md_canary in function
prologues. This is not safe in data_abort(); see commit 2c10be9e06.
Thus, sanitizer runtimes must also avoid accessing the current thread's
canary.
Since SSP has limited utility in sanitizer runtimes, simply disable it
unconditionally to avoid unpleasant surprises in the future.
MFC after: 2 weeks
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
With PERTHREAD_SSP configured, the compiler's stack-smashing protection
uses a per-thread canary value instead of a global value. The value is
stored in td->td_md.md_canary; the sp_el0 register always contains a
pointer to that value, and certain functions selected by the compiler
will store the canary value on the stack as a part of the function
prologue (and will verify the copy as part of the epilogue). In
particular, the thread structure may be accessed.
This happens to occur in data_abort(), which leads to the same problem
addressed by commit 2c10be9e06 ("arm64: Handle translation faults for
thread structures"). This commit fixes that directly, by disabling SSP
in data_abort() and a couple of related functions by using a function
attribute. It also moves the update of sp_el0 out of C code in case
the compiler decides to start checking the canary in pmap_switch()
someday.
A different solution might be to move the canary value to the PCB, which
currently lives on the kernel stack and isn't subject to the same
problem as thread structures (if only because guard pages inhibit
superpage promotion). However, there isn't any particular reason the
PCB has to live on the stack today; on amd64 it is embedded in struct
thread, reintroducing the same problem. Keeping the reference canary
value at the top of the stack is also rather dubious since it could be
clobbered by a sufficiently large stack overflow.
A third solution could be to go back to the approach of commit
5aa5420ff2, and modify UMA to use the direct map for thread structures
even if KASAN is enabled. But, transient promotions and demotions in
the direct map are possible too.
Reviewed by: alc, kib, andrew
MFC after: 1 month
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37255
This is just a dummy enum and struct in order to make drivers compile
more happily as some parts are simply not hidden behind #ifdefs and
this avoids a longer-term maintenance problem.
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37215
Add devm_request_irq() needed by a driver. Turns out all we need
is a wrapper with the right arguments to lkpi_request_irq().
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37217
Add a memcpy variant which takes length of source and destination
buffers and a padding character in case there is free space in the
destination. This is used by a wireless driver.
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37226
Most of the WME code has been there disabled for months. One of the
reasons was that it lead to crashes early on. It is now understood
that the crashes are independent event and we can enable WME.
Update the code and deal with the calls from net80211 and adjust the
updates to when mac80211 drivers expect them, coherently put it under
LKPI_80211_WME and enable the define locally.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Keep all ECN related code in (mostly) one place.
No functional change.
Event: IETF 115 Hackathon
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D37285
Accurate ECN asks to conservatively estimate, when the
ACE counter may have wrapped due to a single ACK covering a larger
number of segments. This is described in Annex A.2 of the
accurate-ecn draft.
Event: IETF 115 Hackathon
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D37281
Provide diagnostics information around AccECN into
the tcpinfo struct.
Event: IETF 115 Hackathon
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D37280
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
Until bnxt is fixed on i386, remove it from its lint. Create a new
section of the config file for things that work everywhere, except i386.
Sponsored by: Netflix
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 no need to ever include sys/conf.h here anymore, so remove
it. It was added years ago as a transition and everything has been
updated.
Sponsored by: Netflix
This reverts commit fe36346a89.
The arm64 Hyper-v code now checks it is running under Hyper-v before
calling into the hypervisor.
Sponsored by: The FreeBSD Foundation
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
