In D59191#1358304, @mmel wrote:

Wait a minute! It wasn't until the second reading that I realised just how different those drivers are. Perhaps it would be better to have them separately, with some shared code. I'm not sure... Sorry.

Thanks for this.
Note that we already have a driver for dwc4 which is named eqos (imported from NetBSD).
When I started to split dwc it was to support dwc4/5 but eqos was imported before I started working on it.
Could you test how does eqos compare to your driver ?
TBH I would have prefer that dwc4 support was done this way since the beginning.

What's the point of having it in base ?

Clock usage looks good for me.

In D56670#1306794, @lwhsu wrote:

I think we also want to create drm-69-kmod? My i7-1370P system works with 6.9 (so as 6.6 but 6.9 works better) but has some hanging issues with 6.12. While I'm trying to debug and provide more useful information, having 6.9 is important to me.

Thanks, will commit this soon-ish unless someone beats me.

Thanks, can you reword the commit message ? otherwise looks good to me.

Awesome.
But I don't think that we should add a new kernel option, just put everything depending on DEV_SPLASH.
Otherwise everything looks ok.

Probably fine, don't expect me to deeply review every bits :)

Thanks and sorry about this.

This will also affect -CURRENT no ? (but it's also better to use weekly by default here)

In D54289#1242003, @imp wrote:

I'd still be tempted to put it in files and just spike 32bit builds. Sure, you can put it in the config file and yhe error is delayed until you build, but that's ok imho. Lots of things in files that don't work evertwhere. No need for a files.64.

In D54289#1241834, @kgalazka wrote:

The module will build only on 64-bit arch (amd64 and powerpc64 was already there, this patch adds arm64). I don't think it was ever tested on 32-bits, and I don't have too many spare cycles to look into that.

Since the module will be built for all arch why not adding the config to sys/conf/files directly ? It's already present in files.amd64 and files.powerpc and now you're adding this to files.arm64, it doesn't make sense.

Maybe start with enabling the module for arm64 ?
It's unlikely that anyone will test adding the driver to their kernel config if they didn't tested with the module before.
Also I don't see why anyone would want the driver in the kernel if a module exists.

In D54253#1239650, @pkubaj wrote:

The real problem is mentioned here: https://wiki.freebsd.org/BjoernZeeb/Ten64

If loaded as module from multi-user we do not get the time set even if manually triggering a sysctl debug.clock_do_io=1. Reason for this is that vfs_moutroot() is responsible to have the clock set and calls CLOCK_GETTIME() indirectly so that log files or other timestamps do not appear to go backwards (if no RTC is found it'll use the vfs root node date?). Look for the inittodr() call.

That's clearly not the way to go, finding the real problem is what you need to do.

In D54193#1238097, @ivy wrote:

please include

Fixes: 436618a427b4 ("etc/mtree: Add package tags for /usr/include")

so we can undo these changes later once we have a better solution. otherwise, looks fine.