Better use of t0 register.

In D47521#1084058, @markj wrote:

In D47521#1084047, @mhorne wrote:

Thanks for handling this one. I had looked at it previously, and the one thing I was uncertain about was the interaction with busdma_thread()/deferred loads. It appears to me there is one unlocked reference to bz->deferred_time which could race with bus_dmamap_destroy(), although it would be exceedingly rare. Can you comment on this?

I think this race is not new with this patch. That loop can also race with bus_dmamap_destroy() and bus_dma_tag_destroy().

More generally, I believe it's only a problem if consumers misuse the busdma interface. A map gets added to the bounce zone's bounce_map_waitinglist when a bus_dmamap_load() fails to reserve enough bounce pages (presumably because another consumer is using them), and BUS_DMA_WAITOK was specified. Later, when a bus_dmamap_unload() call releases some bounce pages owned by the same zone, the busdma layer can try again to reserve pages; this happens in the busdma thread so that the callback is executed in a safe context.

To trigger the race, a consumer would have to call bus_dmamap_load(callback, BUS_DMA_WAITOK), get EINPROGRESS, and then destroy the map and tag (releasing the last reference on the bounce zone) before the callback is invoked. I'd argue that it's the consumer's responsibility to make sure that this doesn't happen, though the documentation doesn't explicitly state this. If so, I believe there is no bug here.

Add clocks for CLK_RISCV, CLK_RISCV_AXI.

This is indeed an improvement. On its own the change is non-controversial, so if @bofh does not reply today I will just commit it.

Thanks for handling this one. I had looked at it previously, and the one thing I was uncertain about was the interaction with busdma_thread()/deferred loads. It appears to me there is one unlocked reference to bz->deferred_time which could race with bus_dmamap_destroy(), although it would be exceedingly rare. Can you comment on this?

@manu This is the first of several changes enabling Allwinner drivers on the riscv platform (probably not all coming today). It suggests that we might move these sources to a more common place (out of arm subdir), but I do not really see any reason this must happen first.

Updated and split into separate reviews: D47514, D47515.

Closing this, as the DTS sources are now present in the tree, imported from Linux.

Don't rely on new compiler features for the THEAD custom instructions. Instead, specify the raw bytes.

Reduce the change, just switch to using s3/s4 registers, still needed to
preserve the values across SBI calls.

No longer needed.

Redo the workaround in assembly.

In D47458#1082358, @jrtc27 wrote:

Running C code without translation enabled is fragile and could break at any time, since it's not running at right address. You're relying on PC-relative addressing being used for everything (i.e. not absolute and not GOT-indirect), which happens to be true today with -mcmodel=medany for this code and all it uses, but there's no guarantee of that. This should really be in assembly (which shouldn't be hard to do, given sbi_get_mvendorid is just a wrapper around ecall?).

Regenerate now that the series is more complete.

I did not try to read all of the discussion in D46918.

Please update the signatures in the groupmember(9) man page.

In D46916#1079351, @olce wrote:

In D46916#1079291, @mhorne wrote:

It seems okay (correct). I am not convinced the ABI break is really warranted. This seems more like a blemish in the existing the code than a true problem that needs fixing.

Yeah, it's a code blemish. We could lift it by not changing the ABI at the price of complicating the generic field copying code, or simply live with it (i.e., have cr_ngroups assigned to twice, possibly elided by the compiler in the produced machine code).

However, is changing the ABI really a problem, as the changed header will trigger recompilation of outside kernel modules and applications (provided they have a decent toolchain)? We don't provide any guarantee that some module built for a given version of -CURRENT works on a later version, at least once __FreeBSD_version has been bumped, do we? Additionally, AFAIK, applications are not even supposed to use struct ucred structures directly but rather grab them through, e.g., sysctl() or some apps/libs in the base system.

It seems okay (correct). I am not convinced the ABI break is really warranted. This seems more like a blemish in the existing the code than a true problem that needs fixing.

LGTM with some small comments.

You are too kind to the foot-shooters ;)

Seems good. This is just a correctness change, yes? As in, CRED_SMALLGROUPS_NB is not touched by any later change in the series?

This well is thoroughly poisoned; time to stop drinking.

a21def4d568fd was the commit removing this driver. AFAICT it did not actually get listed in the release notes.