good catch! would you mind adding a note in the code about this so it's not accidentally removed in the future when someone tinkers with compat stuff?

oh oops! ok sorry yes please test it. i missed that!

wait ignore me. There already IS stuff in sys/dev/intel/

oh one final comment - please put the code in sys/dev/intelpmc/, matching sys/modules/intelpmc/ .

I'm going to land this today unless someone has any last minute objections!

nice work!

address copyright/dates

update to include fixes to build on both 32 and 64 bit platforms

rebase/update

rename ixgbe_mdio -> if_ix_mdio_hw

Thanks! Lemme test it locally and then i'll pull it into -head.

hi! i'm trying to put as much hardware specific code into if_rge_hw.c to hopefully make it easier to keep whole hardware-specific routines in sync with openbsd.

looks like this diff got the flags stuff and shuffling around where the 'struct bus_dma_tag' is defined.
I'll go clean that up shortly.

swizzle when it's done to explicitly do it for mdio/management;
add comments in the code.

Update to latest -HEAD; make it default to off w/out a hint

at the surface this looks all just fine. I trust that if you've tested it a bunch and new installs are ok, I think we're ok.

@kevlo would you mind taking a look at this? What do y'all do in openbsd for SFP+ support?

this is good work! i would like to figure out how to describe the "why" this extra stuff is necessary though, so lemme noodle on that a bit first.

Ok, i'm now actively looking at this.

Lemme see which I can delete and which I need to keep and use.

It's in here just in case i need it when figuring out WOL. I'd much prefer we figure out WOL :P

nice catch!

In D55667#1273924, @olce wrote:

(Alternative: Don't compile this on 32-bit architectures at all, if if_iwx in reality does not support those.)

also - are D55492 and D55564 supposed to be tested together in a stack? which should be applied first?

First up - the alignment should be what the hardware supports, not what the ethernet type supports. Eg, if the virtio API supports 1 byte alignment and it's not hugely inefficient to do so then that's what you should create the DMA tag with.
There's a bunch of un-fun stuff around RX alignment of buffers versus the network stack requirements - notably the IP stack will do unaligned accesses and will trip an exception if you don't enable unaligned access or handle it in said exception handler.
This typically comes up when you have hardware with 4 byte alignment requirements but you need to start the mbuf at a 2 byte offset so a non-VLAN ethernet header will result in the IP header starting at a 4 byte alignment.
(Honestly though it's 2026 and we should just finally fix the IP/TCP stack..) So just keep that in mind if you're trialing 1 byte hardware alignment and you see weird shenanigans with RX path mbufs.