CC @des as well

I would maybe split out the caching of the domain into a separate commit.

Kind of weird that they would match an _ADR value, but this is correct.

I'm somewhat surprised you are doing this when enumerating the PCI bus vs doing it in pcib_attach() FWIW. If the bus numbers are available for growing, that should be just as doable in pcib_attach() time before you attach drivers to child devices, and then you don't need the manual PCI config read/write code as you will have the normal device_t objects around to use with pci_read_config/pci_write_config.

I'm also working on merging changes to iw_cxgbe that should update it btw. For mthca we can find an upstream Linux commit to pull across. I think we should probably just move consumers to the newer KPI.

In D59172#1357540, @emaste wrote:

I think you should commit D52203 now, I will rebase this change after.

Done!

In D58957#1357973, @senguptaangshuman17_gmail.com wrote:

In D58957#1357961, @jlduran wrote:

While I do agree with the change, I do not fully agree with the commit message.
For me, the reason we want to remove this step is because we want to ship a NanoBSD image with the flags set just like a normal FreeBSD installation (/var/empty for instance).

will this work?

nanobsd: Remove chflags call in install_world()
     
NanoBSD images should retain file flags set by the installation process
(such as the schg flag on /var/empty) to match a standard FreeBSD
installation. Unconditionally stripping system flags with chflags -R noschg
after installworld removes these expected security flags.
    
clean_world() already takes care of clearing noschg when wiping
NANO_WORLDDIR and NANO_OBJ during clean builds.
     
Sponsored by:   Google LLC (GSoC 2026)
Differential Revision:  https://reviews.freebsd.org/D58957

Since this is a legacy-breaking change (perhaps the most significant one), we should provide an easy migration path. For example, in the commit message, we can explain that users who want to keep using sector sizes could add an s (for sector) suffix to its current values when migrating to the default plan, this is a deliberate change from strsuftoll, which uses b (for block) for that same purpose.

In D58957#1357961, @jlduran wrote:

While I do agree with the change, I do not fully agree with the commit message.
For me, the reason we want to remove this step is because we want to ship a NanoBSD image with the flags set just like a normal FreeBSD installation (/var/empty for instance).

Please see: https://github.com/Coderangshu/freebsd-src/pull/60, which contains a WIP of NanoBSD using ZFS (the ZFS part is not really relevant at the moment, it was just an experiment). It illustrates that the file gpt.sh should actually be named ufs.sh and that common functions inherent to a GPT partitioning scheme belong in defaults.sh, leaving filesystem-specific functions inside their respective files (ufs.sh, zfs.sh, cd9660.sh, msdos.sh, i.e., anything that makefs(8) supports).

Maybe something closer to:

nanobsd: Disable dumpdev

I don't think we should touch anything legacy, or at least avoid it as much as possible. In this context embedded can be considered legacy.

In D58963#1357697, @jlduran wrote:

In D58963#1357695, @senguptaangshuman17_gmail.com wrote:

In D58963#1357689, @jlduran wrote:

https://docs.freebsd.org/en/articles/committers-guide/#_focus_on_what_and_why_not_how

will this be fine as commit message?

nanobsd: Disable dumpdev

Ship by default with a disabled crash dump device, since nanobsd
doesn't configure a dump target for dumpon(8) to use.

Differential Revision:  https://reviews.freebsd.org/D58963

This has a bit of a circular reference---we're saying we disable it because NanoBSD doesn't configure it, but NanoBSD won't configure it because we're disabling it here. Let's update the rationale to explain why NanoBSD shouldn't have a dump device in the first place (e.g., read only file system, resource-constraints, etc.).

I think _xxx_pkg_db_dump_or_vacuum should be added sooner. In fact, I think this function should not be a _xxx_ function, as we will always want to verify the integrity of the pkg database before shipping our NanoBSD image, so I suggest "promoting" it to a regular pkg function (pkg_db_vacuum since it no longer dumps.) and including it in D58951.
I think the commit message in this revision also needs updating.

While I do agree with the change, I do not fully agree with the commit message.
For me, the reason we want to remove this step is because we want to ship a NanoBSD image with the flags set just like a normal FreeBSD installation (/var/empty for instance).

I think this commit can be squashed with D58951, I see no reason to keep this in a separate commit.

Hi Ronald,

In D59194#1357926, @dfr wrote:

I guess it could be a dependency of FreeBSD-ssh instead but adding it to FreeBSD-runtime covers both FreeBSD-ssh and e.g. openssh installed from ports.

This is probably fine, given the small size. I guess it could be a dependency of FreeBSD-ssh instead but adding it to FreeBSD-runtime covers both FreeBSD-ssh and e.g. openssh installed from ports.

I think the patch is fine now, but I would like to see the flame graphs anyway, so we're sure this does what we think it does.

Address review comments.

CC releng because this should go into 14.5, IMO, which might mean an expedited MFC. I think this is reasonably safe.

This is a bit more complex than I was hoping. I do wonder if we really need all of these separate callbacks, vs. one callback for the initial copyin plus the header and trailer copyins. That would require a bit more code in the callbacks but seems simpler overall.

This LGTM and also tests fine with my Yubikey. My test setup is naive, but just to document it:

@mmel this new driver is effectively the mii_fdt.c equivalent on the mdio side. From a physical perspective, my understanding is mdio is the low-level serial interface that can connect "anything", while MII is the higher level bus intended for PHYs, so MII "sits on top of" MDIO in reality, and they're separate entities in our driver architecture.

I'm also fine with it, thanks. Is the device_get_softc_class() function OK? That's actually the one I had the most trouble with.

The USB key mentioned in D57146 does work with this patch on stable/15 (132e609c2ce5c72e9e04a5d6f3e0e9140e06ebd8)
Thank you.

Oh, I did not know eqos(4) was imported from NetBSD!