Trying to probe+attach the child device at the point it is added comes
before the syscon handle is set up (if relevant). It will therefore be
unavailable to the attach method which is expecting it, and the first
attempt to attach the device will fail.
Just rely on the call to bus_generic_attach() at the end of the function
to perform probe+attach of dev's children.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44268
If the call to clknode_get_freq() returns an error (unlikely), report
this, rather than printing the error code as the clock frequency.
If the clock has no parent (e.g. a fixed reference clock), print "none"
rather than "(NULL)(-1)". This is a more human-legible presentation of the
same information.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44267
We may attach several of these devices, but there is no meaningful
information added to dmesg. For example:
ofwbus0: <Open Firmware Device Tree>
clk_fixed0: <Fixed clock> on ofwbus0
clk_fixed1: <Fixed clock> on ofwbus0
clk_fixed2: <Fixed clock> on ofwbus0
clk_fixed3: <Fixed clock> on ofwbus0
clk_fixed4: <Fixed clock> on ofwbus0
clk_fixed5: <Fixed clock> on ofwbus0
clk_fixed6: <Fixed clock> on ofwbus0
clk_fixed7: <Fixed clock> on ofwbus0
clk_fixed8: <Fixed clock> on ofwbus0
clk_fixed9: <Fixed clock> on ofwbus0
clk_fixed10: <Fixed clock> on ofwbus0
clk_fixed11: <Fixed clock> on ofwbus0
To reduce this noise, quiet the devices for by default. For verbose
boot, the message will be emitted.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44266
This is standard practice for clock drivers that register clocks
dynamically. Nothing else uses the CLK_DEBUG macro.
The result is that the name and frequency of the fixed clock is printed
for a verbose boot, which may aid in debugging.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44265
The msi address contains apic id. The code in vmbus_pcib_map_msi()
treats it as cpu id, which could cause mis-configuration of msix
IRQs, leading to missing interrupts for SRIOV devices. This happens
when apic id is not the same as cpu id on certain large VM sizes
with multiple numa domains in Azure. Fix this issue by correctly
mapping apic ids to cpu ids.
On vPCI version before 1.4, it only supports up to 64 vcpus
for msi/msix interrupt. This change also adds a check and returns
error if the vcpu_id is greater than 63.
Reported by: NetApp
Tested by: whu
MFC after: 1 week
The firmware lacks support for manually setting 1G and 10G baseT speeds.
However, the driver can enable auto speed masks to achieve automatic configuration
at these speeds.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42960
This update enables the display of pluggable module information
to users via the ifconfig utility.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42958
The newly added port extended hardware statistics are now accessible to
users through the sysctl interface. Also, Few obsolete stats are removed
and few stats are renamed.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42957
Increasing the maximum configurable MTU from 9000 to 9600 to
align with the firmware's capability of handling an MTU up to 9600.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42954
Enabled User Configuration of 1G Speed on Wh+ SFP28 Port with AOC
cable.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42953
The 1G speed on DAC medium is incorrectly labeled as 1000baseT, it
should be 1000baseCX. Updated the label accordingly.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42952
We only see a request with a failed controller while we're in the
process of failing the controller. Add a comment to that effect.
Sponsored by: Netflix
Currently, if a media type (e.g., DAC) is hot-plugged out and another type
(e.g., optical cable) is hot-plugged in, the new speed is not reflected in
ifconfig. This occurs when the driver fails to update speeds with unchanged
tx and rx flow control.
To fix, a phy_type check ensures update of phy speeds upon detecting the new
phy.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42951
We're logging when we start a reset, but not when we complete it, nor
the result. Create now log a success or timed_out event for the reset.
Currently, the only detectable error we have from reset is 'failure to
become ready in time,' though the code looks like it might be more
generic. Log this and if we ever have other failure modes, change the
logging to devd when that happens.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44211
Change the devctl events slightly for the controller. SMART errors will
log the changed bits in the NVME SMART Critical Warning State as its
event.
Reset will now emit 'event=start'. Soon more.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D44210
Split the devctl aspect of things out to its own function in
nvme_ctrlr_devctl_log. In preparing to document this, and based on
actual use, we want something different for the SMART errors, so this
will facilitate that.
Sponsored by: Netflix
Reviewed by: chuck, mav
Differential Revision: https://reviews.freebsd.org/D44209
The firmware package version currently appears as "Unknown" through
the sysctl interface. The parsing logic for extracting the firmware
package version from the package log has been modified to ensure
compatibility with all controllers.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42950
Inline generic_pcie_translate_resource_common into its sole caller.
No functional change.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D44206
The generic_pcie_containing_range helper added in commit d79b6b8ec2
assumed that the passed in (start, end) range used to locate the
containing mapping range was a valid address range (with end >=
start). The previous version of
generic_pcie_translate_resource_common only used the start address to
locate a mapping range, so the end address of 0 did not matter, but an
end of 0 now causes the first range to match and an incorrect
translation for resources using a later range.
PR: 277211
Reported by: dch, tuexen
Reviewed by: tuexen
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44205
Previously ranges were only enumerated for the FDT attachment but not
ACPI. This commit moves the enumeration to the shared attach routine
so it is done for both. While here, don't list empty ranges but do
include the resource type for each range.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44132
In particular, don't try to byteswap the values as 64-bit integers and
always print a non-empty version as a string.
Reviewed by: chuck, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44121
It conflicts with the general "DEBUG" macro defined as an option in LINT
builds. Since this is actually unused, just rename it to GMAC_DEBUG.
Reviewed by: manu
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44102
This uses bus_generic_rman_alloc/release_resource to reduce some code
duplication. However, I've left the custom activate/deactivate
methods as-is.
Differential Revision: https://reviews.freebsd.org/D43939
For SYS_RES_MEMORY, use bus_generic_rman_* for
activate/deactivate_resource methods as well as custom
map/unmap_resource methods that request submappings of the sc_mem
resource allocated from the parent bus.
Differential Revision: https://reviews.freebsd.org/D43938
The sample rate selection of snd_uaudio(4) at runtime was implicitly
relying on a specific order in the device config list. In case a default
was set through the hw.usb.uaudio.default_rate sysctl tunable, commit
42fdcd9fd9 removed a duplicate sample rate entry from that list, which
inadvertently broke sample rate selection at runtime. Implement sample
rate selection in a way that works for any order in the device config
list.
Reported by: Lexi Winter <lexi@le-fay.org>
MFC after: 1 week
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D44051
Add a sysctl tunable to unify all physical ports of an HDSPe sound card
into one pcm device, with up to 14 (AIO) or 36 (RayDAT) channels. This
makes all ports available in multi-channel audio software.
Differential Revision: https://reviews.freebsd.org/D43798
Despite still being in production the device appeared not able to use
memory above BUS_SPACE_MAXADDR_32BIT, and if your desktop has a lot of
memory there is a high chance driver would allocate inaccessible memory.
Submitted by: wulf
Reviewed by: mav
Use the macro "UART_CLASS()" for the newly created data set
'uart_class_set' as we do for other data sets.
This further hides the data set name.
Also add UART_CLASS for quicc, which was previously not done.
MFC after: 1 week
Improves: 949670f8f4 dev/uart: Use a linker set to find uart classes
Obtained from: jhb, 269e99ac86
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D43981
Enabling 11n for ath(4) so far was handled by a kernel option, which
was only enabled for certain kernel configurations.
In order to allow loading ath(4) as a module with 11n support on
all platforms, remove the kernel option and unconditionally enable
11n in ath(4).
Reported by: pkubaj
Discussed with: adrian in D43549.
Reviewed by: adrian, imp
Differential Revision: https://reviews.freebsd.org/D43964
The goal of reserving firmware-assigned resources is to ensure that
"wildcard" resource allocation requests will not claim an address
range that is actually in use even if no attached driver is actively
using that range. However, the current approach can break in some
cases.
In particular, ACPI can enumerate devices behind PCI bridges that
don't show up in a normal PCI scan, but those device_t objects can end
up as direct children of acpi0. Reserving resources for those devices
directly from acpi0 ends up conflicting with later attempts to reserve
the PCI bridge windows.
As a workaround, defer reserving unclaimed resources until after the
initial probe and attach scan. Eventually this pass of reserving
unclaimed resources can be moved earlier, but it requires changes to
other drivers in the tree to permit enumerating devices and reserving
firmware-assigned resources in a depth-first traversal before
attaching devices whose drivers request wildcard allocations.
PR: 272507
Reported by: Justin Tocci <justin@tocci.org>
Reported by: john@feith.com, many others
Tested by: Oleg Sidorkin <osidorkin@gmail.com>, dch
The current xc_printf() function uses an hypercall in order to send character
buffers to the hypervisor for it to print on the hypervisor console (if the
hypervisor is configured to print such messages).
This requires the hypercall page to be initialized, which is extra work and can
go wrong.
On x86 instead of using the console IO hypercall use the debug console IO port,
also called "port E9 hack". This allows sending characters to Xen using an
outb instruction, without any initialization required.
Keep the previous hypervisor based implementation by using the weak attribute,
which allows each architecture to provide an alternate (arch-specific)
implementation.
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43929
When resuming from migration or suspension all regular event channels ports are
reset to the INVALID_EVTCHN value, and drivers should re-initialize them
according to the new value provided by the other end of the connection.
However, the driver would first attempt to unbind the event channel handler
before attempting to bind it using the newly provided port. This unbind uses
the stale event channel port that has been set to INVALID_EVTCHN for some
operations (notably as a result of the handler removal the interrupt subsystem
ends up calling disable intr and source PIC hooks).
This was fine when INVALID_EVTCHN was 0, as then the operation would just
result in pointless setting of the 0 bit in the different event channel related
control arrays (evtchn_{pending,mask} for example). However with the change to
define INVALID_EVTCHN as ~0 the write is no longer pointless, and we end up
triggering a page-fault, or corrupting random data that happens to be mapped at
the array position + ~0 bits.
In hindsight the change of INVALID_EVTCHN from 0 to ~0 was way more risky than
initially assessed, and I believe has end up resulting in more fragile code for
no real benefit.
Fix the disable intr and source wrappers to check whether the event channel is
valid before attempting to use it.
Also introduce some extra KASSERTs in several array accesses in order to avoid
out of bounds accesses if INVALID_EVTCHN ever reaches those functions.
Fixes: 1797ff9627 ('xen/intr: cleanup event channel number use')
MFC after: 1 week
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43928
Assign multi-touch slot number based on internal evdev MT state and
reported tracking ID of contact rather than on sequentional number of
contact in report.
Sponsored by: Serenity Cyber Security
Fixes: ef8397c28e ("add Magic Trackpad 2 (USB only) support")
MFC after: 1 month
