Deleting a child explicitly before calling bus_generic_detach is now
redundant, so remove those calls and rely on bus_generic_detach to
delete children instead.
Differential Revision: https://reviews.freebsd.org/D47961
This provides better semantics as a standalone DEVMETHOD for
device_attach as bus drivers should remove child devices they created
as part of detach cleanup. The implementation calls
bus_detach_children() first to permit child devices an opportunity to
veto the detach operation. If that succeeds, device_delete_children()
is used to delete the child devices.
This requires fixing various drivers that were deleting devices
explicitly (via a device_t pointer cached in the softc) after calling
bus_generic_detach to stop doing that and just rely on
bus_generic_detach to remove child devices.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47959
This is simpler and more robust in the face of potential double-frees
(e.g. if called after bus_generic_detach which will delete devices in
a future commit).
Reviewed by: manu, imp
Differential Revision: https://reviews.freebsd.org/D47958
These drivers perform additional teardown steps in between detaching
child devices and deleting child devices.
Differential Revision: https://reviews.freebsd.org/D47957
Add a virtual timer implementation based on SBI Time extension.
This is needed for Eswin EIC7700 SoC which does not include the newer SSTC
extension.
Timer interrupt pending bit (STIP) could not be cleared in the guest system,
so rework interrupts handling: add new "interrupts_pending" field. Use it
for timer interrupt only for now, but later we can extend to store all
pending interrupts (Timer, IPI and External).
With this I'm able to boot FreeBSD (SMP) guest on HiFive Premier P550,
which is the first real hardware with RISC-V 'H'-spec included.
Differential Revision: https://reviews.freebsd.org/D48133
It is already known that rsm != NULL, so no need to check for it.
Reviewed by: rrs
CID: 1523815
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48282
Verify that we reset the cleared time when we zero an address' counters in
a table.
PR: 282877, 282984
Reviewed by: kp
MFC after: 2 weeks
Signed-off-by: Leonid Evdokimov <leon@darkk.net.ru>
Differential Revision: https://reviews.freebsd.org/D48242
cy@ was kind enough to preemptively create a port from the version of
this script in base for those that need this exact interface; add a
pointer to it so that interested individuals could start installing it
sooner rather than later.
Noted by: cy
MFC after: 3 days
The shar(1) program is simple, but the fundamental idea of a sh archive
is risky at best and one that we probably shouldn't be promoting as
prominently as a program in $PATH and a manpage. Let's deprecate and
remove it, since the same functionality can easily be found in
tar(1) instead.
Reviewed by: emaste, philip
Reviewed by: allanjude, brooks, delphij, des, imp, rpokala (previous)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D48130
Signature types need to be parsed out of the key/signature information
that we are presented with from the files we download. We use that to
understand whicher signer we need to dispatch to.
The ECC signer is more-or-less lifted from pkg(8), with some changes to
slim it down for pkg(7).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D48108
This will be used to verify raw payloads, as if signed by pkg-key(8).
It will be used specifically in pkg(7) to verify .pubkeysig as published
by poudriere.
Amend verify_pubsignature() now to use it. For the RSA signer, we need
to verify using a sha256 of the data instead of the data itself.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D48109
We already have to do this for reading the pubkey, just pull it out for
other uses. The ECC signer will use this to verify the bootstrap if
the PUBKEY mechanism is used.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D48107
This mirrors a change we made in pkg(8), and will be used to next add
another signer that does ECC.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D48106
We'll eventually add a pkgsign abstraction over these similar to how we do
in pkg(8), but start by isolating these parts.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D48105
libecc is not intended to be general use, other applications should
really be using openssl. pkg(7) uses libecc to align with the pkg(8)
project and its goals. This will be used in the upcoming support for
ECC in pkg(7).
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D48117
libder will be used in upcoming ECC support in the pkg(7) bootstrap to
read DER-encoded keys and signatures.
Differential Revision: https://reviews.freebsd.org/D48116
These tests create a linked list with one entry for every group on the
running system. On a system with about 30,000 groups, the test took 69
seconds to run, and crashed Kyua with the below error:
kyua: E: string or blob too big (sqlite op: sqlite3_bind_blob) (sqlite db: /root/.kyua/store/results.usr_tests.20241231-203317-570235.db).
Fix the test by limiting it to operating on the first 1024 groups.
Apply the same change to getpw_test and getserv_test too, which are
vulnerable to the same problem.
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D48275
If one of two pointers refers to a forward declaration, let the pointers
be compatible so long as the referred types have the same name.
Otherwise we can get spurious errors.
To give a specific example, this can happen when ipfw_nat.ko is loaded
before ipfw.ko and /usr/lib/dtrace/ipfw.d is processed. Currently,
ipfw_nat.ko does not have a definition for struct inpcb (i.e., none of
its files include in_pcb.h), so in the CTF type graph, struct
ip_fw_args' "inp" member refers to a forward declaration, represented in
CTF with CTF_K_FORWARD.
Then, when libdtrace processes the ipfw_match_info_t translator in
ipfw.d, it decides that the "inp" field assignment is incorrect because
the two pointers are incompatible. However, there's no harm in allowing
this assignment. Add some logic to dt_node_is_ptrcompat() to detect
this case and declare the pointers as compatible so long as the name of
the thing they refer to is the same, similar to how any pointer is
compatible with a void *.
Reported by: marck
Reviewed by: Domagoj Stolfa <domagoj.stolfa@gmail.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48254
The firmware version isn't enough; different firmware is loaded
for different revisions of a given chip. So print out the file too;
it'll make handling reports much easier.
Differential Revision: https://reviews.freebsd.org/D48067
Reviewed by: emaste
Indicate that the missing of the break is intentionally.
Reviewed by: rrs
CID: 1523782
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48273
This change brings the descriptor for target "elf64-riscv-freebsd"
in line with its documentation.
I missed this somehow when reviewing https://reviews.freebsd.org/D20768.
Reported by: Haowu Ge (on elftoolchain-developers)
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D48271
* remove the hard-coded ridx values in rate2ridx(), use the RIDX
defines for CCK/OFDM rates
* Add a placeholder rtwn_ctl_vhtrate() which returns the dot11rate
control rate to use for the given VHT rate index. Since net80211
currently doesn't have any VHT PHY tables, there's no mapping for
us to leverage so just return OFDM 12M for now.
* Use the new macro to convert rate index to MCS rate
* Add a printf() in rate2ridx if it's passed a HT/VHT rate.
Differential Revision: https://reviews.freebsd.org/D48098
Reviewed by: bz
This register (array) controls the initial rate to use for each
MACID. There's no need to set it if firmware rate control is enabled -
it'll actually be under firmware control (and we can read it back to
see what choices the firmware is making.)
Locally tested:
* RTL8188EU, STA
* RTL8192CU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48094
Reviewed by: bz
The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the driver for rate probing and selection.
Part of this is the periodic TX report - which uploads a summary
of multi-rate retries and drops per MAC. Using it drastically
cuts down on the TX notifications - it's fired from a timer
(defaulting to ~ 1.6 seconds) and is a single receive frame in
the normal bulk RX path.
I've not ported / reimplemented the whole vendor driver rate adaption
code - instead, I'm just using the normal net80211 rate control APIs.
It seems to behave OK - I get 25-30mbit down and 20mbit up using TCP/
speedtest.
Locally tested:
* RTL8188EU, STA mode
Differential Revision: https://reviews.freebsd.org/D48088
Reviewed by: fuz, bz
Obtained from: https://github.com/lwfinger/rtl8188eu/blob/master/hal/Hal8188ERateAdaptive.c
Add support to read/write the MAC/PHY registers.
Hide it behind RTWN_DEBUG.
This doesn't cover the RF registers as they require a different
IO path, but I haven't yet debugged the RF paths.
Locally tested:
* RTL8192CU, STA
* RTL8188EU, STA
* RTL8812AU / RTL8821AU, STA
Differential Revision: https://reviews.freebsd.org/D48084
Reviewed by: bz
When storing the old beta values in rack_swap_beta_values(),
ensure that the newreno_flags field is initialized appropriately
instead of using an uninitialized value.
Since the stored newreno_flags aren't actually used, this fix
should not have any functional change.
Reviewed by: rrs
CID: 1523796
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48260
Instead of dealing with ifp == NULL, which should never happen,
assume that this is not true. Use KASSERT to make this clear.
No functional change intended.
Reviewed by: glebius, rrs
CID: 1523767
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48258
