When the multicast filters we're allowed to insert are controlled by the
hypervisor, it may be that we can insert some but not others. So we need
to have fallbacks where we insert any filters we can without rolling back
when one fails to insert.
Submitted by: Mark Spender <mspender at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6318
On WIN8 like host systems, when rescan happens, the already installed
disks seem to return random invalid results for INQUIRY.
More investigation is under way to figure out why random invalid INQUIRY
results are delivered to VM on WIN8 like host systems.
Submitted by: Hongjiang Zhang <honzhan microsoft com>
Reviewed by: sephe
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6316
More of the same sort of issue as r299503, just missed some sysctls added in a
different place than the others.
Reported by: Coverity
CIDs: 1007692, 1009677, 1009678
Sponsored by: EMC / Isilon Storage Division
None of the sysctl handlers in hdaa use the arg2 parameter, so just pass zero
instead. Additionally, the sizes being passed in were suspect (size of the
pointer rather than the value).
Reported by: Coverity
CIDs: 1007694, 1009679
Sponsored by: EMC / Isilon Storage Division
- Introduce new OF API function OF_prop_free to free memory allocated by
OF_getprop_alloc and OF_getencprop_alloc. Current code just calls free(9)
with M_OFWPROP memory class which assumes knowledge about OF_*prop_alloc
functions' internals and leads to unneccessary code coupling
- Convert some of the free(..., M_OFWPROP) instances to OF_prop_free
Files affected by this commit are the ones I was able to test on real
hardware. The rest of free(..., M_OFWPROP) instances will be handled with
idividual maintainers
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D6315
gpiokey driver implements functional subset of gpiokeys device-tree bindings:
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt
It acts as a virtual keyboard, so keys are visible through kbdmux(4)
Driver maps linux scancodes for most common keys to FreeBSD scancodes and
also extends spec by introducing freebsd,code property to specify
FreeBSD-native scancodes.
Reviewed by: mmel, jmcneill
Differential Revision: https://reviews.freebsd.org/D6279
detect failures, and get different PCI IDs.
For the former the interface returns an int to signal an error. The ID is
returned at a uintptr_t * argument.
For the latter there is a type argument that allows selecting the ID type.
This only specifies a single type, however a MSI type will be added
to handle the need to find the ID the hardware passes to the ARM GICv3
interrupt controller.
A follow up commit will be made to remove pci_get_rid.
Reviewed by: jhb, rstone
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D6239
Enable previously added code for MTU handling (based on
Cavium 1.0 driver released on BSD license).
This commit enables possibility to change MTU on VNIC driver.
Obtained from: Semihalf
Sponsored by: Cavium
Number of free Tx descriptors does not need to be locked since
it can be modified atomically between SND and CQ tasks.
It will also block Tx routine from sending packets while CQ will not
be able to free descriptors.
Obtained from: Semihalf
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D6266
Based on v1.0 driver provided by Cavium under BSD license.
Support in-hardware RSS to distribute IP, UDP and TCP traffic
among available RX Queues and hence multiple CPUs.
Reviewed by: wma
Obtained from: Semihalf
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D6230
Delegate interrupts and completion tasks on separate CPUs
for each VNIC.
Reviewed by: wma
Obtained from: Semihalf
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D6229
This is quite harmless on HEAD, but it's worse on stable/10 where
lapic_ipi_vectored is the local APIC native IPI implementation. On
stable/10 cpu_ops.ipi_vectored should be used instead.
MFC after: 5 days
Sponsored by: Citrix Systems R&D
As unicast filters are not chained, we should always try to insert the
specific filter for our MAC address, and then try to insert the unicast
mis-match filter if that fails or all unicast has been requested.
Submitted by: Mark Spender <mspender at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6295
This caused signed/unsigned errors in some subsequent patches.
The only value passed to this is a uint32_t.
Submitted by: Mark Spender <mspender at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6294
The licensing partition for V3 licensing will use the standard TLV format,
so Medford licensing operations on the staging buffer are implemented using
the TLV functions.
Submitted by: Richard Houldsworth <rhouldsworth at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6288
BMan and QMan will do this at attach time. Even though the registers are mapped
now, dpaa_portal_map_registers() will be called at BMan and QMan attach time,
updating the mappings to be private, and in the case of cache-enabled registers,
marked as coherent memory mappings.
- Get rid of hack with re-parenting gpio-leds node to gpiobus
- Use gpio_pin_set_active to enable/disable backlight, it automatically
takes care of active-low pins
Current API assumes that "gpios" property belongs to the device's node but for
some binding it's not true: gpiokeys has set of child nodes with this property.
Patch adds new argument instead of replacing device_t because device_t will be
used to track ownership for allocated pins
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D6277
MacBookPro and i915kms_load="YES" in /boot/loader.conf.
A lowlevel timeout in one of the display ports caused an infinite wait
because a ticks/jiffies comparison was constant. The clock subsystem
which makes ticks/jiffies increment is started after the initial
driver probing is done. Refer to sys/kernel.h and SI_SUB_DRIVERS vs
SI_SUB_CLOCKS .
Discussed with: kmacy @
