| Age | Commit message (Collapse) | Author |
|---|
|
the Armada 7K and 8K SoCs. Additionally, it seems to be used on the
upcoming CN9K SoCs. This only supports version v2.2, since the older
v2.1 is only used on some old ARMv7 we have no support for, and where
there is no hardware for us to support.
A huge part of this driver is configuring the TCAM/SRAM-based "parser".
Thus most of the code, especially the parser handling, was ported from
EDK2 with a sed script doing plenty of automatic renaming and un-camel-
casing.
The controller supports multiple TX/RX queues/vectors and RSS, so this
would be a nice platform for testing network processing improvement on
arm64. For now though we only configure and use a single queue.
The driver is still unfinished, but it's time to continue the work in
tree. At least we can already send and receive packets, good enough
for dhclient to work.
Since the MACCHIATObin uses Clause 45 10G PHYs and SFPs, link state
handling is still a bit bogus, as we have no support for that. The
1G RJ45 port works fine though.
ok dlg@
|
|
found by jmatthew@
|
|
|
|
this basically distributes incoming packets over the rx rings, where
without this they would all land on ring 0.
note that the 722 stuff is stubbed out at the moment. i don't have
an x722 to test with, so it's hard to get motivated to write the
code for it.
this is based on stuff supplied by christiano haesbaert.
|
|
|
|
based on info from christiano haesbaert
|
|
|
|
this adds a struct ixl_chip, which should hold the differences in
functionality between 710s and 722s. this adds which type of chip
each product is to the ixl_devices array.
based on stuff from christiano haesbaert
|
|
stand stubbed for now.
|
|
ixl(4) is only enabled on amd64 and sparc64, and both of them now
support pci_intr_establish_cpu(), so it is safe to apply this.
a few things to note:
- the chip only supports a power of 2 number of queues, (ie, 1, 2,
4, 8, etc), so this also tests the INTRMAP_POWEROF2 flag to
intrmap_create. i tested this on a box with 6 cpus and it did the
right thing.
- the chip can support a lot of vectors, but we're limiting it to
8 for now.
- rss with toeplitz is not implemented yet, so all rxed packets end
up on the 0th queue for now.
jmatthew@ had done most of the work already, and christiano haesbaert
provided some hints to motivate me to work on this bit of it.
tested by jmatthew@ on sparc64
ok jmatthew@
|
|
this should enable tx mitigation, and hopefully provide a speed
bump here too.
iavf is a cut up ixl, so it inherited the IFQ_SETMAXLEN 1.
ok jmatthew@
|
|
There a question if RELOC_ should be changed to R_PPC64_XXX as
the ABI defines.
can clean up later kettenis@
|
|
systat mbuf looks a bit better now.
|
|
Rework ENTRY to contain the r12-> r2 and localentry code.
Powerpc64 float is the same as Powerpc (_float.h, ieee[fp].h)
Profile code, adapted from powerpc
|
|
this effectively enables tx mitigation on this chip. hrvoje popovski
tested it and discovered it adds about 20% to forwarding performance
on his test machine, and brings it more in line with ix(4) performance.
jmatthew thinks i copied setting it to 1 from myx, but myx resets
it to a proper value later on when it figures out what the chip is
capable of. how embarrassment.
|
|
time_second(9) and time_uptime(9) are widely used in the kernel to
quickly get the system UTC or system uptime as a time_t. However,
time_t is 64-bit everywhere, so it is not generally safe to use them
on 32-bit platforms: you have a split-read problem if your hardware
cannot perform atomic 64-bit reads.
This patch replaces time_second(9) with gettime(9), a safer successor
interface, throughout the kernel. Similarly, time_uptime(9) is replaced
with getuptime(9).
There is a performance cost on 32-bit platforms in exchange for
eliminating the split-read problem: instead of two register reads you
now have a lockless read loop to pull the values from the timehands.
This is really not *too* bad in the grand scheme of things, but
compared to what we were doing before it is several times slower.
There is no performance cost on 64-bit (__LP64__) platforms.
With input from visa@, dlg@, and tedu@.
Several bugs squashed by visa@.
ok kettenis@
|
|
|
|
ok gkoehler@
|
|
not a target on the bus. adapter_buswidth is 2.
ok dlg@ as part of a larger diff.
|
|
aassigned to adapter_buswidth to indicate the adapter is not a target
on the bus.
ok dlg@ as part of a larger diff.
|
|
indicate the adapter is not a target on the bus.
ok dlg@ as part of a larger diff.
|
|
the adapter is not a target on the bus.
ok dlg@ as part of a larger diff.
|
|
"Boldface", "Boldface.iso1", and "Gallant".
OK mpi@
|
|
'adapter_target' to a value greater than or equal to
'adapater_buswidth' to allow all possible targets to be probed.
Add SDEV_NO_ADAPTER_TARGET (0xffff), a value guaranteed to
be greater than or equal to the u_int16_t 'adapter_buswidth'.
ok dlg@ as part of a larger diff.
|
|
no functional change
|
|
On powerdown (halt -p), sd(4)'s suspend function tries to powerdown
a USB mass storage using a STOP command. In that case we are already
cold and splhigh(), so that the xhci is supposed to run in polling-
mode.
usb_schedsoftintr() behaves differently when running in polling-mode.
Instead of scheduling a soft interrupt, it immediately dequeues from
the event queue. But dequeueing means touching the xhci registers.
Apparently we need to acknowledge the interrupts before touching those
registers, the hardware doesn't like it otherwise and we will never get
an interrupt status for the second transfer.
ok gerhard@
|
|
ok mpi@
|
|
so that in polled-mode the USB transfers are marked synchronous. In
case that sending commands to the USB mass storage fails, the control
transfers are used to reset the device. Without the synchronous flag,
the STOP command sent by sd(4) on powerdown would wait for completion
indefinitely, possibly hanging the machine.
ok gerhard@
|
|
sigh, i don't know how i forgot this.
yes jmatthew@
|
|
set/trust the scsiconf.c probing limits. Same as was done to
vioblk(4).
ok dlg@
|
|
when sparc64 attaches cpus early during boot, it really just allocates
the software state for them (ie, the devices and the cpu_info
structs) and fills them in with information from openfirmware, but
it doesnt actually spin them up in a physical sense until just
before root is mounted. in between that, we now set up pyro with
an msi event queue per cpu, and target the interrupts for those
event queues at the different cpus. if a device generates an msi
interrupt before the cpus are spun up, pyro will fire an interrupt
at those cpus, but cos they're not running yet, they don't handle
the interrupt, and the event queue never gets processed. because
the msi interrupt state is never cleared by the pyro interrupt
handler because the cpu didn't run it, any further msi interrupts
from that pci device don't cause the eq interrupt to fire again,
so it gets stuck.
one approach to dealing with this is to target all the event queues
that pyro sets up at the boot cpu, and once the other cpus are
running we go through and retarget the event queue interrupts at
the different cpus. this means the boot cpu works on the other cpus
behalf until they're running, and it avoids the eq interrupts being
ignored before the other cpus are running.
another approach is to spin the cpus up when they're attached, so
they'll be set up to process early pyro interrupts, even if they
sit at splhigh until after autoconf has run. i had a quick go at
this and it didn't go well.
the approach we went with was to avoid having the device in question
generate interrupts early.
i left the redistributing code in the tree so people might discover
it if needed, or at least see this description of what's happening.
kettenis@ seemed ok with leaving the code in jmatthew@s
pci_intr_establish_cpu commit, but removing it after. this is that
removal.
|
|
this will make testing easier for everyone.
from Jason A. Donenfeld and Matt Dunwoodie
ok deraadt@ tobhe@
|
|
aplomb. 16 lines of 'C' can be so hard to grok at a glance.
Prompted to look more closely at those 16 lines by mpi@.
|
|
kernel fonts.
OK mpi@
|
|
Tested on a Cubieboard2.
OK patrick@
|
|
possibility. i.e. when bailing out before calling hashinit()..
COVERITY 1452907
ok mpi@
|
|
From Jason A. Donenfeld" <Jason (at) zx2c4.com>
ok patrick@
|
|
From Jason A. Donenfeld" <Jason (at) zx2c4.com>
ok patrick@
|
|
ok dlg@
|
|
it means we can do quick hacks to existing drivers to test interrupts
on multiple cpus. emphasis on quick and hacks.
ok jmatthew@, who will also ok the removal of it at the right time.
|
|
systems. MSIs on these systems are delivered to event queues, which
trigger interrupts when non-empty. The interrupt handler dequeues the
MSIs and converts them into soft interrupts, which run on the same cpu
as the event queue interrupt.
To target pci device interrupts to different cpus, we set up an event
queue per cpu in the system, or as many as we can, if there are fewer
event queues available. For now, we don't have a way to feed this
information back to intrmap, so instead we just map interrupts for cpus
that don't have an event queue to another cpu that does have one.
Tested on V215 (pyro), T5120, T4-1, S7-2 (vpci).
dlg@ got the pyro side of it working for me.
ok dlg@ kettenis@
|
|
time_second and time_uptime are used widely in the tree. This is a
problem on 32-bit platforms because time_t is 64-bit, so there is a
potential split-read whenever they are used at or below IPL_CLOCK.
Here are two replacement interfaces: gettime(9) and getuptime(9).
The "get" prefix signifies that they do not read the hardware
timecounter, i.e. they are fast and low-res. The lack of a unit
(e.g. micro, nano) signifies that they yield a plain time_t.
As an optimization on LP64 platforms we can just return time_second or
time_uptime, as a single read is atomic. On 32-bit platforms we need
to do the lockless read loop and get the values from the timecounter.
In a subsequent diff these will be substituted for time_second and
time_uptime almost everywhere in the kernel.
With input from visa@ and dlg@.
ok kettenis@
|
|
|
|
instead of 48 in the trap setup functions makes it possible to get rid
of the magic offset in proc_trampoline.
Suggested by gkoehler@
|
|
We don't want resettodr(9) to write the RTC until inittodr(9) has
actually run. Until inittodr(9) calls tc_setclock() the system UTC
clock will contain a meaningless value and there's no sense in
overwriting a good value with a value we know is nonsense.
This is not an uncommon problem if you're debugging a problem in early
boot, e.g. a panic that occurs prior to inittodr(9).
Currently we use the following logic in resettodr(9) to inhibit writes:
if (time_second == 1)
return;
... this is too magical.
A better way to accomplish the same thing is to introduce a dedicated
flag set from inittodr(9). Hence, "inittodr_done".
Suggested by visa@.
ok kettenis@
|
|
are handling "genuine" interrupts like the decrementer and hypervisor
virtualization interrupts).
|
|
|
|
cache. We might want to turn that in a per-proc cache at some point, but
this gets us to the point where we can sucessfully have init(1) do its
first system call.
|
|
|
|
|
