If there is a compatible string it likely means that the firmware needs
a dedicated driver (like on RPI*).
PR: 273087
Tested-by: Mark Millard <marklmi26-fbsd@yahoo.com>
Sponsored by: Beckhoff Automation GmbH & Co. KG
Fixes: fdfd3a90b6 ("ofw: Add a ofw_firmware driver")
On 64bit, there is a 4-byte hole in struct vdso_timekeep32 after
tk_current, if the structure is not packed. This is due to the MD
th_x86_pvc_last_systime being 64bit.
Change amd64 VDSO_TIMEHANDS_MD32 to not use uint64_t, replace it with
pair of uint32_t, as it is done for all other members.
PR: 273085
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
If the host doesn't announce VIRTIO_NET_F_CTRL_RX we cannot disable all
multicast traffic. Previously we'd refuse to set the IFF_ALLMULTI flag,
which is the exact opposite of what is actually happening.
This broke things such as igmpproxy.
See also: https://redmine.pfsense.org/issues/14301
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D41356
The panic stack looks like this:
panic: _sx_xlock_hard: recursed on non-recursive sx MANA port lock
@ /usr/src/sys/dev/mana/mana_en.c:1022
KDB: stack backtrace:
vpanic() at vpanic+0x150/frame 0xfffffe011b3c1970
panic() at panic+0x43/frame 0xfffffe011b3c19d0
_sx_xlock_hard() at _sx_xlock_hard+0x82d/frame 0xfffffe011b3c1a70
_sx_xlock() at _sx_xlock+0xb0/frame 0xfffffe011b3c1ab0
mana_cfg_vport() at mana_cfg_vport+0x79/frame 0xfffffe011b3c1b40
mana_alloc_queues() at mana_alloc_queues+0x3b/frame 0xfffffe011b3c1c50
mana_up() at mana_up+0x40/frame 0xfffffe011b3c1c70
mana_ioctl() at mana_ioctl+0x25b/frame 0xfffffe011b3c1cb0
ifhwioctl() at ifhwioctl+0xd11/frame 0xfffffe011b3c1db0
hn_xpnt_vf_init() at hn_xpnt_vf_init+0x15f/frame 0xfffffe011b3c1e10
The lock has already been held in the caller. Remove this
redundant lock attempt.
Reported by: NetApp
Sponsored by: Microsoft
Fix a boot-time panic in qcom_mdio_ipq4018 due to a missing bus function
and hook the file up to the build so that it will not rot away.
Test booted on an ipq807x in 2022.
X-Differential Revision: extracted from D37882
Use IXGBE_GRC_BY_MAC(hw) macro instead of IXGBE_GRC as IXGBE_GRC's
address is different on Denverton platform.
This patch is part of change made in NetBSD kernel
by Masanobu Saitoh, NetBSD maintainer.
Differential Revision: https://reviews.freebsd.org/D19175
Approved by: erj
The x550 uses an upgradable flash code. Check for recovery condition
like other flashable intel cards do in case of fw errors.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31869
With the general removal of MIPS support there's no longer a need to
support these integrated switches.
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D41394
All of these are obsoleted by the general removal of MIPS support.
Actually, corresponding to the removed AH_SUPPORT_x, there is more
superfluous support sprinkled across the HAL source. However, that
code is left in place for now in order to ease a sync to NetBSD.
Reviewed by: emaste (w/ man page fix)
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D41355
Following the removal of general MIPS support, there's no longer a need
to have the AHB bus-frontend in place, which according to Linux sources
also isn't used with any non-MIPS SoCs. For simplicity, PCI bus support
is only made conditional on the main one again, i. e. device ath_pci is
removed, and built into the main module, i. e. if_ath_pci.ko obsoleted,
respectively.
Effectively, this reverts the following commits and associated changes:
dba9c85977e849bb3ecb
Approved by: adrian
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D41354
The two bools in nvme_request create a 6 byte hole today. Move them to
after retires to fill the 4 byte hole there and add a spare[2] to make
nvme_request 8 bytes smaller. spare[2] isn't strictly necessary, but
documents how many bytes we have left in that hole, as the number of
booleans will increase shortly.
Suggested by: chuck
Sponsored by: Netflix
Because the 32-bit md_ioctl structure contains 64-bit members, arm
and powerpc add padding to a multiple of 8. i386 doesn't do this.
The md_ioctl32 definition was correct for amd64/i386 without padding,
but wrong for arm64 and powerpc64. Make __packed__ conditional on
__amd64__, and test for the expected size on non-amd64. Note that
mdconfig is used in the ATF test suite. Note, I verified the
structure size for powerpc, but was unable to test.
MFC after: 1 week
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D41339
Discussed with: jhibbits
We need i2c first to set it to MIDDLE, then we need one of the pmics
so set them to LATE, only then we can attach iodomain which needs some
regulators exposed by the pmic so set it to LAST.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Some SoCs have an external firmware doing power management, clock
and other stuffs. (Xilinx, ARM Juno etc ...)
The way it is represent in the DTB is usually having a 'firmware' node
under the root node and have some nodes under it with the correct
compatible strings.
The firmware node itself doesn't have any compatible strings.
This driver is simple subclassed from simplebus and attaches at
BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE so early drivers (like clock drivers)
can still have a change to attach early.
Reviewed by: andrew
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37612
During porting of etherswitch to NetBSD mistypo was discovered in
Atheros switch version detection.
Reported by: Hiroki Mori yamori813@yahoo.co.jp
MFC after: 1 week
Rather than have a table to walk through, use a sparse array.
Suggested by: jhb
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D41353
Fix comment to note we should grab additional data from the error log
page, but don't currently (it's inclear if we should do that here
and other places in nvd that want it, or if we should let nvd / the
nda periph make the request).
Sponsored by: Netflix
Reviewed by: chuck, mav, jhb
Differential Revision: https://reviews.freebsd.org/D41315
When manually completing an I/O, we do so because we have no status back
from the card. Note M, CRD and P are all 0 because this is an artificial
event (and phase isn't checked when it's completed this way). There's no
MORE information in the error log page and there's no delayed retry
(CRD=0) and we don't currently request CRD to be set to anything other
than 0 and thus don't implement delayed retry.
Sponsored by: Netflix
Reviewed by: chuck, mav, jhb
Differential Revision: https://reviews.freebsd.org/D41314
When we're resetting, and there's outstanding I/O that we're cancelling,
only report we're cancelling the I/O once rather than once per
I/O. Likewise when we reschedule the I/O. We don't need to say for each
one that we're cancelling/rescheduling something, and then report the
I/O that we're doing. Likewise with cancelling admin commands (we never
retry them here, so a similar change isn't needed).
Sponsored by: Netflix
Reviewed by: chuck, mav
Differential Revision: https://reviews.freebsd.org/D41313
get_admin_opcode_string and get_io_opcode_string are identical, but
start with different tables. Use a helper routine that takes an argument
to implement these instead. A future commit will refine this further.
Sponsored by: Netflix
Reviewed by: chuck, mav, jhb
Differential Revision: https://reviews.freebsd.org/D41310
Both nvme_dump_command and nvme_qpair_print_command print nvme
commands. The former latter better. Recode the one call to
nvme_dump_command to use nvme_qpair_print_command and delete the
former. No sense having two nearly identical routines. A future commit
will convert to sbuf.
Sponsored by: Netflix
Reviewed by: chuck, mav, jhb
Differential Revision: https://reviews.freebsd.org/D41309
Both nvme_dump_completion and nvme_qpair_print_completion print
completions. The latter is better. Recode the two instances of
nvme_dump_completion to use nvme_qpair_print_completion and delete the
former. No sense having two nearly identical routines. A future commit
will convert this to sbuf.
Sponsored by: Netflix
Reviewed by: chuck
Differential Revision: https://reviews.freebsd.org/D41308
In commit c77bfaa750 uhid(4) gained support for ioctl from
USB_GET_DEVICEINFO. This is used in libraries like libfido2 to
retrieve information about a device.
This commit adds binary compatible version to hidraw(4).
PR: 264843
MFC after: 1 month
Requested by: grembo
Most em(4) devices now enjoy TSO and TSO6, matching NetBSD and Linux
defaults.
A prior commit automasks TSO on 10/100 Ethernet due to errata and other
bugs for IPv6 were fixed recently allowing this.
Mike Karels identified a performance anomaly on Intel 82574L devices.
These are multiqueue enabled on FreeBSD since the conversion to
iflib. I am investigating whether this can be fixed, in the mean time
MSI-X with checksum offloads remain default.
i219 SPT devices have an errata that downclocks the DMA engine, which
results in TSO not being able to acheive line rate. Therefore, it is
disabled on:
* Intel(R) I219-LM and I219-V SPT
* Intel(R) I219-LM and I219-V SPT-H (2)
* Intel(R) I219-LM and I219-V LBG (3)
* Intel(R) I219-LM and I219-V SPT (4)
* Intel(R) I219-LM and I219-V SPT (5)
Many lem(4) devices enjoy TSO, exceptions being 82542, 82543, 82547.
TSO6 may be possible for some chipsets but I am still working through
my testing matrix and that is hidden behind hw.em.unsupported_tso.
If you encounter issues, you may disable TSO with for example:
ifconfig em0 -tso -tso6.
I ask to be informed of any deviations from normal operation requiring
this.
Thanks to cc@ for access to emulab.net.
On a sample I219 system it saves about 16% CPU on IPv4 and 19% on IPv6.
iperf3 -Vc reported numbers:
total% user% system%
IPv4 TSO
21.3 7 14.4
21.4 6 15.4
21.5 6 15.5
IPv4 no TSO
36.8 5.4 31.4
38.5 5.1 33.5
38.2 5.7 32.6
IPv4 no TSO no TXCSUM
45.1 5.8 39.3
46 6.3 39.7
46.2 5.9 40.4
IPv6 TSO6
21.7 5.4 16.3
21.6 5.1 16.5
21.9 5.6 16.3
IPv6 no TSO6
41.2 5.2 36
41 5.1 36
40.8 5.2 35.7
IPv6 no TSO6 no TXCSUM6
49 5.9 43.1
48.8 4.9 43.9
49 5.6 43.4
Tested by: cc (lem(4)), karels (82574L)
MFC after: 3 months
Relnotes: yes
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D41170
The vlan setting is independent for each interface. Use VFTA table in
'struct ixgbe_softc' that is already defined.
This pull request fixes following bug scenario.
create ixv0.10
create ixv1.10
destroy ixv1.10
create ixv0.11
ixv0.10 no longer receives vlan 10 packets.
In this case, destroying ixv1.10 affects to ixv0.
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/774
When spibus is attached as child of Intel SPI controller it scans all
ACPI nodes for "SPI Serial Bus Connection Resource Descriptor" described
in section 19.6.126 of ACPI specs.
If such a descriptor is found, SPI child is added to spibus, it's SPI
chip select, mode, clock, IRQ resource and ACPI handle are added to ivars.
Existing ACPI bus-hosted child is deleted afterwards.
Apple ACPI SPI extensions are supported.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41248
Required for Apple and Microsoft -compatible HID-over-SPI drivers.
Most logic was already implemented in commit 3c08673438
"spibus: extend API: add cs_delay ivar, KEEP_CS and NO_SLEEP flags".
It dissallowed driver sleeps in the interrupt context. This commit
extends this feature to handle ddb/kdb context with following:
- Skip driver locking if SPI functions were called from kdb/ddb.
- Reinitialize controller if kdb/ddb initiated SPI transfer has
interrupted another already running one. Does not work very
reliable yet.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41247
Some devices like Apple HID-over-SPI may contain more than one report
descriptors necessitating creation of multiple hidbus children.
Add indentificator of child devices to distinct them.
No functional changes intended.
Differential Revision: https://reviews.freebsd.org/D41246
IRQ Resource is allocated on spibus(4). We must release it here too
rather than propagate request down the tree.
Fixes: 4dd8db62e9 ("Add IRQ resource to SPIBUS")
MFC after: 1 week
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41243
Free allocated per-CPU structures in the pcpu_fini and finalize methods.
While here, add debug trace entries to these methods.
Reviewed by: jkoshy, andrew
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41269
Free allocated per-CPU structures in the pcpu_fini and finalize methods.
While here, add debug trace entries to these methods.
Reviewed by: jkoshy, andrew
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41268
The driver belabors the point about unsupported SFPs, printing multiple
times on link up. Limit it to once.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39785
This feature masks TSO capability when a link comes up at 10 or 100mbit
due to errata on the chips. This behavior matches previous versions of
FreeBSD as well as NetBSD and Linux.
A tunable, hw.em.unsupported_tso may be set if the admin desires to
disabling automasking and configure TSO settings manually.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41170
Adds support for detection of the S3X NVMe controller found in the
13" MacBook Pro 2017 without Touch Bar (MacBook14,1)
It is known to be used in following MacBooks:
- Retina MacBook 2016 (MacBook9,1)
- 13" MacBook Pro 2016 without Touch Bar (MacBook13,1)
- 13" MacBook Pro 2016 with Touch Bar (MacBook13,2)
Also disable IPV6 checksum offload.
Spell hw->mac.type < e1000_82543 as e1000_82542. Confusingly, chips
like 82540 and 82541 come later and do not have these issues. There
is no functional change here, as the enum was defined in such a way
it worked correctly. But this reads literally.
MFC after: 1 week
Currently for the MFS, firmware and VDSO template assembly files we pass
the path to include with .incbin unquoted and use __XSTRING within the
assembly file to stringify it. However, __XSTRING doesn't just perform a
single level of expansion, it performs the normal full expansion of the
macro, and so if the path itself happens to tokenise to something that
includes a defined macro in it that will itself be substituted. For
example, with #define MACRO 1, a path like /path/containing/MACRO/in/it
will expand to /path/containing/1/in/it and then, when stringified, end
up as "/path/containing/1/in/it", not the intended string. Normally,
macros have names that start or end witih underscores and are unlikely
to appear in a tokenised path (even if technically they could), but now
that we've switched to GNU C as of commit ec41a96daa ("sys: Switch the
kernel's C standard from C99 to GNU99.") there are a few new macros
defined which don't start or end with underscores: unix, which is always
defined to 1, and i386, which is defined to 1 on i386. The former
probably doesn't appear in user paths in practice, but the latter has
been seen to and is likely quite common in the wild.
Fix this by defining the macro pre-quoted instead of using __XSTRING.
Note that technically we don't need to do this for vdso_wrap.S today as
all the paths passed to it are safe file names with no user-controlled
prefix but we should do it anyway for consistency and robustness against
future changes.
This allows make tinderbox to pass when built with source and object
directories inside ~/path-with-unix, which would otherwise expand to
~/path-with-1 and break.
PR: 272744
Fixes: ec41a96daa ("sys: Switch the kernel's C standard from C99 to GNU99.")
Explicitly set ipcss/ipcse/ipcso for IPv6 per intel SDM as indicated in
inline comments.
Fix and consolidate 82543/82547 hwcsum exemption.
While here rearrange and expand some commentary.
Ringing the doorbell before making the BPF call can result in the
mbuf being freed before the BPF call.
Reviewed-by: markj
MFC-after: 3 days
Differential Revision: https://reviews.freebsd.org/D41189
The ofw_reg_to_paddr() in this file is the powerpc OF_decode_addr()
formerly added in 812403402e. However,
the latter function in turn was based on the sparc64 counterpart I
previously added in 2b2250b149.
The reference to puc(9) is wrong; the page does not exist, and drivers
belong to section 4. Change the reference to puc(4), which does exist.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
While at it, correct the string for 300 series ones, these also are
already xHCI 3.1.
Fixes: d171d2f2 Add AHCI/XHCI device IDs found on AMD Ryzen+B350 system
* em(4) obey administrative ifcaps for using hwcsum offload
* em(4) obey administrative ifcaps for hw vlan receive tagging
* em(4) add additional TSO6 ifcap, but disabled by default as is TSO4
* lem(4) obey administrative ifcaps for using hwcsum offload
* lem(4) add support for hw vlan receive tagging
* lem(4) Add ifcaps for TSO offload experimentation, but disabled by
default due to errata and possibly missing txrx code.
* lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around
full duplex links. It may still be administratively enabled.
Reviewed by: markj (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30072
Add CAM_NVME_STATUS_ERROR error code. Flag all NVME commands that
completed with an error status as CAM_NVME_STATUS_ERROR (a new value)
instaead of CAM_REQ_CMP_ERR. This indicates to the upper layers of CAM
that the 'cpl' field for nvmeio CCBs is valid and can be examined for
error recovery, if desired.
No functional change. nda will still see these as errors, call
ndaerror() to get the error recovery action, etc. cam_periph_error will
select the same case as before (even w/o the change, though the change
makes it explicit).
Sponsored by: Netflix
Reviewed by: chuck, mav, jhb
Differential Revision: https://reviews.freebsd.org/D41085
* em(4) obey administrative ifcaps for using hwcsum offload
* em(4) obey administrative ifcaps for hw vlan receive tagging
* em(4) add additional TSO6 ifcap, but disabled by default as is TSO4
* lem(4) obey administrative ifcaps for using hwcsum offload
* lem(4) add support for hw vlan receive tagging
* lem(4) Add ifcaps for TSO offload experimentation, but disabled by
default due to errata and possibly missing txrx code.
* lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around
full duplex links. It may still be administratively enabled.
Reviewed by: markj (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30072
Always set TXD_CMD_IP for 82544
Otherwise set TXD_CMD_IP for IPv4, not IPv6
Reviewed by: markj (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30072
In some cases driver may ask FW about link state before FW finishes
configuration of a (Q)SFP+ transceiver. If first attempt of using Get Link
Status AQC after loading driver or handling a reset fails, then re-try
periodically for 5 seconds.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Tested by: jeffrey.e.pieper@intel.com
Approved by: erj@
MFC after: 2 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D40899
rid was stack garbage, so the bus_alloc_resource_any() call could fail
and fall through to the SMCCC version check even if a bridge had a
memory resource.
Debugging help: jrtc27
Reviewed by: jrtc27
Fixes: c9a05c0722 Add a PCI driver that follows the Arm DEN0115 spec
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41025
Use autonegotiated link speed value while updating link status
to iflib.
This patch is part of change made in NetBSD kernel
by Masanobu Saitoh, NetBSD maintainer.
Differential Revision: https://reviews.freebsd.org/D19176
Approved by: erj
The default per-queue packet rate of 8000 will cause packet loss when
forwarding at 2.5G with a single stream, as is common when using e.g.
iperf3 to test a platform.
Bump this to 20000 (the "low latency" value in the Linux driver) which
avoids packet loss for this type of test.
Future work will use adaptive interrupt rate in a similar fashion
to the ixgbe driver.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Reviewed by: erj, kp
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D40904
It points to non-existent documentation. The wiki page still contains a
useful overview, so keep this link.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Rename isp_rd_2400_nvram to isp_rd_2xxx_flash.
Cleanup some leftovers.
Hide all output regarding FLT parsing behind ISP_LOGDEBUG0.
Thanks to imp@ and mav@ for reviewing and commenting.
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
The ISP26xx based HBAs are left as is for now with static NVRAM addressing.
Those HBAs are known as 83xx (2031 and 8031 for real) and need special handling.
This is left for further investigation for now.
Cosmetics:
- rename functions and defines as they are no longer specific to 28xx
- set reasonable log levels
- sort FLT and NVRAM functions (in the order they are used)
Tested and approved to work on real hardware with:
- Qlogic ISP 2532 (QLogic QLE2562 8Gb 2Port FC Adapter)
- Qlogic ISP 2722 (QLogic QLE2690 16Gb FC Adapter)
- Qlogic ISP 2812 (QLogic QLE2772 32Gbit 2Port FC Adapter)
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
The FLT is like a TOC for the flash area and contains entries for every flash
region with start/end address, size and flags.
Start using NVRAM addresses from FLT instead of hardcoded ones for ISP28xx
based HBAs.
The FLT should be available on earlier HBAs too, probably since ISP24xx based.
This needs further investigation and testing.
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
Use correct NVRAM address for ISP28xx based HBAs to read NVRAM contents.
WWPN/WWNN and framesize are correctly read from NVRAM now.
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
This covers the following HBAs:
ISP2812-based 64/32G Fibre Channel to PCIe Controller:
QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter
QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter
QLE2870 Single Port 64GFC PCIe Gen4 x8 Adapter
QLE2872 Dual Port 64GFC PCIe Gen4 x8 Adapter
ISP2814-based 64/32G Fibre Channel to PCIe Controller:
QLE2774 Quad Port 32GFC PCIe Gen4 x16 Adapter
QLE2874 Quad Port 64GFC PCIe Gen4 x16 Adapter
While here, add required bits to support 64GB FC.
Default framesize is set to 2048 for ISP28xx based HBAs for now.
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
Refactor to eliminate duplicated rate and delay tables, with minor style
tweaks for changed lines. Remove an obsolete comment about needing to
convert from microseconds to ticks (that's done elsewhere). Remove
traiing whitespace in kbdcontrol.c.
Except for the new warning, no change in behavior
Sponsored by: DSS GmbH
Reviewed by: imp [minor style tweaks as well]
Pull Request: https://github.com/freebsd/pull/683
Differential Revision: https://reviews.freebsd.org/D38818
To enable faster debug of customer issues Intel wants an end user to
gather information about PHY configuration and status to debug link and
connection issues in the field. For this reason the end user should
have possibility of obtaining PHYs registers values at runtime during
debugging.
Differential Revision: https://reviews.freebsd.org/D40354
Approved by: erj
Simply speaking, being started the drm-kmod driver should create sysfs helpers,
which is «drm» class devices, with the unit number 0, 128 and, perhaps 64.
If a drm helper created by vgapci driver with the corresponding unit number
exists then the drm-kmod driver initialize it by the device_initialize() lkpi
method, otherwise drm-kmod driver create new «drm» device.
For hw, where two or more different GPU installed, it's not guaranteed that
the order of loading GPU drivers will be the same as the vgapci devices numbered.
I.e., on hw where vgapci0 is Nvidia GPU and vgapci1 is Intel GPU, when drm-kmod
loaded first it will use drm0 helper of vgapci0 device.
There is no problem for drm-kmod driver unless we do not traverse device
tree, as needed for https://reviews.freebsd.org/D38545.
drm-kmod is ok for this change as it has fallback to create corresponding
drm device.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D38546
- Add new DB_DEFINE_TABLE and DB_DECLARE_TABLE macros to define new
command tables. DB_DECLARE_TABLE is intended for use in headers
similar to MALLOC_DECLARE and SYSCTL_DECL.
DB_DEFINE_TABLE takes three arguments, the name of the parent table,
the command name, and the name of the table itself, e.g.
DB_DEFINE_TABLE(show, foo, show_foo) defines a new "show foo" table.
- DB_TABLE_COMMAND, DB_TABLE_COMMAND_FLAGS, DB_TABLE_ALIAS, and
DB_ALIAS_FLAGS allow new commands and aliases to be defined. These
are similar to the existing DB_COMMAND, etc. except that they take
an initial argument giving the name of the parent table, e.g.:
DB_TABLE_COMMAND(show_foo, bar, db_show_foo_bar)
defines a new "show foo bar" command.
This provides a cleaner interface than the ad-hoc use of internal
macros like _DB_SET that was required previously (e.g. in cxgbe(4)).
This retires DB_FUNC macro as well as the internal _DB_FUNC macro.
Reviewed by: melifaro, kib, markj
Differential Revision: https://reviews.freebsd.org/D40819
