oops i need to delete this too

and this is here because i'm not quite sure yet what the preconditions should be to actually /attach/ an mdio bus to an ix interface. Let's figure THAT out first. :-)

i likely need to bump this to 2024, since the code i grabbed came from dpdk

I would like these pushed down the file quite a ways, maybe after ixgbe_if_i2c_req, and add function prototypes above as necessary.

honestly, i'm thinking of also making an if_ix_mdio.c file and just putting these in there.

(Especially if i'm going to use this as an excuse to play with clause 45 MDIO bus stuff and add those routines as i can then speak to the on-chip PHY register space and use it as a dev platform.)

Another angle.. what happens if this is exposed to a device with no mdio bus?

That would be fine too, if_bypass.c is similar in spirit as a local hack (Intel doesn't like bypass adapters..)

Yup, that's why I need to figure this out.

The linux upstream driver always attaches an mdio bus, but for the backplane chipsets it only attaches it to the lowest present backplane pci dev as it's shared between all MACs. (The firmware / hardware semaphore guards against overlapping use though.0

Is the "ixv inet" entry here required; ixv shouldn't need this file, right? I'm still not familiar with what needs to be added where in these kernel compile config files.

What happens when there's supposed to be an mdio device but it doesn't get attached here? I'm assuming the mdio driver will complain about something first, and then nothing will happen here, silently? It'd be good to find a way to see if a device is expected to have an mdio bus from within the ixgbe driver, but there doesn't seem to be a universal-ish mechanism for this like in ixl with its device/function capabilities admin queue commands.

I need to double check but I think IXGBE_MSCA_OLD_PROTOCOL can be used only with X552/X553 devices, and if I understand correctly MDIO interface is exposed for all types of HW. I wonder if it won't cause any unexpected side effects if used eg. with E610 (https://reviews.freebsd.org/D50067) which has completely new FW.

I'm not 100% sure how this will behave if another thread already acquired this semaphore. Also it guards single read/write and some operations require accessing several registers. I think you need to grab a iflib ctx lock in ixgbe_mdio_(read|wrige)reg

it /looks/ like the linux driver always attaches the mdio device, no matter what?

I'm looking at drivers/net/ethernet/ixgbe/ixgbe_phy.c : ixgbe_mii_bus_init(), which creates it for any NIC that this driver probes/attaches, and ixgbe_mii_bus_init() is called in ixgbe_probe().

So, is linux's ixgbe driver in this particular probe/attach path only supporting a subset of what ours does? Or is there something else I'm missing?

Would you mind checking? I'm comparing this to what the linux driver is doing too to try and make sure we're not deviating from what they're doing with the hardware.

Thanks!

I'm not 100% sure how this will behave if another thread already acquired this semaphore. Also it guards single read/write and some operations require accessing several registers. I think you need to grab a iflib ctx lock in ixgbe_mdio_(read|wrige)reg

I was wondering about that. Ok, lemme go find the iflib ctx lock bits and add them in here. Thanks!

Hm, the only iflib locks are /in/ iflib. How am I supposed to interact with this?

Should the mdio bus be exposed /by/ iflib first?

I would assume if you hold the fw semaphore you'd have exclusive access to the adapter.. is the worry that callers might also have requested the semaphore before calling this?

In e1000 there are some gymnastics around ASSERT_CTX_LOCK_HELD and you can see where I prod it in a similar situation for accessing the NVM with struct sx *iflib_ctx_lock = iflib_ctx_lock_get(sc->ctx).. I forget the exact details why we had to do that, it might have been related to the watchdog (which used to trip a lot) triggering stalls, but it does serialize access to the hardware semaphore.