Yes, please go ahead!

In D53119#1213368, @jrtc27 wrote:

The logic for removing this in the FDT is that, on Linux, the clock framework comes up early enough (or at least some early part of it) in order to be able to query the UART clock's frequency from the clock driver, whereas we don't do anything like that with clocks prior to newbus passes, so way too late for cninit.

Fix aw_spi.4

This prompted a secondary question of whether the x86 FDT experiment bits can be removed outright (sys/x86/x86/fdt_machdep.c).

You can use Fixes: 7393b267c6ce ("libc: Provide sub fp(s|g)etmask() implementations for RISC-V") in the commit message.

No objection from me on this one; @fuz your comments don't seem to be blockers, just possible refinements?

In D47807#1182659, @jhb wrote:

I'm trying to think of a case when the roundup would ever be correct. That is, there are two cases after the previous expression:

		sgsize = MIN(buflen, PAGE_SIZE - (curaddr & PAGE_MASK));

Either 1) sgsize == buflen, or 2) sgsize == PAGE_SIZE - (curaddr & PAGE_MASK)

Your patch turns case 1) into a no-op as it effectively undoes the roundup. Case 2) seems worse though. This means that we can now expand the S/G entry *off the end of the page* and randomly read/write data on the next physical page of RAM. There is no way that is correct. I wonder if this was meant to be a rounddown to keep segments a multiple of the alignment instead of a roundup? However, in that case you'd never finish a buffer whose size wasn't a multiple of the alignment.

Aha! See this part of the commit log from daf6545e6158f:

Now all contiguous regions returned from bus-dma will be aligned to the
alignment constraint and all but the last region are guaranteed to be
a multiple of the alignment in length.

I think if that is the desired behavior, then the correct fix instead is to replace the roundup2 line with this:

if (sgsize != buflen)
    sgsize = rounddown2(sgsize, dmat->common.alignment);

That will give the desired property. It should never have been a roundup2().

I've built and booted the driver.

In D47807#1098307, @markj wrote:

I'm sorry for the delayed follow-up. I'm trying to understand the purpose of the roundup. It appears to have been introduced by commit daf6545e6158f; the implication seems to be that some drivers depend on the property that "the relative alignment of two consecutive bytes in the I/O stream have a difference of 1 even if they are not physically contiguous."

I don't really understand why that property is important, but assuming so, I think your patch is probably the right thing to do.

Seems fine to me, with a couple tweaks needed.

Looks good to me, with some small nitpicks.

In D43034#1170569, @jsihv_gmx.com wrote:

This small update includes the proposed smaller changes.

Your larger proposition looks like a straightforward application of a generic structure from other GPIO drivers, so if you like to add it by yourself, just go ahead. I considered writing just the same thing by myself (mostly after the example of SiFive's gpio driver) but I didn't understand why those data structures would be needed for this particular driver.

In D51262#1170478, @ziaee wrote:

2. I only have amd64, but when I looked into this, we do have quite a few things that actually are only for certain architectures. One of my aspirations is definitely to clean that up, they should be moved to their respective man4/man4.*/ directories and have their .Dt's fixed.

I am happy with the idea of making this consistent across man/man4.$arch.

Thanks for the update. Despite my many absences in the past, we should be able to move quickly on this and get it merged.

Two thoughts beyond the scope of this change:

1. Should we provide uaudio(4) as a legitimate link to the page? The answer might be no.

Do you intend to enable it in the build for some config? Maybe in std.arm?

I am back after some time away. I plan to commit this soon, so, last chance to look :)

Seems fine to me, but I am not an authority on the subject matter.

Please check the commit description before pushing.

Looks good, I am unfamiliar with the content/purpose here, so trusting your fact-checking.

Approved, please go ahead and commit this.

Oh spare me your wounded pride and perceived victimhood.

The subject of line-breaks is infinitely bikesheddable, so I will state my opinion here once more and then never again.

So, should it also be expanded/applied to the various hardware notes in this commit (not just the template)?