rng90: Microchip RNG90 I2C random number generator driver

[ptudor_ptudor.net]

Summary

Add rng90(4), an iicbus(4) driver for the Microchip RNG90. The device returns 32 random bytes per command at its fixed 7-bit I2C address 0x40. The driver attaches only to an explicitly hinted iicbus child (addr="0x80" in FreeBSD's shifted hint form) or a device-tree node compatible with "microchip,rng90"; it never scans an address.

A root-only /dev/rng90N provides one CRC-verified block per blocking read. Kernel feeding is opt-in through dev.rng90.N.feed or a feed=1 hint. Wake, Info identity, response length, device status, and CRC are checked before bytes leave the driver. Raw reads are not also submitted to the kernel. Three health or self-test results without a valid block latch collection until reattach.

Add a dedicated RANDOM_PURE_RNG90 high-quality push source. random_harvest_queue() stores at most two uint32_t values in one event and reduces larger inputs to a 32-bit hash, so each verified 32-byte result is submitted as four 8-byte events. The source is registered once per module.

Transfers are single-message iicbus_transfer() calls without bus ownership. Detach takes the driver lock, marks the device dying, then releases the lock before cancelling and draining the taskqueue. It sends no final command to possibly removed hardware. Controller errors other than NACK end the operation and start a fixed one-second quiet period. Statistic sysctls snapshot values under the same lock, including on architectures without atomic 64-bit accesses.

The tested hardware places the RNG90 behind cp2112(4). The CP2112 error-path fix needed for reliable hot-unplug operation on that bridge is tracked separately as PR 300017:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=300017

The RNG90 driver does not otherwise depend on CP2112.

Test Plan

• The compact and full-context patches apply cleanly to the recorded FreeBSD main base e809c7d810ced2307741a7c0c135a8b1bef1851b.
• FreeBSD checkstyle9.pl reports 0 errors and 0 warnings. All 47 protocol tests pass normally and with ASan/UBSan on macOS and FreeBSD. FreeBSD mandoc -Tlint completes without diagnostics.
• The revised module builds with -Wall -Wextra -Werror against the matching 15.1-RELEASE-p6 source, both normally and with FDT enabled, using FreeBSD clang 19.1.7.
• Deployed the revised module and rebooted the matching kernel. Three unload/reload cycles with feeding enabled and three CP2112 resets with concurrent raw reads and feeding completed cleanly. The raw reader returned ENXIO on disconnect; each new attachment resumed feeding with zero error/status counters.
• An hour-long test showed steady entropy collection, zero errors or health failures, and no new kernel messages.
• Collection continued overnight. The next-day check showed normal operation, zero errors or health failures, and no new kernel messages.
• The original submission had a complete matching amd64 GENERIC kernel/module build, physical-removal testing, and a clean five-day run. Those historical results belong to the original source; physical removal was not repeated for this revision.
• The hinted iicbus path is hardware-tested. FDT compiles but has not been exercised on hardware.

[adrian]

+ @ziaee for manpage

[adrian]

hi! thanks for this! A few things and some comment cleanups!

sys/dev/rng90/rng90.c

2

This should be a multiline comment, not two one line comments and i believe the copyright and name + email goes first!

47

if these are stats then i'd put them in a struct, like

struct {
uint64 ... ;
} stats;

Just to keep them grouped.

75

hm, why do you need an atomic load for dying if you hold the sx lock?

368

I'm .. not a huge fan of device names that have numbers in them. I'm not going to say that we should change this in the commit as it's popped up elsewhere, but i am going to ask what we should do in general moving forward.

376

So this is interesting; you're using PROC here when you could be using .. I think SYSCTL_ADD_U64() for a uint64_t pointer?
Ok yes you would be assuming that 64 bit reads and writes to the stats entries are atomic, which i don't believe we currently guarantee. But if you'd like to do that, i think it'd be nice to also have an array of stat strings to use here for the sysctl descriptions so the individual stat descriptions mean something.

382

This is a very verbose way of saying whats in the manpage. It likely should be something like:

Enable feed (via hint.rng90.N.feed="1") to begin entropy collection at attach

447

Why not just grab the lock, set the dying flag, and release the lock? Is there something preventing acquiring/releasing the lock here?

Yes you can't hold the lock over the taskqueue cancel/drain as that causes other issues.

449

You don't need these comments; the cancel/drain loop is the normal way to do this and is in the taskqueue manpage.

463

You don't need this verbose comment either. If you needed some way to send a shutdown command you would've done it above.

[emaste]

For future uploads (if you update the review) please include full context via e.g. -U999999.

sys/dev/rng90/rng90.c

368

I agree we should avoid a trailing digit in the name, but I don't have a great suggestion on a general approach we should use on naming.

[ziaee]

microchiprng(4) ?
miicrng?
mciicrng?

[ptudor_ptudor.net]

Thanks, I've grouped the driver statistics, added individual sysctl descriptions,
and applied the header and comment cleanups. I kept the sysctl handlers so the
64-bit values are copied under the driver lock on all architectures.

The earlier atomic flag let detach interrupt protocol retries while an operation
held the lock. With the controller-error latch and bounded CP2112 waits in place,
detach can wait for the current operation. It now takes the lock, sets dying,
and releases the lock before cancelling and draining the taskqueue. All accesses
to dying use that lock.

I agree the name is awkward, and I'm happy to use whatever name the team
settles on. For now I've left rng90 in place while we work toward consensus
and continue with the rest of the review.

I've also prepared the next diff with full context (-U999999).

The revised module builds on FreeBSD with and without FDT, and the protocol
tests pass normally and with ASan/UBSan. After deploying and rebooting, I ran
three unload/reload cycles with collection enabled and three controller resets
with raw reads and collection active. Each detached and resumed collection
cleanly. The device-tree path remains compile-tested only.

An hour-long test and an overnight follow-up both showed steady collection,
zero errors or health failures, and no new kernel messages.