Thanks. This was humbling.

The move into the generic place seems good.

In D55284#1264897, @mhorne wrote:

Looks good. The main thing is that we don't throw off the balance by including interrupt sources which exist but will definitely remain unused (the isrc == NULL case). Here the allocation is a good indicator that a driver is attached and it will/can be used.

Looks good. The main thing is that we don't throw off the balance by including interrupt sources which exist but will definitely remain unused (the isrc == NULL case). Here the allocation is a good indicator that a driver is attached and it will/can be used.

In D55201#1263765, @mav wrote:

I've requested removal of those constants from OpenZFS 2.3.6. In 2.4.0 they are not used already. So in few weeks there will be at least one release from each active branch not depending on them any more.

Perhaps aw_mmc(4) as well?

In D41573#1260119, @emaste wrote:

I'll push this in soon.

In D55083#1258981, @emaste wrote:

We still have aarch64-gcc12 through aarch64-gcc14 in .cirrus.yml (and nothing newer), but I think the older GCC versions don't work for amd64 any longer either. This change is fine with me but I'll let @jhb comment on whether have to care about older GCC still.

In D55095#1259555, @tpearson_raptorengineering.com wrote:

In D55095#1259290, @adrian wrote:

oh that's a good catch!

What about regions, pregions, numa_pregions, etc? Are there any other shared variables that need to be unified here?

I checked; the only function we use from the HPT side of things is moea64_bootstrap_alloc(), therefore this is the only variable that needs to stay in sync. While I can't say I particularly like this brittle architecture, I suspect it's going to be changed so infrequently that it's not worth rewriting everything at this point.

Not knowledgeable here but it seems correct.

Thanks a lot for handling this.

Fine by me.

FYI, there is a small set of allwinner manpages (aw_gpio(4), aw_mmc(4), etc.) that maintain the list of compatible strings and SOC_ALLWINNER_* options.

I think I need some more context to understand this diff.

Bump to latest v1.8.1 and bump fu540 u-boot revision

In D54421#1243662, @lwhsu wrote:

I think the question is more "do we want to support FU540?"

If the workaround is still working and no impact to others, it probably doesn't very hurt.
But it it cause issues, we may remove its support, along with sysutils/u-boot-sifive-fu540.

In D51076#1237849, @ziaee wrote:

Why abandon?

In D37981#1213421, @markj wrote:

In D37981#1210335, @avg wrote:

Totally belated, but would it make (have made) sense to split default behavior of reboot and reset commands?
I think that it would be more natural if reboot tried to do a reboot and reset just went for a reset (where implemented)?

I think that would make sense. In retrospect it's a bit silly that reboot and reset are aliases of each other, and both have the /s modifier.

Most likely, this same treatment should be applied to the similar cd_detect() function in sys/dev/sdhci/sdhci_fdt_gpio.c.