Colin Percival [Sun, 30 May 2021 20:17:11 +0000 (20:17 +0000)]
MFC loader+userland TSLOG support
stand/common: Add file_addbuf()
libsa: Add support for timestamp logging (tslog)
stand/common: Add support for timestamp logging (tslog)
i386/loader: Call tslog_init
efi/loader: Call tslog_init (+ bugfix)
stand/common command_boot: Pass tslog to kernel
kern_tslog: Include tslog data from loader
loader: Use tslog to instrument some functions
Add userland boot profiling to TSLOG (+ bugfix)
Summary:
One was required to press a key to continue after every 18 lines of
output. This requirement had been in the "show vmopag" command since it
was introduced, which was many years before paging was added to DDB.
With paging, this explict key check is no longer necessary.
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
Test Plan:
Run "show vmopag" from db> prompt and see that it does not need additional
keypresses other than the ones needed for the pager.
Bjoern A. Zeeb [Tue, 30 Nov 2021 14:23:18 +0000 (14:23 +0000)]
fw_stub: fix -Wunused-but-set-variable for firmware files
In case we are only embedding a single firmware image the variable
"parent" gets set but never used. Add checks for the number of files
for it and only print it out if we are exceeding the single file count.
This fixes -Wunused-but-set-variable warnings for the majority of
firmware files in the tree.
Bjoern A. Zeeb [Mon, 13 Dec 2021 22:10:25 +0000 (22:10 +0000)]
rc: network.subr improve network6_getladdr()
In network6_getladdr() we are iterating over inet6 lines and are not
interested in any others. So tell ifconfig to limit output to "inet6"
as much as possible.
This is probably a micro-optimisation but was noticed while looking
at other IPv6-related boot-time improvements.
Mark Johnston [Tue, 28 Dec 2021 22:44:57 +0000 (17:44 -0500)]
x86: Do not attempt to calibrate the LAPIC timer if no APIC is present
Reported and tested by: Michael Butler <imb@protected-networks.net>
Reviewed by: jhb, kib
Fixes: 62d09b46ad75 ("x86: Defer LAPIC calibration until after timecounters are available")
Sponsored by: The FreeBSD Foundation
Mark Johnston [Mon, 6 Dec 2021 15:42:19 +0000 (10:42 -0500)]
x86: Perform late TSC calibration before LAPIC timer calibration
This ensures that LAPIC calibration is done using the correct tsc_freq
value, i.e., the one associated with the TSC timecounter. It does mean
though that TSC calibration cannot use sbinuptime() to read the
reference timecounter, as timehands are not yet set up.
Reviewed by: kib, jhb
Sponsored by: The FreeBSD Foundation
Mark Johnston [Mon, 6 Dec 2021 15:42:10 +0000 (10:42 -0500)]
x86: Defer LAPIC calibration until after timecounters are available
This ensures that we have a good reference timecounter for performing
calibration.
Change lapic_setup to avoid configuring the timer when booting, and move
calibration and initial configuration to a new lapic routine,
lapic_calibrate_timer. This calibration will be initiated from
cpu_initclocks(), before an eventtimer is selected.
Reviewed by: kib, jhb
Sponsored by: The FreeBSD Foundation
Mark Johnston [Mon, 15 Nov 2021 20:31:21 +0000 (15:31 -0500)]
x86: Implement deferred TSC calibration
There is no universal way to find the TSC frequency. Newer Intel CPUs
may report it via CPUID leaves 0x15 and 0x16. Sometimes it can be
obtained from the PLATFORM_INFO MSR as well, though we never use that.
On older platforms we derive the frequency using a DELAY(1000000) call,
which uses the 8254 PIT. On some newer platforms the 8254 is apparently
non-functional, leading to bogus calibration results. On such platforms
the TSC frequency must be available from CPUID. It is also possible to
disable calibration with a tunable, in which case we try to parse the
brand string if the TSC freq is not available from CPUID.
CPUID 0x15 provides an authoritative TSC frequency value, but even that
is not always available on new Intel platforms. CPUID 0x16 provides the
specified processor base frequency, which is not the same as the TSC
frequency. Empirically, it is close enough for early boot, but too far
off for timekeeping: on a Comet Lake NUC, CPUID 0x16 yields 1600MHz but
the TSC frequency is rougly 1608MHz, leading to frequent clock stepping
when NTP is in use.
Thus we have a situation where we cannot calibrate using the PIT and
cannot obtain a precise frequency from CPUID (or MSRs). This change
seeks to address that by using the CPUID 0x16 value during early boot
and refining the calibration later once ACPI-based timecounters are
available. TSC frequency detection is thus split into two phases:
Early phase:
- On Intel platforms, query CPUID 0x15 and 0x16 and use that value
initially if available.
- Otherwise, get an estimate using the PIT, reducing the delay loop to
100ms from 1s.
- Continue to register the TSC as the CPU ticks provider early, even
though the frequency may be off. Otherwise any code executed during
boot that uses cpu_ticks() (e.g., context switching) gets tripped up
when the ticks provider changes.
Later phase:
- In SI_SUB_CLOCKS, once the timehands are initialized, load the current
TSC and timecounter (sbinuptime()) values at the beginning and end of
a 1s interval and use the timecounter frequency (typically from
kvmclock, HPET or the ACPI PM timer) to estimate the TSC frequency.
- Update the TSC timecounter, global tsc_freq and CPU ticker with the
new frequency and finally register the TSC as a timecounter.
Reviewed by: kib, jhb (previous version)
Discussed with: imp, cperciva
Sponsored by: The FreeBSD Foundation
Piotr Kubaj [Mon, 22 Nov 2021 02:28:46 +0000 (03:28 +0100)]
Add assembly optimized code for OpenSSL on powerpc, powerpc64 and powerpc64le
Summary:
1. https://github.com/openssl/openssl/commit/34ab13b7d8e3e723adb60be8142e38b7c9cd382a
needs to be merged for ELFv2 support on big-endian.
2. crypto/openssl/crypto/ppccap.c needs to be patched.
Same reason as in https://github.com/openssl/openssl/pull/17082.
Bjoern A. Zeeb [Sun, 26 Dec 2021 15:33:48 +0000 (15:33 +0000)]
IPv4: fix redirect sending conditions
RFC792,1009,1122 state the original conditions for sending a redirect.
RFC1812 further refine these.
ip_forward() still sepcifies the checks originally implemented for these
(we do slightly more/different than suggested as makes sense).
The implementation added in 8ad114c082a159c0dde95aa35d2e3e108aa30a75
to ip_tryforward() however is flawed and may send a "multi-hop"
redirects (to a host not on the directly connected network).
Do proper checks in ip_tryforward() to stop us from sending redirects
in situations we may not. Keep as much logic out of ip_tryforward()
and in ip_redir_alloc() and only do the mbuf copy once we are sure we
will send a redirect.
While here enhance and fix comments as to which conditions are handled
for sending redirects in various places.
Andrew Turner [Tue, 14 Dec 2021 15:49:07 +0000 (15:49 +0000)]
Fix dtrace fbt return probes on arm64
As with arm and riscv fix return fbt probes on arm64. arg0 should be
the offset within the function of the return instruction and arg1
should be the return value.
Reviewed by: kp, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33440
Andrew Turner [Fri, 19 Nov 2021 11:32:58 +0000 (11:32 +0000)]
Add accelerated arm64 sha512 to libmd
As with sha256 add support for accelerated sha512 support to libmd on
arm64. This depends on clang 13+ to build as this is the first release
with the needed intrinsics. Gcc should also support them, however from
a currently unknown release.
Reviewed by: cem
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33373
Andrew Turner [Tue, 7 Dec 2021 14:23:13 +0000 (14:23 +0000)]
Handle table attributes in the arm64 kernel map
When getting the arm64 kernel maps sysctl we should look at the table
attributes as well as the block/page attributes. These attributes are
different to the last level attributes so need to be translated.
The previous code assumed the table and block/page attributes are
identical, however this is not the case. Handle the difference by
extracting the code into new helper functions & calling them as needed
based on the entry type being checked.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33321
Andrew Turner [Mon, 6 Dec 2021 13:08:39 +0000 (13:08 +0000)]
Teach vm.pmap.kernel_maps about both XN bits
The arm64 vm.pmap.kernel_maps sysctl would only check the kernel XN bit
when printing the kernel mapping. It can also be useful to check none
of the mappings allow userspace to execute from a given virtual address.
To check for this add the user XN bit when getting the kernel maps.
While here fix the ATTR_S1_AP_USER check to use ATTR_S1_AP to shift the
value to the correct offset.
Reviewed by: kib (earlier version), markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33304
Andrew Turner [Tue, 14 Dec 2021 18:09:47 +0000 (18:09 +0000)]
Don't fail changing props for unmapped DMAP memory
When recursing in pmap_change_props_locked we may fail because there is
no pte. This shouldn't be considered a fail as it may happen in a few
cases, e.g. there are multiple normal memory ranges with device memory
between them.
Reported by: cperciva
Tested by: cperciva
Reviewed by: alc, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33459
Andrew Turner [Tue, 14 Dec 2021 10:05:15 +0000 (10:05 +0000)]
Only change DMAP props on DMAP covered memory
When changing memory properties in the arm64 pmap we need to keep both
the kernel address and DMAP mappings in sync.
To keep the kernel and DMAP memory in sync we recurse when updating the
former to also update the latter. There was insuffucuent checking around
this recursion. It would check if the virtual address is not within the
DMAP region, but not if the physical address is covered.
Add the missing check as without it the recursion may return an error.
Mark Johnston [Tue, 14 Dec 2021 20:10:46 +0000 (15:10 -0500)]
vm_fault: Fix vm_fault_populate()'s handling of VM_FAULT_WIRE
vm_map_wire() works by calling vm_fault(VM_FAULT_WIRE) on each page in
the rage. (For largepage mappings, it calls vm_fault() once per large
page.)
A pager's populate method may return more than one page to be mapped.
If VM_FAULT_WIRE is also specified, we'd wire each page in the run, not
just the fault page. Consider an object with two pages mapped in a
vm_map_entry, and suppose vm_map_wire() is called on the entry. Then,
the first vm_fault() would allocate and wire both pages, and the second
would encounter a valid page upon lookup and wire it again in the
regular fault handler. So the second page is wired twice and will be
leaked when the object is destroyed.
Fix the problem by modify vm_fault_populate() to wire only the fault
page. Also modify the error handler for pmap_enter(psind=1) to not test
fs->wired, since it must be false.
PR: 260347
Reviewed by: alc, kib
Sponsored by: The FreeBSD Foundation
Clean up a couple of MD warts in vm_fault_populate():
--Eliminate a big ifdef that encompassed all currently-supported
architectures except mips and powerpc32. This applied to the case
in which we've allocated a superpage but the pager-populated range
is insufficient for a superpage mapping. For platforms that don't
support superpages the check should be inexpensive as we shouldn't
get a superpage in the first place. Make the normal-page fallback
logic identical for all platforms and provide a simple implementation
of pmap_ps_enabled() for MIPS and Book-E/AIM32 powerpc.
--Apply the logic for handling pmap_enter() failure if a superpage
mapping can't be supported due to additional protection policy.
Use KERN_PROTECTION_FAILURE instead of KERN_FAILURE for this case,
and note Intel PKU on amd64 as the first example of such protection
policy.
Andriy Gapon [Mon, 6 Dec 2021 07:59:28 +0000 (09:59 +0200)]
vmxnet3: skip zero-length descriptor in the middle of a packet
Passing up such descriptors to iflib is obviously wasteful.
But the main conern is that we may overrun iri_frags array because of
them. That's been observed in practice.
Also, assert that the number of fragments / descriptors / segments is
less than IFLIB_MAX_RX_SEGS.
Dimitry Andric [Fri, 24 Dec 2021 11:46:00 +0000 (12:46 +0100)]
Apply clang fix for crash or assertion failure compiling part of llvm
Merge commit 77e8f4eeeeed from llvm git (by David Green):
[ARM] Define ComplexPatternFuncMutatesDAG
Some of the Arm complex pattern functions call canExtractShiftFromMul,
which can modify the DAG in-place. For this to be valid and handled
successfully we need to define ComplexPatternFuncMutatesDAG.
When building parts of llvm targeting armv6 on stable/12, the following
assertion can appear (or if assertions are disabled, clang is likely to
crash):
Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon, file /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 3573.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/obj/usr/src/freebsd12-amd64/tmp/usr/bin/c++ -cc1 -triple armv6kz-unknown-freebsd12.3-gnueabihf -S --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -mrelocation-model static -mconstructor-aliases -target-cpu arm1176jzf-s -target-feature +vfp2 -target-feature +vfp2sp -target-feature -vfp3 -target-feature -vfp3d16 -target-feature -vfp3d16sp -target-feature -vfp3sp -target-feature -fp16 -target-feature -vfp4 -target-feature -vfp4d16 -target-feature -vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature -fp-armv8d16 -target-feature -fp-armv8d16sp -target-feature -fp-armv8sp -target-feature -fullfp16 -target-feature +fp64 -target-feature -d32 -target-feature -neon -target-feature -sha2 -target-feature -aes -target-feature -fp16fml -target-feature +strict-align -target-abi aapcs-linux -mfloat-abi hard -fallow-half-arguments-and-returns -ffunction-sections -fdata-sections -O1 -std=c++14 -fdeprecated-macro -fno-rtti -fno-signed-char -faddrsig -fexperimental-new-pass-manager PPCISelLowering-009095.ii
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'PPCISelLowering-009095.cpp'.
4. Running pass 'ARM Instruction Selection' on function '@_ZN4llvm17PPCTargetLoweringC2ERKNS_16PPCTargetMachineERKNS_12PPCSubtargetE'
This crash or assertion is fixed by the upstream commit.
Dimitry Andric [Mon, 20 Dec 2021 09:52:02 +0000 (10:52 +0100)]
tests/libalias: Make inline functions static inline
In C, plain inline functions should never be used: they should be
declared either static inline or extern inline. In this case, they are
clearly meant to be static inline.
黃清隆 [Mon, 13 Dec 2021 16:09:15 +0000 (08:09 -0800)]
sys/dev/arcmsr: Update Areca RAID driver to fix some issues on ARC-1886.
1. Doorbell interrupt status may arrive lately when doorbell interrupt on
ARC-1886.
2. System boot up hung when ARC-1886 with no volume created or no device
attached.
Many thanks to Areca for continuing to support FreeBSD.
Rick Macklem [Mon, 13 Dec 2021 23:21:31 +0000 (15:21 -0800)]
nfsd: Limit parsing of layout errors to maxcnt bytes
This patch decrements maxcnt by the appropriate
number of bytes during parsing and checks to see
if there is data remaining. If not, it just returns
from nfsrv_flexlayouterr() without further processing.
This prevents the tl pointer from running off the end
of the error data pointed at by layp, if there are
flaws in the data.
Domagoj Stolfa [Fri, 17 Dec 2021 16:01:54 +0000 (11:01 -0500)]
dtrace: Disable getf() as it is broken on FreeBSD
getf() on FreeBSD calls _sx_slock(), _sx_sunlock() and fget_locked().
Furthermore, it does not set the per-core fault flag, meaning it
usually ends up in a double fault panic once getf() does get called,
especially from fbt.
Reviewing the DTrace Toolkit + a number of other scripts scattered
around FreeBSD, I have not been able to find one use of getf(). Given
how broken the implementation currently is, we disable it until it
can be implemented properly.
Also comment out a test in aggs/tst.subr.d for getf().
Rick Macklem [Sun, 12 Dec 2021 23:40:30 +0000 (15:40 -0800)]
nfscl: Fix must_commit handling for mirrored pNFS mounts
For pNFS mounts to mirrored Flexible File layout pNFS servers,
the "must_commit" component in the nfsclwritedsdorpc
structure must be checked and the "must_commit" argument passed
into nfscl_doiods() must be updated. Technically, only writes to
the DS with a writeverf change must be redone, but since this
occurrence will be rare, the must_commit argument to nfscl_doiosd()
is set to 1, so all writes to all DSs will be redone.
This bug would affect few, since use of mirrored pNFS servers
is rare and "writeverf" rarely changes. Normally "writeverf"
only changes when a NFS server reboots.
Andriy Gapon [Wed, 15 Dec 2021 11:37:59 +0000 (13:37 +0200)]
mmc_sim: fix setting of the mutex name
To quote the manual:
The pointer passed in as name and type is saved rather than the data
it points to. The data pointed to must remain stable until the mutex
is destroyed.
It seems that the type is actually copied, but the name is stored as
a pointer indeed.
mmc_cam_sim_alloc used a name stored on stack.
So, a corrupt mutex name would be reported.
For example:
lock order reversal: (sleepable after non-sleepable)
1st 0xd7285b20 <8A><C0><C0>P@<C1><D0>P@<C1>^D^A (aw_mmc_sim, sleep mutex) @ sys/cam/cam_xpt.c:2804
This change moves the name to struct mmc_sim.
Also, that name is used as the sim name as well.
Unused mtx_name variable is removed too.
The name buffer is reduced to 16 characters.
Rick Macklem [Sat, 11 Dec 2021 23:00:30 +0000 (15:00 -0800)]
nfscl: Fix must_commit/writeverf handling for Direct I/O
Without this patch, the KASSERT(must_commit == 0,..) can be
triggered by the writeverf in the Direct I/O write reply changing.
This is not a situation that should cause a panic(). Correct
handling is to ignore the change in "writeverf" for Direct
I/O, since it is done with NFSWRITE_FILESYNC.
This patch modifies the semantics of the "must_commit"
argument slightly, allowing an initial value of 2 to indicate
that a change in "writeverf" should be ignored.
It also fixes the KASSERT()s.
This bug would affect few, since Direct I/O is not enabled
by default and "writeverf" rarely changes. Normally "writeverf"
only changes when a NFS server reboots, however I found the
bug when testing against a Linux 5.15.1 kernel nfsd, which
replied to a NFSWRITE_FILESYNC write with a "writeverf" of all
0x0 bytes.
Alexander Motin [Fri, 17 Dec 2021 20:24:56 +0000 (15:24 -0500)]
ahci(4): Allow enclosure emulation without hardware.
After 53f5ac1310e allowed SATA device mapping to enclosure slots,
it may have sense to provide enclosure device emulation even without
real hardware interface like SGPIO just for purposes of physical
device location tracking (still assuming straight cabling).
Andriy Gapon [Sun, 19 Dec 2021 09:26:40 +0000 (11:26 +0200)]
twsi: fix handling of consecuitve write messages in transaction
Make sure to reset 'message_done' flag when jumping from a message to the
next one within the same interrupt handler call. This happens only when
a write with no-stop flag message is followed by a write with no-start
flag message.
Without this fix the second message would be prematurely "completed"
without waiting for an ACK (or NACK) for its first byte and without
sending subsequent bytes (if any).
Fixes: ff1e8581 twsi: support more message combinations in transfers
Doug Moore [Thu, 16 Dec 2021 18:20:56 +0000 (12:20 -0600)]
vm: Don't break vm reserv that can't meet align reqs
Function vm_reserv_test_contig has incorrectly used its alignment
and boundary parameters to find a well-positioned range of empty pages
in a reservation. Consequently, a reservation could be broken
mistakenly when it was unable to provide a satisfactory set of pages.
Rename the function, correct the errors, and add assertions to detect
the error in case it appears again.
Alexander Motin [Thu, 9 Dec 2021 02:06:11 +0000 (21:06 -0500)]
mca: Some error handling logic improvements.
- Enable local MCEs on capable Intel CPUs. It delivers exceptions
only to the affected CPU instead of global broadcast, requiring a lot
of synchronization between CPUs. AMD always deliver MCEs locally.
- Make MCE handler process only uncorrected errors, while CMCI and
polling only corrected. It reduces synchronization problems between
them and is explicitly recommended by the documentation.
- Add minimal support for uncorrected software recoverable errors
on Intel CPUs. It allows to avoid kernel panics in case uncorrected
errors do not affect current operation, like ones found during scrub
or write. Such errors are only logged, postponing the panic until
the corrupted data will actually be needed (that may never happen).
- Reduce polling period from 1 hour to 5 minutes.
Alexander Motin [Thu, 16 Dec 2021 16:44:34 +0000 (11:44 -0500)]
loader.efi: Do not use as frame buffer BLT-only GOPs.
Kernel needs physical frame buffer address and size, which Block
Transfer-only Graphics Output Protocol instances do not have.
Some recent ASUS boards like PRIME Z690M-PLUS D4 and PRIME H570-Plus
report two GOPs, out of which the second one support ConOut protocol,
that made it preferable, but is BLT-only, that made console unusable.
The e1000 drivers (em, lem, igb) are currently looking at the
iflib copies of the capabilities bitvectors (scctx->isc_capabilities
and scctx->isc_capenable) rather than the ifnet ones
(ifp->if_capabilities and ifp->if_capenable). However, the latter
are the ones that are actually updated by ifconfig and that should
be used by the drivers during interface operation. The former are
set by the driver on interface attach (for iflib internal use)
and should not be used anymore by the driver.
This patch fixes the e1000 driver to use the correct bitvectors.
Andriy Gapon [Wed, 15 Dec 2021 11:00:45 +0000 (13:00 +0200)]
rk_i2c_fill_tx: fix a number of issues
- maximum number of bytes that can be sent is 32, not 8;
- previous interface required callers to bump sc->msg->len in addition
to setting sc->tx_slave_addr;
- because of the above there was an issue with writing one too many bytes
because sc->cnt is not advanced when the slave address is written;
- the inetraction between outer and inner loops was confusing as the former
was bounded on the number of bytes to write and the counter was
incremented by one, but the inner loop advanced four bytes at a time;
- the return value was incorrect in the tx_slave_addr case; one call place
had to use its own (and incorrect in some cases) notion of the write
lenth.
All of the above issues should be fixed.
Some sanity asserts are added.
All callers use the return value to program RK_I2C_MTXCNT.
iic_msg::len no longer needs to be hacked.
A constant is added to reflect the maximum number of octets that can be
sent or received in one go (they are the same).
Andriy Gapon [Wed, 15 Dec 2021 09:11:15 +0000 (11:11 +0200)]
rk_i2c_transfer: minor improvement to bit twiddling
No need to mask a uint8_t with 0xff, the mask covers the whole type.
Explcitly cast to uint32_t before bit shifting instead of relying on
the implicit promotion to signed int.
Andriy Gapon [Wed, 15 Dec 2021 08:51:24 +0000 (10:51 +0200)]
rk_i2c: keep sending bytes until all bytes are sent
Previously the code would decalre the transfer complete after sending
first 31 bytes (plus the slave address) of a larger I2C write transfer.
That was tested using a large write to an EEPROM with 32-byte write page
size and a 2-byte address type. Such a transaction needed to send 34
bytes, 2 bytes for an offset and 32 bytes of actual data.
Cy Schubert [Sun, 12 Dec 2021 23:57:36 +0000 (15:57 -0800)]
ipfilter: Fix struct ifnet pointer type
The fr_info struct contains a summary of a packet. One of its fields
is a pointer to the ifnet struct the packet arrived on. It is pointed
to by a void* because ipfilter supports multiple O/Ses. Unfortunately
this makes it difficult it examine with DTrace. Defining fin_ifp as a
pointer to an ifnet struct makes the struct it points to using a DTrace
script possible.
Emmanuel Vadot [Wed, 1 Dec 2021 15:13:09 +0000 (16:13 +0100)]
fb: Add new FBTYPE_EFIFB
Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app that I found find checks the type but at least now it's correct.
Emmanuel Vadot [Wed, 1 Dec 2021 10:57:42 +0000 (11:57 +0100)]
fb: Remove some unused ioctls
6d1699583d7e added the FBIOGXINFO,FBIOMONINFO and FBIOPUTCMAPI/FBIOGETCMAPI
ioctls and said that implementation in driver will come later.
Since it was in 2001 I think we can remove this.
Emmanuel Vadot [Wed, 1 Dec 2021 10:53:03 +0000 (11:53 +0100)]
fb: Remove unused FBIOVERTICAL ioctl
Commit 6d1699583d7e added the FBIOVERTICAL ioctl and said that implementation
in driver will come later.
Since it was in 2001 I think we can remove this.
Alexander Motin [Tue, 14 Dec 2021 18:20:14 +0000 (13:20 -0500)]
isp(4): Allow more than 2 ports to read WWNs from NVRAM.
It appears at least on QLE2694L cards 3rd and 4th ports follow the
same NVRAM addressing logic as the first two. In lack of proper
documentation this guess is as good as it can be.