Currently if an e1000 interface is set to a fixed media configuration,
for gigabit, it will participate in auto-negotiation as required by
IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
for 100 or 10, it does NOT participate in auto-negotiation.
By my reading of Clauses 28 and 37, while auto-negotiation is optional
for 100 and 10, it is not prohibited and is, in fact, "highly
recommended".
This patch enables auto-negotiation for fixed 100 and 10 media
configuration, in a similar manner to that already performed for 1000.
I.e., the patch enables advertising of just the manually configured
settings with the goal of allowing the remote end to match the manually
configured settings if it has them available.
To be clear, this patch does NOT allow an em(4) interface that has been
manually configured with specific media settings to respond to
auto-negotiation by then configuring different parameters to those that
were manually configured. The intent of this patch is to fully comply
with the requirements of Clause 37, but for 100 and 10.
The need for this has arisen on an em(4) link where the other end is
under a different administrative control and is set to full
auto-negotiation. Due to the cable length GigE is not working well. It
is desired to set the em(4) end to "media 100baseTX mediatype
full-duplex" which does work when both ends are configured that way.
Currently, because em(4) does not participate in autoneg for this
setting, the remote defaults to half-duplex - i.e., there's a duplex
mismatch and things don't work. With this patch, em(4) would inform the
remote that it has only 100baseTX full, the remote would match that and
it will work.
Approved by: erj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D34449
New connections will use the new values. Existing connections are not
affected.
Obtained from: jhb@
MFC after: 3 weeks
Sponsored by: Chelsio Communications
As the PolarFire SoC needs SGMII to connect the PHY, check the
'phy-mode' property of device tree node for ethernet and act on it
appropriately.
Add the compatible strings for the PolarFire SoC device tree.
'microchip,mpfs-mss-gem" is not officially documented but has been
observed in the available firmware for this platform, so it is included
for now.
Also, fix a typo in if_cgem_hw.h.
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: Conclusive Engineering
Differential Revision: https://reviews.freebsd.org/D34764
Rather than doing these checks based on the detected hardware variant, allow
quirks to be specified as a set of flags for each compatible string.
This simplifies adding support for new compatible hardware.
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: Conclusive Engineering
Differential Revision: https://reviews.freebsd.org/D34764
All supported compilers (modern versions of GCC and clang) support
this.
PR: 263102 (exp-run)
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D34802
All supported compilers (modern versions of GCC and clang) support
this.
Many places didn't have an #else so would just silently do the wrong
thing. Ancient versions of icc (the original motivation for this) are
no longer a compiler FreeBSD supports.
PR: 263102 (exp-run)
Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D34797
Both of these headers check for _SYS_CDEFS_H_ after including
<sys/param.h> which itself includes <sys/cdefs.h>.
PR: 263102 (exp-run)
Reviewed by: brooks, imp, emaste
Differential Revision: https://reviews.freebsd.org/D34795
When FreeBSD is running as dom0 (initial domain) on a Xen system it
has access to the native ACPI tables and is the OSPM. However the
hypervisor is the entity in charge of the CPU idle and frequency
states, and in order to perform this duty it requires information
found the ACPI dynamic tables that can only be parsed by the OSPM.
Introduce a new Xen specific ACPI driver to fetch the Processor
related information and upload it to Xen. Note that this driver needs
to take precedence over the generic ACPI CPU driver when running as
dom0, so downgrade the probe score of the native driver to
BUS_PROBE_DEFAULT in order for the Xen specific driver to use
BUS_PROBE_SPECIFIC.
Tested on an Intel NUC to successfully parse and upload both the Cx and
Px states to Xen.
Sponsored by: Citrix Systems R&D
Reviewed by: jhb kib
Differential revision: https://reviews.freebsd.org/D34841
