How often do you OPEN objects?

You're taking current implementation into account only when I re-used dpaa2_cmd extensively without proper locking though. I'm working on a patch to allocate dpaa2_cmd on stack and initialize them ad-hoc. We won't need to lock them, but DPAA2 objects themselves will be opened/closed more frequently.

Overall changes look good to me.

My understanding is that re-setting the command token to zero explicitly isn't what MC expects in most operations (except xxx_CREATE ones when token = 0 means that a newly created object will be assigned to the resource container that hosts the MC command portal currently executing the command), i.e. when you're going to open an object (DPNI, DPMAC, etc.) within a resource container, you must supply an authentication token obtained previously when the resource container was opened.

• dpaa2_mc.c patched to fix LINT-FDT build (discovered and fixed by @bz, thanks!);
• copyrights of dpaa2_ni_dpkg.h and dpaa2_swc.c updated to include copyright notices from the original files together with the updated SPDX license identifiers.

Whitespace changes in sys/arm64/conf/std.nxp removed

• DPAA2 files were placed between dev/cpufreq and dev/dwc in sys/conf/files.arm64;
• Copyrights were added to sys/dev/dpaa2/dpaa2_ni_dpkg.h (drivers/net/ethernet/freescale/dpaa2/dpkg.h) and sys/dev/dpaa2/dpaa2_swp.c (drivers/soc/fsl/dpio/qbman-portal.c) as their significant parts were copy-pasted from the Linux drivers.

SOC_NXP_LS to lower case

Closed in favor of https://reviews.freebsd.org/D36793

Obtain DEVICE_PROP_HANDLE properties using new API (as @bz suggested in https://reviews.freebsd.org/D36793#837246)

@mw, this diff is supposed to substitute some pieces from sys/dev/dpaa2/dpaa2_mc_fdt.c and sys/dev/dpaa2/dpaa2_mc_acpi.c (https://reviews.freebsd.org/D36638):

• memac bits are re-worked by @bz to separate FDT/ACPI parts into the different drivers (thanks!);
• frame queues aren't blocked anymore on Rx now (not necessary due to the QBMan's processing of the Volatile Dequeue commands where frames are pulled from the only frame queue in response to the command; it fixes LOR reported by @bz as well)

OK, I'll make a note for myself. Thanks for a suggestion!

Review for ACPI changes: https://reviews.freebsd.org/D36677

_STANDALONE test removed

cosmetic changes, alphabetical re-ordering and ACPI changes removed (to be reviewed separately)

In D36638#831758, @manu wrote:

I'm using it for a few months now on my Honeycomb and it works great, never had any issue.
Reviewing all that is a bit too big for me but you can at least add me as a Tested by: entry :)

Thanks a lot for working on this.

I've provided an actual diff revision URL and removed [PATCH] prefix from the commit message.

I've just got a kernel panic at the same place with IOMMU enabled and DPAA2 driver WIP on Honeycomb board.

outid will be written in case of a non-null output node found only. This is how iort_pci_rc_map() used to work and I don't want my patch to change this behavior.

Shared parts of the iort_pci_rc_map() and iort_named_comp_map() were extracted into a separate iort_smmu_trymap() function.

@andrew It definitely won't be, but I wanted to have a separate function for named components from IORT table similar to one for PCI RC nodes. I'll probably extract the same parts of the both functions into a separate one.

You won't see "MSI allocated" in dmesg if you clone the repository or pull the latest changes now. Please, ping me and I'll explain how to test this patch.

@mhorne, @andrew, thanks for help here :)

@mhorne Should I update a patch attached to the PR also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251053 ?

Unnecessary tests of the devtype argument have been removed from uart_cpu_getdev() in sys/dev/uart/uart_cpu_arm64.c and sys/dev/uart/uart_cpu_fdt.c. uart_cpu_fdt_probe() checks for console types it supports.

Please, take a look at the updated patch.

I've tried to follow all of the comments during the review.

There's some information here if you haven't found it already: https://wiki.freebsd.org/Phabricator

No, I haven't seen it yet - thanks for sharing! What's a preferred way to create a revision: via command line or web interface?

Would you be willing to create a new phabricator review for the change?

I've re-worked this patch and opened a PR at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251053.