I'm sorry this got forgotten. I think this is ready, so I'm going to merge it now so that it doesn't get dropped again.

Hi, thanks for taking this on, it would be nice to see this conversion completed.

Seems like a few have already spoken. Thanks for being attentive here.

The IGNORE seems like a fine solution for now, and can be changed to fit how these macros actually get used. I suspect the active/legacy release lists will still require frequent micro-management. (this is now your purview? ;) )

Thanks for working on these macros. I think in many places they are highly desirable.

Not an authority on shells and their lineage, but I certainly agree with your assessment in the description.

Thanks. I will commit, with a couple of style/whitespace tweaks.

In D41277#1281501, @ali_mashtizadeh.com wrote:

I just started looking through the backlog I think we can abandon this change now?

Similar comments to D55907. The structure looks good, but I did not review the clock method logic.

This looks straightforward to me. I did not review the recalc / set_freq methods in detail.

Can you use the existing clk_fixed class for these clocks? It seems like it. See sys/dev/clk/clk_fixed.h.

This appears to be a duplicate of D55907. Is there a difference?

The change seems correct to me, but the test plan does not; pmcstat does not make any use of the pmc_get_msr() code path. Perhaps you have some other use-case or test program that you used?

Tweak comment instead, to retain the useful info.

I am sorry to speak up only now, after the review sat open for so long. But in looking over the change it seems to be incomplete.

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.