In D47685#1087555, @imp wrote:

Might be worth publishing the noise count as a per-dev sysctl

Closed by 09ef5387

Should this also be applied to stand/powerpc/boot1.chrp/bootinfo.txt?

In D47525#1083994, @emaste wrote:

As an aside, are ifapi man pages coming soon?

$ apropos ifapi
apropos: nothing appropriate
$ apropos if_getlladdr
apropos: nothing appropriate

Thanks!

Ping, anyone?

In D47358#1080093, @emaste wrote:

Really cool work. I think this could use a better description though (and possibly a rename) - in current usage the rescue prefix suggests rescue(8) and it's not clear to me what a "direct dumper" is. The summary message should include a brief description of what this actually is.

Put it in the right place.

Ping? I think I addressed all feedback, but may have missed something.

Makes sense to me.

In D41837#1041737, @sanastasio_raptorengineering.com wrote:

Hi all,

As far as I can tell, this change still hasn't been committed despite receiving approval. If someone with the appropriate privileges could do so I'd greatly appreciate it.

Thanks,
Shawn

In D45211#1040937, @andrew wrote:

Do you need interrupts in this driver? It looks like Linux only uses them when using DMA to transfer data to/from the device.

• Remove unnecessary code
  • linux_exec_setregs() is identical to exec_setregs(), so dedup. Could dedup even more, too.
• style(9) some bits

Fix the build

Address feedback. Add new linux_ioctl_handler for powerpc-specific TTY ioctls.

Address style feedback.

In D45211#1036980, @andrew wrote:

In D45211#1036969, @jhibbits wrote:

3.4.1
SSPRXINTR
The receive interrupt is asserted when there are four or more valid entries in the receive FIFO.

That's a different interrupt, see 3.4.4 SSPRTINTR of the same document.

In D45211#1036945, @andrew wrote:

One limitation of the driver is that hardware only raises an interrupt if the RX queue contains at least 4 characters, so fewer than 4 characters in the queue may result in data never being received.

Do you not receive the SSPRTINTR interrupt?

In D45431#1036871, @alc wrote:

In D45431#1036870, @jhibbits wrote:

From a (very) quick check, it looks like the same change in amd64 should be made to mmu_radix for powerpc.

It doesn't apply because mmu_radix_enter_quick_locked() doesn't attempt promotion.

From a (very) quick check, it looks like the same change in amd64 should be made to mmu_radix for powerpc.

In D45287#1033199, @rlibby wrote:

In D45287#1033196, @jhibbits wrote:

The only time this makes a difference is if the sizes of bus_addr_t and bus_size_t are different, and I don't have any test hardware where that's the case and I can test TPM. (Only hardware I have where that's the case is ppc Book-E, but that doesn't have a TPM).

Right. Not that I think this is risky, but would you like to do any testing of tpm at all before pushing to main? Otherwise I'll go ahead and push it without testing beyond make.

The only time this makes a difference is if the sizes of bus_addr_t and bus_size_t are different, and I don't have any test hardware where that's the case and I can test TPM. (Only hardware I have where that's the case is ppc Book-E, but that doesn't have a TPM).

Given that all(?) other ethernet drivers unconditionally ETHER_BPF_MTAP() (so, ether_bpf_mtap_if()) if we're worried about the bpf being NULL it's probably better for the check to be in ether_bpf_mtap_if() anyway, letting the netstack deal with that.

In D45170#1030347, @dougm wrote:

In D45170#1030344, @jhibbits wrote:

PPC LGTM. If you haven't, test a buildkernel with MPC85XX (powerpc) and QORIQ64 (powerpc64) just to be safe.

With or without these changes in place
make -j 24 buildkernel TARGET=powerpc KERNCONF=QORIQ64
fails:
./machine/reg.h:80:41: error: declaration of 'struct reg32' will not be visible outside of this function [-Werror,-Wvisibility]

80 | int     fill_regs32(struct thread *, struct reg32 *);

begins a stream of errors.

PPC LGTM. If you haven't, test a buildkernel with MPC85XX (powerpc) and QORIQ64 (powerpc64) just to be safe.

Address @kd's feedback.

LGTM, though I didn't compile it.

Address feedback.

In D44274#1017742, @sanastasio_raptorengineering.com wrote:

Hi all, sorry for the ping. If anybody had time to review this, it would be greatly appreciated. We've deployed this patch internally on some of our production systems and in addition to the massive performance improvement, it has proven stable under various workloads.

Committed by @stevek in 3bbe8ed1a7 (D44535)