In D32905#743481, @donner wrote:

If I understand correctly, the requirement is to align the IP header unconditional.
So there is no need for an extra message, but all other nodes might be urged to add this, too.

In D32905#742921, @afedorov wrote:

I don't understand what the alignment does in this case.
Does it fix a bug or is it an optimization?
What part of the code requires this alignment, is it the TCP/IP stack?
Because not only ng_eiface(4) can inject Ethernet packets into the network stack.

Just some other examples of unalligned packets with netgraph:
ng_device(4) -> ng_ether::upper(4) -> TCP/IP stack
ng_socket(4) -> ng_eiface -> TCP/IP stack

As I can see, ETHER_ALIGN is only used by network drivers. Is there any alignment requirement for network drivers or TCP/IP stack?

Other changes, I think you can commit:

1. Support of the "getdevname".
2. Automatically give the node name same as device name.

Before these changes, ofw_bus was a simplebus that also did a bit of resource management. With the rman stuff gone, is there any difference at all between ofw_bus and simplebus?

In D32357#735518, @ehem_freebsd_m5p.com wrote:

You already know I really dislike the default range, but I have no reason its use causes actual harm. For the moment, things need to go this way.

I would be a bit more wordy in the commit, something like;

I suspect these stats aren't much-used in the real world, and can't think of any reason not to do this.

In D31244#703740, @imp wrote:

In D31244#703722, @kbowling wrote:

In D31244#703721, @imp wrote:

ZFS is useful on these small memory beasts?

Unsure, @cem laid out some other real problems with the small stack size in the referenced commit https://reviews.freebsd.org/R10:3f6867ef6386435a52ec564780b91a47dd948b0c. Is there a significant drawback here versus the safety of a larger stack?

I don't believe there is a huge drawback, I just hit a big wall trying to set ZFS up years ago on older V7 gear and was wondering if things had changed with OpenZFS. This change would be a problem on the older armv5 gear due to its limitations on RAM. The v6/v7 machines start at 512MB and go up from there. They aren't memory constrained. The only detail I hesitate on would be if this increases overhead on context switches or something like that. I don't believe it will, so the change is fine, but I'd love to see what others say before making the change.

This has been on my to-do list for ages. Several people who use zfs on 32-bit arm have requested it over the years.

In D29369#657802, @rwatson wrote:

In D29369#657694, @andrew wrote:

I wonder if we should be checking for __NO_STRICT_ALIGNMENT (and defining it for architectures other than x86)

Hmm. I didn't know that existed.

I think it is the right goal, but I don't think we should aim for it in this patch. Not least, I'm not easily set up to test the various other cases covered by that define currently.

I don't understand the need to add new methods to ofw_if. The new methods are just extracting standard properties from a standard dtb in memory; if new functions are needed at all, why aren't they just a couple new convenience functions in ofw_subr.{c,h}?

A few last minor tweaks to the test program.

This update adds the option to choose between detailed (the default) and summary reporting, and removes the restriction that only one pin-change event can occur between each call to read(2) without losing data. It also adds a new test/demo program, based on the test code written by Christian for the gsoc project.

Allow only edge-triggered interrupts, and only if they are supported on that pin according to the capabilities flags from the hardware driver.

Primarily style fixes, mostly reformating block comments to the freebsd standard.

Locking fixes. The original code had several places where an error-handling path would exit a function with a mutex unlocked that would be re-locked on a normal exit. There was also a place where an SLIST was traversed without holding the mutex that protects additions and deletions on that list.

Just a note to mention that the initial diff is the exact code from https://github.com/ckraemer/freebsd/tree/gsoc2018, with a couple small tweaks to resolve conflicts due to the freebsd base code having changed a bit over the past two years.

Applied patch to freebsd 8 (which we use at $work but it has the icee.c source from -current) and freebsd 11 and it behaves as expected on our products.

In D26302#584718, @imp wrote:

In D26302#584633, @ian wrote:

So, what prevents "kldunload icee" while someone has the cdev open?

Nothing. Just like we don't do it for almost all other devices. If that's really needed, we should do it via the device_quesce mechanism.

So, what prevents "kldunload icee" while someone has the cdev open?

In D25312#558270, @kib wrote:

I do not like it.

[...]

The argument that we have around a hundred places where the rule is already broken in fact confirms that most of our code confirms to the style(9) in this regard, since hundred places for several MLoCs of our own code is quite good ratio.

I believe 0750 is an ideal mode for the /root dir; it adds some security, and it seems unlikely that existing scripts or other automation people have in use will fail due to the change.

After some discussion on irc we realized we don't need a get-capabilities interface between gpio and pinctrl, because both are soc-specific drivers, and the gpio driver already "knows" what capabilities the soc has.

What kind of flags go into the flags arg? I suspect the quick answer is GPIO flags. The more complete answer is probably "some subset of gpio flags which differs from one device to another". That leads to the question of what to do on an attempt to set multiple flags where some are supported and some aren't.

When replacing objdump with llvm-objdump came up on a mailing list, there was some opinion expressed that most users don't need objdump at all and should have to install a package to get it. But I find llvm-objdump to be a completely-usable replacement for gnu objdump that we've had in base for years. That leads me to think a knob such as WITH[OUT]_LLVM_OBJDUMP that defaults to WITHOUT might be a good solution for this.

Committed (forgot to link to phab) as r356278.

Remove the bus_select callback pointer and instead create an iicmux_if.m to define a bus_select method.

In D22945#502734, @imp wrote:

So devices are just detached on unload, not deleted, so the device_t shouldn't be stale ever...

Of course, it would be better to have a newbus invalidate callback when deleting a device node, but until then, this is fine

Committed as r356180

Doh! I totally missed that, thanks.

Uploaded a new diff with proper context.

In D22922#502063, @imp wrote:

I like where this is going, and have a couple of questions...