This will need a __FreeBSD_version bump.

Where do these values come from? Do they match anything native? Do we want at least a comment which ones are considered "to be fixed"?

I would assume this is to be passed in by a Makefile but let's keep it here for now.
I have no idea what it means if they don't agree with our native ones or with what Linux thinks of it.
A comment in the commit message about if they are Linux or FreeBSD or matching versions would likely be good.

@imp if you could have a glance, better now? Otherwise I'll commit this the next days.

In D55976#1280369, @zlei wrote:

Tested with a copper interface and SFP+ with a DAC.
media: Ethernet autoselect (10Gbase-LR <full-duplex>)

With a DAC module the media shall show 10Gbase-Twinax ? The LR / SR is for optical modules if I understand right.

@imp this is mostly just to glance at if you think the names like this would be fine.

Maybe get D55845 in before this one?

Ok, with my above change and the sbuf_clear() from the other review and your two changes I believe dumping all readable entries from rtw88 works.
I have not yet tried the write path.

Not sure if this should be applied to the old style first as well and then this one on top. Either way it needs to be fixed to avoid the -EFAULT.

So I think the only one thing here is the sbuf_clear(); In theory that should go in by itself upfront; be my guest to just do it; Reviewed by: bz

In D55833#1278447, @jhb wrote:

Ok, so with seq_file fixed, I am now able to build all the debugfs bits in the wireless drivers under CHERI, so I think this finds all of them. I've split out the changes to use simple_read_from_buffer into a separate commit before this one now.

I'll get back to you within the hour.

I managed to test and my memory was correct though I couldn't find it Friday;
there's more sbufs out there which now need to be changes I assume, e.g., sys/compat/linuxkpi/common/src/linux_seq_file.c

I need to go ans see what all is affected by this to see what I have avail to test in wifi land. I'll try tomorrow; I don't think I'll still make it tonight.

See comment about why I accepted this.

The drm-kmod part is here; I hope it still applies cleanly otherwise I have a branch https://github.com/freebsd/drm-kmod/pull/398

I would highly advise to not try to run this on a desktop yet (unless
just to see how much it works in a throw-away BE).

In D54901#1275378, @imp wrote:

My profuse apologies for sitting on this so long...

@imp ping6.

I believe some wireless drivers also do have special handling for this or for rman. I have a lot more troubles with <linux/delay.h> though and still not found a working solution without conflict.

Hi,
sorry for the delay. It's easier if the comments are marked "done" so we do easily see what's still open.