Many thanks, Mitchell!

Look good to me. Thanks!

Hi guys,
basically, I agree with Hans and not sure it will behave well w/o spinlock.
But that way VT will be faster and machine performance will be better.
/me vote to try

Agree.
The use of a Parallel NOR Flash is infrequent nowadays. And virtual mapping of an SPI NOR Flash I saw only on MIPS SoCs.

Looks good to me.
Thanks!

In D32316#741213, @emaste wrote:

@ray I assume you can go ahead with committing this one?

In D32335#747099, @gbe wrote:

Could you ran 'mandoc -Tlint' over the man page. There are plenty of warnings, which could easily be fixed, like 'new sentence, new line' and so on. It would be nice if you could also add the author of the man page.

And you have to include this man page in the makefile of the directory.

Fix formating according to mandoc lint hints.

Fixed. Thanks for review!

Review fixes.

All fixed. Thanks for review, Mitchell!

style(9) changes.

In D32670#747725, @mhorne wrote:

Oh yes, and one question. Should sys/dev/hwpmc/pmu_dmc620.c be located elsewhere, similar to sys/arm64/arm64/cmn600.c? To me, it does not seem to belong in the hwpmc sub-directory.

Cleanup.

Remove debug leftover.

Done comments.

In D32316#737876, @mhorne wrote:

It seems to me that only the changes to pmc_arm64_initialize() should be necessary, because it handles optional classes in the same way that pmc_intel_initialize() does, by passing the correct nclasses value to pmc_mdep_alloc().

Update classes base ri to handle optional classes out of order.

LGTM
Thanks!

I like it.
Thanks!

LGTM
Thanks!

Squash commits.

Fix comment.

In D30047#676281, @mhorne wrote:

This looks fine to me, thanks for fixing this.

It seems that pmc_id_t should be an opaque type for consumers of libpmc? I.e. the only userspace consumer of these bit macros should be libpmc itself.

If that is the case, then this change should be okay without a PMC_VERSION bump. There are no uses of PMC_ID_TO_MODE or PMC_ID_MAKE_ID in libpmc. However, I did not check if this was true for older releases.

Looks fine.
Thanks!

Looks good to me.
Thanks!

Looks good to me. Thanks.

Thanks, Hiroki san!

Handle PCI_RES_BUS special way.

While working on a separate change (GitHub/bsdjhb/freebsd/tree/bus_map_resource_more) I remembered more of why PCI_RES_BUS is special. It's presence indicates to MI code (e.g. sys/dev/pci/pci_pci.c) that the MD host-PCI bridge drivers support managing bus numbers and so bus ranges should be allocated via bus_alloc_resource(). After the bus_map_resource_more branch lands, it will be possible to rework the one gross hack in pci_pci.c (where it calls bus_activate_resource to "map" child resources but asking the parent to do so) and then NEW_PCIB will be able to be turned on by default for all archs. However, the PCI_RES_BUS bits still need to be conditional to platforms that support PCI_RES_BUS. This is generally managed in the host-PCI bridge drivers rather than in the nexus. So in practice the '#ifdef NEW_PCIB' in the new header is in fact wrong. The real test is something more complex like this:

#if ((defined(i386) || defined(amd64)) && defined(NEW_PCIB)
#define PCI_RES_BUS 5
#endif

Except you need more convoluted expressions to handle other architectures. For x86 the rules is that bus numbers are only supported in host-PCI bridge drivers if NEW_PCIB is defined. It seems that only riscv, powerpc, and sparc64 don't already define PCI_RES_BUS, so perhaps a negative architecture list is shorter than a positive one.

Rename base to baseoff. Fix comment.

In D21827#476548, @markj wrote:

Can you show the readelf -S output for the input file where this change matters? The change looks ok to me, but I do not understand why it is useful.

In D21703#476461, @jhb wrote:

Some places use whether or not PCI_RES_BUS is defined to decide if they should handle PCI bus numbers. BTW, I called it PCI_RES_BUS instead of SYS_RES_* because it isn't a bus-independent "system" resource (like memory or I/O ports or DMA channels), but instead is specific to a PCI bus (and in a multi-segment/domain system you would have duplicates even).

In D21703#475791, @kib wrote:

In D21703#475705, @ray wrote:

Return back #ifdef NEW_PCIB, @jhb not sure it is safe to omit.

Can you explain why ?

Return back #ifdef NEW_PCIB, @jhb not sure it is safe to omit.

Nice, that it works.

It is wrong way to fix elfcopy bug.
Thanks to @strejda for pointing that.

In D21703#473617, @kib wrote:

This looks fine to me, but I have no idea why John put PCI_RES_BUS under #ifdef NEW_PCIB instead of defining it always.

I will wait for @jhb input about that. But everything I found PCI_RES_BUS were checked together w/ NEW_PCIB. And I didn't found any place where defined PCI_RES_BUS can break anything.

o Do not copyright "empty files"
o Give old owner (i386) old number (PCI_RES_BUS to 5)

Looks good. Thanks.

In D21478#469653, @nwhitehorn wrote:

I have pretty mixed feelings about this approach. It only works for ofwbus children, not simplebus children, and canonicalizes a bunch of behaviors that I don't believe are standards (I'm in an airport departure lounge and don't have the spec handy). I'm also not really sure how it interacts with multipass etc. Could you elaborate a little more on the mechanism?