LGTM, but why "half-working"? Is there BFP_MTAP on Rx somewhere?

LGTM, thanks @bz

@jhb yes, of course.

Compiled, booted and tested under load for several hours out of curiosity. Looks good to me.

@jrtc27 @bz Any comments?

re-based and updated according to the comment

Added a comment about "mod_abs"

@jrtc27 Could you comment or accept it if everything's according to your expectation?

Re-based on the latest main.

@bz I'm not exactly sure why phabricator shows diffs this way, but I don't see those lines changed between main and dpaa2 branches: https://github.com/freebsd/freebsd-src/compare/main...mcusim:freebsd-src:dpaa2

Commit message has been updated and $FreeBSD$ removed from new files only.

$FreeBSD$ removed

I somehow missed this interface sorry ...

@manu, I'll need the only method in sff_if.m for now to implement SIOCGI2C in dpaa2_ni.c. I haven't ever worked with SFF/SFP modules and not sure what registers in their EEPROM or GPIO pins have to be tinkered with in order to let them start properly. This is the reason for such a draft instead of a fully fledged driver.

Commit message's updated.

In theory this should be broken up into multiple commits: first move the code as is into extra files (no functional changes), then reduce code duplication etc, then rename variables etc without other functional changes, ... a dedicated cleanup change, ... I know this is hard and a lot of extra work. Please try to get to that in the future. It helps a lot with review, keeping functional changes smaller, also when going back in history and looking at a change again or when bisecting for other reasons.

@bz, Can I commit?

I've replaced anonymous enum with macro definitions for sizes.

I've added CTASSERT checks to all of the types which sizes are fixed or shouldn't exceed limits enforced by DPAA2 firmware.

I've removed a [DMAP_MIN_PHYSADDR,DMAP_MAX_PHYSADDR] range limit for DMA tags as @mhorne explained. Initially, I thought that it's a requirement to calculate KVA by PHYS_TO_DMAP properly.

No further comments. I didn't realize I can accept it :)

diff has been updated to provide full context.

May we have it committed?

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.