This trips me up whenever I'm fooling around with partially supported
NICs that fail to fully attach or initialise - the firmware gets loaded
and references, but something fails - and the firmware references
aren't cleaned up.
After perusing the PHY-LP code (don't ask why; honest) I discovered that
it /has/ 5GHz support - but it's not ever used. I found one NIC - a
BCM4312 w/ pci id 0x4315 - which advertised dual-band PHY-LP support.
Turns out it works.
Whilst here, move up the support bit logging code so I can use it
to debug this.
Tested:
* BCM4312 (pci id 0x4315); 5GHz STA operation
On Medford, licenses are required to enable RX and event cut through and to
disable RX batching. To avoid the need for the driver to make decisions based on
the licensing state, the MC_CMD_INIT_EVQ has been extended to allow us to leave
the decision to the firmware. If the adapter is licensed for low-latency use,
the firmware will choose the optimal settings for latency, otherwise it will use
the best settings for throughput.
For Huntington we still need to choose the settings ourselves.
Submitted by: Mark Spender <mspender at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6717
This seems to make 5G work better.
It doesn't fix powersave handling though, that still sees the PHY get
stuck during initial calibration and everything goes pear shaped.
I'll look into that later.
Tested:
* QCAFN222 NIC, STA mode, 5GHz
Obtained from: Linux ath9k
Turns out I wasn't even initialising or programming a lot of stuff
for the AR9462 2.1 chip. Oops.
This mostly gets it working. powersave scan results in some pretty
hilarious NFcal hangs and I don't see beacons reliably.
There are still some xlna gain tables missing that ath9k has; I'll
follow up with some fixes and then see if the QCAFN222 NIC I have
tests this path.
Tested:
* QCAFN222 NIC, STA mode, 2GHz and 5GHz
the graphics drivers can benefit from access to the lid handle for querying and getting notifications
Submitted by: kmacy
Differential Revision: https://reviews.freebsd.org/D6643
Fix typo made when adding the blacklistd.conf file to OptionalObsoleteFiles.inc
Submitted by: Herbert J. Skuhra ( herbert at mailbox.org )
Reviewed by: rpaulo
Approved by: rpaulo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D6715
Add support for fetching SPROM data from OTP on chipsets with an
IPX OTP controller (including the BCM43225).
This integrates the NVRAM data source into the chipc_caps capability
structure, and adds a sprom_offset field that can be used with OTP
to locate the SPROM image data (found within the general use
region, H/W subregion).
This also removes one of two duplicate parse error messages reported by
both the bhnd_sprom driver and the underlying SPROM parsing API.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6729
Now that bhnd(4) provides feature parity with the previous siba/mips
implementation, we can switch sentry5 over and begin lifting common
support code out for use across bhnd(4) embedded targets.
Changes:
- Fixed enumeration of siba(4) per-core address maps, required for
discovery of memory mapped chipc flash region on siba(4) devices.
- Simplified bhnd kernel configuration (dropped 'bhndbus' option).
- Replaced files.broadcom's direct file references with their
corresponding standard kernel options.
- Lifted out common bcma/siba nexus support, inheriting from the new
generic bhnd_nexus driver.
- Dropped now-unused sentry5 siba code.
- Re-integrated BCM into the universe build now that it actually compiles.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6712
This adds support for serial (via SPI) and parallel (via CFI) flash
as found on BCM47xx/BCM53xx SoCs.
Submitted by: Michael Zhilin <mizhka@gmail.com>
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6250
- Correct IRQ lines for UART (to fix IRQ lookup in future)
- Check device unit in resource assignment during chipc_add_child
- If chipc hint->size is RM_MAX_END, resource end should be same as window end
- Clear reference from resource list entry to resource in case of resource release
- Add CHIPC_GET_CAPS implementation
- Correct chipc flash constants (to be unshifted)
- Default implementation of get_attach_type should iterate over device tree
- Add default implementation for BHND_CHIPC_GET_CAPS usable by chipc grandchildren
Submitted by: Michael Zhilin <mizhka@gmail.com>
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6584
It turns out that <machine/param.h> actually defines a macro under this
name, even when we're not in kernelspace. This causes us to suppress
some macro definitions that are used by userspace apps.
PR: 210026
Reported by: jbeich@
MFC after: 2 weeks
PowerPC64 has two different ABIs, neither of which is elf64_freebsd_sysvec.
Using sysent and freebsd32_sysent achieves the same effect.
X-MFC-With: r301130
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
This fixes WITH_SYSTEM_COMPILER, WITHOUT_CROSS_COMPILER, external compiler, to
pass the external compiler metadata rather than the ${CC} metadata. On
a build host that has clang as CC it was passing the clang metadata rather than
GCC metadata during the build.
When the low-latency firmware variant is running, it is reported as not
being capable of batching RX events, but it can still do so if the
FORCE_EV_MERGING flag is set on an RXQ. Therefore we need to handle
batched RX events even if the capability isn't set.
If this bug is fixed in the firmware such that the capability is set
even when running the low-latency firmware variant, it will almost
always be reported so I don't think we lose much by removing the check.
Submitted by: Mark Spender <mspender at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6705
This also adjusts the timer values used to match the Linux net
driver implementation:
a) non-zero time intervals should result in at least one quantum
b) timer load/reload values are only zero biased for Falcon/Siena
Submitted by: Andy Moreton <amoreton at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6704
code uses the GetTime function from the Runtime Service, however this has
been shown to not return a useable time on many arm64 UEFI implementations.
Reviewed by: jhb, smh
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D6709
leapfile will be ignored and ntpd will behave as if it has no
leapfile.
While here, remove an extraneous blank line.
Suggested by: ache
MFC after: 1 week
BAR size to 1MB. According to Xeon v3 specifications and my tests, that
size register is write-once and so not writeable after BIOS written it.
Instead of that, make the code work with BAR of any sufficient size,
properly calculating offset within its base. It also simplifies the code.
Discussed with: cem
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
NTB_MSIX_RECEIVED status, before making upper layers overwrite it.
This is not completely perfect, but now it works better then before.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Take care of very old bug leading to heap-buffer overflow by
processing certain file headers via bfd binary.
PR: 200888
Obtained from: OpenBSD
MFC after: 2 weeks
Since no WORLDTMP/usr/bin/cc is created, cc cannot be found
during installworld time since /usr/bin is not in the PATH.
Pass along the known compiler metadata to allow installworld
to work. The same fix was used for WITH_SYSTEM_COMPILER.
A better route would be to store a cookie in buildworld
containing this compiler metadata and then using that
at install time, rather than rerunning cc.
Reported by: Mark Millard
Sponsored by: EMC / Isilon Storage Division
Ccache will not affect the output of the objects, so just ignore it for
meta mode handling. This avoids having everything rebuild if ccache is
updated.
Sponsored by: EMC / Isilon Storage Division
The first file in these lists will generate everything else so only
it should be getting a .meta file. With bmake's missing=yes meta
feature these would otherwise cause a rebuild without the
.NOMETA hint.
Sponsored by: EMC / Isilon Storage Division
This breaks cross-building with WITH_META_MODE since it will rebuild
'build-tools' during the 'everything' phase.
A more proper fix is coming to bmake to implicitly require .META unless
.NOMETA (and other restrictions) are in place.
