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...

Add arm64; the changes needed are almost identical to armv6/7.

Just an update to note that the commit for this was reverted in r356078 due to CI build failures. I'm unable to install a working riscv toolchain for building and testing myself, apparently at least in part because I'm still running 12.0-stable (and if I try to upgrade from that my video card turns into a pumpkin).

Since we don't generate ldscript files anymore, remove the generated files from the CLEAN+= list.

In D22921#502044, @imp wrote:

Are the Makefile.arm and Makefile.mips changes separate?

Does anyone know why riscv needs writable text segments? Or if it really does?