In D20840#455193, @ganbold wrote:

Tried with smaller wait values per frequency respectively.
However it is not working. So added more comments in the code
describing why more safer value would work in any case.

That fixes my problem with my drm driver, thanks.
Tested-by: manu

For rockchip there is a clock exposed (via the clock-output-names property) but you don't register it and you try to get it in the emmc-phy review (D20840).

I'd like to commit that soon, anyone have objections ?

In D20956#454445, @kib wrote:

I explained the reasoning for runtime package in https://lists.freebsd.org/pipermail/freebsd-current/2019-April/073209.html. I do not think that increasing the size of the package just because it is convenient is reasonable. If you want all other (non-C-runtime) libs in one package, create it, but keep runtime package for its purpose.

In D20962#454420, @bapt wrote:

I don't like the idea of a separated package for manuals

LGFM

Commited as r349588

I'm one of the reason Ian opened this review because I was pondering adding clog support into syslogd for embedded use case.
clog is present since monowall (at least) and still is used in pfSense and OPNSense but talking to Ian about this I preferred his solution better.
The goal here is to

1. Do not fill up your disk (when ether it's a real disk or a tmpfs)
2. In case a program crashes in a loop for $somereason you still have access to the original log that caused the crash (hopefully), playing with log rotation with newsyslog will make sure at 100% that you will loose the original problem because the logfile rotated.

Forgot to write to out if no other pages were found.

In D20347#441879, @kib wrote:

In D20347#441878, @manu wrote:

In D20347#441757, @kib wrote:

This all looks fine, except one detail. I reviewed UEFI 2.8 description of EFI_BOOT_SERVICES.GetMemoryMap() but did not found a mention that they require the map ordered by phys address. Did you miss the code to sort the map ?

In chapter 4.6, EFI_MEMORY_ATTRIBUTES_TABLE it is said : The list must be sorted by physical start address in ascending order.

I am even more confused. The description said that about EFI_MEMORY_ATTRIBUTE, not about memory map. And you correctly use memory map, because MEMORY_ATTRIBUTE seems to be some after-thought patch only applicable to EFI runtime code and data.

qsort the efi map
If out is supplied, search for the last page with the same attributes as the requested out and write the address in out.

In D20347#441757, @kib wrote:

This all looks fine, except one detail. I reviewed UEFI 2.8 description of EFI_BOOT_SERVICES.GetMemoryMap() but did not found a mention that they require the map ordered by phys address. Did you miss the code to sort the map ?

return (0) -> return (false)

Use bsearch and address kib's comments.

In D20348#441192, @dougm wrote:

You could build a table of descriptors with EFI_MD_ATTR_RT set, sorted by md_virt value, and do a binary search on that table to find which range, and thus which descriptor, had the address you're looking for.

I don't know anything about EFI, so I don't know if the ranges come in sorted order already, or whether we'd have to sort them. And I don't know if this is something that could be done once in efirt.c:efi_init, or would need to be done in efirt_machdep.c:eft_create_1t1_map for each architecture. In any case, it seems not too hard to replace a linear search with a binary search.

LGTM, I'll try to find to time to test today on armv7 and armv6.

So with a pctrie (I can post the code somewhere if you want) I have 14 non-leaf node
db> show pctrienode efi_map_trie_zone
node 0xffff000000ad3f90, owner fffffd0010d0b540, children count 19408, level 4305:
slot: 0, val: 0xffff000001568060, value: 0, clev: 4305
slot: 1, val: 0xbfffd3ff18, value: 0, clev: 4305
slot: 2, val: 0xbfffd3fb18, value: 0, clev: 4305
slot: 3, val: 0xfffffdbf7fd30018, value: 0, clev: 4305
slot: 5, val: 0xffff000000760795, value: 0xffff000000760794, clev: 4305
slot: 6, val: 0x1030000, value: 0, clev: 4305
slot: 7, val: 0xfffffdbf6a38b200, value: 0, clev: 4305
slot: 9, val: 0xfffffd00101a2c40, value: 0, clev: 4305
slot: 10, val: 0xfffffd0010b9e400, value: 0, clev: 4305
slot: 12, val: 0x1dcd6500, value: 0, clev: 4305
slot: 13, val: 0xfffffd0010b9e380, value: 0, clev: 4305
slot: 14, val: 0xfffffd0010b9d200, value: 0, clev: 4305