LGTM

There is a lots of portlint error :
FATAL: Makefile: extra item "FLAVORS" placed in the MAINTAINER section.
FATAL: Makefile: extra item "x86_64_PKGNAMESUFFIX" placed in the MAINTAINER section.
FATAL: Makefile: extra item "i386_PKGNAMESUFFIX" placed in the MAINTAINER section.
WARN: Makefile: COMMENT is set externally to this port's Makefile, but this port is not configured as a slave port.
FATAL: Makefile: extra item "MAINTAINER" placed in the LICENSE section.
FATAL: Makefile: extra item "COMMENT" placed in the LICENSE section.
WARN: Makefile: "LICENSE" has to appear earlier.
WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "BUILD_DEPENDS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.
5 fatal errors and 5 warnings found.

In D19869#426773, @jhb wrote:

Or instead of slave ports, flavors, where each target arch was a separate flavor. In that case you would keep the port name as it was and just append ARCH to the page name as it's flavor name.

As said on irc we want multiple version of this package for each arch.
Since we also want all the edk2 arch available for all FreeBSD arch the best way is to convert the port to a master/slave scheme.
You will have sysutils/uefi-edk2-qemu as the master port and sysutils/uefi-edk2-qemu-${ARCH} for each available arch.
The slave ports will select which compiler to use based on the host and target.

LGTM.

Herald doesn't like this ...
Consider it ok from me for dts changes.

Remove myself from blocking reviewer.

In D15955#420643, @kibab wrote:

In D15955#357900, @manu wrote:

Quoting myself :
20:51 < manu> I'm not sure this is the right solution
20:52 < manu> it seems that it's cam only code
20:52 < manu__> so I don't understand why it's not in a generic function

The correct solution is implementing proper card insertion detection. This is, however, out of scope for this change. I'm just replicating the way it's implemented for mmc(4) in this driver, for now.

In D19036#417431, @mw wrote:

In D19036#417396, @manu wrote:

It looks ok for me now but could you please separate the change for drivers and GENERIC kernel config ?
Thanks.

I'll do this when commiting, no need to resubmit. I need to only check if clearfog continues to work with this.

It looks ok for me now but could you please separate the change for drivers and GENERIC kernel config ?
Thanks.

LGTM

I've just commited my mv_xhci to generic_xhci patch, now we need a proper dwc3 driver.

Just looking at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt?id=4436a3711e3249840e0679e92d3c951bcaf25515#n64
The driver needs to handle phy (and we need a phy driver), the arasan,soc-ctl-syscon property (whatever it is used for) and deal with clocks.
So for me the mmc patch is a no go for now.
I've commited my sd patch in r344626 and r344627

This miss all the ext_resources stuff (phy, clocks) but that could be added later I guess.
Don't you need to DECLARE_CLASS and DEFINE_CLASS_0 ? (This stuff was always obscure to me ...)
Otherwise looks good for me.

I don't think this is a good approach.
My goal for this is :

You missed the gate for hclk_sdmmc (in CRU_CLKGATE_CON33) and maybe more.
The SD clocks matches what I have in my patch locally.
With r344527 commited sd is faster on RK3328, I'll test on RK3399 and commit my patch after.

I have a patch locally that enable sd on rk3399, but I wanted to make the driver better before committing. I haven't check your clocks in this patch.
If you didn't test eMMC don't add it to your patch, I haven't looked at the arasan controller yet but I'm sure that if there is a different compatible it's because we need to do more work than just matching on the compatible.
Thanks

I have a local patch that I need to finish to do the switch from marvell xhci to generic-xhci, it also handle the phy properly. So I will try to do that this week and you can then rebase your work on it.
For the snps,dwc3 I think the better way is to add a different file, it's a big controller that can do a lot of thing and this doesn't belong in generic-xhci.
You also need to handle the drmode, on the RockPro64 you have two dwc3, one in host mode and one in otg mode.

The changes were commited a while ago.

Thanks, looks good for me.

accept with just the comment on removing MODULE_DRM2 from __DEFAULT_NO_OPTIONS